The "Reverse Demo" Explained
At gai, we follow what we call 'semi-agile' development methodology - in plain English, this essentially means we have stopped getting all pedagogic about Agile and use it as we, and more importantly the client, feels appropriate. We show client progress on the website usually on a on a weekly / bi-weekly sprint basis. We have found these 'Client Demos' tremendously useful. The article describes how we go about giving these demos.
The traditional Sprint Demo goes as follows:
- Giving the client a brief overview of the functionality we have taken up for this sprint.
- The development team does a screen-share and a hands-on, step-by-step walk-through in the user journey (forms, screens and data).
- Noting client feedback and inputs. And err, some bugs that crop up just when we're giving the demo!
- Summarizing the demo in meeting notes.
As we matured in Agile project implementation, we moved towards more complex applications. Our requirements analysis got more detailed. Our Quality Assurance (QA) team prepared extensive test plans and our demo flows became better documented.
Progressively, the User Interface and User Experience (UI/ UX) got finer and the scenarios got more complex.
For example, there could be multiple scenarios in a user-journey based on various user decisions. Correspondingly UX flows require tuning and tweaking. The best examples could be fantasy gaming or gamification applications.
During this whole journey, something interesting happened: we realised that, rather than we giving client the demo, we hand over the mouse to the client! And the client walked us through the work that we'd done. And guess what? It worked great with some of our clients! And now, we offer this as a practice to our new clients during the project kick-off. Some like it, some don't, but hey, such is life.
Before any Client demo, we do an internal demo:
- The Scrum master, or whoever is giving the demo makes sure that QA, all the tickets are done, done.
- She goes through the complete demo flow with the Team.
- This assures the team of the flow, and any issues that may come up.
- She documents the demo flow on the project management system (Redmine, usually).
The next day, we do the Client Reverse Demo.
We call it a Reverse Demo because:
- The client is hands-on the system and shares his screen (against traditional demos, where the dev team is hands-on and shares the screen).
- We do the verbal walk-through guiding the Client through the site/application.
- The client becomes the 'real user'. She experiences the system in a completely new and different way against to the dev-controlled-testing environments.
The Reverse Demo requires meticulous preparation. The way gai prepares for these are:
- The client opens the staging environment.
- The client shares his screen.
- The client is briefed on the demo flow.
- The client navigates through the flow.
- The demoer guides the client through the flow.
- Any bug found is documented by the demoer.
- Any change request coming up is documented by the demoer.
- Any clarifications coming up is documented by the demoer.
Bugs generally show up in the 'Reverse Demo', since the client is not yet well versed with the flow. These bugs could be because the team did not think of possible or absurd scenarios. Since the bugs are produced then and there, the team makes notes for re-production on the spot.
The Reverse Demo has the following advantages:
- The client gets an active feel of the UI / UX, resulting in quality and honest feedback.
- The client is free to stress test the system in terms of scenarios and cases, resulting in quality feedback.
- The client's inputs are independent of other's controls resulting in better inputs.
Reverse Demos cut the time between demo and User Acceptance Testing by half, resulting in higher productivity and delivery turn-around times.
For example, in a complex project that had multiple development teams, a bug was encountered by the client during the Reverse Demo. It was noted prima-facie as a freak scenario. But the devs actually re-produced it in the call itself, dug deeper and by the end of the call the analysis was sent to the primary dev team.
Turns out, there was a major architectural consideration that had not been covered. These are big wins in complex projects.
In a normal demo, the same actions could have taken up a full week of technical time.
Do consider the Reverse Demo for your next client demo, the results will be sour to start, but get sweeter in the long term.