I received this question recently:

We made some progress, but opened up another can of worms on whether or not we should have deadlines. Let me know if you have any thoughts on that one!!I spent a bit more time than usual answering the question, so I thought it might be helpful to share it here.

The key to deadlines is figuring out what you are hiring the deadlines to do.

First off, I am assuming you mean artificial deadlines. Real deadlines have a direct (and often large) economic consequence. Not meeting the deadline will seriously jeopardize some future outcome. Artificial deadlines don’t work like that. There may be an economic impact, but the link between “hitting the date” and the economic impact will be a lot more subtle and abstract.

Example: I had a deadline to renew my car’s registration by 1/1/2019. That is a real deadline. I tried giving myself artificial deadlines so as not to leave it until the last moment. I blew through both types of deadline, and decided to pay the fine if I get pulled over. Turns out the real deadline wasn’t so real after all.

A good question to discern the difference between a real and artificial deadline is to ask how much it will cost if you’re a day late. Or a week late. If that $ is big and immediate (like my fine) then it is real. If it is a small, rather incremental amount per day…then it is probably artificial. If someone can’t answer and says something like “well well, we just wanted to give ourselves a kick in the butt”…then that is artificial.

Real deadlines happen infrequently in product development (vs. project development), but they do occur (e.g. having something to show off at the annual conference). Depending on the organization, you’ll see varying approaches to artificial deadlines. The “jobs” of artificial deadlines include:

1. To “box” an investment (spending more time wouldn’t be desirable)
2. To inspire a sense of healthy urgency
3. To inspire ruthlessly cutting down scope (“don’t gold-plate!”)
4. To prevent a team from “going rogue”
5. To encourage goal setting and focus
6. To coordinate dependencies (“because I said team X would start Y on #####”)
7. To coordinate with other teams (“so you can sell X on #####”)
8. To have “something people can be held accountable for”
9. To inspire a sense of predictability and calm with “the business” In situations with lots of coordination, dependencies, etc. you’ll see more desire (and need) to “play Tetris”, which requires deadlines/estimates (6 and 7).

As with any set of needs, these all can be “healthy” or go off the rails.

Some teams use the idea of recurring cadenced deadlines (time-boxed sprints, for example) to achieve many of these “jobs”. But a good chunk of those teams ignore the true intent of the sprint forcing function. They don’t produce a potentially shippable increment. They don’t deliver thin-slices across the problem-space with each time-box. And they aren’t leveraging frequent integration for all the positive things it can deliver. In short, sprints aren’t really helping. If anything they are just overhead, which is a shame.

Sprints have been called “mini, variably scoped projects” (fixed time, variable scope), and I think this very much speaks to the healthy potential. If they are not treated that way…you have a problem. If you never revisit your work — the dreaded ship it / MVP bait and switch — you ALSO have a problem.

Another approach to artificial deadlines is having quarterly goals (or six week goals). This is honestly just an “big sprint”. It is no different. The trouble here is that two-week sprints are hard enough to get right, let alone trying to “pack” a quarter with a set of deliverables. Magically, somehow everything gets done on the last week of the quarter, as if they were all started concurrently w/o aggressive prioritization. It feels suboptimal vs. a single prioritized list and pulling items in sequence.

Then there are just plain old arbitrary artificial deadlines like “this will take 4–6 weeks, OK, let’s call the deadline 4 weeks”. This does some of the jobs above, but there are issues. It 1) encourages premature convergence 2) may be out of the team’s control, and 3) may push the team to optimize for the wrong things and make bad decisions.

Ok, where does that leave us, and what is my (John’s) opinion? First, I’ll dig out my forcing function quote:

A forcing function is an aspect of a design that prevents the user from taking an action without consciously considering information relevant to that action. It forces conscious attention upon something (“bringing to conciousness”) and thus deliberately disrupts the efficient or automatised performance of a task.I do believe in healthy forcing functions.** **Without frequent integration of ideas, expectations, learning, etc. we’ll have trouble solving problems.

Arbitrary artificial deadlines fueled by estimates are unhealthy IMHO. They don’t do the jobs above very well. I do think you need coarse-grained forecasts to inform investment decisions (your “bets”), but they can be very coarse and you need to be careful NOT to inspire premature solution convergence. Which leaves us a couple directions to consider:

1. Using time-boxes to their fullest effect (with all the benefits, and none of the theater)
2. Focusing primarily on flow while considering ways to inspire frequent integration (e.g. if an item has been open for +14d, do an immediate retrospective). In this model, you can generate forecasts by looking at actual throughput vs. point estimates and deadlines, etc.
3. In cases where we need deadlines for coordination / dependency Tetris, be very transparent about that, and consider alternative approaches. Is the Tetris playing and 3d chess really paying off? Big note: Some teams don’t use deadlines at all. To the outside this feels heretical and “completely irresponsible!” What they don’t see is that the jobs above are being accomplished in other ways, and that is a big lesson: you can do many of those jobs more safely and effectively without deadlines.

What does #1 look like? It means sticking to the spirit of the time-box. This might look a short one-week sprints (with a potentially releasable product), nested within a six-week time-box to capture more meaningful “major” items and themes. The whole point here is the fixed time / variable scope nature of the work. There is no question whether the artificial “deadline” will be hit. What goes in that release may vary though. The risk here is replacing waterfalls with whirlpools, so I always recommend something like Story Mapping to keep the big picture in mind.

What does #2 look like? The team will still use cadenced inspection, but does not adhere to a fixed time-box. You’ll need to make sure things don’t go off the rails (e.g. cadenced forcing functions like demos/retrospectives to inspect/adapt), but this is doable for some teams (often because they’re good at working small without the structure of sprints).

This might also be a good option if due to forces beyond the team’s control it is hard to “hit” a fixed time-box (e.g. case #3). In this case, “fake” sprints will obscure the actual impediment.

Of all the options, I find the variable, arbitrary estimate-driven larger batches (e.g. measured in weeks, not hours/days) to be the least effective. My advice:

Stay very focused on the “jobs” above (if those jobs even matter to you).

Finally, realize that deadlines often treat the symptom, not the cause.

Hope this helps!