_edited.png){kind=logo}
For several years now, I have been on a crusade against deadlines that have no business value, or as I like to call them, "most deadlines." Usually, the establishment of deadlines (and the subsequent failure to meet them) is the result of planning processes that need a significant upgrade. But are all deadlines bad? Better yet, can the traditional concept of deadlines be re-purposed for agile software production?
I want to look briefly at three kinds of deadlines and give you some ideas on where they do and don't belong.
The Ex Nihilo Deadline
"Ex Nihilo" is Latin for "out of nothing." This is easily the most common kind of deadline. It exists just because.
Most deadlines fall into this category. They tend to arise from questions like, "How long do you think this will take?" or "Do you think we could have this by X?" They exist to keep the project from going on indefinitely and create an arbitrary line in the sand where people can expect delivery.
The best way to determine if you have an E.N.D. is to ask the question, "What will happen if we miss this deadline?" If the answer is mainly, "People will be disappointed," then you probably have a deadline with no actual business value attached to it. These deadlines tend to cause undue stress on your production for no particularly good reason.
A much better way to get a predictable timeline is to make projections based off your team's actual metrics. Hiring self-motivated people who do not need the threat of deadlines to be productive is also a good idea.
Verdict: Kill
The Business Value Deadline
These deadlines are very rare in the field. These deadlines exist because there is an actual business consequence for failing to meet the deadline. For instance, there is no point in finishing the Christmas Sale marketing materials three weeks after Christmas. If a new law gives you a year to bring your software into compliance, getting it done in a year and a half is no good.
In other words, you know you have a B.V.D. if the value of completing the project drops significantly or disappears altogether if the deadline is not met. If the project is still mostly valuable if you get it done after the deadline, you probably have an E.N.D. pretending to be a B.V.D. A genuine B.V.D. tells you, "If we don't get done by the deadline, there's not much reason to get it done at all (or before the next significant B.V.D.)."
These deadlines are completely legitimate, and your developers need to know when they arise and what the consequences are. In fact, if you are diligent about eliminating your E.N.D.s, you'll find your teams a lot more receptive to the genuine B.V.D.s that need to be met.
Verdict: Keep Alive, but with a Small Population
The Challenge Deadline
These "deadlines" are not deadlines at all, but rather a way a team can challenge themselves. We all like to feel the pride of getting a difficult job done in record time, and micro-challenges are a way a team can do that.
These deadlines are deadlines a team sets for themselves to get a particular body of work done. These deadlines are best when they are short and the body of work reasonably well-defined. They come from the team and are not imposed from the outside. Teams that adopt a challenge may also reward themselves for a challenge successfully met. They may keep track of successful challenges.
Challenges should be used to get a shot in the arm, but not so regularly that the team burns out. During these challenges, teams are probably working above their sustainable pace, so they should be used sparingly.
The key is that the teams themselves decide when a challenge is appropriate and what the parameters of that challenge will be. People not on the team should definitely cheer them on, but the team should not feel there are consequences for failing their challenge above and beyond what that means to them. Perhaps failing a challenge provides a great learning experience for the team. Perhaps they will discover new ways of working in a challenge that are improvements even if they don't make the "deadline." The challenge should be a fun (well, as fun as you can make such a thing) way for the teams to stretch themselves and not ulcer-inducing cauldrons of delivery anxiety.
But used appropriately, these kinds of team-driven deadlines can produce some great results and remind your teams of how good they really are.
Verdict: Keep Alive