Image from Amazon Title: Fixing your Scrum
Author(s): Ryan Ripley & Todd Miller
Publisher: Pragmatic Press
Amazon wrote:Broken Scrum practices limit your organization's ability to take full advantage of the agility Scrum should bring: The development team isn't cross-functional or self-organizing, the product owner doesn't get value for their investment, and stakeholders and customers are left wondering when something--anything--will get delivered. Learn how experienced Scrum masters balance the demands of these three levels of servant leadership, while removing organizational impediments and helping Scrum teams deliver real-world value. Discover how to visualize your work, ...
I'm working in the office and one of my colleagues asked if I could bring home two books for her since we leave nearby. One of them was titled “Fixing Your Scrum – Practical Solutions to Common Scrum Problems.” I had to read it! I'll consider that my commission for bringing it home.
The book starts out with a review of the Scrum framework. I like that it heavily emphasizes the values of Scrum. They show up in many chapters to show how different parts of Scrum relate. I also like the distinction between the framework itself and complementing practices. This shows what can be customized. For example, you need to have a standup. You don't need to have a burndown chart. Each chapter ends with “coach's corner” and ideas to try.
The book is filled with anti-patterns, stories and examples. Some I learned the hard way. I wish my team had read “why a rotating Scrum Master” is bad before starting Scrum. We stopped rotating it but could have spared us the trouble of experiencing firsthand why it isn't a good idea. And it was nice seeing what some teams consider gospel that isn't necessary. For example, they say you can decide who should come to each product backlog refinement session. (My team does this – we have smaller ones with different people depending on the topic. Then we use the first 20 minutes or so of sprint planning to review/change anything that got missed/etc).
One of my favorite anti-patterns was the various roles you shouldn't have: Scrum Lord, Scrum Secretary, janitor, etc. Very memorable! I particularly liked the message that there is no such thing as a failed sprint just an undesirable outcome that we clan learn from with the stakeholders.
The book encourages reading the Scrum Guide monthly. While that feels too often, I like the idea of reading it regularly to reflect and am going to start doing that.