The trigger for this post is an interesting experience I had during our weekly demo. I led the demo and made the client worried. This demo had a positive side – only a few crashes, our system had stability problems during the previous phases. Being able to work with almost no exception is great progress. So far, so good. The downside was that we had to set the environment at some points during the demo, like:

• Run a script to fix the registry
• Watch the task manager to ensure it’s done processing before sending new request
• Delete local DB between sessions
• …

It repeated itself during the last few demos, it annoyed us – the developers and it definitely annoyed the client. The result was a request from the client to change the architecture. This is rarely a legitimate request, the client asks for features, for a “demoable” value. Architecture and design should not be the client’s concerns. This helped us learn important basics about the demo: how did a demo with such progress made a client so worried?

The purpose of demo

A demo has two parallel purposes, they can exist side by side, but it’s crucial to know which one each demo serves:

Feedback for new concepts

This is clear characteristic of demos of new products. The client has a hard time telling what the exact features are that solves the problem the product is aimed for. In this phase, the developers are in charge of demonstrating how the initial ideas “feels” in real life – a POC the client can interact with. The POC phase is important in the product lifetime. In this phase the features must be perceptible, but not perfect. The ideal result of this demo is a client decision on whether the feature is good or not – should it be thrown away or should it go into the product?

Show the value the product provides

Hopefully, this is the characteristic of most demos. These demos give the client a close view of the development progress – the client knows what value the product provides. At this point decisions can be made – use the new value (like selling the new version) and choose the next important value the product should provide.
Choose wisely – which purpose this demo serves? Defining before the demo what it is supposed to achieve is crucial.

When should we choose?

The answer is easy – before the iteration plan. The reasons are clear: For a POC the least possible should be done, the feature may not be part of the product and there is no need to put effort there at this moment. For a progress demo, a feature will be planned differently – coding will take longer (this is not a throw away code – refactoring, unit-testing…), satellite tasks will be required (like installer, licensing, etc.). In this iteration the feature will require more tickets, so it must be planned accordingly.

How to choose?

If there’s confidence that the feature is what the client wants in the product – plan an iteration in such a way that the feature is in the product and it’s “productized”. If there’s a doubt, plan in such a way the feature will be demoable but with as little effort as possible.

What is done

“What is done” is important in a demo that shows the current value of the product. Then what is done? The answer is very simple: The product can be released right after the demo. In these demos there’s a simple but important guideline – perform the demo on a neutral machine from an installed version. Meaning – running the product from the development IDE on a development machine is not good enough.
If the demo’s purpose is to show what the client can use, show the client what can be used. The client can use only what is already “productized”, so if the feature is not part of the installer, it doesn’t help. If the feature is not linked to the license, it doesn’t help. If the feature crashes and constantly requires workarounds, it doesn’t help.

Bottom line

All developers know how to achieve a successful demo. The problem is identifying the next demo purpose. Before planning the next iteration, be clear about the iteration “What is done”. One of the things which could cause a failure is acknowledging the product passed the POC phase and it’s a real product (This is where we failed this week). A good parameter for moving between the phases concluded from the question “when will users use it?”.
After identifying the demo’s purpose, plan the iteration accordingly and make sure the demo fits its purpose.