Responsible Slack

First published in 2017. I was trying to gather what I knew then about software development into a set of principles, a project that didn’t go much further.

The Development Principles Series started with Software is Bananas, highlighting the cost of delay and the importance of short feedback loops. Today we talk about slack.

Wiggle Room

“Do not tighten the screw at this time.” Have you ever ignored this instruction? Nothing seems to go wrong when you do it, but later when you try to put other pieces together they just won’t go. The system needed wiggle room to come together and you eliminated that wiggle room up front. And you didn’t need to eliminate the wiggle room when you did. Self-inflicted error.

When you’re working alone, all you need to prioritize effectively is to work on the most important thing until either it ships or it’s not the most important thing any more. As development grows (as measured by the number of people involved), person-to-person dependencies appear and then team-to-team and organization-to-organization dependencies.

The first strategy for managing dependencies is always Dependency Breaking. At some point, though, the tradeoff between breaking and managing tips in favor of managing [need to think about this tradeoff]. What makes for a good dependency?

• Short. Dependencies are bananas too. The longer they last, the worse they taste. If you can trade off duration with expense, consider paying for the shorter dependency. For example, I like pairing across a dependency even when it feels micro more expensive.

• Clear. The clearer the interface across the dependency the better. Clarity often conflicts with duration. You can spend more time making the (assumed) interface clearer. The clearest interface is the one in production.

• Certain. If my team is depending on your team, I want to be damn sure you’re going to deliver because if you don’t I’m hosed. Works the other way around to. If I commit to providing a dependency I want to be damn sure I’m going to deliver.

The key to making dependencies work is wiggle room, slack. If I accept a dependency on your team, I want to see slack in your schedule. I don’t care about your earliest possible ship date if absolutely everything goes perfectly. Irrelevant.

Similarly, if I commit to a date I want to be absolutely sure I can hit it. The only way to be absolutely sure of a date is to be absolutely sure of the day before that, and they day before that, and pretty sure of the day before that.

Slack contradicts our culture. Reach. Stretch. Who knows what’s possible? Aim high. Don’t limit yourself. These are helpful sentiments while exploring, less helpful or actively harmful while extracting. By the time you’re extracting, you know a fair bit about the constraints in your environment. Pretending ignorance won’t help.

So What?

If you are preparing a schedule, build in slack.

If you are depending on a schedule, identify the slack before passing on the commitment.

If you are reviewing a schedule, ask where the slack lives. If there isn’t any, ask what happens if an appropriate amount of slack is added. If the consequences of slack aren’t acceptable, either cut scope or get over it.

Further Reading

Critical chain project management makes the case for project-level slack instead of task-level slack. Other CCPM assumptions don’t hold here, but it’s still useful way of thinking.