Mike Cottmeyer has also been talking about scaling Agile. In his recent post on Second Order Agile Scaling he talks about how important it is to reduce the number of active projects in the portfolio. In other words, the goal is to focus on finishing projects as fast as possible, not on starting them faster or keeping your resources busy. When the organization has too many active projects at a time, it overloads the system and actually slows down delivery. You will see this when you have too many applications open on your computer. One application runs fast. Two probably still run well. But if you open ten or more applications, all of them slow down.
In the last year I have seen a company with almost as many active projects as IT resources. Another company had the philosophy to start projects early so they wouldn’t get cut when the budgets were revisited. Not surprisingly both of these companies are late and over budget on almost every project. This is not a talent or process problem, it is a scheduling problem. When you overload the system, the resources start multi-tasking. My friend Steve defines multi-tasking as the intentional stoppage of ongoing work to transition focus to another task area. This is a bad plan. You want to avoid overloading the system with multi-tasking.
I have written about Multi-taking before. Several of my favorite bloggers have also discussed multi-tasking. Reforming Project Management, Focused Performance, and Clarke Ching often explain the dreadful impact of multi-tasking. Multi-tasking is bad for a number of reasons. I am drawing on my post at http://blogs.synaptus.com from March 2007 to discuss four of them here in the context of the current conversation.
One: Starting sooner doesn’t mean you will finish sooner.
Let’s say you have three people that want you to do something. To simplify this example, each thing takes three days to perform. You want to make everyone happy so you start working everything as soon as possible. You switch between them each day to continue to show progress on each thing. So your work looks like this.
Scenario 1: ABCABCABC
You deliver “A” on day 7. “B” on day 8. And “C” on day 9. In trying to make everyone happy, you pushed A and B back and didn’t do C any favors. If you had worked on these things in sequence, your work would look like this.
Scenario 2: AAABBBCCC
You deliver “A” on day 3. “B” on day 6. And “C” is still delivered on day 9. Starting sooner didn’t get work done sooner.
Two: Sometimes work needs to be expedited.
It just happens. In Scenario 2 above, you could just drop the expedited work into the queue as the next thing to do. You don’t interrupt other work in progress, and you will finish it just as fast as possible. Remember, starting it as soon as possible isn’t what’s important. Finishing it as soon as possible is what’s important. Mixing expedited work into the middle of the flow will slow everyone down. Because it takes an incremental approach and working software is delivered at the end of each iteration, Agile development enables this much better than BUFD projects.
Three: Customer requirements change over time.
When you take longer to deliver work, you raise the risk that the customer requirements will change. You want to have the shortest amount of time from when the work starts to when the work is delivered to the customer. This will reduce the risk that the customer requirements will change on work in progress. When customer requirements change on work in process, it creates rework. Rework is extremely expensive.
When you run in an Agile fashion, you will schedule epics (or big features or capabilities) into the pipeline well in advance. You have an Order of Magnitude estimate of time and cost, a general idea of what problem it addresses, and a perspective on the value of the epic (or big feature or capability) that you use for prioritization. You don’t do the detailed requirements and design until just before you drop it into the pipeline to be built. This shortened time reduces the risk that the customer will change the requirement.
Four: Task switching is expensive.
As this NY times article points out, we are not effective at getting back to productive work when we are multi-tasking. One of the tenants of lean is to eliminate waste. There are Eight Wastes defined in Lean. Multi-taking directly contributes to six of these wastes. We create Defects from forgetting what we were doing. We create Inventory from work piling up when we switch away. We create additional Processing from having to put away work and then find it again. We create Waiting (interruption of flow) and then the customer forgets what they asked for or their requirements change. We create Overproduction because we have more work started then the system can efficiently process. Finally, we create Non-Utilized Talent through the stress that is created for the developer who is always behind and having switch between tasks. Multi-tasking is a bad investment.
Following an Agile approach increases productivity because it specifically focuses on reducing these wastes. This is not accidental. When I took the Certified Scrum Master class from Jeff Sutherland he said that among other things they had intentionally drawn on proven concepts from Lean.
Excessive multi-tasking derails productivity.
Our work lives are probably impacted by most of these issues – often in combination. The multiplying effects of multitasking are devastating to performance in organizations. You can have the right people, the best processes, and a solid strategy. Multi-tasking can derail the productivity of the group. Fixing this problem can double the productivity of a work group. In reality, you can’t eliminate multi-tasking completely. This is a complex problem to address but it is worth the investment. Taking an Agile approach to work, prioritizing completion of work over starting work, and intentionally coordinating work across functions with the intention of reducing multi-tasking are the first steps.