Multi-tasking

Multi-tasking can be a problem at a couple of levels. From an organizational point of view, people can be allocated to multiple projects. This could be two different releases, it could be a new release vs. support of an old release (for more on this topic, see this blog entry), etc. Working on multiple projects causes several issues.

First, it affects productivity. See this link for more on this topic. The gist is that there is a tremendous amount of time wasted when you have to constantly switch contexts.

Second, it can make it hard to understand what the priorities really are. Forcing people to balance between projects will often result in misalignment with priorities (as they will focus on the squeaky wheel or the part that they can make the easiest progress on or the "funnest" one).

Third, it blurs responsibility. It makes it too easy to blame the other project. It makes it too hard to judge what a fair expectation would be.

Fourth, it can give an inaccurate portrayal of how fast projects should be moving. For example, if you have 8 people on a project, but each is only 20% on the project, then it is only really 1.6 people. If you include the penalties of context switching, it is less than that (potentially much less). So the sense is that the team isn't working out, when in reality it is the lack of focus that is the issue.

Finally, it can increase overhead. Take the previous example. Generally, you want your agile team to have roughly 6-10 people or so. 8 people falls in that range. But you're going through all the overhead (meetings, etc.) and only getting a little over a person worth of work. Scale to 24 people with the same ratios. Now you're getting maybe 3 or 4 people's work, but you're paying a penalty for the overhead of 3 teams. In this example, if you focused people on a single project at a time, you would only pay the overhead of 1/2 a team.

Now, say you heed the above advice and you ensure that people on a team are only focused on one project at a time (reallocating as needed on iteration boundaries). You can still have a problem within the project if people are taking on multiple things at once. Your best bet is to take on the highest priority item, see it to completion and then take on the next highest priority item. Given that not everyone can work on a single item, this might be the top items instead of top item. Taking this approach will ensure that you get the most important things done in the iteration rather than making some progress on a lot of things, but completing none.

Bottom line:

• Work on one project for the iteration
• Change projects only on iteration boundaries
• Within an iteration, focus on one thing (the most important thing you can help with) at a time