Re-Read Saturday, Fixing Your Scrum, Week 14, Chapter 14: The Sprint Review

I have heard the sprint review called everything including a demo, demo day, show and tell and sprint review. If teams and organizations do the sprint review well, I don’t care if you call it jello. Scrum defines the sprint review as a mechanism for the team to inspect what has gone on during the sprint and what was delivered in the increment with all involved stakeholders. The event is collaborative with stakeholders to generate acceptance and feedback. It is also a critical path for change management and decision-making. Sprint reviews are a powerful tool for the team and organization to ensure that what is being built, assembled, and/or configured delivers value.

Todd and Ryan point out that like any other process with humans, the sprint review can go off the rails. The authors review several common antipatterns in this chapter, yet I would raise one to the top of the list that can cause most of the other antipatterns. The antipattern is a simple misinterpretation caused by lack of training and complicated by calling the review the wrong name. When organizations adopt Scrum they often sheep dip everyone with training (mass training), customize the names of the events, and then let time work its magic. As the organization changes over time, the original mass training is forgotten and people wander away from the Scrum basics. The review becomes something it was not designed to be, stakeholders get bored, and the event gets erratic. No backstop of re-training and coaching lets the event lose value.

One of the first antipatterns tackled in the book is lack of stakeholder involvement. This is a pattern I have seen many times. Fear can lead team leads and managers to avoid reviewing the team’s work with stakeholders – feedback being equated to a mark on a leader’s blotter. The goal of the review is to generate feedback, without stakeholder participation the team is working in a very small fish bowl, which can lead to failure. Transparency is one of the core values of Scrum, involving stakeholders increases transparency.

As both the book and I have noted more than once, the product owner (PO) is part of the team. The PO plays an important role that connects the development team with the stakeholder. The PO is not a replacement for stakeholder involvement. Almost every reader of this blog has played the telephone game as a child or as an agile training game. When the PO becomes a conduit rather than a connector their biases will act as a filter for stakeholder feedback which will reduce accuracy and transparency. The PO should leverage their knowledge of the business to connect and involve stakeholders not act as their stand-in.

One of the other anti-patterns I would like to comment on (because I see it every day) is what Todd and Ryan call “The Judge.” In this scenario, the PO (or PO committee – ouch) sits in judgment of the team and gives them a thumbs up or thumbs down. In this scenario, the whole goal of the session is to get a not-guilty verdict and move on. This scenario creates all sorts of poor behavior. I have seen teams lie, cheat and steal to “pass” the judge’s scrutiny. This behavior (often called culture) yields piles of technical debt, failures of trust, and costly systems failures. Any process that causes people to hide the truth and not seek useful feedback hurts everyone involved. A few years ago on the first day of an engagement, I observed a sprint review. The product owner, the judge, rejected every piece of work that a team had done. Everyone walked away in utter and complete frustration. Discussions highlighted that the PO (and the PO proxies – another issue) and the team were not talking during the sprint. The team felt that they did not want to bother the business and the business felt the technical team did not understand the business. The lack of involvement fostered the judgment mentality at the sprint review. Without communication and interaction between stakeholders, the PO, and the development team, the judgment model will self-generate and NO ONE will be better off.

I have called the sprint review a demo and I may have thought the judgment model was a good idea 20 years ago. We need to work very hard, every day to seek feedback, listen with care, and act with good judgment. A good sprint review helps make that possible.

If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems

A quick reminder, please help choose the next book in the Re-read Saturday Series. Vote in our poll!

Previous Installments

Week 1: Re-read Logistics and Front Matter – https://bit.ly/3mgz9P6

Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad – https://bit.ly/37w4Dv9

Week 3: Breaking Bad Scrum with a Value-Driven Approach – http://bit.ly/3stGc9Q

Week 4: The Product Owner – https://bit.ly/3qpKvSn

Week 5: The Product Backlog – http://bit.ly/3cAEk9c

Week 6: The Development Team – http://bit.ly/2OLVAAs

Week 7: Embracing The Scrum Master Role – https://bit.ly/3m0HB5D

Week 8: Management – https://bit.ly/31Kv39l

Week 9: Thinking In Sprints – https://bit.ly/321wXTg