When To Slack + What it Gives Us

This is the second in a series of posts, beginning with Slack--we're Not Slacking Off!

We need slack in order to be creative, to maintain a sustainable pace, and to improve. So when should we slack? To answer this, we need to understand the costs and benefits of slack.

What is its cost?

Zero. Apparently, on Ilja Preuss' team, they schedule a full day of slack once per month, and they see no drop in velocity for that week. Our team aims for a full day per week of slack, and I'd say we get an increase in velocity for that. Based on this statistically insignificant sample size, I have to say that slack is free or value-producing. So last week in retrospective we decided to call slack our default activity and label card work a side-job. We said this was to emphasize the "research" part of our R&D group, to make sure everyone knows they're supposed to be coming up with innovative, even disruptive, ideas. I admit the idea of full-time slack is a bit extreme, so let's keep holding on to the one-day-per-week goal, 50% of the time.

What are the benefits of slack?

• Beck, in XP Explained 2nd ed, talks about slack as a way of making sure we meet our commitments--it is about transparency and building trust.
• Slack gives the Product Owners perspective on the health of the code and of innovation. If all developers do during slack time is refactor, we can ask if they're taking on too much work (and creating technical debt). If they're tweaking functionality they worked in the past, we may need to look at functional debt. If they're creating entirely new prototypes, then we only need to monitor the feedback cycle on these ideas to be sure the value is qualified before much is invested. Near the end of the iteration when I see people hovering around the story wall looking for something useful to do, I know they're not overworked--and when I see them starting prototypes, I know the iteration buffer is big enough.
• When the team reaches slack before the end of an iteration, they can share in success together--maybe they were lucky, or maybe they worked together well, but in either case, it's a success. The value is two-fold: the iteration work is Done-Done (and hopefully deployed and generating business value), and the team bonds are stronger.
• DeMarco says slack is a way to give employees control. Dan Pink talks about why control is important--motivation comes from autonomy, purpose, and mastery. So giving employees control is a way to keep them happy, motivated, and productive.
• Retaining our employees, as the Toyoda family and DeMarco have noted, is the most significant means of avoiding huge drops in productivity.
• DeMarco talks about being too busy, the myth of total efficiency, the impact that no slack has on change... we are not cogs in a machine, we can't be interchanged and we can't task switch without penalty. If we don't invest in slack, we will end up being overly bureaucratic, rigid, and conservative.

So when should we slack?

• Whenever there are no more cards to work on
• Towards the middle of the week (because people are tired Friday and Monday)
• When the whole team agrees there is no useful/effective/efficient way to divide up the remaining work any further. If some people are in slack while the rest of the team is pulling in the iteration, it can deteriorate team spirit.

One team I worked with ended iterations Tuesday night--it gave a beautiful cadence to an iteration... we finished Tuesday, slacked Wednesday + had a planning game Wed afternoon, started the iteration Thursday & Friday; by Monday we came in and asked "are we at least half way through? ", then hustled our way to the end of Tuesday again. It was nice to have a weekend break in the midst of an iteration--the distance from the work gave us new insights.