8 Do’s for Successful Agile Showcases
Agile showcases usually have the following objectives
- Demonstrating working software to stakeholders
- Getting feedback
- And as result, validating if the right product is being built in the right way
Thus, showcases are very important and should be done as frequently as possible. Typically, this means that they are done at end of every iteration. In this article, I am going to be focusing exclusively on the software demonstration.
The following are a few patterns I have gleaned from successful showcases I have been part of — as a neutral observer, a stakeholder, a product owner and as someone who has run showcases.
Identify an owner
Standard wisdom says that this should be extempore in the sense that the team should not spent “too” much time in preparing for the showcase. I recommend that someone in the team take the ownership for preparing the script.
Prepare a script
This script should definitely include a logical sequence in which the software is going to be demoed. The owner should also be aware of potential bugs, workarounds, incomplete functionalities and things not to do (which might potentially break the application). A deck with a couple of slides summarizing the sequence goes a long way in communicating this to the other members inside and outside the team. In addition, definitely do the demo to someone else in the team with data that you are going to be using in the showcase. This lets us know if the script is logical as well as if there are unidentified deviations from expected behaviour. Also, it gives you feedback on your communication. I typically pair with a QA to do all the above, even if the QA is the one who is going to be doing the actual demo.
Set up meeting rooms/video conferences etc.
Make sure that you have all you need for a showcase. Ensure that whoever needs to be in the showcase is invited. This might mean pulling in people who have an indirect influence on the software or are affected by it in a sense. This helps ensure that the product is getting the right kind of attention and areas of concern are flagged immediately. You might want to consider recording the meeting & the demo so that this can be circulated to people who could not make it for some reason or the other. There are too many showcases which have not gone well (i.e. achieved their objectives) because either the conference facility was not good or the room was too small or the Wi-Fi connectivity was poor or some important stakeholder who should have been there, wasn’t.
Set the ground rules
Walk through the deck or the sequence in a form that the people in the meeting can understand. This might talking in their terms — technically, functionally or otherwise. This helps them in directing their attention where it is needed. You might want to have additional rules like informing the group that questions are welcome at any time or only towards the end. I have found that the first few showcases are very important in the sense that they set the archetype for future showcases to follow. A poor first showcase is always a difficult thing to overcome. Note: “poor” does not mean that the software was bad. “Poor” means that something came in the way of people understanding what the showcase and software were all about.
Make notes
Have a scribe if needed to take down notes and feedback. Depending on the context, you might want to quickly prioritize some of the feedback or have very quick huddles. This practice, though is dangerous, and needs to be monitored carefully so that the showcase does not go off on a tangent. These conversations help in engaging otherwise not so engaged stakeholders. Take down notes (this is so important I have to repeat it twice).
Surprises will happen
Be ready for surprises. It is rare for a software demo to go smoothly. What matters is if you can explain to the stakeholders what has happened or not and why. Follow up on these surprises is critical to build up trust
Summarize
You might call these showcase notes or cards in a tool of your choice or minutes of meeting etc. Whatever it is, ensure that all the important points that came up have been covered along with what has to be done about them. For example — a new feature might have been identified. If you need more time to discuss and analyse it, a simple statement to this fact lets everyone know that the team is on top of it.
Learn
Whatever learnings you have from a showcase, take it into the next one. This could include a different presentation, different environments on which the showcase needs to be run, a different meeting room etc.
Having said that, since this is part of agile methodologies, there are numerous ways where some of these guidelines need to be bent or broken, depending on the context. This will be covered in a different article.
