{{announcement.body}}
{{announcement.title}}

Remote Agile (Part 7): Sprint Review with Distributed Teams

DZone 's Guide to

Remote Agile (Part 7): Sprint Review with Distributed Teams

In this series focusing on using Agile remotely, we take a look at how to conduct the Sprint Review among distributed teams, and some antipatterns.

· Agile Zone ·
Free Resource

We started this series on remote Agile with looking into practices and tools; we explored virtual Liberating Structures, and how to master Zoom. We had a look at common remote Agile anti-patterns, and we analyzed remote Retrospectives and Sprint Plannings based on Liberating Structures. This seventh article now looks into organizing a remote Sprint Review with a distributed team: how to practice the review with virtual Liberating Structures, including and giving a voice to team members, stakeholders, and customers.

Remote Sprint review

The Purpose of the Sprint Review

Before we get into recreating the Sprint Review online in a virtual setting, let us first revisit the purpose of the Sprint Review. The Sprint Review is empiricism at work: inspect the Product Increment and adapt the Product Backlog. The Development Team, the Product Owner, and the stakeholders need to figure out whether they are still on track delivering value to customers. It is the best moment to create or reaffirm the shared understanding among all participants whether the Product Backlog is still reflecting the best use of the Scrum Team’s resources, thus maximizing the value delivered to customers. It is also because of this context that calling the Sprint Review a “sprint demo” does not match its importance for the effectiveness of the Scrum Team.

The Sprint Review is thus an excellent opportunity to talk about the general progress of the product. The Sprint Review’s importance is hence the reason to address Sprint Review anti-patterns as a Scrum Master as soon as possible.

What Does the Scrum Guide Say about the Sprint Review?

In contrast to other Scrum events, the Scrum Guide goes into detail regarding the Sprint Review. The Sprint Review includes the following elements from Scrum Guide 2017:

  • Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
  • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done;”
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
  • The entire group collaborates on what to do next so that the Sprint Review provides valuable input to subsequent Sprint Planning;
  • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
  • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

“The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.”

Virtual Liberating Structures for a Remote Sprint Planning

The Sprint Planning indeed features a level of bringing everyone onto the same page, although this should not be confusing with a reporting session. Nevertheless, it seems to be tempting to many teams to handle Sprint Reviews precisely like that: as a team, show that you have been a useful entity of the organization by delivering the feature requests to the stakeholders that are paying for the team. This attitude tends to prevail in less “Agile” organizations that are still in the early phases of a change, often fostered by a traditional management style rooted in the industrial paradigm, thus focused on output and the utility of the individual. 

While this scenario is problematic when working co-located, its inherent lack of trust is seriously impeding a Scrum team’s ability to create value for customers in a remote scenario. Scrum is an excellent probe for organizational dysfunctions in normal, more or less co-located corporate life. Moving everything into the virtual realm is like putting the organization’s culture under a microscope: Remote Scrum reveals all shortcomings, problems, and issues at a much faster pace. 

Therefore, to mitigate the risk of running a remote Sprint Review, for many Scrum teams applying Liberating Structures is sound business advice. Including everyone in the process, giving everyone a voice in the remote Sprint Review builds the trust to cope not just with the competition of the markets but also with the challenges of working remotely. Hence the following virtual Liberating Structures microstructures offer a useful start to learn, inspect, and adapt how to run a remote Sprint Review.

Virtual Sprint Review Part 1: What Has Scrum Team Accomplished During the Sprint?

Consider the following microstructures for the first phase of the remote Sprint Review:

  • Shift & Share — the science fair approach: Members of the Scrum Team present different elements of the Product Increment to the whole group by screen sharing. (While Shift & Share properly includes the developers, the stakeholders might remain passive. To address that issue, see below: Simple Ethnography.)
  • Simple Ethnography: Why present the outcome to the audience, when the stakeholders can explore the Product Increment on their own while the Scrum Team is carefully observing what is happening? (If the stakeholders are thinking loud during the exploration, it will improve the Scrum Team’s capability to understand whether the Product Increment is meeting expectations and where there is room for improvement. Simple Ethnography uses screen sharing and session recording for later analysis and is hence simple to move to a remote work environment.)
  • User Experience Fishbowl: The UX Fishbowl is an effective follow-up to Simple Ethnography. Working in the whole group, use mute and video off to distinguish between the inner circle — the stakeholders — and the outer circle — the Scrum Team — of the User Experience fishbowl. Here, the outer circle members turn their video off as well as mute themselves. Gather additional questions through the chat channel from the out circle members. A facilitator should pass on these new questions in due time. (While discussing the topic at hand, the inner circle members should try not to read these new chat messages at the same time.) Use W3 to debrief in the whole group. 

Virtual Sprint Review Part 2: Is Our Product Backlog Prepared for the Next Sprint?

