I honestly believe that having high-energy and high-impact Sprint Reviews truly differentiates high-performance agile teams and organizations. It's very much a "Show Me the Money" moment for the team. It allows the team to be transparent and demonstrate their results. It allows the organization to provide feedback. And it serves as a progress baseline / milestone so as to measure progress towards established goals. And finally, it should be cause for "celebration".

In many ways, agile delivery is about Earned Value, and EV is demonstrated one sprint at a time.

Since it's so important, I wanted to write this short post that captures multiple articles that surround delivering on the promise of effective Sprint Demo's. Here are three from my blog archives:

And here is another approach by Erik Weber that I really like. He brings up a different approach to sprint reviews he calls "Science Fairs". I think it can be very effective in larger scale situations where you still want to foster Team - Stakeholder collaboration, but you've got a lot of teams in the game. For example, in SAFe environments.

One of my concerns about implementing SAFe is the separation that is recommended / suggested between Sprint Reviews (for the Team) and System Demo (rolled up x-Team reviews for Stakeholders). Literally the teams don't have to "meet" the Stakeholders as part of the review "process". Instead the Product Owners run the reviews.

This separation, recommended under the banner of Stakeholder time efficiency and team focus, really concerns me. Science Fairs might be an elegant way to balance the collaboration within SAFe or other larger scale environments and still achieve time efficiency.

And to put the cherry on top of things, here's some generic advice from Agile for All and generic advice from ScrumCrazy.com

Wrapping Up

I've written a lot about Sprint Demo's or Reviews. Why? Because I think they're an incredibly important part of a healthy agile adoption and organizational alignment. I've seen many cases where teams do them poorly or not at all. In this case, it usually leads to bad results and blaming "agile" for them.

I've also seen them become something that transcends the team and leads towards true organizational learning and transformation. I write about them to help you hold the latter as your vision for your reviews and I hope you achieve this wonderful state in your agile journey.

Stay agile my friends!

Bob.

 

 

Comment