Thinking for a Change

Where do we intervene and what do we do?

When we first start to improve processes, the situation is daunting: we can see so much that can be improved. Where do we start? What will have the biggest effect? And when we’ve done that, what do we do next?

The “Theory of Constraints” gives us a simple and powerful framework to guide our process improvement: “The Five Focusing Steps”.

Step 0: What is the goal?

The first and most difficult step is to determine (and agree on) the goal of the “System”.

Before we can do that we must determine what the System is. As a rule of thumb the System equals the “Sphere of Influence” of our Client: everything that our Client has the authority change.

To determine the goal of the System, we must ask ourselves “Who uses the results the output of the System and what do they value?”. We try to find metrics that measure the amount of valuable output we produce. The Theory of Constraints calls this the “Throughput” of the System.

On the “B” project, our goal was to release valuable features that were actively used by our users. Our measurement was the “Business Value” estimate that our onsite customer put on each User Story.

What is your system? What is its goal?

Step 1: Where is the bottleneck?

The fundamental insight of the Theory of Constraints is this: “the output of any system is determined by one bottleneck.” A chain is as strong as its weakest link. If we want to make the chain stronger, we need to work on the weakest link.

At the start of an improvement process, the bottleneck is easy to spot. A bottleneck resource is:

• Always busy. But busyness isn’t the only (or even a good) criterion by which to recognise bottlenecks. Many systems are mistakenly optimised to get high utilisation (or rather busyness) out of all resources.
• Work piles up in front of them.
• Downstream resources are regularly idle.

The development team was the bottleneck. We had a list of features that was piling up in front of us. It would take us several releases to implement our backlog. Users were getting impatient for features to be implemented and deployed.

Where is your bottleneck?

Step 2: Exploit the bottleneck

If the output of the system is constrained by the output of the bottleneck, we must first try to increase the output of the bottleneck. Any idle time of the bottleneck reduces output of the system. What can we do?

• Remove any non-value adding work.
• Remove or limit interruptions. Remove impediments.
• Let the bottleneck resource work at a steady pace.
• Provide high quality tools and materials.
• Carefully prioritise the bottleneck’s work so that they always work on the most important tasks.
• Ensure that there’s always enough work to do for the team (the backlog), so that they don’t become idle through lack of input.

As team lead, I received and prioritised all incoming requests and questions. As I could deal with most of them, the team wasn’t interrupted.

Production issues needed to be handled quickly. All issues were handled by me and one developer. The bugfixer role rotated after every bug. This provided a nice balance between keeping the team focused on developing the current iteration and ‘feeling the pain’ of production issues.

I made sure that everyone worked at a sustainable pace. No more overtime!

Warning: don’t shield the team from useful information like input from the customer, production issues, installations and feedback from users.

We start by fully exploiting the bottleneck because this type of improvement is relatively easy:

• It requires no extra cost or investment.
• Only one resource is involved.

How can you exploit your bottleneck?

Step 3: Subordinate every other decision to the bottleneck

When we’ve fully exploited the bottleneck, we must subordinate every other decision to our decision to exploit the bottleneck. All the resources that aren’t bottlenecks have, by definition, some slack. Use that slack to support the bottleneck. We can subordinate by:

• Letting the non-bottlenecks help the bottleneck or take over some required but low value adding work.
• Everybody works at the pace of the bottleneck, no faster no slower, to avoid overloading the bottleneck with work in progress.
• Those in front of the bottleneck ensure that the buffer of work for the bottleneck is always filled, but not too much.
• Those after the bottleneck ensure that they have some slack to deal with variations in output of the bottleneck.
• Non-bottlenecks ensure that only high quality work in progress handed to the bottleneck.

As team lead, I subordinated all my work to the team: whenever there was a request for the team, a production issue or an impediment, I dropped all my work and supported the team. I quickly learned that I shouldn’t commit to delivering stories. My contribution to the team was less in contributing to its throughput and more in protecting the throughput of the rest of the team.

The onsite customer performed acceptance testing on completed stories every week, so that the developers got rapid feedback on the quality and fit of their development.

The onsite customer and I prepared stories for the next iteration and release, so that the team always had something to work on.

Subordinating is still relatively easy:

• It requires no extra cost or investment.
• Only a few resources, typically those that interact directly with the bottleneck, are involved.

However, there is one aspect of subordinating that won’t be accepted easily: whereas the bottleneck resources should be fully loaded, non-bottleneck resources must have slack time to be able to support the bottleneck and deal with variations. Most managers are evaluated on the efficiency and not the effectiveness of their people. Deliberately making people work below their capacity goes against their goals. We can solve this problem by fully loading the non-bottlenecks but ensuring that a part of their work is ‘discardable’, “nice if it gets done, but not essential or time-critical”. Whenever the non-bottlenecks need to support the bottleneck, they can drop the non-essential work to free up time.

Which decisions do you need to subordinate to the bottleneck?

Step 4: Elevate the bottleneck

This is the step most people will intuitively apply first: add more people, more machines, more training, more tools, more of everything. We only take this step when all the ‘free’ improvements have been performed. We can elevate by:

• Adding more people or machines
• Training and mentoring
• Better tools, faster machines
• Switching to a different technology

My manager asked me about every week if I wanted some more developers, if I “wanted to elevate my team by adding more people”. I declined, because we had plenty of room for improvement left with exploit and subordinate improvements. I asked if we could get faster computers instead. He told me we couldn’t because the hardware budget was exhausted. But there was budget for extra developers if I needed any…

Elevation improvements are more difficult because they require an investment. Elevation improvements are dangerous because most of these improvements take some time to produce results. Results might even worsen until the improvements start to have a positive effect. For example, when we add people to a team we lower the team’s velocity and accept less work while the team members help the newcomer get up to speed.

Don’t elevate yet. I know you can apply so many more exploit and subordinate improvements.

Step 5: And again!

When we’ve applied one improvement and have seen a positive effect, we go back to the beginning:

• Is our goal still valid? Is our measurement of throughput still correct?
• Where’s the bottleneck? After some improvements we may have solved our worst problem. As there’s always a bottleneck, our second-worst problem gets a promotion. We now need to focus our attention on the new bottleneck.

And the result was…

The team got better and better by repeatedly going through the five focusing steps. After a while, they started to develop stories faster than customers could write them. That’s when we needed to apply focusing steps six and seven.

I want to know more

Read the Goldratt books about the Theory of Constraints.

Download and play the “I’m not a Bottleneck! I’m a free man!” simulation from http://www.agilecoach.net

Read more about the Theory of Constraints on this blog.