An Agile Demo typically occurs during a Sprint Review session, and is crucial for providing visibility to team members and stakeholders. One would think that sharing such insight via a demo would be one of the easier aspects of agile adoption, but far too often teams fail to give it the attention it deserves. Before I list out some of the more common demo failures, let us share in a success story.
The Good
Company X has two disparate systems. Management has tasked their employees to manually fat finger in orders received from one system into another. This is not ideal by any means, but flaws in their waterfalled design landed them this situation. This time an agile team is brought in to build out the integration. About 2 weeks into their efforts, the agile team decides to demo a very early prototype of their solution. It doesn’t have any bells or whistles, however one system has the ability to export into a CSV file, while the other system now has a rudimentary CSV upload feature. The stakeholders watch as 1000’s of orders are uploaded within seconds and appear in the second system.
They are ecstatic!
Management immediately decides to fast track this prototype upstream so that they can take advantage of this simple CSV upload functionality. This feature alone cuts down 80% of their workload. The agile team continues to build out other features while the rest of the workforce can give their fingers a much needed rest.
Seems simple enough right? The early demo provided valuable insight that impacted ROI much faster than anyone anticipated.
So how can this demo process go horribly wrong?
The Bad
Fail #1. The PowerPoint Demo – For some reason we are lead to believe that there is value in seeing screen shots in PowerPoint. I personally believe that PowerPoint Templates are there so you do not have to actually think, but that is another blog post. If you refer to the story above, and the tenants of agile, the goal is to demo working software. I admit that you’ll need to be creative at times, and more often than not will have to dummy up XML files or CSS, but I cannot stress enough the importance of taking the time to do so. People tune out during screen shots much more so than they will during a demo, even if it is rough around the edges. Stay away from PowerPoint or screen shots!
Fail #2. Not Inviting the Team – I’m not going to dictate who runs the demo. In some cases the Developer(s) may be required, in others perhaps the Product Owner or even Business Analyst, but regardless they all need to be there! One sure way to train wreck your agile process is to have demos that include only the developers with no stakeholder feedback (or vice versa). This is a team exercise, and Scrum Masters need to put the kibosh on any rogue demos that do not include the team. One only knows what sick and twisted promises will be made from a stakeholder-only demo session!
Fail #3. Not Having Demos – This one may be a no brainer, but when under lots of pressure and a looming deadline, more often than not the first thing to go is the Sprint Review session. This usually means the demo is an unnecessary casualty. Take time to plan out your sprints to include demos, and be disciplined about this.
Hopefully I’ve covered some of the more common demo failures, and also illustrated how a demo can change the course of the future in a positive manner. I’m certain there are other demo traps out there, so by all means feel free to share yours below.
Loading ...