Why many Scrum teams struggle with continuous improvement, and how you can do better
Do your Sprint Retrospectives feel like a waste of time? Are members of your team wondering what the point is of talking about improvement when nothing ever happens? Are you struggling to improve with your team, even though the whiteboard, Mural, or desk is littered with stickies with improvement ideas? We wrote this post to help you.
If you’ve been following the content that Barry Overeem and I create at The Liberators, you probably noticed that we like to keep things practical. This is why we created 65+ do-it-yourself workshops to empower teams to tackle specific impediments and problems in their teams. We are also creating the Scrum Team Survey to help teams diagnose themselves and identify where to improve. And we purposefully added over 40 actionable experiments to our recent book, the Zombie Scrum Survival Guide.
There is a reason for this practical focus. Throughout our work with hundreds of Scrum teams, Scrum Masters, and Agile practitioners, we found that it is easy to remain stuck in the “intention”-stage of improvement, and never to reach the “execution”-stage. Lofty ideas like “involve your stakeholders” or “expand your mandate” are great. And everyone probably agrees with them. But coming up with what you need to improve is only a fraction of the work. The hardest part is to make it tangible and practical. More simply put, teams and practitioners often remain stuck in the “What?” of continuous improvement, without clearly thinking the “How?” through. Successful continuous improvements need both. But these are hard skills to come by.
In this post, we share what we learned in how to keep things practical. We also offer 3 actionable tips on how to create better improvements with your team.
Continuous Improvement: One Step At A Time
When it comes to the challenges that many Scrum teams face in their efforts to work empirically, it may seem easier sometimes to move entire mountains. But even seemingly impossible hurdles are overcome when you take it one step at a time, one day at a time. That is the heart of continuous improvement. I also believe that there is a substantial amount of skill and creativity needed to make this work.
Because how exactly do you take it one step at a time? We consistently observe that teams struggle here. Instead of keeping it small, simple, and practical, teams go for ambitious — but vague and unclear — improvements. And without a good starting point, there is no feedback and no motivation to start. So the expected improvement never materializes. All potential is lost.
“We consistently observe that teams struggle here. Instead of keeping it small, simple and practical, teams go for ambitious — but vague and unclear — improvements.”
There is a great example of this in the Professional Scrum Master II class that I created with Barry Overeem for Scrum.org. Throughout the training, we ask people to identify actionable improvements based on what they learned. For example, one exercise focuses on the Definition of Done and how it reduces the risk of complex work. When we ask people to share their action steps after this exercise, they are often surprisingly vague like “Talk about the Definition of Done” or “Involve management”. In the other exercises, people struggle to identify specific practices, creative tips, and ideas on how to a) involve more stakeholders, b) expand the autonomy of teams c) involve leadership and d) increase release frequency. Barry and I are always on the lookout for Scrum Masters that have an extensive toolkit of simple, creative, and practical actions to move things forward, or help other people to do so — these are often also the best Scrum Masters we know.
Another illustration comes from the improvement actions that Scrum teams create in our Scrum Team Survey. Here too, actions often remain unclear and vague, like “Define stakeholders”, “Go to meetups” or “Focus on Sprint Goals”. This is a pattern we also see with many of the Scrum teams we interact with.
We’ve come to call these not-really-improvements. These are improvements that only clarify intent, like “involve stakeholders”, but don’t provide any details on how that intent will be achieved. While they may sound good on a sticky, they don’t address the essential part of actual improvement; how to do it. Whenever improvements like these appear during a Sprint Retrospective, training, or in our work with Scrum teams, we know that there is work to do.
Weak improvements come with many problems. The first is that they lack any sense of scope. When someone suggests to “increase our autonomy as a team”, there is no way for me to understand what effort is involved in that. Because there is no sense of scope, there is also no sense of timeline. Should this be done by tomorrow, next week, next month? This is further compounded by a lacking sense of involvement. Who will contribute to this, when and why? It is not surprising that these kinds of improvements are not at all motivating to get started with. So what happens is that they end up on a “to-do list” and usually remain there.
At this point, we would recommend taking a look at the improvements you identified with your team during a recent Sprint Retrospective or Sprint Review. How many of them only express the intent of the improvement, but leave out the practical details of how to achieve it entirely?
“At this point, we would recommend to take a look at the improvements you identified with your team […] How many of them only express the intent of the improvement, but leave out the practical details of how to achieve it entirely?”
Create Actionable Improvements Through Refinement
So how can you do better? A common line of thought is to make improvements SMART. George Doran (1981) initially coined this acronym, and it was expanded further by Peter Drucker (e.g. 2007). The acronym stands for Specific, Measurable, Assignable, Realistic, and Time-related. While SMART is a useful set of characteristics to craft more actionable goals, we believe that they are often too constraining. More importantly, they don’t really address the issue at the heart of weak improvements.
Our experience is that weak improvements are weak when they remain too broad and unspecific on how something will be improved. Interestingly, this creates a clear connection with something else that good Scrum teams spend a lot of time on: refinement. The Scrum Guide defines refinement as “the act of breaking down and further defining Product Backlog items into smaller more precise items”. Here too, it begins with a vague and unclear chunk of work that gradually becomes clearer as it is refined and implemented. And here too, there is a substantial amount of skill and creativity required by Scrum teams to do this well. Although the Scrum framework uses refinement mostly in relation to the work that needs to happen for a product, the principles apply to improvements all the same.
So you can boost the potential for continuous improvement in your team by investing deeply in refining those improvements from vague and broad to small and specific. It is far easier to make tiny specific adjustments here and there than it is to make big and unclear ones. The fortunate reality for Scrum teams is that all those tiny incremental adjustments accumulate to large changes over time, just like all those small items on the Sprint Backlog eventually accumulate to a substantial product over time.
With that intent in mind, let's now look at some practical ways to achieve that intent.
The fortunate reality for Scrum teams is that all those tiny incremental adjustments accumulate to large changes over time, just like all those small items on the Sprint Backlog eventually accumulate to a substantial product over time.
Tip #1: Begin By Asking “How?”
We found that the single best way to create more actionable improvements is also childishly simple: consistently ask “How?” in response to suggested ideas. Or the friendlier version, “How do we/you intend to achieve that?”. Delivery is obviously important here. The best way to shut a brainstorm down is to make the “How?” come out dismissive and confrontational. So use the “How?” or “How shall we go about doing that?” to encourage teams to shift from ideas to actions.
Tip #2: Refine Your Improvements By Making Them Smaller
Although asking “How?” already works wonders, you can still easily end up with fairly large actions. An action like “We start a book club to read books about development” is already quite actionable, but it is still too large. The reason for this is that it is surprisingly difficult to descend into the particulars of improvements. This is where you really have to make things so practical that you can see what they should look like in practice. It is cognitively taxing to go into so much detail — but highly important.
So “refinement” is the key here. You have to help yourself and your team descend into the particulars by asking questions that are aimed at clarifying and reducing the scope of improvements. We’ve found the following questions helpful here:
- What does this look like in our day-to-day practice?
- Where should we start?
- Who should be involved, and how?
- When should it be done?
- Which steps are involved, and in what order?
In practice, a conversation in a team could look like this:
Team: “We should improve our deployment pipeline”
You: “How can we improve our deployment pipeline?“
Team: “We can automate the steps of the deployment process that take a lot of time and are prone to error”.
You: “Which step should we automate first?”
Team: “Let's start with integration tests for the Stripe API. This API is most prone to errors and most critical to our product”.
You (refining the scope of the “how”): “Where should we start with the integration tests of the Stripe API if we want a working first version of this Sprint?”
Team: “Let's start with a basic order for one product for a customer that already exists”.
You: “Who should be involved in making this happen?”
Team: “Sonia and Jeff have the most experience with it, and Daniel can join to learn.”
So at the end of this conversation, we have an actionable improvement. It also matches the SMART characteristics, but only because we’ve gone through a process of refinement.
Tip #3: 15% Solutions
The Liberating Structure “15% Solutions” is also ideally suited for the identification of improvements. It works as follows:
- First individually, ask people to list their personal 15% Solutions to a shared challenge at hand. Explain that a “15% Solution” is any first step that each person can take to contribute to addressing the challenge without requiring approval or access to resources they don’t have autonomy over (5 min);
- In trios, invite people to share their 15% Solutions (1–2 minutes per person). The purpose is to share ideas, not to judge or respond to them;
- In the same groups, members help refine and clarify the 15% Solutions (5 minutes per person). The purpose here is to make the 15% Solutions as actionable as possible and to make them smaller when needed. Another purpose is to explore how groups can help the individuals in achieving their 15% Solutions.
The strength of this structure lies in the focus on how each individual can contribute to a shared challenge. Through the three steps, we’ve found that participants inevitably find ways to support each other's improvements or make them even better.
Tip #4: 100 Quick Tips in the Scrum Team Survey
Finally, Barry and I worked with our community of patrons to create over 100 actionable improvements to help and inspire Scrum teams. Each set of quick tips addresses a specific area, like team autonomy, stakeholder collaboration, better Sprint Reviews, and so on. To identify which tips are probably the most relevant for your team, your team first participates in a survey. We then use the results, combined with a scientific model, to identify which areas are most likely in need of improvement. For these areas, we offer a selection of actionable improvements (“quick tips”), as well as detailed do-it-yourself workshops to address these impediments. You can use the entire platform for free, and see quick tips for up to five areas, or see all of them with a subscription.
Continuous improvement is incredibly hard. It doesn’t only require a recurring opportunity to think about what you can improve, it also requires a lot of creativity and cognitive attention to drill into the particulars of how you actually intend to improve things. Our experience is that many Scrum teams struggle greatly here, and this explains why the Sprint Retrospective so often feels like a waste of time.
- Doran, G. T. (1981). There’s a SMART way to write management’s goals and objectives. Management review, 70(11), 35–36.
- Drucker, P. (1955). The practice of management (1st edition). Routledge.