This article originally appeared in the December 2012 edition of Web and PHP magazine and is republished with permission.

Many web design firms work on too many projects simultaneously.  When these firms start using agile software development practices, it forces them to look for different solutions to develop and meet the needs of their customers.  This article presents ideas to consider if you want your web development teams to focus on one project at a time.

Let me guess, you work in a small web design firm and are working on ten projects simultaneously.  Your management team heard about Agile, thought it would be cool so they decided to hop on the bandwagon but somehow, it is still taking forever to deliver a single project?  Are you feeling overwhelmed?  Is it a frustrating situation for you and your team?  There is a solution you know, it starts by imagining what could happen if you focused your people on one project at a time.

I worked with a few small companies in the last few years and before transitioning to using Agile practices, they used to spread their efforts across all their projects pretty much at once depending on which customer screamed the loudest.

Do you really need to focus on all these projects at once?  The answer I usually get when I ask this question is because there is a need to meet customer commitments, but I found that often the real challenge is in how to properly manage customer expectations.

Figure 1 below shows the problem with working simultaneously on multiple projects is the high cost of context switching between each project.  Each time team members switch projects, they must remember where they last left off and put themselves back in context.  What may seem like a ten to fifteen minutes to get ready for your day actually has a multiplier effect when you touch many projects in a day.

Figure 1 - Effect of task switching on efficiency

Figure 1 – Effect of task switching on efficiency

There is no magical answer for the number of projects a development team should simultaneously work on, because it depends on the size of the projects and the team.  In one context, you have your team of five or six people working on two websites at once. In a different context, the same team of five or six people may be working on a single large website.

The ability to share and spread work among team members on a single project is one of the factors that may help you decide.  For example, you may not benefit having the entire team working on a single project if team members would step on each other’€™s toes doing that.  For the sake of this article, let’€™s assume the entire team could work on the same project an entire sprint.  For you agile newbies, a sprint is a two to four week period of time during which your team works together to deliver a working piece of functionality.

Accepting that possibility, the next question to ponder on is how long should that team focus on that single project?  Is it a good idea to focus the team on one project for multiple consecutive sprints?  Should the team focus on a different project every sprint?  This is where properly managing customer expectations begins to factor into the equation.

The main complaint I hear around focusing on one customer at a time is the turnaround time when asking customers for feedback or data entry.  If this is your case, I suggest you consider how well you are communicating and collaborating with your customers.  They need you to let them know what you will need from them ahead of time to free up the key people that can support you.  If you continually make last minute requests, they will not be able to handle them quickly.

How can you foster tighter collaboration with your customer?  It starts right at the beginning of your project, while you are deciding how you will work together.  Begin by telling your customer you will develop their website using agile practices and this means you will want to involve them early and often during the development cycle.

Ask them to appoint someone on their side who will collaborate daily with your development team.  Depending on how open and collaborative you want to be, you may also want to invite this person to sit with your team in your office every day while you are building their website.  Let them know this person will need to make decisions on the project and you will refer to this person as the Product Owner.  Inviting a Product Owner to come work with your team every day is a powerful way to make sure your team focuses on a single customer, on a single project at a time.

The other important thing is to let your customer know when you will have a development team ready to work with them.  Give them a timeframe and explain the high level steps of your development process.  This will help them better understand when they will need to free up the Product Owner to collaborate with you.  Another benefit of having their Product Owner on-site is this person potentially has various contacts in their company that can contribute with some extra testing and data entry when necessary.

At this point, the next objection looks something like: “But I have ten projects on my plate, I cannot tell my customers I will not work on their site for a few months!”  Again, how are you managing expectations?  Do your treat your customers as your business partners?  If historically, there was a rocky relationship between you and an existing customer, you should focus on trying to fix those relationships.  You can start doing that by apologizing to your customer for collaboration issues of the past and then explaining how you would like to work together moving forward.  Your most critical challenge after this conversation will be living up to your collaboration promises.

The next thing you may want to consider is to start focusing on emptying your pipeline of current projects.  The question forces us to return to our original questions about having all the team members focusing on a single project or having the team work on multiple projects at once?  How the team shares the workload on a project remains the answer.

For the sake of discussion, let’€™s say a team has a designer, a couple of back-end programmers and a few integrators for the UI work.  What happens when you propose that the entire team swarm and work together on a project?  Are they protective of their pieces?  Do they flatly refuse because they feel they will step on each other’s toes?  My first question to them would be to ask them what happened the last time they tried.

This may cause an interesting reaction because they possibly never tried doing this and they are letting a big assumption get in the way of experimenting around it.  The follow-up is to ask them to try it and see what problems they run into and see what they learn from the experience.  Assuming you have two weeks sprints, how much time would this experiment cost you?  Worst case, they will try for two weeks and stop doing it but what if they find a way to make it work?  Consider how much faster you may deliver a project if you could double the staff working on it?  You should be able to find some benefits even if you do not double your productivity.

Let’s assume you can convince your team to try it and let’s pretend as well they find issues doing it.  What next?  In these circumstances, the Sprint retrospective is the perfect place to discuss these challenges and find solutions to improve their effectiveness.  The truth is the team will never know what they need to change until they commit to maximizing their collaboration and pushing themselves out of their comfort zone.

How else can you reduce your project pipeline if you focus a team on a single project at a time?  The most obvious solution is to create more multidisciplinary teams to assign projects to.  As you staff the teams, you need to find a combination of knowledge and experience for each of the teams; this will allow them to tackle the widest range of projects possible.

You must reduce the number of projects in your pipeline before adding more new projects for the teams or at a minimum, slow down the pace for new projects coming in to allow the teams to catch up.  Once you reduce your pipeline of existing projects, it will enable you to get the teams in a constant rhythm and will allow you to more closely collaborate with customers on new projects.

Conclusion

Focusing your development teams on a single project at one time may seem like a crazy idea, but it will allow your team to focus and become more predictable in the long term.  The key to allowing your teams to focus is by developing a closer working relationship with your customers.

Inviting your customers to provide a Product Owner to work onsite with your teams will force you to focus on their projects and show your willingness to be transparent with your customers.  This transparency will force you to improve your processes and may eventually provide you with a competitive advantage.

The key to being able to focus an entire team on a single project is to challenge them to do it and encourage them to focus on finding solutions to any collaboration issues they run into.  Allowing them to work separately does not foster collaboration and shared ownership of the project.

About Web and PHP Magazine

Web and PHP Magazine logoWeb & PHP Magazine dives into the latest front- and back-end developments and practices in the world of PHP and web technologies, with feature articles by industry experts and innovators. Web & PHP is a community resource, so completely free to download!  Visit our website at http://www.webandphp.com.