About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2005.Mar.29 Tue
The concept of Slack I got from DeMarco's book is that fast responsiveness to unplanned work requires people who do not have their schedule filled to 100% capacity.
In Theory Of Constraints, we learn that scheduling extra work for any part of the system that is not the constraint will not improve the flow through the system, and may even slow down the entire system. Thus only one part of the system - the constraint - should be scheduled at 100% capacity [if that can be safely done], and other parts of the system should be idle some of the time in order to synchronize flow with the constraint.
In my tour of the Toyota-managed NUMMI auto plant. I noticed that there is very little buffering... parts arrive in shipments as often as 4 times a day and get used up the same day. Hundreds of small groups of people work on the line: each group has 83 seconds to do their part of the job on each car that moves down the line. The members of a team ring the bell/electronic-music-chimes if they need their team leader to help - and those chimes are going off almost continuously [not the same team every time]. But the line hardly ever needs to be stopped, meaning that the help from the team's leader is quick enough and effective enough to fix whatever problem that came up within that 83 seconds almost all the time.
I did not see people running or otherwise acting in a hurry at NUMMI. It looks like none of the people I saw were scheduled to fill 100% of their 83 seconds with constant work. (Some of the welding robots maybe, but there were few robots). Eighty-three seconds is a short iteration with very small buffers, but after decades of eliminating waste and improving the process, Toyota can take advantage of such short iterations.
See also James Shore on Slack and Scheduling and More on Slack.