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 Demo"  tremendously useful. The article describes how we go about giving these demos.

The traditional Sprint demo goes as follows:

1. Giving the Client a brief overview of the functionality we have taken up for this sprint.
2. Development Team does a screen-share and a hands-on, step-by-step walk-through in the user journey (forms, screens and data)
3. Noting Client feedback and inputs. And err, some bugs that crop up just when we're giving the demo!
4. Summarizing the demo in meeting notes

As we have matured in Agile project implementations, 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.

The practice

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 steps are:

1. The Client opens the STAGING environment
2. The Client shares his screen
3. The Client is briefed on the demo flow
4. The Client navigates through the flow
5. The demoer guides the Client through the flow
6. Any bug coming up is documented by the demoer
7. Any change request coming up is documented by the demoer
8. Any clarifications coming up is documented by the demoer

Bugs show up in the "reverse-demo", since the Client is not well versed with the flow yet. These bugs could be because the team did not think of a 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:

1. The Client gets an active feel of the UI / UX, resulting in quality and honest feedback
2. The Client is free to stress test the system in terms of scenarios and cases, resulting in quality feedback
3. 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 is a major architectural consideration that was uncovered.
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.