I love books and most of the books I have today are on Agile, Scrum, or related topics like Lean, leadership or teamwork. For me, every book I read reminds me of just how much I have to learn. To be effective as an Agile Trainer and Coach, you really need to have a deep understanding of a wide range of topics. For most of us that means a combination of book learning, classroom training and hands-on experience.
That said, I felt like the Fixing Your Scrum Book by Ryan Ripley and Todd Miller is one book that can really pack a punch when it comes to gaining a deep understanding of Scrum. It provides that book learning AND a substitute for the firsthand experience. Ripley and Miller have mined their collective experience to produce a book that highlights the anti-patterns they’ve seen or experienced and the lessons learned from them. In this way, the book becomes a great boost for anyone short on experience and book learning.
I like that Ripley and Miller wrote in a conversational style with a great sense of humor. They shared their firsthand experience and offered exercises and experiments to try. And they showed humility as well as an appreciation for the difficulty that Scrum Masters face in trying to do their job well.
Disclaimer, I know Ryan Ripley. I’ve attended conferences with him, taken training from him and even connected him with some of my corporate clients. He is great and I’d like to think my relationship with him didn’t color my review of his book. Both Ripley and Miller are Professional Scrum Trainers among other things which puts them in a relatively small group of experts on Scrum.
Let’s dive in.
Book Summary for Fixing Your Scrum
My one-sentence summary of the book would be this:
Ripley and Miller wrote a book detailing all the ways that Scrum can go wrong, why they go wrong and the lessons learned based on their collective Scrum experience as developers, Product Owners, Scrum Masters, coaches and managers.
OK that is probably a run-on sentence but that is what the book provides. The book is primarily for Scrum Masters and I think that is great because there are a lot of Scrum Masters out there with little or no training and experience who don’t really qualify as “Masters” of anything. Reading this book will help them to level up and be more experienced. Even if they don’t read the book cover for cover, they can use the chapters as references for when they hit the inevitable bumps in the road.
I also think that there are Agile Coaches that would benefit from this book. Back in 2019, Agile Coach was named one of the top 25 hottest jobs by Indeed.com. I think it is still a pretty hot job and, like the Scrum Master role, one that is plagued by people who don’t necessarily know what they are doing. This book will help coaches as well.
Finally, managers in organizations that are using Scrum or interested in adopting Scrum will benefit from this book. Managers that understand Scrum will leverage it and be more supportive of Scrum Teams.
Scrum Masters, Agile Coaches and Managers all need to appreciate that Scrum is pretty easy to screw up. Hence the need for “Fixing”.
Yep, Scrum Is Easy to Screw Up
Scrum is one of those concepts that are simple to understand and yet difficult to put into practice effectively. I didn’t come up with that statement of course – many other people have said that. There are 5 events, 3 artifacts, and 3 roles in the Scrum Framework. That seems pretty simple, right? So simple that the definitive reference for Scrum, the Scrum Guide, is just 14 pages.
What could possibly go wrong? Well for one, perhaps it is so simple that many people don’t bother to read the 14-page scrum guide. Who reads instructions anymore? Men typically don’t. And those who don’t have enough time to read the Scrum Guide probably won’t make time to read this book :(.
Sure Scrum is simple, whether or not you read the short instruction manual.
The challenges come when you try to practice Scrum in an organization that is optimized to deliver using more traditional ways of thinking. Which is most organizations. Where people are treated as resources that need to be used at 100% for maximum efficiency. Where departments are siloe’d and turf battles are common. Where individuals have specialized skills and complex problems are broken down and assigned to individuals so that they solve a small part of it without a view to the entire solution.
In some ways the Scrum community created the problem back with the introduction of the Scrum Alliance and the certification of individuals as “masters”. The most popular Scrum certification training is the 2-day course leading to Scrum Master certification. Between the CSM, PSM, or one of the cheap and poor-quality knockoffs, hundreds of thousands if not millions of individuals have been trained in Scrum and anointed Scrum Masters.
Which is an unfortunate title as most graduates of these courses are not masters of anything. They know just enough to be dangerous and perhaps pass a simple test. As one of my early coaches said, new Scrum Masters shouldn’t be near a team for at least 6 months until they have hit the books (he recommended a list of over 70 books that he considered required readings for new Scrum Masters).
Unfortunately, book learning is not very fashionable these days and most graduates of Scrum Master training jump right in and act as Scrum Masters for teams. (This is better than becoming a Scrum Master without any training!)
This is the sweet spot for the Fixing Your Scrum book from Ryan Ripley and Todd Miller. Most of those newly graduated Scrum Masters will feel comfortable focusing on the team and facilitating (sometimes directing) the team through the various events in the Sprint. They are going to make some mistakes and they and the Scrum team are going to adopt some anti-patterns.
Those are the antipatterns that Ryan and Todd have shared. And I appreciate their humility in that many of the antipatterns are accompanied by a personal story from Ryan or Todd that explains why you should not do what they did.
My Top 10 Takeaways from the Fixing Your Scrum Book
When I first started reading the book I found that I was reading to look for agreement or correctness. In essence I was reading to see if I thought Ripley and Miller got it right. Once I caught myself I was able to make a shift and focus on learning. I was able to let go of anything that I thought I already “knew to be true” and just read for understanding and knowledge. And of course that really opened me up to gain some new insights.
I highlighted a lot while I was reading. I noted what jumped out at me, what impacted me and areas where I found myself thinking, YES or AHA!
I can’t possibly share all the notes that I had. So let me focus on my top 10 takeaways though I would also say that if I read the book again in six months my top 10 list would probably be different.
#1 – The Sprint Goal – The descriptions of how and why to use the sprint goal were great. Ripley and Miller mention Sprint Goal over 100 times in this book and they dedicate a section of Chapter 2 Why Scrum Goes bad to “Lacking Goals”. I am a little embarrassed to say that I was never great at supporting teams to leverage Sprint Goals. It could be that it wasn’t covered in the CSM training that I took back in 2014 and none of the mentors and coaches that I worked with emphasized it to me. I fell into the trap where the Sprint Goal was to complete all the PBIs which is a no no.
A Sprint Goal is a singular objective that describes the purpose of the sprint.
#2 – Coaching Managers and the organization – Coaching managers and the rest of the organization is an important part of the Scrum Master role. It was never my strength and actually something that I wish I had made a priority as a Scrum Master. The book reminded me to use powerful questions and the WIIFM orientation to learn what managers value or fear.
[Check out this related post about Using Inception for Agile Coaching that was inspired by reading Chapter 8: Management.]#3 – Effective Development Teams – This is an area that I think a lot of organizations struggle with. Many organizations don’t see how to possibly have dedicated teams when they have so much work. Or the existing organization structure doesn’t support cross-functional Scrum teams because of specialization.
Advocating for true development teams is a worthwhile goal. That means teams that are dedicated and that have all the skills necessary for end-to-end delivery. It may not be enough just to say they are needed, you may have to develop a business case for them.
Miller shared the story of a team that had architecture code review as part of their definition of done. After doing some exercises to map out their development process and collect some data, the team could see more clearly where there was a bottleneck caused by the Architecture team. They proposed that the Scrum team take responsibility for the code reviews and that was accepted by upper management.
Scrum can provide a lens into or insights in why your org structure does not serve your customers or products very well. If you cannot form effective teams, you may want to ask why.
# 4 – Blaming and Complaining – This was mentioned in Chapter 15 Retrospectives though the concept is applicable at all times. Blaming and complaining are red flags that there is something wrong. As a Scrum Master or coach, your job is to help the team and not simply pile on with your own complaints.
You need to be aware of the dangers of complaining. It builds a culture of negativity and helplessness where problems aren’t solved, but are only discussed. Steer the conversation back to how the Scrum Team can own the impediment or issue they’re discussing.
— Ryan Ripley and Todd Miller, Fixing Your Scrum (2020)
#5 – Special Sprints – While I am not a fan of special sprints like hardening, design or testing sprints, I didn’t see them for what they are – a desire for the team to leverage sequential or waterfall ways of working. Sprint zero is one of the most popular of these special sprints. Here is what Ripley and Miller say about Sprint Zero:
The problem with having a sprint zero is that the team establishes a precedent of allowing special types of sprints that don’t deliver business value. If the development team’s goal for a sprint is creating a product backlog, they’re obviously not delivering a potentially releasable increment during that sprint. When business value isn’t on the line, teams can be tempted to extend sprint zero a few days, weeks or months. As a Scrum Master, if you allow these behaviors, you’re opening the door to the team using similar arguments in the future when delivery is on the line.
— Ryan Ripley and Todd Miller, Fixing Your Scrum (2020)
#6 – Liberating Structures – Ripley and Miller reference Liberating Structures several times in the book, particularly in the Coaches Corner section at the close of each chapter. The techniques are great for including everyone and breaking patterns of thinking or behavior.
The book was written before COVID and some of these exercises required adjustments to work with remote teams. Perhaps Ripley and Miller will provide Miro or Mural templates for these exercises as part of the second edition of the book.
You can learn more from the Liberating Structures website.
#7 – Clapping or Cheering During Sprint Reviews – I’ve seen stakeholders clap or cheer for the team during sprint reviews before and never gave it much thought. Ripley and Miller point out that the purpose of the Sprint Review is for the team to have frank and sometimes tough conversations about the product. On the surface, clapping or cheering when the team does something that the stakeholders like seems innocuous. But the downside is if that the team may orient to those extrinsic rewards rather than the intrinsic rewards that come from mastery and autonomy.
It is important that the Scrum Team set clear expectations with stakeholders as to why the stakeholders attend sprint reviews. It’s not an event designed to punish or reward the Scrum team. Rather, it’s an opportunity for the stakeholders to inspect what’s happened, provide feedback, and decide what to do next.
— Ryan Ripley and Todd Miller, Fixing Your Scrum (2020)
#8 – No Failed Sprints – I use to say this all the time – you are going to fail the sprint. By that I meant that they were not going to complete all the PBIs. I was reminded by the authors that there is no such thing as a failed sprint. That’s right, we need to remove the phrase failed sprint from our vocabulary.
Every sprint is an opportunity to learn something about the product, your organization, and the complexity of the work that you’re doing.
There is no such thing as a failed sprint, just an undesired outcome that we can learn from with stakeholders.
— Ryan Ripley and Todd Miller, Fixing Your Scrum (2020)
What I love about this statement is “learn from with stakeholders”. This is a great reminder that the stakeholders are not our adversaries. Everyone is on the same side, the same team.
#9 – Don’t Cancel the Sprint Review – Cancelling a Scrum event is a no no, in case you were wondering. In fact, none of the Scrum Events should be canceled. The Sprint Review is one that is easy to skip and there are numerous reasons given as examples.
Don’t skip the Sprint Review. Doing so reduces transparency and feedback and it could postpone a tough discussion to a time when it will be even tougher. It could also lead to a wasteful sprint:
We learned the hard way that canceling even one sprint review could result in the team heading in the wrong direction, because we didn’t have timely input from stakeholders.
— Ryan Ripley and Todd Miller, Fixing Your Scrum (2020)
#10 – Trust is Essential – The authors mention the word trust nearly 50 times in the book. Clearly trust is important for the Scrum Master to be effective. You cannot coach or influence without trust.
But the authors take it one step further and link transparency to trust:
Without trust, you can’t have transparency. If the members of a Scrum team don’t trust each other or an organization doesn’t trust a Scrum team, then it’s impossible to make the team’s work and progress evident to stakeholders. Instead, people play defense: they blame one another and fail to work as a truly collaborative team.
— Ryan Ripley and Todd Miller, Fixing Your Scrum (2020)
And trust is especially important between the development team and the broader organization:
An important component of Scrum, and one that impacts all the practices and principles of it, is building trust between the organization and the Scrum team. Having stakeholders attend sprint reviews helps build that trust, especially early in a product-development effort.
— Ryan Ripley and Todd Miller, Fixing Your Scrum (2020)
The best way to build trust? Deliver. You can bank good will by delivering, one sprint at a time.
What is Missing from Fixing Your Scrum
There isn’t much to say here as I think the book does a great job providing the insights to avoid the anti-patterns. I could only think of two things that would have made the book better.
First, the book was published prior to COVID. With remote work so prevalent now, many of the coaching exercises as well as the physical task board just don’t work as described. As an old guy, I still prefer being face to face. However, it doesn’t seem like remote work is going away any time soon and the book could reflect that.
It would not take a lot of work to provide a corresponding version of these for remote teams. Perhaps the second edition of the book could include the Miro/Mural equivalents of these exercises or even provide them as a value-add download.
Second, I personally think not everyone is cut out to be a Scrum Master and that could even be a section. The book reads as if it will help anyone to be a better Scrum Master. Unfortunately, I have met many individuals who came up in other traditional roles including management, project management and business analysts. They don’t belong in this role if they continue to cling to other paradigms or worldviews. This would include those who like to talk of “hybrid agile” or Scrummerfall. They see the world through a different lens and haven’t really understood the agile mindset well enough to embrace it beyond simply paying it lip service.
So I would recommend the authors include a section that speaks to this. Perhaps it could be called, “Are you sure you are cut out to be a Scrum Master?” for them to better understand that hey, perhaps they just aren’t a fit for the role
Finally, I initially thought that there could be more content in the book for managers and leaders. Doing so might water down the impact for Scrum Masters. Plus, Ripley and Miller are probably already working on the sequel for managers and leaders.
Wrapping it Up
I highly recommend this book and I am going to add it to my top 5 recommended books for Scrum Masters for 2022!
I think this is a great book for all Scrum Masters and Agile Coaches and it will be particularly useful to those that are new and lacking experience. I think the sweet spot is those with less than 8 to 10 years of experience.
Hat tip and thank you to Tom Cagley for prodding me more than once to read it!