Painless demo’s

Within an Agile project environment periodic demos are one of the main strongholds. Demos are good for the team and the customers. They set focus and make progress painfully transparent. Agile promotes demoing the teams results every iteration, so every 2-4 weeks, and from the first iteration on. In this article we will present 2 real life cases, and discuss some considerations one should take into account to prevent early demos to have a boomerang effect on the project. Early demos can set the customers expectations to unrealistic levels which will lead to frustration all around.
Case 1
The project was about the development of a very technical innovative application. Of course the team applied Agile, actually Scrum, with 2-weeks sprints. At the start of the project, the team was composed of 3 very experienced experts. After only 2 weeks they managed to realize the basic technical flow, the proof of concept needed to give confidence in the feasibility of the investment. They were delighted and very proud with this enormous performance! The end of the sprint demo, the first of the project, attracted one technical guy from the customer and management level guys from both supplier and customer sides. An hour late, due to other meetings of the management guys we finally started at around 4:00 PM.
It was difficult to show the efforts made: “well, here you see the current website, and if you select this and this and press that ‘go’-button …..<1 minute of silently peering to the screen>…. tadaaaa …. there is the new website!!!!!” Of course we had this short action packed in a Powerpoint presentation which explained some of the technical complexity.
The audience showed a lukewarm response. It turned out they had not understand the technical talk at all and well, we have to admit the action part of the show was not that spectacular. The discussion quickly moved to the user interface: “This way we can never ship this product!” Two weeks later we demoed the same system with a flashy design and the crowd went mad, so to say.
Case 2
A few months later we were in another project. It looked quite straight forward. Again, we were on a 2-weeks Scrum rhythm. The system contains a complex data-loader back-end and website front-end. In the first 3 sprints we took slices of the system, capturing a few fields from this external datastream and processed it all the way up to the user interface. One of the teammembers in the team decided to spend her free evening on goldplating the user interface a bit towards the design sketches we had seen. It looked way cool!! And so the customer thought: “If you can do this in only a few weeks! I know it is only the beginning, but just add a few functions and we can go live! I know this is just the beginning, but I am very confident we will finish the project in time!“ Madness in the room again.

Demo`s and customer expectations
In the first example the team did a marvelous job, but the demo was not tuned to the audience. We did not manage to get the complexity over. Nor did we leave a feeling of confidence at the client or got the appraisal we definitely had earned.
In the second example, the data-loader part of the project turned out to be very, very complex. And without the data in, there is little to show on the website. The customer expectations had been set very high with the first demo, despite the explicit nuances we gave during the demo. In fact this successful demo right at the beginning of the project was working against us later on in the project.
Conclusion
Never skip a demo, but don’t think too light about it. Five rules to make each demo successful.  Even the first ones!

1. Give the customer confidence. But be careful to show off. Showing that you learned to understand the complexity, especially of the business environment, will gain confidence as well.
2. Words of nuances are not enough. You need to make the complexity visible in a way your client understands.
3. Demo in terms of functionality and business benefits. Use the words in the user stories implemented.
4. The first sprints are risk-driven. Show the risk and the mitigation you made.
5. Be reluctant and modest to display smart designs, better save the smart design thingies until you need them.