The Silent Project Killer

Agile projects, especially if you are starting your agile transition, can have plenty of problems. Some are technical debt problems, such as the build taking too long or having insufficient automated tests to know if your changes are helping or hurting the system. But there’s another insidious management problem when many teams transition to agile: when the project team is supposed to work on more than one project at a time.

Sometimes, the team perceives this problem and solves it during their retrospectives. But if the team members have been accustomed to multitasking for years, they may not even realize this is a problem. Or if the team realizes that they’re multitasking, they may not know how to solve the problem. That’s when a few observations or measurements may just be what your team needs.

The Silent Project Killer

If you have people multitasking in a non-agile project, you might not know until the end of the project (or until some interim milestone) that the team members have not spent enough time on your project for far too long. But on an agile project, you can tell inside of one iteration. Multitasking slows everything down and makes people forget where they were. When developers and testers multitask, they create problems or lose track of where to look for problems.

So why do managers insist on asking people to multitask? There are two chief reasons. The first is that managers multitask all the time, so they forget that that technical work is different and that technical people can’t afford to multitask. The second is that when you have a large number of projects in progress, it’s quite difficult to decide what you are going to commit to for an iteration and what you will not commit to for now. Managing the project portfolio becomes a question of who do you offend across the organization and for how long. Managers find making those decisions difficult and uncomfortable.

Instead of taking a stand on which projects to staff when and which projects to postpone, senior managers often say, “Work longer days” or “I don’t care. You need to do all the work.” That’s a systemic obstacle. If you are an agile project manager, you have a responsibility to the team to work on that obstacle before any other. If you can’t manage that obstacle, all your estimates will be wrong. Your team won’t be able to commit to stories for an iteration. You will always have too much work in progress. Your project is a mess.

You have some choices, and the first is to gather data to show your managers how multitasking is affecting your project.

Gathering Data

Cumulative flow diagrams (CFDs) show how much work in process there really is on your project. See Figure 1 for a cumulative flow diagram on a highly multitasked project:

multitasked cumulative flow

Figure 1: Cumulative Flow Diagram for a Highly Multitasked Project

You can see that the total work in red continues to grow throughout the project because the team is unable to finish much work. There is significant pressure for more work because the team can’t finish anything. The work in process is in yellow, and there’s a significant amount of it. The team is making some progress later in the year (in the green). But if you look at the January through June time period, you can see the team finished almost nothing. They were working on a lot, but they were unable to finish work. CFDs are useful for the team and for management. The chart helps people see the effect of multitasking. Just add all the work in process that the team is working on and when the team members finish. You will be amazed.

In addition to a CFD, consider a velocity chart, primarily for the team. A velocity chart is a guide for the team to know how much they can commit to for an iteration. If team members are accustomed to multitasking, they may not realize their velocity doesn’t settle down into something predictable. Showing an unpredictable velocity and explaining that multitasking is preventing the team from estimating well might help everyone understand the problem.

In Figure 2, sometimes the team finishes a larger number of story points, and sometimes they finish many fewer. Having a range of 10 to 90 story points per iteration–as this team does–is unpredictable.

unpredictable velocity chart

Figure 2: Unpredictable Velocity Chart

Burnup charts show not just how much work is done but also how much work is being added to the project. Adding work to a project is a symptom of the project team not making enough progress for the interested parties. See Figure 3 for a burnup chart that shows how close to completion a project is and how much more work is being added.


unpredictable velcocity chart

Figure 3: Burnup Showing Insufficient Progress

Once you have data, your managers might decide to manage the project portfolio and stop the multitasking. If not, you can defensively manage it. You have several options: to decide on the project portfolio yourself; to spend one-week iterations rolling among projects, one per iteration; and to create space in the iteration for ad hoc work.

  • Defensively manage the project portfolio. If you think this is a good alternative, first gather the list of projects everyone on your team is working on. Organize them in a grid, month by month, and show when they are supposed to start and end. If you are willing, evaluate the project portfolio with your fellow project managers and decide which projects to do now and which to postpone. Use that list as a strawman for your management team to discuss. You might get it right the first time, you might not. When they have the data, your managers will find it easier to discuss what everyone is working on and suggestions for what people should work on.
  • Work on one project for a one-week iteration. Maybe you can’t decide (or your managers can’t decide) which projects to work on when. In that case, consider rotating among the projects in a one-week rotation. Each week, the entire project team works on just one project. You have a backlog for that project. You make progress on just that one project. The next week, you change projects. This is the one time that I recommend you start iterations on Monday morning and end them Friday afternoon. Monday morning, do your iteration planning and commit to some number of stories for the week. Do the work, have the demo after lunch on Friday, conduct the retrospective and use the weekend as the context switching time. The next Monday, start a new iteration for a new project. Your product owner will have to work to make sure the product backlog is ready for you when the iteration starts. It’s frustrating for the project team to only have one week as an iteration to work on a project, but your team will actually finish work instead of constantly spinning its wheels.
  • Build time into the iteration for support work. If the project team only has support for a previous release as its multitasking, you can help it make that work transparent. Make space in the iteration for “support” or “ad hoc work” and guess how many of those items you have in an iteration. Once you have data, you can plan for those problems. But if the multitasking is about other products, you need to remove that obstacle now.

Kill the multitasking, not the project.

Agile provides you the tools to end multitasking. Working in short iterations, completing work and getting to “release-able” for every iteration gives you the tools to stop the multitasking. If you are transitioning to agile, make sure you eliminate the multitasking. Everyone will be pleased by the progress the project team makes.

© 2010 Johanna Rothman. This article originally appeared on

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

4 Replies to “The Silent Project Killer”

  1. Pingback: Pragmatic Ways for Your IT Team to Deal with Technical Debt | On Technical Debt
  2. My perspective:
    CFD across project only leads to the insight described in you article, if DONE equals “Value Created”.

    For the agile teams the work item is a Value Container. When it moves to Done, Value has been created (a need is satisfied).

    For non-agile team the work item is NOT a Value Container. When a work package moves to Done, value has not been created. Eg concept work done means no value has been created, because none of the customer needs can be satisfied with it.

    Non-Agile teams typically operate on the assumption,that there is a linear relationship between time passed or tasks done (Percentage of Completion) and value created. Earned Value Management proposes if 50% of task are DONE, then 50% value was created- even if the only thing you have achieved so far is a Design, which doesn´t solve any customer problem.

    So only if DONE actually means Value (satisfaction of a need) has been realised, CFDs generate insight in mixed environments.

    1. Peter, thanks for this comment. My assumption is that done was value created because I was talking about agile teams.

      You are correct: CFDs help you see where the work is, regardless of the type of life cycle the team uses. That might be helpful, and not nearly sufficient.

      Irrespective of CFDs, multitasking kills forward momentum on projects. I bet you might agree with me on that!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.