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.

1. 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.
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

2. 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
o If the rough plan holds then the team delivers a product at the set time
with the agreed upon scope and quality
o The only problem is that in complex product development, the initial
rough plan will almost never be accurate
o 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
o 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
o If they make it without problems – awesome
o 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

3.  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?

4. References
[1] Carrot and Stick
https://en.wikipedia.org/wiki/Carrot_and_stick
[2] Self-determination theory
https://en.wikipedia.org/wiki/Self-determination_theory
[3] Drive
https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motiv
ates_Us
[4] Cynefin
https://en.wikipedia.org/wiki/Cynefin_Framework
[5] The Scrum Guide
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
[6] Temporal Motivation Theory
https://en.wikipedia.org/wiki/Temporal_motivation_theory
[7] Emergent Design
https://www.mountaingoatsoftware.com/blog/agile-design-intentional-yet-
emergent