Rob Westgeest and I ran the I’m not a Bottleneck! I’m a Free Man! session on the “Theory of Constraint’s 5 focusing steps” at XP Day London.
We had rather a large group, so instead of the usual 7, we played the session simulation with 14 people or 7 pairs.
You can see the first run of the simulation on the left. Notice how
- some people are very busy, most notably the two people in the middle who have to fold the boats. Half finished work starts to pile up in front of them.
- some people are idle and look a bit bored, like the people at the end of the production line. They only receive some work once in a while, most of the time they’re waiting for input.
As per the simulation’s design, the ‘programmers’ in the middle of the team are the bottlenecks. Our first round programmers didn’t seem to be very happy about that.
Rob and I then introduced the “5 focusing steps” to optimize the system. We chose one of the optimization steps and ran the simulation again with 14 other people. This let everybody experience the simulation and avoided the “elevation by experience” effect.
This time, the team produced one more boat/hat pair (their primary goal) and consumed a lot less paper (their secondary goal). As expected.
But we also saw some unexpected stuff happening. This time round, all of the player roles were idle some of the time. In a system with a bottleneck, we expect the bottleneck never to be idle, because every bit of work wasted at the bottleneck is wasted work for the whole system. Why did this happen? Maybe the players in front of the new bottleneck (design, just in front the programmers), over-optimized the second goal (don’t waste paper) at the expense of the primary goal (fold more paper boats and hats). By doing this they “starved” the bottleneck.
We had some more discussion of the 5 focusing steps. Usually we do this first part in one hour. At XP Day London we had 90 minutes. Instead of stopping when the material ran out, we continued, trying to fill the extra 30 minutes with some extra material on Throughput Accounting. That was a mistake, because the participants (and presenters) got very low on energy. We should have listened better to Tim Lister’s keynote where he wondered why projects never finish early…
In the second part, 4 volunteers played “customers” who wanted some help with their process. The other participants played newly graduated “Theory of Constraints consultants” who wanted to make a lot of money help their customer.
Some observations:
- most “customers” felt that their “consultants” had really helped them to see their situation and options more clearly.
- I thought most of the “consultants” really had trouble following the focusing steps “slowly”, but wanted to jump ahead to the solution before understanding the problem. I have this problem too. That’s why I use the 5 focusing steps: they force me to slow down and think carefully.
- One customer said that the goal of his system was to “implement “. It’s not uncommon in “real life” that customers bring in a consultant to “just implement my solution”.
Programmers often complain that “customers don’t know what they want“. For consultants, a customer “who knows what they want” is the most dangerous kind. Whatever you do, never implement this solution, unless you’ve made sure that it really is a good solution for the worst problem the customer has. If someone asks you to implement a solution, ask them first “If that’s the solution, what’s the problem?”
Simon Baker has written a blog entry about the session
