155 reads

Webinar #9: Sprint Review Anti-Patterns [Video]

by Stefan Wolpers6mDecember 15th, 2018

Too Long; Didn't Read

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.

Companies Mentioned

featured image - Webinar #9: Sprint Review Anti-Patterns [Video]

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.

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.

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 chapter 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 chapter 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 does not make our customers happy. There is no justification needed, think of sunk costs — the money is gone. Instead, we are interested in the 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 chapter 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 chapter 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 chapter 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 chapter 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 chapter 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 chapter 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 chapter 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 chapter 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 chapter 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 twelveth chapter 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 chapter 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.