TL;DR: Webinar Sprint Review Anti-Patterns
The ninth Hands-on Agile webinar Sprint Review anti-patterns addresses twelve anti-patterns of the sprint review—from death by PowerPoint to side-gigs to none of the stakeholders cares to attend.
🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.
Update 2018-12-15: The Replay of the Webinar Sprint Review Anti-Patterns Is Available
The video of the webinar is available now:
Note: If the browser will not start the video automatically, click here to watch the replay of the webinar sprint review anti-patterns directly on Youtube.
Cannot see the form?
Please click here
Webinar Scrum Master Anti-Patterns: The Chapters
Let us start with a short refresher from the Scrum Guide. According to the Scrum Guide, a “Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.” In other words, the sprint review is not a demo but a crucial event to figure out what the next steps are: are we still on the right track?
The first episode covers not having a sprint review in the first place. All Scrum events are essential for a team’s success — you cannot skip a Scrum event. Junior Scrum teams may be tempted, though, to skip the sprint review. “Reasons” for this attitude might include:(1) More time is desired to accomplish the sprint goal. That is a bit too late. The scrum team needs to re-negotiate with the product owner if they recognize mid-sprint that they might miss the sprint goal.) (2) There is “nothing to show.” (Has really nothing been DONE? My take: This is precisely the moment to have a sprint review! Besides, it is a misperception that the team can only show frontend tasks. In my experience, you can show APIs, too, even at the command line level — give it a try and be surprised.
The second episode covers the metric-driven reporting session. Here, the team demos every task accomplished, and stakeholders do not take it enthusiastically. Remember, we are not accountants. Having a detailed report on what issues the money was spent on does not make our customers happy. There is no justification needed, think of sunk costs — the money is gone. Instead, we are interested in learning: are we still on the right track? Or do we need to change? My tip: Tell a compelling story at the beginning of the review to engage the stakeholders and leave out those tasks that are not relevant to the story.
The third episode covers death by PowerPoint. The participants are bored endlessly by a presentation. Admittedly, we need to check the backlog — but that does not equal using Jira, Excel, or PowerPoint. For example, you can re-create the current product backlog items on stickies and put them on the wall. The foundation of a successful sprint review is always “show, don’t tell.” My suggestions are as follows: Why don’t you let the stakeholders take the helm and try the new stuff for themselves? Or what about a science fair approach? (That is particularly useful for sprint reviews with more than one team. If you talk Liberating Structures, it is “Shift & Share.”)
The fourth episode covers side-gigs of the engineers. The development team increases the scope of the sprint – without prior consulting of the product owner — by adding unnecessary work to sprint backlog items; also referred to as scope-stretching or gold-plating. This ignorance may result in a questionable allocation of resources. My take: The developers and the product owner need to talk more often with each other. If the product owner is not yet co-located with the development team, now would be the right moment to reconsider this situation. Also, is there enough slack-time for the engineers? Probably, they just wanted to test new technology and got carried away. You may want to make experimentation official in future sprints.
The fifth episode covers absent developers. It is always the same few members from the development team who participate in the sprint review. The problem is that fewer participating development team members result in a reduced level of transparency. A reduced level of transparency on the engineering side may result in a flawed inspection of both the product increment and the product backlog. It may also result in an inferior adaptation of the product backlog.However, the challenge is that you cannot enforce the development team’s participation either, though. Instead, make it interesting enough that everyone is eager to participate in the sprint review.
The sixth episode covers the works-on-my-machine syndrome. The development team demos items that are not ‘Done.’ All work shown during the sprint review needs to meet the definition of done. (That provides the necessary transparency to the product owner that the team created a potentially shippable product increment the release of which is possible at any time at the discretion of the product owner.)
The seventh episode covers that no stakeholders attend the sprint review. This effect creates an unhealthy bubble for the Scrum team due to the disconnect to the stakeholders. There are several reasons why stakeholders might not attend the sprint review, for example, they do not see any value in the sprint review. Related but not identical to this notion is that they do not understand the importance of the sprint review. Or, there is a conflict with a more critical meeting. (You can’t be in two places at the same time.) In my experience, you need to “sell” the sprint review within the organization, particularly at the beginning of the journey to agility. (Bate the hook feed the fish.)
The eighth episode covers the sprint stage-gate. The sprint review is turned into a stage-gate-like approval process where stakeholders sign off features. This anti-pattern is typical for organizations that are still rooted in the industrial paradigm, exercising command & control, and often found in the “my budget, my feature“ attitude. (In this case, the organization sees a Scrum team usually as an internal agency.) Probably, there is also a metered funding approach practiced on top of this anti-pattern. In this case, I suggest to start over with your agile initiative; you are practicing Water-Scrum-Fall. (Just for clarity: it is the prerogative of the product owner to decide what increments to ship when there is no sign-off required.)
The ninth episode covers the silent treatment. The stakeholders are passive and unengaged — a tricky situation when the Scrum team wants to collaborate with the stakeholders to figure out what to build next. You can address this situation by (1) Educating the stakeholders about the importance of the sprint review event and their role. (2) Let the stakeholders drive the sprint review and put them at the helm. (3) Or organize the sprint review as a science fair with several booths. (Note: All of the suggestions require that the real stakeholders participate, not just some poor proxies.)
The tenth episode covers the omniscient product owner, a product owner without any doubt where to go. He or she does not need the team, does not require the stakeholders — collaboration would only slow him or her down. The product owner provides the “Why + How + What” at the same time. A dominant product owner plus a submissive team plus absent stakeholders is a terrible combination for inspection and adaptation and answering the “are we still on the right track” question. (Checks and balances are gone; too bad that Scrum thrives on an equilibrium of all roles.)
The eleventh episode covers the selfish product owner. Let me put it this way: there is no “I” in “team.” The Scrum team wins, the Scrum team loses. The Sprint review is a rather moment to shine for the development team and surprise customers & stakeholders. It is not a show to praise the product owner.
The twelfth episode covers the broadcasting product owner. The sprint review is a regular, repeating opportunity to realign the scrum team with customers and stakeholders to answer a simple question: What are we building next? This requires collaboration from all participants, not just a product owner broadcasting decisions already made in advance. If the product owner is not seeking feedback actively, the purpose of the sprint review is missed.
The last episode summarizes my dirty dozen of the Scrum Sprint Review anti-patterns: from death by PowerPoint to side-gigs to none of the stakeholders cares to attend.
Update 2018-11-21: The Slide Deck of the Webinar Sprint Review Anti-Patterns Is Available
The slide deck of the webinar is available:
If the slide deck will not work within this browser window, please click here to browse the slide deck of the webinar Sprint Review anti-patterns directly on Slideshare. There, you will also be able to download a PDF of the slide deck.
📺 Join 1,000-plus Agile Peers on Youtube
Now available on the Age-of-Product Youtube channel:
- Agile Maturity and Agility Assessment: Is Agile a Fad or Trend?
- Agile Failure Patterns 2.0
- Product Owner Anti-Patterns
📖 Hands-on Agile Webinar Scrum Master Anti-Patterns — Related Links
Download the ‘Agile Transition – A Hands-on Guide from the Trenches’ for Free
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn more about the Sprint Review Webinar: Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.