The power of deadlines: Asking critical questions and making tough decisions

For a long time I have expressed my disapproval of deadlines in agile software development, because in my opinion they cause unnecessary pressure and stress in the teams. With a few exceptions, such as a legal requirements with a fixed date, most deadlines seem artificial and arbitrarily set. So why should a team possibly burn itself out and work to exhaustion just to achieve an imaginary goal?

One of the things that matters in agile software development is delivering value at a steady, sustainable pace, i.e. explicitly not exhausting yourself (e.g. through overtime or technical debt) in such a way that a team has difficulty delivering in the future or takes a long time to recover from. These have been my thoughts on deadlines so far.

In the past few years, my perspective has changed: Deadlines can help a team.

The great danger of not having a deadline and clear expectations from the outside is that critical questions are not asked and hard decisions are postponed further and further. The much needed prioritisation and cutting of unnecessary extra bells and whistles does not happen. There is no reason to focus because the scope is arbitrarily large, or at least perceived as such.

Deadlines force teams to ask critical questions and make tough decisions.

The “Fixed Time, Flexible Scope” principle aims to do exactly that. Projects are completed within a fixed time frame, while the feature set (scope) remains flexible. The team is responsible for continuously adjusting the prioritisation and actual functions and features to deliver the maximum value within the given time frame.

By keeping the time constant and adjusting the scope, the team can focus on the most important functions and thus provide better added value for the client, while drastically reducing the risk of getting lost.

So far, so good. Of course, this only works if the team has the freedom to make these decisions and is able to manage itself and set hard limits. If the team does not have this freedom and these skills, there is a real risk of burning out. Many teams have a lot of work to do at this point, firstly to develop the necessary skills in the team and secondly to build the trust of the stakeholders (more on this in an upcoming article).

If, on the other hand, this fixed framework does not exist, Parkinson’s law applies: “Work expands to the exact extent that time is available for its completion”.