Sprint Bazaar, Screams Bizarre!
It’s my third week at GovTech, and it has dawned upon me that teams here are highly experimental. For one thing, one of the delivery managers (who assumes the Scrum Master role) in my team has managed to co-opt his entire Scrum team to run the Sprint Review very differently from how most other teams have chosen to run it.
Brave soul. Let’s give him a big hand, shall we:
Apparently, it’s a special way to facilitate the Sprint Review, known as the Sprint Bazaar. Screams bizarre? Well, read on!
The Typical Sprint Review
So here’s how a Sprint Review typically goes:
- The Product Owner (PO) opens the session, calling the Sprint Goal into focus. The Scrum Master (Scrummy) may facilitate and remind, but doesn’t take the limelight.
- The time is handed over to the Developers (Devs), who introduce one feature at a time.
- As the Devs demonstrate the working increment, the Stakeholders (Stakeys) invited to the session are invited to comment, query and provide feedback.
- Either the PO or Scrum Master (Scrummy) can consolidate all these feedback for subsequent consolidation or refinement of the Product Backlog.
Definitely not rocket science, and seems fairly easy to implement. In fact, it’s a little too easy for advanced self-managed teams! Speaking to various colleagues, a significant number of people commented that for those who were highly experienced, such a linear and controlled process was not optimal for gathering feedback.
And feedback is critical for a piece of software (or any other artefact of knowledge & creativity) to improve.
The key problem seemed to be that the Devs were holding too much power of interaction with the product — when it ought to be the Stakeholders (or business users) who should be using the product and giving feedback. Because Devs are extremely familiar with their own product (you would be too if you worked on it day in day out), they tend to explore happy paths, and inadvertently always interact with the product in the correct manner.
This is similar to the situation in a policy case study presentation, where the policy analyst zooms past the policy background, hypothesis and evidence, and goes straight into the policy recommendations as though they were common sense. Senior Management (if they’re too tired) being too bamboozled by the whirlwind of information, sometimes gives the policy analyst the benefit of the doubt and the questions just stop.
But it’s the questions that leads to good policy formulation. And it’s also the questions and feedback that results in a robust tech product.
Sprint Bazaar: Increasing the Rate & Quality of Feedback
Enter the Sprint Bazaar, a fun (or in true Agile spirit, constructively chaotic!) way to increase the efficiency of Sprint Reviews, and also open the team up rapidly to the Transparency-Inspect-Adapt cycle. Before I go into how my Delivery Manager implements his Sprint Bazaar, let’s explain conceptually some of the features that make this mode of facilitation so useful.
At the heart of the Sprint Bazaar is the belief that increasing Stakeys’ interaction time with the product also increases the rate and quality of feedback. The rate of feedback increases because the Stakeys are no longer passive observers; the quality of feedback increases because the Stakeys are unlikely to follow happy paths when interacting with the feedback, generating unexpected results or errors even, which are useful data points to adapt the product further.
The more advanced Scrum practitioner would also notice that the Sprint Bazaar runs multiple inspections in parallel (more on this later): by increasing the number of instances of inspections, one essentially opens up the product to a greater number of inspections in a different context. Again, more feedback results in a better product.
Interested to see what it’s like? Let’s go!
Implementing the Sprint Bazaar
- [5 mins | Introduction] As usual, the PO hosts the event, but the Scrummy facilitates. The PO performs the usual re-iteration of the Sprint Goal and work done, and the Scrummy emphasises the importance of feedback. But this time, the Scrummy holds a bell — for he is also timekeeper in this party of chaos.
- [5 mins | Feature Pitch] Here’s where the fun begins — for every feature that was part of the working increment, the Devs set up a booth to demo their product. They make a product pitch as to why the Stakeys should pay attention to their feature and visit their booth. Maybe they solved the problem of the century; or maybe they found a crazy way to solve a problem. Their goal is to get the Stakeys interested in their feature with powerful punchlines.
- [20 mins | Bazaar Round 1] Based on the feature pitches, the Stakeys split up and visit one booth of their choice. At the centre of the booth is the software product, which is free for the Stakeys to interact and play with. As the Stakeys use the product, they give feedback — the Devs step in to explain and also receive the feedback. Have the Devs themselves collect the feedback in Post-Its, rather than the PO, so that they experience the market. The PO and Scrummy should have a scan of the feedback collected, so that they can facilitate later.
- [10 mins | Group Shareback 1] Ring the bell, and converge the teams into a main area for a giant shareback. Here’s where the PO and Scrummy step in to collect feedback in a group context. As feedback is shared in a group context, aggregation of the earlier feedback Post-Its also takes place. This allows the group to synthesise the individual feedback into a collective whole.
- [20 mins + 10 mins| Bazaar Round 2 + Group Shareback 2] As above. But increasingly, the PO and Scrummy should further streamline the feedback and aggregate feedback towards consensus and convergence.
- [15 mins | Conclusion] The PO rounds up the session and it’s vision casting time! For each feature, he groups the feedback at high level, and talks through the key nature of the feedback given. If possible (and if the PO is so efficient), he may share what he intends to do with the feedback, explaining his thinking clearly. As this happens, the PO accepts whatever working increment he can, and refines whatever he can of the Product Backlog — essentially, preparing the Product Backlog and the team for the next Sprint container.
Embrace the Chaos!
So what do I think?
Definitely not for POs and Scrummys who are beginners! To be honest, the sheer chaos of it all was intimidating for someone like me who had never observed a single typical Sprint Review at all.
But you can’t deny it, that when you allow your users and Stakeys to play with the product, questions naturally come. You see their body language and expressions, and naturally the Devs come in to explain the product — and that’s when you know the product can be refined further.
There is something to be said about trading off centralised order and control here for something that’s more forthcoming, and more organic. Things did get heated up, but there was also laughter, and there were also sighs of relief.
The room did feel a bit more real. And that’s how we want to keep the Sprint Review, right? An informal working session, rather than a cold, smooth and methodical presentation.
Looking forward to learning more from all of my teams in my coming months — cheers!
