Or “Why should we sequence our work to improve focus?”

One of the base ideas of lean and agile is to:

Stop starting and start finishing!

However, this is one of those things that are easier said than done. We typically face a number of pressures:

• Demand for more: Management in organizations, often responding to corporate pressure or as a result of a feeling that we are not getting enough for the amount we are spending, will demand that Teams produce “more”. The natural response to this is to show that we are trying to achieve this by starting more and more projects.
• Desire to please: 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!”.
• Need to be busy: 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 these are natural responses, it turns out that these approaches actually mean that you slow down the delivery 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.

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

You can see there are two work sequencing approaches have been set up, Sequencing Approach 1 on the top and Sequencing Approach 2 on the bottom. Both scenarios show 2 Projects each of which has 3 tasks to complete using a set of people (e.g. a Team, or an ART).

Sequencing Approach 1, the top of chart, shows what happens when we switch between two jobs because we have started two jobs and are now working to finish them by doing a bit at a time. From the perspective of the Projects, we are multi-tasking the Projects, and there is churn in our efforts to complete.

Sequencing Approach 2, the bottom chart, shows what happens when the only change we make is to sequence the work so we focus on one project at a time, working it to completion.

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. As you can see, because of this focus we get value on the first Project far earlier using Sequencing Approach 2, which means we have the opportunity to accumulate more of the value over time.

Clearly the bottom approach, Sequencing Approach 2, makes more sense to implement, at least from the $ perspective.

Now let's look at it from a Project perspective. The Sequencing Approach 1 (the top of the chart) shows that Project 1 is delivered in Iteration 5 while Project 2 is delivered in Iteration 6. Sequencing Approach 2 shows Project 1 is delivered in Iteration 3, which is way better than Iteration 5 shown previously, while Project 2 is delivered in Iteration 6 for both sequencing approaches. 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 we have a far better result for Project 1, while pretty much keeping what would have happened with Project 2.

Again, clearly the Sequencing Approach 2 approach makes more sense than Sequencing Approach 1, at least from the perspective of Project 1's stakeholders, and the perspective of reducing overall risk from an organizational perspective.

There another downside to working Sequencing Approach 1 versus Sequencing Approach 2. Looking at the completion dates for the first approach, you can see that the Projects almost come in at the same time. If you have downstream work from these Projects then that downstream system is about to be hit with all this new incoming demand - a surge. The surge often happens after a significant lull - no demand until the Projects complete - resulting in seemingly unmanageable peaks and troughs of this downstream effort. A classic example of this is the demand on operational systems as projects complete development in time for an end of year cutoff. On the other hand if you use Sequencing Approach 2, demand on downstream activities is smoother, more consistent, as the upstream work is delivered in a more continuously.

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 (see What is the Impact of Context Switching on the Ability to Deliver? for more information). What this means is that not only does Sequencing Approach 2 give you more value or learning because the first Project is are delivered earlier, Project 2 is also delivered earlier as there is reduced penalty associated with context switching.

What this shows is that Sequencing Approach 2 provides more capacity to the projects.

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, in addition to reducing WIP (“work in progress”), we should look at how we sequence work at any given time, especially for projects that leverage the same people or other resources, and focus our efforts so we maximize the amount of value delivered.

But, and this is a big but, there is a tendency for organizations to not control their focus 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 focus. No matter how good the teams are at controlling their own focus, from a “business results” perspective, if there is no control of organization focus there will be no improvement in the organization's ability to deliver value.

In summary, sequencing work to improve focus will:

• Allow you to deliver value or learning faster.
• Allow you to improve the use of capacity.
• Reduce the impact of surges on downstream processes, allowing for improved planning.
• Contribute to improved cycle times (time to market) and throughput (value delivery).

Not a bad return from an decisions that sequence work to improve focus.

• 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