Slack: we’re not slacking off!

In a technical climbing technique known as lead climbing, a rock climber, the lead, takes a calculated risk by climbing above any anchors, in order to climb higher.  This kind of climbing requires precise coordination between the lead and the second, for without slack, the lead cannot advance at all; with too much slack, a fall is more dangerous; and with too little slack the lead can be thrown off balance and fall.  (Photo Credit)

Note that it is physically impossible to climb without slack. When it comes to software, however, I’ve too often become obsessed with productivity, moving cards, increasing velocity, process improvement, and delivering business value, to the point I optimized out all slack.  It’s not that I’m the only one to get lured by the “myth of total efficiency”—it is a common problem in agile and non-agile environments.  Slack is covered authoritatively in Tom DeMarco’s Slack, included in the core XP Practices in Beck’s Extreme Programming Explained, 2nd edition, institutionalized by the Pomodoro Technique, and championed by Deming and the lean school of thought using pull scheduling.  Yet on a recent discussion on the Extreme Programming yahoo list, I got the impression that my understanding of slack is a bit unique.

 

Buffer Slack and Creative Slack

Back to rock climbing—a good second will always give the lead at least some slack until the lead starts descending—triggered either by a fall or the lead calling “belay!”.  There are two kinds of slack on the cliff—the constant foot or so of buffer slack that allows the lead to move freely in the same spot.  The second kind of slack is the excess rope that the second liberates only when the lead is climbing higher.  This creative slack is given when the lead requests it explicitly, by yelling “slack!”.  This call signals that the second must stay vigilant, because it means the lead’s life now depends on correct belaying.

Just as in rock climbing, I see two kinds of slack for a software team.  The first is buffer slack—it is the down time between official work, be that work related to story cards, administration, or meetings.  It is work that happens when we’re waiting on someone else or we’re not yet ready to take on new work.  Buffer slack is what gives us time to reflect and to consider the larger context of what we’re working on.  We might fix a bug, or refactor some code that was out of scope of our last story, but that we just happened to notice.  It doesn’t require communication with the team because it won’t impact them or the goal of the iteration.

Creative slack is analogous to climbing higher on the rock face—it requires a bit of forethought, a consideration of the feasibility and impact of the next few moves.  Creative slack requires a significant investment and focus before one can start advancing. It allows us to improve our current technology, to build prototypes of potential new features, and to consider strategic moves for the product. I’m not giving license here for YAGNI or  BDUF.  It’s just that we can’t make significant gains without some forethought. Creative slack happens when the team explicitly schedules it; on my current team it’s the time between iterations, and it is typically 15% of our work week.

It’s funny that I didn’t discover the second kind of slack in the software realm until I came to France.  Buffer slack happens naturally, unless we over-optimize our process.  So when I intentionally left some room for it on my team in Philly, I thought I had slack—and I did—buffer slack.  Yet our retrospectives in Philly identified a problem—a lack of innovation—that we weren’t sure how to fix.  Our product owner insisted that any time he heard a good idea, he wrote it up on a card and scheduled work on it when he saw fit, so he denied that innovation was suffering.  What I didn’t realize is that we needed to schedule creative slack for the whole team.  When I joined my team in France, with the standard 7-weeks vacation, 35-hour work week, 2-hour long lunch breaks, there was a lot more natural buffer slack.  So when we started nailing iterations early, all the buffer activities were already done.  I noticed that the end-of-iteration slack was creative in ways that simply was not possible in buffer slack.  It was a new kind of slack: creative slack. I’m not the only one to have learned about Slack from the French culture of working to live instead of living to work.  Though he is a native Pennsylvanian, DeMarco studied here in France, at the University of Paris.  Maybe that’s why he knows so much about slack.

Note: Though important for recharging, non-work activity (returning a personal phone call, lunch break, evenings and weekends), is not slack in my opinion.  Slack is not the same as slacking off.

 

The Published Discourse on Slack

One of the main reasons I was attracted to Extreme Programming, when I first read about it in 1999, was the idea that we can do good work without overtime.  In Beck’s Extreme Programming Explained, 2nd ed., he explains that slack is about building trust—about keeping our iteration commitments.  This is obviously buffer slack.  James Shore builds upon the buffer concept by saying that it's the variability in problems that determine how much slack we need.  In the Pomodoro technique, we learn to pause every 25 minutes.  Why?  Partly to make sure we're doing what's important.  In my opinion, this is buffer slack too—it is still focused on the tasks at hand, rather than uncharted territory.

Though not specifically labeled creative slack, DeMarco’s work touches upon the idea, by identifying that if you don't have slack, you can't take risk, because there's no room for recovery from failure.  He also says that the more optimized you are, the less slack you have, and the less you're able to change.  Both risk-taking and change are likely to lead us into new territory, and is therefore, what I’d call, creative slack. 

 

Unanswered Questions

I have a lot of questions about what to do with creative slack.  Apparently Google requires that employees demonstrate a proof of concept before they are allowed to invest significant amounts of slack time in a project.  My team is not doing that—all our creative slack is purely free and unmanaged.  This doesn’t seem quite right to me because some of those projects have no value to me as a Product Owner—but I do not interfere because I think the energy these projects generate gives enough of a velocity boost that it’s justifiable.  I also don’t want to kill good ideas that I just don’t understand yet.

What do you think about the following?

• Can you manage slack (like Google does, without diminishing the energy generation of slack)?
• Can you suggest items for exploration (without impacting the restorative power of autonomy)?
• Should slack be unconditional?
• Should it be a reward?
• Does discussion forum/tech news/book reading/technical exploration count as buffer slack or creative slack?  Or is self-improvement slack a category that should be explained here?
• How do we balance individual needs for slack with team needs?
• Is creative slack part of your job?