How to organize effective iteration demo in outsource project?

Question

Most of our clients are abroad, so it's impossible to have a face-to-face conversation at the demo meeting. Are there any best practices on how to show progress and capabilities of the increment at the end of the iteration?

Answer 1

On our project, we hold virtual demos for clients at the end of releases all the time. We have a pretty standardized format for this, that usually works pretty well.

First of all, you want to make sure that everybody involved understands what technology you are using for the meeting itself. Are you using webex? Skype? Skype for business? Something else? Make sure the customer knows how to use the app. It sounds super basic, but you wouldn't believe how many issues come out of simple things like not knowing how to mute, how to un-mute, how to share a screen, etc. Communication is the lifeblood of any project and you NEED client feedback. You don't want barriers. I recommend doing a "remote meetings for dummies" email (obviously not titled that way!) where you literally spell out how the meeting app works and have screenshots of all the important controls you expect them to use. Never assume they know how to use something, especially with the proliferation of collaboration tools today.

Secondly, an online demo has to be a little more structured than an in-person meeting. A good way to go is to literally call roll at the beginning of the meeting. Also, actively call out people for feedback that you are interested in hearing from. People jump in to a conversation FAR less over a remote connection. They are much more likely to be passive listeners who just watch your demo, stay on mute, and then hang up. You need feedback and interaction, so think about who you are most interested in hearing from about what and specifically ask them, also as I said, the roll call is not a bad idea just to be sure you have all the necessary stakeholders in the "room". Nothing worse than a successful demo that later you hear someone was NOT present for and that someone is an important stakeholder who has reservations about something that was delivered.

The presentation itself (in our case) tends to be a combination of powerpoint and in-app demo via screenshare. Important points on this: if you have to transition from one presenter to another, make sure both presenters are well versed in the sharing app and do a couple dry runs. It is easy to have bizarre mistakes like dropping the entire meeting with a dozen participants because somebody fat-fingered something while trying to share a screen.

Make sure that all of YOUR people are in one room. Use a desk phone for audio, it helps keep the presenting team on one page to be physically in one location together.

If you have to set up data in a database, create a "user" or stage things in your app in order to demo, make sure you have that done well in advance. Also, as with any demo, always use a STABLE build, not the sandbox environment build. If your app relies on an internet connection to function properly or outside services of any kind, make sure that you create a backup powerpoint with a series of screenshots showing the demo just in case some connection flakes out in the middle of your demo. That way you just switch to a powerpoint and keep on presenting. Users generally understand and like screenshots if nothing else is available.

Try to keep the presentation down to one machine. As I said, transferring presenter status from one to another machine is a pain point that we have run into again and again.

Finally; understand that not every software engineer is born to be on stage. What I mean by that is that our industry tends to have a lot of people with a certain set of skills and social skills are NOT among them. Your most brilliant developer is VERY likely to be one of your worst choices to actually give the presentation. Find the more outgoing, personable, and well spoken individual (also, obviously, in outsourcing situations, the one who speaks the same language as your customers!) Make sure that the presenter has a GOOD knowledge of the feature being demoed. Also, it always helps to have the original developer in the meeting, with the understanding that they aren't required to say anything unless they want to (which often relieves some stress). That way, if someone says something incorrect about how your app works, the developer can pipe up and correct them right then and there.

Basically, it boils down to planning, keeping things simple, and communicating in advance. Oh, I almost forgot: Assign someone the task of CAPTURING the feedback being given by the customer! That is important. Make sure they try to document what is said, who said it, what slide or part of the live demo it was related to, etc.

Best of luck!

Answer 2

I guess a lot depends on what you are demoing.

For example, if you are doing a mobile app development, or a web site development, then "demo" can be given by doing a screen-share.

There are many tools such as Skype, Google Hangout etc. Using Google Hangout communication tool or similar, , invite can be sent to all "interested" parties. Let them all join on Google Hangout at pre-defined time slot. Once all joined the call, you can "show" them all developed mobile app screens by running the mobile app on Simulator/Emulators.

Similar can be done by for web pages development. This way, all stakeholders can see the actual development done and importantly, can provide a Feedback about the developed screen & functionalities during demo.

Someone from your team can capture these feedbacks as you give demo so that those feedback items are not lost and addressed in future sprint/development activities.

We have been doing this kind of "demos" after each sprint/milestones & so far it has been very much appreciated by stakeholders, who as in your case, are working abroad, in a different geography and different time zone than us.

Answer 3

I can think of three quick possible solutions.

1) Skype. Even if abroad, there's no reason they can't be involved in a demo.

2) Actually send them your increment, along with your list of the changes you made, and have them demo it themselves (sending any feedback back to you, of course).

3) Have the client assign a local delegate, with the authority to make decisions on the client's behalf.