Archived from: DZone
Author: Anton Bevzuk
Published: January 28, 2019

Background

Dodo Pizza’s first attempt at sprint reviews failed spectacularly. While a pizza chain might not seem to need Scrum practices, Dodo Pizza’s key advantage is its own IT system (Dodo IS) controlling all working processes across 430 pizzerias in 11 countries. With over 60 programmers and analysts (planning to grow to 200+), they use Agile frameworks including Scrum, LeSS, and extreme programming.

Their initial sprint review for a new Kazakhstan website received positive feedback from franchisees, but after launch, the site was seriously lacking. They had wasted time on a review without getting useful feedback, and quietly stopped doing reviews altogether.

The Turnaround

Several months later, with eight teams working in the LeSS framework, canceling sprint reviews violated LeSS rules. They committed to finding the right format through trial and error, asking participants to rate each review on a scale of 1-10. Initially grades were low, but through experimentation, reviews moved to the upper part of the scale.

Key Improvements

1. Doing Homework

Sprint review preparation demands as much time as the review itself, or more. A two-hour review requires three hours of preparation: discussing goals with teams and stakeholders, booking rooms, making posters, finding facilitators, creating timetables, and hanging feedback flip charts.

2. If It’s Not Finished, Don’t Show It

They stopped showing half-ready features. When the CEO saw the same mapping service three times (first demo, then bug fixes, then live), he rightfully questioned why he had to see the same thing repeatedly. Now they only show features already live on the site.

3. Conference Rooms Instead of Open Space

LeSS recommends “bazaar” style reviews where teams demonstrate work in a large room. This created noise, confusion, and small uncomfortable laptop screens. They switched to gathering in a large room only at beginning and end, with main presentations in small conference rooms with proper equipment and video conferencing for remote participants.

4. Wandering Not Allowed

Initially stakeholders walked freely between teams, but latecomers asking questions about already-covered material disrupted presentations. They established a rule: choose a subject and stay for the full 20-minute session.

5. Guest List Matters

Nothing motivates developers more than the CEO attending, especially for technical features like Kubernetes microservices. CEO Fyodor Ovchinnikov can energize an audience in three minutes. For front-end features, they invite outside guests from Facebook acquaintances.

6. A Funny Presenter and a Cap

The presenter makes up half the success. After trying various Scrum masters, mobile app product owner Sergey Gryazev became the permanent presenter with his jokes. They also acquired a ritual artifact—the Speaker’s Cap—which cheers everyone up.

7. Remote Participants

With employees in Syktyvkar, Nizhny Novgorod, Kazan, and Goryachy Klyuch, remote inclusion is critical. Initially they complained about poor audio/video. Now the checklist includes equipment checks, Slack updates, and YouTube streaming.

8. Don’t Gather Feedback

Counterintuitively, they stopped gathering feedback at sprint reviews. In those conditions, feedback is never comprehensive or high quality (the Kazakhstan website proved this). They gather meaningful feedback during the sprint itself. Even the Scrum Guide doesn’t mention gathering feedback—it says the team and stakeholders “collaborate,” not gather feedback.

9. Welcome to the Backstage

Beyond showing what’s done, teams now discuss the genesis of features: What was the goal? What happened during the sprint? What distracted or impeded? What measures were taken? This helps managers understand why seemingly simple tasks aren’t trivial, while helping developers think in terms of client problems rather than solutions.

Conclusion

The key insight: don’t obsess over Scrum Guide recommendations. Go by trial and error—there are no universal solutions. Find what works for you. As they warn: “Don’t copy our format. It works for us because it was born from experimenting. Look for your own approach.”