Sprints Are Not Deadlines!
Recently I saw a discussion suggesting that Sprints are actually deadlines. Somehow this is motivating for individuals.
This type thinking is fueling the resistance to Scrum in particular and Agile in general.
Artificial Deadlines
There is a common misconception that there are no deadlines in Agile. Nothing could be further from the truth. Regulated industries, such as banking or online business, have real deadlines. Many of these come in the form of laws and regulations which you either follow or face heavy fines.
The difference is that there are no “fake” or artificial deadlines. Those are anti-patterns. They are often management, or Product Owner, promises to deliver something by a certain date. Or attempts to enforce control. Rather than being actual deadlines, these are examples of wishful thinking. Yet they are imposed upon teams as if they were deadlines.
Misunderstanding Scrum
The “Sprints are deadlines” reasoning seems to come from a misunderstanding of the Scrum Guide. Whether the misunderstanding is intentional is a distinct possibility. A holdover from Project Management or Theory X thinking.
What the Scrum Guide says:
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.
It is quite clear from this quote that the team commitment is to the Sprint Goal. They do not commit to the exact work needed to achieve it. That means they do not commit to the exact work selected during Sprint Planning. That remains flexible.
Treating a flexible scope of work as a deadline is incorrect. It also locks teams into a rigid plan by not allowing them to adapt as more is learned during the Sprint.
What the Scrum Guide also says:
As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
I’m not suggesting that you blindly follow the Scrum Guide. You adapt to context. But, you should understand the intent. What is it trying to teach you?
Each excerpt from the SG mentions adaptation during the Sprint:
- flexibility in terms of the exact work
- negotiate the scope of the Sprint Backlog within the Sprint
I hope we can all agree that having a deadline with flexible scope doesn’t make a lot of sense. So we can dispense with that line of reasoning.
The Sprint Goal provides the reason for the Sprint. Why are we spending all this money? What value does it bring?
How the team gets there is allowed, indeed expected, to flex during the Sprint. During the Sprint is when the team will discover the actual work to deliver the Sprint Goal. As work proceeds they learn more and adapt the work as necessary.
Flexibility and negotiation as learning happens. Begin with a plan to achieve the Sprint Goal. Understand that the path may change once work begins even though the Goal remains fixed. These are keys to agility. This is part of what Scrum is attempting to teach with Sprints.
Treating the Sprint Plan, as created during Sprint Planning, as a fixed scope with a deadline can have negative consequences.
Reduced Agility — Treating the Sprint Plan as a commitment with a deadline will cause teams to stick to the plan. They would rather avoid repercussions than adapt to new knowledge or changing circumstances. This delays pivoting until the next Sprint.
Cutting Corners — Quality may suffer if the team feels the “commitment” is in jeopardy. Making the deadline will take precedence.
Reduces innovation — Teams will play it safe. They will not attempt creative or innovative solutions which might jeopardize the “commitment”.
Slows delivery — Rather than take a chance they will begin to “sandbag” Sprint Planning. They will play it safe and plan less to avoid the possibility of not making the deadline.
Burned Out Teams — A deadline increases pressure and stress. Having a deadline every two weeks will cause people to burn out. Artificial deadlines will magnify these effects as people know they are fake. People will begin to find ways to leave the team. They may even leave the organization.
I hear many managers talk about “motiving” their people.
How about stop doing things that demotivate them as a first step? (then read Drive by Daniel Pink)
Sprints are Timeboxes
If you’re attempting to leverage Agile Ways of Working to improve delivery you must also change your Ways of Thinking.
That understanding seems to be the single biggest piece missing from transformations and Agile adoptions. That thinking must also change.
Sprints are ways to teach limiting scope and introducing short feedback loops. They use a timebox for these concepts.
Over a short period of time teams will learn about how much work they can complete within a single Sprint. Sometimes they will do a bit more, sometimes a bit less. The key is limiting scope to reduce distraction and provide a focus.
The Sprint also sets up two feedback cadences, the Sprint Review and the Sprint Retrospective. Both are inspect and adapt events.
The timebox defines the inspection points. Are we developing the right product is the focus of the Sprint Review. Are we working effectively is the focus of the Sprint Retrospective.
The duration of the timebox regulates risk. The longer the timebox, the higher the risk of either creating the wrong product or continuing to work less effectively.
The Sprint is an artificial construct, used to reduce risk. While it’s a necessary component of Scrum, it is not required when creating software.
What about Parkinson’s Law?
A definition from wikipedia: “work expands so as to fill the time available for its completion“
This is a favorite argument from those defining Sprints as deadlines.
Aside from being full of Theory X thinking (people are lazy) it’s another misunderstanding of Scrum.
The team does not need to wait until the Sprint Review to deliver their work. Many teams finish and release product during the Sprint.
Once teams adopt this practice, the need for the Sprint (timebox) begins to disappear. It’s an indicator the team is ready to experiment with continuous flow approaches.
While Scrum is lightweight, it’s not free. It has overhead. But that’s another topic for another day.
If you’re still treating Sprints as deadlines hopefully the information above will cause you to reconsider. Even with good intentions it’s a practice that can cause harm to teams.
If you found this article helpful, please click on 👏 and follow me for more valuable information on Agile, Lean and Book Reviews.
Until next time!
