Slack

Slack is the XP practice of including some work in every plan that can be dropped if the team falls behind. Not padding an estimate, which hides the buffer: naming a few items as droppable, in the open, so that a bad week costs the team the optional work rather than the commitment.

The argument is about waste. Beck’s index entry for the practice is blunt about where the loss comes from: waste created by over-commitment. A plan with no slack is a plan that can only be met by luck, and the predictable response to a plan that cannot be met is to cut corners quietly, skip the tests, defer the refactor, or work the weekend, all of which cost more later than the dropped feature would have cost now.

The counterintuitive part is that slack increases what a team is believed to deliver, because a team that hits a modest commitment every week accumulates credibility, and credibility is what buys it room. Slack trades a small amount of scope for the ability to make a promise that holds.

It has a direct partner in energized work: both are practices that decline the tempting short-term trade, and both assume that the sustainable rate is higher over a quarter than the heroic one.

Signal: this week’s plan contains something everyone agrees can be dropped, and the team has dropped it before without treating that as a failure.

Sources

• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd edition (Addison-Wesley, 2004): Slack is a primary practice in chapter 7; the book’s index routes “waste created by over-commitment” to that same page. Both are visible in the publisher’s free sample.
• Tom DeMarco, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency (Broadway Books, 2001): the general argument that an organization run at full utilization loses the capacity to respond or improve.