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.
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:
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.
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.
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 Gantthead.com
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.