Consider the following microstructures for the second phase of the remote Sprint Review:

  • The Celebrity Interview is a useful way for the Product Owner to repeat the upcoming Sprint’s business objective as well as the long-term objectives, thus encouraging reflection on whether the Product Backlog is still up to its task. Working in the whole group, use mute and video off to distinguish between the Product Owner, the interviewer—a member of the Development Team or one of the stakeholders—and the remaining participants. Gather additional questions through the chat channel from the listeners as the interview proceeds. The interviewer should pass on these new questions in due time. (During the discussion, the interviewee should not read these new questions at the same time. The Celebrity Interview is also an excellent format to interview, for example, the CEO, when a shift in the organization’s product strategy has occurred or is imminent.) 
  • Min Specs: Min Specs is an excellent exercise to focus the whole team on the essential work to accomplish the next Sprint Goal. In a remote setting, it is a sequence of individual work and group work based on breakout rooms, aggregating findings in shared workspaces to be shared with the whole group in the end. Min Specs work well with embedded 1-2-4-All and Shift & Share, see below.
  • If you need to balance the demands of the Product Owner for new features with the necessity of the Development Team to keep technical debt at bay, probably already a latent conflict, consider running an Integrated~Autonomy session and ask “How is it that we can be more integrated and more autonomous at the same time?” As Integrated~Autonomy builds on a sequence of small group work based on 1-2-4-All, breakout rooms, and a shared workspace to visualize the outcome, it is also well-suited for a remote Sprint Planning.

Virtual Sprint Review Part 3: Closing

To close the remote Sprint Review, consider running a virtual Mad Tea to identify areas of improvement for the upcoming Sprint Retrospective. Of course, we cannot recreate two concentric circles of attendees facing each other. However, what we can do is use a prompt—a half-sentence that the team members shall complete—and the chat channel to create a quick picture of the team’s sentiment. As the moderator, prepare a few prompts in advance regarding the upcoming Sprint Review, for example, “I think the next Sprint Review should be…” Then post that prompt to the chat and ask the participants to add their answer(s) but not to hit enter. That is done simultaneously by all attendees when the host asks for it. The result is a bunch of suggestions from the stakeholders and the Scrum Team members regarding the upcoming Sprint Review, serving as data for the next Sprint Retrospective.

Supporting Liberating Structures

Two Liberating Structures can support a remote Sprint Review with a larger team: 1-2-4-All, and Lean Coffee:

  • To cover 1-2-4-All, we need breakout rooms and a place to aggregate the findings. We start with everyone in the whole group for a minute in silence; then, we split the whole group into pairs using Zoom’s breakroom feature for 2 minutes. After that round, we merge two pairs into a group of four for five minutes—this has to be done manually by the host–and the group aggregates its findings, for example, on a Google sheet prepared for each group in advance. We can introduce each group’s findings to the whole group by screen sharing in a Shift & Share. 
  • Lean Coffee is an excellent example of a workaround for virtual Liberating Structures. Gather all the input in the usual way, for example, engaging in 1-2-4-All, and gather those on a FunRetro.io board while voting is turned off. (Use several columns if the whole group is large to speed up the gathering process.) Then ask the whole group to cluster similar topics, then turn on the voting and order the remaining entries by votes. For here, you continue with a whole group discussion, or you engage smaller groups with breakout rooms.

Remote Sprint Review Antipatterns

There are plenty of Sprint Planning anti-patterns in general. However, I want to point at a few anti-patterns that are particularly relevant for a remote Sprint Review. It is all about embracing the new reality and trusting in people:

  • Death by PowerPoint: Participants are bored to death by PowerPoint presentations. (The foundation of a successful Sprint Review is “show, don’t tell,” or even better: let the stakeholders drive the discovery.)
  • Scrum à la stage-gate®: The Sprint Review is a kind of stage-gate® approval process where stakeholders sign off features. (This Sprint Review anti-pattern is typical for organizations that use an “Agile”-Waterfall hybrid. However, it is the prerogative of the Product Owner to decide what to ship when.)
  • Cheating: The Development Team shows items that are not “done.” (There might be a good reason to show unfinished work on some occasions. Selling partially finished work as good to go, however, violates the concept of “Done,” one of Scrum’s first principles.)
  • No customers: External stakeholders—also known as customers—do not attend the remote Sprint Review. (Break out of your organization’s echo chamber, and invite some paying users to your Sprint Review. Inviting customers is even more important concerning the challenges that remote product discovery imposes on the value creation process.)
  • No stakeholders: Stakeholders do not attend the Sprint Review. (In the remote realm, this is the ultimate dysfunction. Of course, there are several reasons why stakeholders do not participate in the Sprint Review: they do not see any value in the event, or it is conflicting with another important meeting. They do not understand the importance of the Sprint Review event. No sponsor is participating in the Sprint Review, for example, from the C-level. To my experience, you need to “sell” the event within the organization, at least at the beginning of using Scrum. When working in a distributed environment, consider doubling down on fixing this issue.)

Conclusion

Sprint Reviews are challenging at the best of times, and moving them into the virtual world compounds the difficulties. Given that the flow of information and the discovery of opportunities is likely to drop at the beginning of a Scrum Team’s journey to remote work, the importance of the remote Sprint Review has just increased significantly. Scrum Team, it is your turn now to overcome these impediments.

What kind of remote Sprint Review have you organized? Please share it with us in the comments.

Topics:
agile, distributed agile, distributed agile teams, liberating structures, remote agile, sprint review, sprint review meeting

Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}