Continuous Feature Demos
A Feature Demo is an opportunity for conversation and learning between the development team and the users while demonstrating their work. This is a chance to talk about what the team has done and get real, valuable feedback on the work in progress. Constant feedback helps to eliminate risk and unpleasant surprises, and reduces costs by fixing any errors, omissions, or misunderstandings while any deviation remains small.
Slideshows are for marketing, not development. Demo using actual working, tested features. Demo continuously throughout the development process, not just at the end of an iteration or at the end of the project.
Pain Points
- Teams operate largely in the dark with no real or timely feedback from users
- Users lose trust in the development team, as the team does not understand why certain decisions were made or the reasoning behind certain requirements
- Users complain that the software that gets to production isn’t the same as what was shown in demos
- Teams feel unappreciated and are typically confused about important details related to a feature
- Teams don’t feel their work is valuable to the organization
Benefits
The feature demo is a chance to come together look at what has been completed, see how it works and get relevant and timely feedback regarding it’s fitness and usability. Everyone wants their work to be meaningful and appreciated. The demo provides an opportunity to show others your work and get feedback that allows development teams to continuously adjust and deliver value.
- Shortens delivery cycles as this practice forces teams to use practices like TracerBullets
- Ensures a working skeleton early in the development process
- Enables fast feedback from users
- Focuses the entire team’s efforts on fully delivering the next item to be demonstrated rather than having too many items in parallel work streams, which leads to waste
- Builds trust with the user community which gets to see the working software on an ongoing basis
As noted in TracerBullets, slices of functionality will move through the system, shining a light on the dark corners and overlooked details. After the technical bits have been ironed out and are working, you’ll have a system (thanks to all the canned data) that appears to be working (even though it isn’t) and can be demonstrated to your customer. You’ve now skipped far ahead of a typical software project and you can ask your customer if the work flow makes sense long before you complete the rest of the system.
Assessment
- Development teams and the user community routinely engage in demos and engage in meaningful and timely dialog regarding features developed (100pts)
- Development teams and the user community attempt to routinely engage in demos and sometimes have meaningful and timely dialog regarding features developed (50pts)
- Demos are scheduled but seldom are attended and feel more like checking off a box for a task rather than a meaningful feature discussion (-50pts)
- Demos are largely ignored and little or no discussion is held regarding delivered features (-100pts)
- Teams rarely demo working software and use demos and slide shows as proxies for actual working features (-200pts)
Application
✓ Critical ❑ Helpful ❑ Experimental
Adoption Experiment
Setup
- Pick a feature that the team will begin work on in the near future
- Compile a list of all of the relevant users and stakeholders interested in the feature
- Send a note to each one of the users/stakeholders informing them of the demo and that they will get an alert about 1 day prior to the expected demo. Let them know where the demo will be and if needed, the web meeting link. Also let them know the meeting will be time boxed to 15 minutes for the feature
Trial
- Have the team show the actual working feature they developed and explain the design trade offs, user experience criteria, risks, performance and other relevant facts about the feature
- Take up only about 5 minutes on demoing the feature to leave plenty of time for user questions. Draw out their comments, and actively engage them in dialog
Evaluate Feedback
- Did you successfully engage the users in dialog?
- Did they provide meaningful feedback?
- Did the schedule work?
- Did you need to record the demo for those who couldn’t attend and if so, did they send feedback?
- If a demo was recorded and you didn’t get feedback, what should you do about that for the next time?
What Does it Look like?
The team assembles a list of interested users/stakeholders of a feature. When the team is confident of its results, they sent an alert to the users/stakeholders of a demo one day later. During the demo, the team demonstrates working software (not slides or proxies) and openly discussed. The team then takes that information and makes adjustments to the code and/or processes to ensure they are well-aligned with users needs.
Warning Signs
- Only one person talks at the demo
- No users/stakeholders show up for the demos except the person who’s running it
- Demos are irregular and/or infrequent
- The team demos from slides or video instead of showing their work live
- The team schedules a demo only to cancel last minute due to some last minute “bug” or other crisis
- You ignore the other practices that can contribute to the success of this practice and just dive in
- Continuously put off or reschedule demos
- No users show up for the demo
- Users remain silent and do not offer any feedback or critique. See CritiqueDontReact
Growth Path
Start small and hone your process on a few pilot features before engaging this on all features across the project.
If another team is consuming your work (or you are consuming their’s), make a point of attending each other’s demos and see what’s coming down the pipeline.
Use demos as a communication tool. Reach out to users and invite them to attend, in person or virtually.
Remember that requirements are a conversation.
How To Fail Spectacularly
- Hold demos only once a month, or at the end of the project
- Do a demo from slides… does your code not work?
- Trying to “pass” on doing a demo. Is your team not doing any meaningful work?
- Scheduling a demo but not listening to feedback from your users because you already know what’s best for them
←Prev (ShareTheSecrets.txt)(Two Sets of Eyes) Next→
