Why all deadlines are bad for quality

In this article I will explore why I think that deadlines should never be communicated to the development teams, and why all deadlines are basically meaningless anyway.

Johan Hoberg, Blogger

March 15, 2016

7 Min Read

In this article I will explore why I think that deadlines should never be communicated to the development teams, and why all deadlines are basically meaningless anyway.

But to reach our destination we first have to explore a few other concepts. Let us start with motivation. Historically deadlines have been used to “motivate” employees to work harder towards a specific date. The old carrot and stick [1]. If you believe this is the best way to motivate people, then by all means, continue to set deadlines. However modern motivation research shows that this type of extrinsic motivation is far from optimal [2][3]. This is just not how you motivate employees who are developing complex products in an Agile environment. So to recap: Setting deadlines to motivate people is a bad idea. Stop doing that.

Sidebar: Temporal Motivation Theory [6]

The temporal motivation theory "models the motivating power of approaching deadlines, arguing that the perceived utility of a given activity increases exponentially as the deadline nears. These and similar ideas have been applied to the pervasive phenomenon of procrastination".

In Agile and Scrum this type of motivation is given by working in sprints, and not by setting a product delivery deadline.

Let’s move on to planning. The whole idea of being able to plan a complex product up front in a high level of detail is, to me, absurd. The word complex implies that the relationship between cause and effect can only be perceived in retrospect, but not in advance. How can you plan something like that up front in any detail? The Cynefin framework [4] tells us that we should probe-sense-respond to complex problems, and the Scrum mantra is “inspect and adapt” [5]. We need to start with a rough plan, start working and then inspect what we learn from our work and adapt to what we see. This is the only way to handle complex product development. Every plan made up front to solve a complex problem is just a best guess with the information you have when you write the plan – don’t let it dictate what you do when you later have more information about how to solve the complex problem. And to recap: Stop trying to create detailed up front plans for solving complex problems – you are just fooling yourself and others if you believe in them.

So, with this in mind, what happens when you communicate a deadline to a development team? The way I see it, a development team has three variables to work with: time, scope and quality. Of course you could add more people to the team, or add additional teams to the product development, but in the short term, this is perhaps not feasible. So when you fix the time variable, the team has two options: 1. Cut scope and 2. Cut corners. But scope is the domain of the product owner, not the development team. If the team communicates that it will not be able to handle the current scope in the set time frame, then the product owner could reduce the scope, and hopefully the team would make it, unless something unpredictable happens, which is usually the case when dealing with complexity. If the scope is also fixed, then the only other variable to change is quality.

So what different scenarios can we see happening when we communicate a deadline to a development team, who is supposed to develop a complex product with a defined scope?

The team makes a rough plan of what they will be able to do until the deadline, and communicates this scope to the product owner, who agrees with the new scope
- If the rough plan holds then the team delivers a product at the set time with the agreed upon scope and quality
- The only problem is that in complex product development, the initial rough plan will almost never be accurate
- If they still have to deliver the same scope they set in the rough plan, at the same date, then the only variable to change is quality – the team has to cut corners to make the deadline, and deliver a product at the set time, with the agreed upon scope, but with worse quality than agreed upon
- If they can continuously change the scope, then they can retain agreed upon quality levels – but this could be done without telling the development team about the deadline in the first place, through the product backlog
The team tries to implement the predefined scope within the given time frame
- If they make it without problems – awesome
- But if the scope is too extensive and they cannot make it in time, they have to cut corners to save time, which reduces the quality of the product

Sidebar: Emergent Design

When designing a complex product I think you need to take an emergent approach, as you cannot predict the complex. This makes it even more difficult to plan everything up front.

“Scrum teams acknowledge that as nice as it might be to make all design decisions up front, doing so is impossible. This means that on a Scrum project, design is both intentional and emergent. The design emerges because there is no up-front design phase (even though there are design activities during all sprints). Design is intentional because product backlog items are deliberately chosen with an eye toward pushing the design in different directions at different times.“[7]

So what should we do instead? First, let’s start with believing that the development team will work at a sustainable pace through out the product development and work to the best of their abilities. Next, let’s trust that they will work according to the priorities set by the product owner. With this out of the way we should do the following:

Make a rough plan (read: backlog) of what we want to develop
Start working from the top of the backlog
Inspect what we have
Based on what we have, update the plan (backlog) and make it more accurate
Continue working from the top of the backlog
Inspect what we have
The plan (backlog) becomes more and more accurate over time as complexity is dispersed and we explore and learn about the complex problem we face

At any given time we have developed the most prioritized features for the product at a pace we can handle – no initial detailed plan would have changed this.

But what if a stakeholder wants to know when the product will be delivered? Our backlog will become more accurate over time, but the best way for a stakeholder to know the status of the product is to come to sprint reviews and look for themselves. Then they can decide at any given time if they want to continue development, change priorities, or cancel the product.

So in conclusion: Don’t set deadlines for complex product development. Complex problems cannot be planned accurately up front, and you are not motivating anyone properly.

There is only one scenario where deadlines are good, and that is if the date is more important than the value you are delivering, and you have a predefined scope that you cannot change. But how often is this really the case? How often is it more important to release on a certain date, regardless of how the product works and what value it gives to your customers?