Why all deadlines are bad for quality
Download as DOCX, PDF3 likes914 views
The article argues against setting deadlines for development teams, asserting that they can harm quality and are ineffective motivators for complex product development. Instead of adhering to fixed timelines, teams should adopt a flexible and emergent approach, relying on iterative planning and adjustments based on progress. Ultimately, the focus should be on delivering value rather than meeting arbitrary deadlines, as this enhances product quality and aligns better with agile methodologies.
![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](https://image.slidesharecdn.com/whyalldeadlinesarebadforquality-160315083440/85/Why-all-deadlines-are-bad-for-quality-1-320.jpg)
![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](https://image.slidesharecdn.com/whyalldeadlinesarebadforquality-160315083440/85/Why-all-deadlines-are-bad-for-quality-2-320.jpg)
![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](https://image.slidesharecdn.com/whyalldeadlinesarebadforquality-160315083440/85/Why-all-deadlines-are-bad-for-quality-4-320.jpg)
Why all deadlines are bad for quality
- 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