Sprinting to catch your flight
While I've done my share of traveling, I've never missed a flight. I did come close once or twice, though.
Most of us make it on board, but not because we are on time. It's quite the opposite. Most of us are terribly early whenever we need to catch a flight. Too early, like too late, is not on time.
Nobody enjoys starting their holidays waiting at the gate. But all of us understand the alternative is worse. We prefer to wait and drink an overpriced coffee in an airport bar. That's astronomically better than missing the flight.
Yet it would be ridiculous to apply this logic to every aspect of our lives. We can't be two hours early every time we go to the supermarket, just in case.
We look at the penalty for being late and plan accordingly.
We need to apply this common sense to software planning as well. While it would be great to have another week before releasing that big feature, it would be inefficient to add an extra week to every iteration, just in case.
We make a trade-off between productivity ("How much stuff can we ship?") and predictability ("When will it be done?"). Predictable plans often feel like they lack ambition. Productive plans feel like rushing it.
There must be a healthy balance.
I often see teams darting for the gates at the end of every sprint. They feel like they must keep their commitment. I see those same teams complain about "arbitrary deadlines" right before they need to keep a promise to their users. These teams are in permanent crunch mode. They reenact the Home Alone airport scene and are sure to forget Kevin at some point.
On the other side of the spectrum, I’ve worked with a team that added a "stability sprint" after every iteration. They knew they consistently missed their commitment and added another three weeks of buffer to catch up and fix bugs. That's the equivalent of being 4 hours early at the airport.
I like the airport metaphor because it gives us a good rule of thumb.
If the price for being late is high, the buffer should be big.
If the penalty for being late is low, we can try to cram in a little bit more work.
We need to actively tip the scales of predictability/productivity depending on the cost of being late.
If a feature is promised to a customer, make sure to keep a healthy buffer. It's better to wait idly at the gate than to miss your plane.
If development is just business-as-usual without any deadlines, there's no need to add additional buffers on top of the iterative buffer planning.
If your team systematically carries over tickets to the next sprint, they are rushing from gate to gate. They are sure to miss a connection soon. Plan better.
Only when your team systematically delivers ahead of time can you crank up the ambition.
We talk a lot about sustainable pace. It’s often sold as a steady cadence without ups or downs. I find that to be an impractical view of software development. Some periods will be a bit more stressful than others. That’s OK as long as our teams never enter crunch mode.
Sustainable pace doesn’t mean the same rhythm all the time. It means balancing productivity and predictability without ever having to make a last-minute dash toward the gate.