Aah! demo day. Finally, the day where the developers get to shine. This is the moment everyone has been waiting for, the fruit of months of labour and thousands of dollars.
But it never really works up to a rosy picture now does it? For me at least it never was.
The pattern was eerily similar:
4 weeks to demo: App is mostly ready just this two features to knock off
3 weeks to demo: Critical design flaw found that means rewriting a huge chunk of work to accomodate new features
2 week to demo: Work around found, tests no longer run. That is ok the app still works
1 week to demo: Panic all around, bugs seem to be popping every day at an increasing day
0.5 weeks to demo: The *Whack-a-bug* is proving insurmountable. Even previously working features have started to disintegrate
2 days to demo: Decision is made to postpone any new code. From now on anything that doesn't work we mock. We can make it work later.
1 day to demo: Barely passable app, what doesn't work has been mocked up. The client can't possibly know
Demo day: The client notices some design flaws but thinks its kinda ok
1 week after demo: App has failed terribly in production. The client's customers are fielding complaints about the product
3 weeks after demo: The application is pulled off the market Thankfully those days are no longer with us. If you still face this challenges, then read on.
What I present here is a series of 5 guidelines that when applied are guaranteed to make your demo day much smoother.
Work on a definition of done
It is surprising how many teams don’t have a definition of done. It is easy to assume that once a feature is done, it will be self-evident to all parties concerned. Assumptions pave the way to demo hell.
The developer team and the client should agree on a definition of done. A sample definition would compose of the following checklist:
- Coded
- Tested
- Documented
- Usable
- Running on target device
Appropriate platform
Emulators are everywhere. They are fast reliable and give you a way to quickly iterate over your work without ever leaving your sweet desktop environment. They, however, hide a dirty secret. Your PC is performing at a rate that most servers or mobile phones can not match. So unless you are building a desktop app, the feedback you are getting is just lies.
Compile the application and run it on a range of phones, deploy the app to a 1GB server. In short, do anything and everything to test your app regularly on the environment it will be expected to run in production.
During the demo, ensure the app is running on this platform as well.
Don’t fake it
If a feature is not ready, don’t fake it. You may avert the client’s wrath for a while but trust me your reputation is worth more than a few uncomfortable moments. In fact, if you communicate the schedule slip in time, you just may get more time on the project or otherwise agree on a mutually satisfying solution.
This, of course, goes all the way through to internal demos. There is no half way done. Only done and not done.
Just another day
If you have to go out of your way or dramatically change how you work on the lead up to the big day, then you have already lost. People who work too hard make too many mistakes. Progress should be consistent and maintainable throughout the duration of the project.
The presentation itself should be informal. With the team and the client discussing what has been presented. Try to have the client physically there for the demo if possible. If not, use the best AV devices you can get to simulate co-location.
Timebox it
All good things must come to an end. Have a strict timebox for the presentation. Informal here does not mean disorganized. There should be a structure to the meeting. Something like.
- Introduction by scrum master
- Reiteration of the sprint goal
- Allocation of time slot for presentation of various features
- Allocation of time for feedback on presented features
- Approval by client
How do you run your own demos? Tell me in the comment section below or on my twitter @jchex
