Dec
03

I’m not a Bottleneck! at XP Days London

TOCatXPDayLondon2005_1Rob 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.

TOCatXPDayLondon2005_2Rob 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

Dec
03

The Toyota Way at XP Days Germany

TheToyotaWayMarc Evers and I hosted a talk and workshop on the “Toyota Way” at XP Day Germany 2005.

The session contained two parts. In the first part we gave an overview of the 14 principles outlined in the book. In the second part, participants were asked to tell which principles they had experienced. For each principle, they had to tell a short story to the other participants in their working group. Their experience could be positive or negative, indicated by putting a green or red sticker on the card that represented the principle.

Here’s the tally of experiences that we collected:

Principle Green Red
Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals   1
Create continuous process flow to bring problems to the surface 3  
Use “Pull” systems to avoid overproduction    
Level out the load (Heijunka) 1  
Build a culture of stopping to fix problems, to get quality right the first time 2  
Standardized tasks are the foundation for continuous improvement and employee empowerment 2  
Use visual control so no problems are hidden 4  
Use only reliable, thoroughly tested technology that serves your people and process   1
Grow leaders who thoroughly understand the work, live the philosophy and teach it to others    
Develop exceptional people and teams who follow your company’s philosophy    
Respect your extended network of partners and suppliers by challenging them and helping them improve 2  
Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu) 4  
Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly 2  
Become a learning organisation through relentless reflection (Hansei) and continuous improvement (Kaizen) 2  

What can we learn from this very summary overview?

  • Many people recognized the principles. There are only three principles without examples. Interestingly, there’s no example of the “people” processes to develop exceptional leaders and teams.
  • Most of the stories got green stickers. Participants found these principles useful. Or maybe they prefer to tell positive stories.
  • Two principles got a red sticker: the “long term philosophy” and “use only reliable technology” principles. We didn’t have the time at the session to go into the stories, but I’d love to hear the story behind those. If the participants who told those two red stories would like to share them, let me know.

I enjoyed the session. We got lots of questions and debate during the presentation. Some people even called my implementation of some of these principles “extreme” 🙂

I’m particularly happy that the participants recognized these principles in their own work. We can all use management techniques, because we’re all managers, even if some of us only manage ourselves.


Update 11/12/2005: Andreas Zwinkau blogs about the session (in German).