Scrum Teams Do Not Have To Deliver Features Every Sprint
Perceiving Scrum as a delivery framework will ensure mediocre results.
Perceiving Scrum as a delivery framework will ensure mediocre results.
Originally published in GoRetro
You read it right. Not every Sprint must end in features.
How do you perceive Scrum? Do you see it as delivery or an agile framework?
A flawed understanding traps teams and limits their potential. The faulty perception that Scrum is a delivery framework will ultimately ensure the team won’t go beyond watered-down results.
Whenever you observe one of the following situations, you’ve got a warning sign shouting at your face:
Stakeholders expect Scrum teams to deliver features every single Sprint
Everything is good when velocity is increasing; the moment it decreases, you are troubled
Handing over activities is the status quo. Somebody outside the team defines what to do and hands over a pre-defined solution to teams
Product Owners must sign off tasks done by developers
Software engineers are expected to code. They are measured by the output they create
Bug-free is the ultimate definition of quality, even though some “bugs” may never happen and cause no hassle for real end-users
Following processes is more important than figuring out alternatives for creating value faster
Do these points ring a bell for you? For me, they trigger a fire alarm. I’m picky about it because I’ve been in all of these situations before, and it sucks to fall into these pitfalls.
Let me walk you through common misperceptions and alternatives to escape from them. I hope that can generate insights that help you in your scenario.
Scrum Isn’t a Delivery Framework.
I’m a calm person, and only a few things can derail me. One of them is diminishing Scrum teams to delivery teams. That’s a massive misconception of Scrum, and it will set the team in a pointless direction.
Many companies perceive Scrum teams as responsible for the execution, and they have no saying in the direction. They must ensure features are delivered on time and as specified. That isn’t Scrum at all, that’s waterfall, or Waterscrumfall.
To understand Scrum better, let’s have a quick look at the Scrum Guide.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
1- A Product Owner orders the work for a complex problem into a Product Backlog.
2- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4- Repeat
I think the biggest misunderstanding comes from this sentence, “The Scrum Team turns a selection of the work into an Increment of value during a Sprint.” People may interpret all Sprint ends up with features. But wait a moment, does that mean features guarantee value?
No feature will guarantee value without end-users benefiting from it.
The Sprint should be used to create value. Self-managing teams should organize themselves to uncover what yields value and what doesn’t.
When teams get themselves too busy with the implementation, they miss the mark. The goal is not to create more output but more outcomes.
Scrum Can Be a Bad Choice
People often approach me to learn to do Scrum better. So I try understanding them and give some tips. Common questions I get are:
How could we improve our performance?
How could we be more efficient?
What are the tricks to increase velocity?
How could we be more predictable?
How could we reduce our risks?
Such questions disturb me. They don’t represent a value-driven mindset but a fixed one. When I get these questions, I realize the company might be using Scrum without knowing why they are using it in the first place.
Whenever someone asks me how to do Scrum better, now my first question is, “Why do you do Scrum?” The answer to this question often surprise me, and I quick realize Scrum was a bad choice.
Don’t do Scrum when your goal is solely related to:
Increase output
Increase predictability
Improve performance
You will be disappointed and make people frustrated working with Scrum.
“What you’re really seeing is Agile for delivery, but the rest of the organization and context is anything but Agile.”
― Marty Cagan
Beyond Features
It might take companies a while to understand, but eventually, management realizes that a prescriptive roadmap doesn’t go beyond pleasing internal stakeholders. They notice that more features doesn’t mean more value, and something is wrong with how they work.
When companies get interested in a life beyond features, they will evolve their mindset and start thinking about creating value over developing features. That’s the moment Scrum can shine.
Scrum has better chances of yielding valuable results when:
Top management is frustrated with the current results
Executives are ready to empower teams to pursue goals over meeting deadlines
Innovation becomes more important than avoiding failures
Exploring opportunities is better seen than mitigating risks
With such motivation, Scrum teams will have the required support and room to do what’s needed to create value.
Doing Scrum goes beyond developing features. It’s about being comfortable with the uncomfortable and curious to uncover the unknown. Solid Scrum teams take responsibility from end to end and focus on doing whatever it takes to create value for end users and businesses.
“The objectives do not need to cover every little thing the team does, but they should cover what the team needs to accomplish.”
― Marty Cagan
Despite the possibilities Scrum brings, I must warn you there’s no shortcut for agility. The journey will be challenging; you will hit the wall, fall, get mad and frustrated, yet you’ve got to stand up and keep moving forward. You will continuously face resistance; some stakeholders will push you for features, predictability, and deadlines. You cannot avoid that, but with support from leadership, you can help them understand how to work with Scrum.
Final Thoughts
The Scrum Guide insists there’s an increment at the end of every single Sprint and that should be your goal, but don’t limit the word “increment” to features. Here are some examples of potential increments:
Validate or falsify a set of critical assumptions of your business model
Uncover real end-users jobs and pains
Collect evidence that justifies investing energy into an initiative
The main point is that Scrum teams must be cross-functional and accountable for results. They work as a self-managing team eager to solve end-user problems.
Real Scrum Teams start with the end in mind and work backward to create value. They may not know the path but are ready to embrace the unknown and navigate uncharted waters.
Waterscrumfall teams don’t have any goal to achieve beyond matching precise requirements defined by someone outside the team. They are afraid or unempowered to go through unknown paths.
Your goal should be to become a real Scrum team, but the truth is that not all organizations are ready for that. Yet, don’t be powerless, do your best to influence the leadership to understand the importance of empowerment and going beyond features.
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