Documente Academic
Documente Profesional
Documente Cultură
Steps” in action
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”.
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.
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.
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:
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.
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.
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.