More on Slack

The discussion on slack roils on at the xpe2e list. It's even spread to the main XP list now. My position hasn't really changed, but I had the opportunity to clarify it. For your viewing pleasure:

To summarize my position:

  1. Slack is important because "shit happens," not because "our estimates suck" or "we don't learn from the past." Slack is for when there's an exceptional event, like Joe getting sick, the integration machine dying, or a snow day.
  2. Slack should always be present and rarely used.
  3. Slack allows you to absorb life's little surprises. That's good for trust, it's good for morale, and it's good for throughput.
  4. Slack should be important but not urgent. You should be able to set it aside at a moments' notice. Silver stories are neither important (by definition) nor can they be set aside easily. Silver stories: yuck.
  5. Combine (2) and (4): Many XP practices count as slack. The constant capability improvement, for one, and sustainable pace, for another. Hard drive crashed and took a day to repair? Stay on target by setting aside the rest of that database refactoring until the next database story comes along, and work a few late hours for a couple of days.
  6. (5) only works if we respect the "rarely used" part of (2).
  7. You need more slack the more chaotic your project environment is.
  8. Explicitely scheduling slack (as in, "we need 20% slack") seems wrong somehow. Instead, be aware of how things that *are* scheduled can be *used* as slack when slack is needed. So include capability improvement in story estimates and explicitely call out things like continuous learning and sustainable pace.

My position, not necessarily the right one. :)

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.