Slack is an Agile practice (coming from Extreme Programming, or XP, which falls under the Agile umbrella) that we haven’t talked about much. What is slack? In common usage it probably has a negative connotation, as in “he has been slacking off”. But in planning for successful sprints that yield consistent, high-quality results, it is essential.
Here’s an explanation from James Shore in his book The Art of Agile Development:
“Imagine that the power cable for your workstation is just barely long enough to reach the wall receptacle. You can plug it in if you stretch it taut, but the slightest vibration will cause the plug to pop out of the wall and the power to go off. You’ll lose everything you were working on.
I can’t afford to have my computer losing power at the slightest provocation. My work’s too important for that. In this situation, I would move the computer closer to the outlet so that it could handle some minor bumps. Your project plans are too important to be disrupted by the slightest provocation. Like the power cord, they need slack”.
Slack can help us consistently deliver on our sprint commitments, and deliver high quality software. Slack goes hand-in-hand with other Agile practices such as continuous refactoring and emergent design. Here’s how it works: throughout the sprint your team follows the practices of emergent design and refactoring. Then see what your resulting velocity is. Use this velocity in future sprints, so that time for good design and refactoring is built in.
It may be non-intuitive at first, but these practices will help you go faster in the long run. Refactoring is a way to pay down technical debt. If you don’t continuously pay down this debt, the design of the code deteriorates and the software becomes brittle (hard to change). This makes you go slower. On the other hand, if constant attention is paid to design, through refactoring, the code becomes easier to change, which increases velocity.
With these good design practices built into your sprint, you have some room (some slack) when emergencies come up. In these cases, you may put off some refactoring in order to meet your sprint commitment. However, you have to use this option wisely (and rarely), or technical debt will start building again. If you find you are consistently putting off needed refactoring, you don’t have enough slack.
James Shore also said: “By varying the amount of time you spend paying down technical debt, you can assure that most iterations come in exactly on time”. Slack gives you this assurance, and also yields higher quality code with a good design, allowing you to move faster.
For further reading, see Tom DeMarco, 2002; Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.