Maintaining a sprint reviews so it doesn't turn into company demo days.
Why sprint reviews and company demos are different.
[Side Note: Early this year, I got access into OpenAI’s GPT-3. With that, I’ve built two demos: Tiger & Ollie, which explore applied ML summarization and generative writing because I’m exploring applied ML. It’s been amazing to experience the power of ML in action. Drop a note if you’re interested and I’m happy to write a separate article sharing my learnings.]
One reason it’s hard working at a growing startup is because internal processes are constantly changing. A process that works for 25 people doesn’t work for 100, and the process that works for 100 people breaks again at 200. Just when you’ve created some repeatable process, you’re back to the drawing board. This is why people describe startups as “flying a plane while building the plane and figuring out how to build the plane.” Today, I’ll discuss the misunderstood sprint review process and how to evolve it as your company grows.
What is a sprint review?
Ken Schwaber and Jeff Sutherland define it as “… a working session [to] review what was accomplished in the Sprint and what has changed in their environment [so] attendees collaborate on what to do next.” [emphasis mine]
The common problem with sprint review
Unfortunately, most sprint reviews focus only on “what was accomplished”, which is why there’s an emphasis on the sprint demo. What’s missing is the discussions around “changes in their environment” and how it affects what you do next (i.e., sprint plan)
Setting up a Better Sprint Review Process
The basics are simple. Invite the product team + a few stakeholders. Keep meeting for an hour. Demonstrate working software and discuss changes that should influence the next sprint. But I’m going to talk about four anti-patterns.
Inviting “end-users”, not just senior stakeholders. There’s a tendency to invite people with titles (e.g., Head of XYZ) to sprint reviews. Two reasons: You want to showcase the work and gather feedback. However, not all stakeholders are as in-touch with the end-user of the software. This is to say senior stakeholders’ opinions are invalid.
For example, if you’ve created a new feature to make customer success more productive, don’t only invite the Head of Customer Success who requested the feature. Instead, invite a customer success associate who will use the feature day in and day out. Similarly, if you’ve built better devOps tooling, don’t only invite the PM from another team, but invite the software engineer who is going to be using the new devOps tool. Senior stakeholders can provide “broad” feedback, but “end-users” are better at tactical feedback.Tell the invited “end-user” that they’ll be demonstrating the new feature. It’s common during sprint reviews for either the PM or the engineer who created the feature to give a demo. However, a different approach is to assign the demo task to your “end-user stakeholder”. Give the person a specific task to accomplish and help them through the demo. Reframe the sprint review as a working session rather than a “show & tell”. Make sure someone is standing by to answer questions and troubleshoot. This approach changes several dynamics. First, the software needs to be deployed into a stable staging or pre-production environment, showcasing working software than working software parts. Second, stakeholders are more engaged through the sprint review. Third, you’re more likely to invite stakeholders that are closer to the problem who can give concrete feedback. Finally, it reduces the likelihood that you’re giving “slide presentations” because the stakeholder can’t “demo” slides.
Solicit observation feedback from product team members first. Sprint reviews that are PM or engineering led with Q&A sessions aren’t as helpful to the product team themselves, even if it’s educational for others. Questions from stakeholders such as “Why did you [___]? “Has the team thought about [___]?” “What about [problem]…?”), while good in intention, creates pressure for presenters to “answer” and defend their decisions. Change this dynamic by telling product teams that after the demo, you’ll be asking each person what’s an interesting observation or specific improvement they think the team should do next after observing the demo. This engages everyone on the product team into user interview mode. Once everyone has spoken, then ask your stakeholder for feedback on what she’s heard, her thoughts, and where she wants to drill in deeper. This will help your prioritize based on “end-user” feedback on what’s valuable.
Don’t schedule a sprint review if the team is set on “what’s next”. For diehard scrum advocates, this is heresy. But sprint reviews aren’t always helpful. If you’re developing consumer products and doing continuous deployments (e.g., daily releases), the opinions of a few stakeholders isn’t going to predict feature success. Besides, you’ve already released it. Thus, it’s better to talk or observe actual users. Or, if what’s completed during the sprint isn’t working or working software, but partly working software (i.e., an end-point and the feature is for developers), you’re not going to change what you do next sprint. In this case, not much benefit to having a sprint review when new information won’t adjust what the product team works on next.
The Evolution of Sprint Reviews into Company Demos
As the company grows, more product teams are formed. With each team performing its own sprint review, demos, and discussions with stakeholders, a common idea starts. Why not combine them all these separate sprint reviews together and do a company wide demo. You can reduce pressure on stakeholders attending overlapping sprint reviews, increase information sharing across teams, and save everyone time.
Hurry! It is a great idea, but for reasons that are antithetical to the goal of sprint review.
Sprint review is to help the product team adjust and decide what’s next. Sharing general knowledge and improving cross team communication is laudable, but doesn’t help each individual product team figure out what’s next. Here’s why it doesn’t help.
Company wide demos are a mile wide, but only an inch deep. Typically, these are 1-2 hour max. With product teams across the company sharing, it quickly becomes TEDx “like”, necessitating presentations (antithetical to working software). You might fight this, but eventually a team will bring up a slide and I’ve never seen anyone yank the stop cord. As a result, these company demos reward good presentation skills, incentivize teams to spend time polishing demos or choosing presenters (i.e., PM frequently gets selected by default).
Go too deep and you’ll make people fall asleep. To combat #1, companies increase company demo duration, allowing more in-depth conversation. However, because the audience is much larger than sprint review, deep discussions in a particular issue will only be relevant to some people (e.g., devOps talking about a new deploy tool and acquisition marketers looking puzzled). Thus, attendees will pick and choose what to listen and engage with, which diminishes the perceived benefit of “increasing information across teams”. With remote teams, no one is going to police if you’re actually listening or not. Also, with such a large invitee list, you’re going to have some people skipping, which only further hampers knowledge sharing across teams.
There’s an argument for a company demo as a fun and general team bonding event, but it doesn’t replace sprint reviews for individual product teams. It is the cost of more people and growth in complexity. One idea I’ve had is asking your “stakeholder” in the sprint review to pick one person in their functional role after a sprint review meeting and spend 5 minutes sharing what you learned. If there’s anything better, add a comment below.
Sources:
4 Reasons Why Your Scrum Sprint Review Isn’t Effective (And How to Resolve Them)
Why most Sprint Reviews are boring (paywall, open in incognito)
We hate the Scrum events! (paywall, open in incognito)