The Show
Why Reviews Are More Than Just Demos
Theatre showcases are a opportunity for drama students to present a piece demonstrating their developing talents. Treading the boards to show their progress. The parallels to sprint reviews are many. Think of the squad showcasing their progress on building software to an audience of eager critics.
The sprint review is intended to showcase the accomplishments of a sprint. Arguably it should be used to highlight failures and learning outcomes as well. These days we are fortunate to have built increased engagement with our clients. Specifically, we finally have a dedicated and passionate Product Owner who has built strong interest in the product in-progress. With that we have seen that the same old sprint demo format needs some polishing.
Recently our team has been reflecting on our sprint review processes. More specifically, I’ve been asking myself one simple question. Can a sprint review be more than a demo? This week I look back over our review roaming, and contemplate the lessons I’ve learned on this turbulent trip.
Start the Show
The early days of our agile adoption were a buzz of activity as we adjusted to this new way of working. Enthusiasm among developers and users alike was infectious. Every two weeks we would have strong attendance to showcase multiple deliverables across numerous products. This new level of engagement did wonders for engineer morale, as their contributions were regularly recognised.
Following any dizzying high, there follows a devastating low. Over time attendance began to dwindle. Frequency of demo sessions began to drop. Feedback on new features was not forthcoming. Developers were left questioning the value of the features they built. It was definitely quite a fall.
See You at the Show
To rebuild the review revelry, we must undertake a postmortem to identify the cause of death. Part of the problem boils down to squad behaviour. One bad habit was the team cancelling reviews when they didn’t have a complete feature to showcase. Perhaps the competitive culture in which we strive to succeed encourages us to hide failures offstage. Encourage a spotlight to shine on both successes and failures to build up feelings of accountability.
Lack of preparation for demos is another cause. Developers quite often prepare a non-production environment to showcase, or mock up messages to present ticking data. Yet, they don’t memorise their script, or plan how to best present the feature. Presenters must strike the balance between winging it and over-preparing to ensure they can cover all aspects of what was achieved, as well as field the unexpected questions.
Stakeholders also have a part to play in the demo demise. Not all clients want to see all features. In our case, key users were only interested in enhancements to the products they used to conduct their daily business. Supervisors however were curious about all products generally. The lesson here is to consider your audience carefully. Distinguish between mandatory and optional audiences in any invites.
The final cause for disengagement could be a lack of context. With rewrites this can be more prominent, but I have seen the same effect on new products. A single small feature does demonstrate the incremental value we are delivering. However, clients often need to see the road we have travelled, and what lies ahead to validate we are heading in the right direction.
Don’t Stop the Show
Such issues have plagued our reviews over the past year. These are indeed fixable with preparation and mixing up the format, as we shall see in the final act. What requires more work is the changing of engineering attitudes. Technologists will always attempt to justify why their work should not be shown. The wording here is purposeful as we must consider software and infrastructure based projects in this argument.
I often hear that although work X was completed, that it is not possible to demo. Reasons for this belief are varied. In the software world, any enhancement without a UI is considered impossible to showcase. In infrastructure circles, the effort to build a functioning environment often outweigh the benefit of demonstrating the benefit.
These reasons highlight that the time is right to get creative, and choose the appropriate medium to showcase our work. It is true that presenting working software is a very effective mechanism. But this format is not always the right call. Perhaps it’s automated testing, message passing, diagrams. Something that shows why what was built is important and useful. If you enforce this way of thinking, the sole argument for not showing off an enhancement is then a question of business value.
The Show Must Go On
With the aforementioned concerns alleviated, technologists can no longer justify not showcasing what they’ve built. The review feedback loop is vital, regardless of the Agile paradigm practised. Rather than calling time, it should be taken as an opportunity to consider a different format. Application of experimentation and continuous improvement applies to the entire process, including reviews.
The latest and greatest feature doesn’t have to be the only item showcased. Recall one of our key issues with clients questioning where this new feature fits in their process. When clients continually ask what’s coming next, they are not providing the team with feedback on the product.
To elicit constructive commentary, we are starting to use additional artefacts. The product roadmap is the perfect tool for discussing the route we are travelling, and providing context on where we are, as well as our current direction. By-products of any analysis or design thinking stages such as wireframes and flow diagrams can be useful active mediums in conveying the value produced over the current cycle. With many methods available for reviews, it is vital for us to plan in advance with the product owner to ensure an effective feedback process.
Thanks for reading! Applause, critiques and reviews for the show are, as always, appreciated!
