Sprint Bazaar — Behind the scenes

From theory to reality — tips for a smoother adoption

Thanks Yeo Yong Kiat for the shoutout on BGP’s ongoing experiment… the sprint bazaar! He covered the what, why and the how in his recent article, and garnered interest within our agile community. I thought it will be timely to share some tips based on our multiple iterations and refinement for fellow practitioners to note before they embrace the chaos…

Expect Resistance, lots of it

You will face resistance from Development team:

• You mean I have to present 2 or 3 times now??? I only have to do it once last time!

Tip: This requires a mindset shift from developers. Facilitate instead of presenting. Saves energy + give the user a chance to tinker with the product for more useful feedback

• If I have to mend a station, does that mean I don’t get to visit other stations!

Tip: Station ICs should consider having a 2nd IC, so they can visit other stations when the rotation ends.

You will face resistance from Product Owners:

• Why can I only choose 2 stations to visit? What about the other 3 stations? Won’t I be missing out?

Tip: Sprint Review is not a “staffing” session. For those not familiar with this term in government, it means to inform or to update. This is probably a sign that the PO is still in the passive inspect-accept mode, waiting for information to be spoon-fed. Consider going back to basics and ask the PO what a sprint review is for — to bring their stakeholders to view the product and give feedback + decide what’s next!

• Can we go back to the old cadence (of silos sprint reviews in monologue), I don’t understand why we have to do something so complex

Tip: Go back to Why (see below). If going back to why fails to convince, you need to HTHT (heart-to-heart-talk) to understand why this person prefers the old cadence. The reason we got was because of the previous point: using Sprint Review to be “staffed”, and FOMO (fear of missing out on stations)

Expect to facilitate more

For a start, give step by step instructions. Lots of it. Sprint Bazaar is not the most intuitive event by nature and can get quite chaotic.

5 mins — Introduction

• Get PO to recap sprint goal + welcome stakeholders

5 mins — Feature Pitch

• Get presenters (devs) to give a 1-liner of their station. A useful format to sell their stations is asking them “What you can learn from my station”. Also nudge presenter to share where is their station located.

30 mins each — Bazaar round 1 /2

• Timeboxing is required and a bell will be useful to signal the need to rotate
• Prepare sticky notes and sharpies for the stakeholders to solicit feedback

15 mins — Conclusion

• Gather all the disparate feedback and support the Product Owner in his debrief
• Look out for important stakeholders to ask for their closing feedback!

Always Go back to Why

Sprint Bazaar is just like any other initiative. You will face fence-sitters, naysayers in your adoption and in your darkest hours, when you doubt even yourself — you go back to why:

Here’s my why:

1. To serve the Development Team by:

• creating an environment for learning and mastery
• embedding cross-squad learning
• providing opportunities to facilitate and market their feature

2. To serve the Product Owners by:

• Building flexible teams which can adapt to changing priorities — Flexible teams don’t happen overnight. They need to continuously learn from each other for both domain and technical knowledge.
• Increasing rate and quality of feedback through smaller groups engagement — to build better products
• a Sprint event that can scale with more teams

3. To enable Inspect-Adapt, not Inspect-Accept

• Our previous sprint reviews used to be Developers going through each and every acceptance criteria to prove that work is done and you can expect the reactions: Product Owners just “orh” and “okay”, no feedback!
• POs now accept stories throughout the sprint and focus on making the bazaar an engaging one to solicit feedback for adapting the product

4. To achieve greater team engagement through a series of diverge-converge activities.

11 Sprints and 5.5 months of experiment

Our current state:

• Teams are getting comfy in smaller groups discussions
• Developers and business inspect and adapt increment closely together
• We are excited to see how this can accommodate more squads as we ramp up
• No more showing stories or acceptance criteria but instead…

Some party photos:

Mamta showing her feature to other developers for feedback

Our intern Christopher showcasing his automation work to fellow BGPers, agile coaches and business.

David sharing with stakeholders and team members how he drastically reduced loading time

Was it worth it?

If you asked me earlier on when we first started, I would say No. Things get done, life goes on, why make life so difficult for everyone? If not for the why that keep driving the purpose on attempting this experiment, it is easier to just let it go.

Today, the GovTech Agile Coach team paid a visit to this madness and paid compliments to the team:

We can’t tell who is business or devs, vendors or GovTechies anymore

and that One Team One Product feeling, somehow made it all worthwhile!