Or “Why should we control how much work we put in progress (process)?”

Let's face it: when working most people and Teams want to not only be working on important things, but also want to be seen to be working on important things. We also want to please people: our peers, our managers, etc. When one of these people come around and ask us to get something done, the natural reaction is to respond “sure, we can get that done!”.

We also too often face the situation where, if something is blocking us from getting something done, the simplest decision is to suspend that work, and take something else on. After all, “if this one is blocked, I don't want to be seen to be sitting around doing nothing …”

While a natural response, it turns out that both of these approaches actually mean that you slow down the deliver of value (or learning). What we should focus on is working things to completion, even working through things that slow us down, rather than starting something new. In other words we need to

Stop starting and start finishing!

To understand why, have a look at the chart below:

You can see there are two situations set up (top and bottom of the chart). Both scenarios show 2 Projects each of which has 3 tasks to complete.

The top of the chart shows what happens when we switch between two jobs because we have started two jobs and are now working to finish them. The “$” signs represent value: when we can either realize value in terms of dollars because we have delivered the item to the customer and they have paid for the capability, or in terms of learning because we have delivered something to the customer and they have provided feedback, allowing us to course correct.

The bottom of the chart shows what happens when the only change we make is to focus on one thing at a time, working it to completion. As you can see, because of this focus we get value (or feedback) on the first job far earlier which means we have the opportunity to accumulate more of the value over time.

Clearly the bottom approach makes more sense than the top approach, at least from the $ perspective.

Now lets look at it from a Project perspective. The top of the chart shows that Project 1 is delivered in Sprint 5 while Project 2 is delivered in Sprint 6. The bottom of the chart shows Project 1 is delivered in Sprint 3, which is way better than Sprint 5 shown previously, while Project 2 is delivered in Sprint 6 for both the top and bottom of the chart. In other words while the people on Project 2 might wish their project was favored, the reality is that by choosing to prioritize and focus Project 1 over Project 2 meant that we had a far better result for Project 1, while pretty much keeping what would have happened with Project 2.

Again, clearly the bottom approach makes more sense than the top approach, at least from the perspective of Project 1's stakeholders, and the perspective of reducing risk overall.

It turns out that the effect is even worse than this. Switching from job to job means that you are context switching. Each time you do this, the data indicates that you will take a significant amount of time to get to the point where you are actually doing productive work. The data indicates that every time you context switch, you will reduce your real ability to work on something by about 20% (see What is the Impact of Context Switching on the Ability to Deliver? for more information). What this means is that not only does the second approach give you more value or learning because one item is delivered earlier, but using the second approach both items are potentially shipped earlier due to the penalty associated with context switching.

This effect applies at all levels: personal, Team, and organization. This is not to say that an organization should only work on one thing at a time. That clearly would be silly for any decent sized organization. It does say that we should look at how much work we have is process (“WIP - work in progress”) at any given time, and work to optimize this so that we can maximize the flow of work delivered.

But, and this is a big but, there is a tendency for organizations to not control their WIP effectively resulting in a flood of work for teams and people. Many organizations have a problem saying “no” to work. Others decide to kick off projects based on funding approvals, but fail to understand what the actual capacity of the organization is to take the work on. The sad thing is that most teams if they are doing agile do a reasonable job of controlling WIP (either directly through WIP limits on a Kanban team or indirectly through the work commitment in a Scrum team). Sadly, no matter how good the teams are at controlling WIP, from a “business results” perspective if there is no control of organization WIP there will be no improvement in the organization's ability to deliver value.

• What is the Impact of Context Switching on the Ability to Deliver? for additional reasons that we should not multi-task.
• Should We Do WIP Limits Even Though We Are Doing Scrum?
• WIP: why limiting work in progress makes sense (Kanban) - Good illustration of the use of WIP limit to optimize both number of customers served (business benefit) and time to service each customer (customer benefit)
• The Resource Utilization Trap: Henrik Kniberg’s excellent demonstration of the problem of focusing on resource utilization in bringing value to our customers