The Hidden Cost of Deadlines

Every day, my kids tell me about a new homework assignment. They always finish the description with “and it’s due on…”; school is habituating them to think about deadlines. My wife and I have deadlines of our own, such as applying to high school for said kids, and filing taxes.

At work, deadlines are everywhere. Almost every nontrivial undertaking has some date attached to it by which it ought to be completed, released, delivered.

Have you ever wondered why we do that? And why dates always seem to matter as much as they do? Why they are so ubiquitous, that the word “deadline” is no longer reserved only for really important dates?

Some deliverables do matter only within some time window. Later than that, they are no longer needed or justified, or they negatively affect the recipient. Examples of such deliverables are current-year upgrades to tax software, development of shared components, and responding to proposals. The time window might be exactly one-day long; the work that goes into setting up elections, marathons, and trade show exhibits is like that.

The trouble, especially in a service/product delivery context, is when this situation doesn’t apply. Instead, the longer we delay the deliverable, the less valuable it is. There’s cost to the delay, so the earlier the better. But… when is that? After a (sometimes harrowing) negotiation between provider, customer, and management, a date is specified. And before you know it, that date becomes an important constraint, a “deadline” that dwarfs other important considerations.

This dynamic happens all the time. Even though there’s no pressing event or a clear window of opportunity, workers are pushed to meet an artificial date rather than strive for “earlier is better.” As a result, they — and their customer — have one fewer degree of freedom. The more work parameters are constrained, the more other parameters have to give. When constraining dates, the first parameters at risk are scope and quality; a team that’s constrained on those as well will usually trade away teamwork and individual well-being.

Agile methods are well suited for earlier-is-better, delay-has-cost situations. Collaborative, stable teams use small time-boxes and limits on work in progress to focus their energy. That energy goes to developing the most valuable elements first, constantly adjusting with feedback and learning, assiduously getting to “Done,” and planning for less. This way, they produce meaningful (though partial) results early. The more time they have, the more useful and “lovable” they can make the deliverable. They use short cycles, maximize quality, and their main lever is scope.

If the main lever is scope, when should a team stop working? Since Agile is all about customer-delight outcomes, the answer is, “Stop working when the delivered value no longer justifies the investment.” But even with all the Agile planning mechanisms, once a team associates finishing with a date, they run the risk of not delivering sufficiently useful results.

If the date is real and important — or merely a constraint they can’t ignore — they can limit the extent of change and pivoting they allow. For instance, they might choose to embrace only noncritical changes. Or, they might extend their planning horizon to better manage dependencies and reduce surprises. Both examples speak to reduced flexibility, which is a legitimate choice if the date matters more than flexibility.

However, if the date isn’t really important — the “earlier is better” scenario — then making it a deadline will do more harm than merely reducing flexibility. Since dates, like budgets, lend themselves to easy measurement and monitoring, they encourage certain behaviours. Individual contributors are likely to think “inside the box” and proceed with unvalidated assumptions. Managers may be tempted to wield dates as accountability sticks. And those timely deliveries may not be all that useful to customers.

In my experience, managers attach dates to tasks and projects more often than they should; sometimes, that’s just due to habit. Remember that Agile is all about delighting the customer (repeatedly), and the set of Agile principles constructs a framework for doing so with the most flexibility. The next time you do Agile work, make sure you don’t unnecessarily reduce your degrees of freedom.