I’ve been part of the Scrum community for about 12 years. In this period, I’ve noticed a clear pattern in the majority of Scrum-related threads on social media like LinkedIn, Medium, Twitter, and so on. As a community, we excel at putting our fingers on the sore spots of what teams and organizations do wrong. We are also very good at contrasting this with the ideal state of Scrum. The stronger the opinion, the more discussion it triggers and the more “Likes” it generates.
Some examples of good Scrum versus bad Scrum we all seem to agree on…
- The Product Owner has full mandate to make product decisions versus the Product Owner is an order taker without any mandate;
- The Scrum Master drives change across the organization versus the Scrum Master is the scribe, Scrum police, tool-master, and organizers of meetings;
- Each Sprint has a clear, specific, and compelling Sprint Goal versus for each Sprint the only goal is to finish the Product Backlog;
- Scrum teams frequently engage with their stakeholders versus the only person that engages with stakeholders — if there are any — is the Product Owner;
- Scrum teams release early and often and validate assumptions versus Scrum teams only release once every quarter and each time is a painful exercise.
The Product Owner has full mandate to make product decisions versus the Product Owner is an order taker without any mandate;
I wonder how helpful this content really is for Scrum teams. What is exceedingly clear to me is that many Scrum Masters, trainers, and consultants thrive on debating them online. But how useful is it for members of a Scrum team or an organization that actually wants to succeed with Scrum? When they read these articles, they might consider them enjoyable. They might also recognize what’s described as “bad Scrum” and agree with the description of “good Scrum”.
The problem is that there’s often a huge gap between the team's current & desired state, and most articles don’t describe how to actually bridge the gap. They also lack the nuance to allow teams to figure out how. As a result, teams only get more frustrated and wonder why they should use Scrum at all. To me, it seems that this kind of polarizing discourse is exactly what drives so many teams and organizations away from Scrum and Agile. I can’t imagine that this is what we hoped for as a Scrum community.
I believe there’s a better way to support Scrum teams. An alternative approach that’s more helpful, doesn’t compromise on the rules of the Scrum framework but also acknowledges the tough challenges many teams and organizations face. In this blog post, I share my thoughts on this alternative approach. It’s something Christiaan Verwijs and I have been working on for the past years.
Why does it matter?
If teams acknowledge that their current situation should be improved, but they don’t know how to do it, three situations might occur. 1) Scrum teams won’t look in the ‘Scrum mirror’ anymore. 2) Scrum teams fill the gap with best practices only. 3) Scrum teams only make meaningless improvements. Let’s explore this in more detail.
#1 — Scrum teams won’t look in the ‘Scrum mirror’ anymore
A popular quote from Ken Schwaber (although we have been unable to find a reference) is “Scrum is like your mother-in-law, it points out ALL your faults”. Put differently, the Scrum framework is a mirror that helps you create transparency about the state of Scrum in your team and organization. It doesn’t solve the problems but makes them painfully visible. It’s up to the teams and the organization to figure out what solutions work best in their context. This makes sense and is totally fine. But if a Scrum team struggles to improve because the organizational impediments are so tough to resolve, it becomes very frustrating to look in the mirror. Without guidance on how to improve, teams probably won’t look in the mirror anymore. The reality is too difficult to deal with.
If a Scrum team struggles to improve because the organizational impediments are so tough to resolve, it becomes very frustrating to look in the mirror.
#2 — Scrum teams fill the gap with best practices only
The Scrum framework is purposefully incomplete, it only defines the parts required to implement Scrum theory. It offers a frame or structure in which the teams can include various processes, techniques, and methods they consider useful. And this makes sense. In complex environments, there are no best practices. Each team and organization is different. Practices that worked really well in organization A, might not work at all in organization B. With complexity comes unpredictability. So teams need to run small experiments to figure out what works best for them.
I’ve never met a team that doesn’t want to improve. I have worked with many teams that don’t know how to make the necessary changes. The intrinsic motivation to improve, but the lack of knowledge on how to improve, make teams dependent on what we offer as a Scrum community. Unfortunately, chances are they’ll mostly find lots of best practices to bridge the gap between ‘bad Scrum’ and ‘good Scrum’. The Spotify Model is probably the most famous example, but other examples are the SAFe framework (which is essentially a large best practices container), or simply the use of Story Points, Sprint 0, or a Definition of Ready.
It’s not that these practices are necessarily bad, but the very nature of complex systems means that there are no “models” or “best practices”. By simply copying the (supposed) result, organizations never develop the ability to learn which is essential to solving complex challenges.
By simply copying the (supposed) result, organizations never develop the ability to learn which is essential to solving complex challenges.
#3 — Scrum teams only make meaningless improvements
I’m convinced that every Scrum team wants to improve. The problem is — as I’ve mentioned earlier — not every team knows how to improve. In addition to implementing standardized models and best practices, Scrum teams might end up identifying meaningless improvements. For example: let’s change the time of our Daily Scrum, let’s experiment with Sprints of 3 weeks because it’s too difficult to create a done Increment in 2 weeks, and let’s try a different tool for our virtual whiteboard. Although these improvements are well intended, they don’t have any significant impact on the Scrum team's effectiveness. And they don’t directly address the essence of Scrum, which is to deliver a potentially releasable, and valuable increment every Sprint.
Another example of this is what we’ve come to call “Happy-Clappy Scrum”, in our book the “Zombie Scrum Survival Guide”. Here, Scrum teams focus their energy on making the Scrum events as fun, light-hearted, and energizing as possible, leveraging the many games and facilitation techniques that can be found online. This often happens when teams cannot influence impediments or don't know how to do so, and their well-intentioned improvements remain superficial. Although there is great value in creating inclusive and engaging environments, this doesn’t help when the team is not actually inspecting their results and adapting their product and their approach based on feedback. Rather than using the Scrum events as opportunities to remove larger impediments to inspecting and adapting, the Scrum team focuses on re-energizing people to survive another Sprint amidst a wasteland of Zombie Scrum.
Happy-Clappy-Scrum often happens when teams cannot influence impediments or don’t know how to do so, and their well-intentioned improvements remain superficial.
“Don’t you do the same with Zombie Scrum?”
In our book the Zombie Scrum Survival Guide, we dive deep into what causes Zombie Scrum; something that looks like Scrum from a distance, but lacks a beating heart. Now, you might think “hey, aren’t you guys doing precisely the same with the Zombie Scrum concept?”. Yes, you can compare Zombie Scrum with the earlier mentioned “bad Scrum”, and our description of healthy Scrum is similar to “good Scrum”. The difference is that we also offer tons of super-practical experiments to help teams recover from Zombie Scrum. With these experiments, we don’t offer best practices. But each experiment enables teams to create transparency about their current situation and allows them to inspect & adapt. In addition to the experiments we describe in our book, we also created 65+ do-it-yourself workshops. Each workshop contains a fully prepared string of Liberating Structures to help teams resolve impediments and use Scrum more effectively.
With our experiments and do-it-yourself workshops, we don’t offer standardized models or best practices. We offer teams a structure to create transparency around persistent impediments, inspect the situation together, and make adaptations accordingly. For many teams, this remains challenging. Although the workshops are intended to support teams to close the gap between “Zombie Scrum” and “healthy Scrum”, it can remain difficult to decide on what the adaptations & improvements should be. What are the first steps a team could take in order to move in the right direction?
To support Scrum teams with this challenge, we developed the Scrum Team Survey, included all 65 do-it-yourself workshops, AND created 125+ quick tips! As such, the Scrum Team Survey supports teams to diagnose their current situation, inspect the results together, and identify tangible next steps and meaningful adaptations.
An alternative approach: quick tips!
We’ve found 15% Solutions to be very helpful. Gareth Morgan defines these as any first step that you can take without approval or resources from others and that is entirely within your discretion to act. It is something that you can start right now if you want to. It might not be the ultimate solution, but it’s definitely a good first step in the right direction.
In the Scrum Team Survey, we call these 15% Solutions “Quick Tips”. The purpose of quick tips is to spark small and incremental change in your Scrum team. Small steps in the right direction to remove impediments, improve collaboration, manage risk, and deliver value sooner.
“The purpose of quick tips is to spark small and incremental change in your Scrum team. Small steps in the right direction to remove impediments, improve collaboration, manage risk, and deliver value sooner.”
With these quick tips, Scrum teams can get “unstuck”. Even better, as Kent Beck puts it in his book Extreme Programming Explained: “under the right conditions, people and teams can take many small steps so rapidly that they appear to be leaping.”
Trigger BIG change by starting small with ‘15% Solutions’. We call these “Quick Tips” in the Scrum Team Survey.
10 Examples of quick tips
Let’s make it more specific with 10 examples of quick tips. Each tip is focused on a different area. As you’ll see, these aren’t the ultimate solutions for Scrum teams, they’re intended to help the team move in the right direction. We’ve learned that this is extremely powerful. Once the team gets in the flow of continuous improvement, team morale & happiness increase, and removing even the most persistent impediments seems possible!
- Quick tip to improve quality: Interview 3 important stakeholders to learn from them how you could improve the quality of your product.
- Quick tip to improve psychological safety: During the next Sprint Retrospective, ask: ‘What is a conversation we currently don’t have as a team, but really should have?’. Next, have the conversation!
- Quick tip to improve self-management: Pick one aspect of your current work method that is holding you back as a team. Stop doing it for a Sprint. Reflect during the Sprint Retrospective on what improved and what got worse.
- Quick tip to improve cross-functionality: For the next Sprint, agree to limit your work-in-progress to no more than a third of the number of members in your team and work together on those items as creatively as possible.
- Quick tip to improve management support: Take 10 minutes after your next Daily Scrum and ask ‘How can we tell if management is supporting us in the right areas? What else would be needed?’. Work together to identify 1 improvement.
- Quick tip to improve team autonomy: In the next Sprint, make 1 decision that would normally be taken by someone outside the team. Inform this person afterward.
- Quick tip to improve refinement: Vote which item on your Product Backlog is the least clear. In the next Sprint, clarify 3 of these items together with the Product Owner. Or remove them.
- Quick tip to improve team morale: During the next Sprint, work with your Product Owner to write the Product Goal on a large banner and put it visibly in the team room.
- Quick tip to improve Sprint Goals: Next Sprint, your team will politely say ‘No’ to any non-critical request that comes in that doesn’t fit the Sprint Goal.
- Quick tip to improve value focus: Share your Product Backlog with at least 3 stakeholders, ask them what items they consider the least valuable. Remove the items you can’t explain either.
All quick tips are included in the Scrum Team Survey. With this free product, Scrum teams can diagnose themselves with an extensive, scientifically validated survey and receive detailed results and evidence-based feedback upon completion. Give it a try, and receive quick tips for each of the 25 topics the survey contains!
Closing
In this blog post, I shared my thoughts on how I see many Scrum teams struggle to identify meaningful improvements. There’s often a gap between the current & ideal state of Scrum, and many teams don’t know how to bridge the gap. With our quick tips, we offer an alternative approach. A good quick tip is short & concise, actionable & specific, bold & courageous, easy to use & try. Although creating quick tips might seem easy, we’ve learned that it’s actually quite difficult. It requires a different type of refinement skills to identify small and specific improvements.
Why don’t you draw inspiration from the improvements we shared in this blog post, and use the next Sprint Retrospective to create new quick tips with your team? Even better: use the Scrum Team Survey first, and base your improvements on *real data*, instead of assumptions. If you’ve got any new quick tips: feel free to share them. Let’s learn and grow, together!