Whale Spotting – Demo

For this exercise you’ll be holding a demo for the mini-project you’ve been working on as a team for the last two weeks.

Demos are used as a way of showing the client what progress has been made on a project. Your team lead will decide which features need to be demoed, and which developer will demonstrate it. During the call each team member will in turn share their screen and demonstrate the features assigned to them. After each feature the client is given time to ask questions and give feedback.

Teams usually hold a demo at the end of every sprint as well as at major milestones of the project. Demos are often to a larger audience, also including people who are less involved with the project day-to-day.

Why Do We Hold Demos?

As mentioned above the main purpose of a demo is to show the client what progress has been made on a project. They often won’t have much visibility of what developers are working on day-to-day, so it’s useful for them to have a regular check-in.

It’s also useful for the team to be able to take stock on progress. It gives good visibility on what the rest of the team has worked on, and is an opportunity to celebrate the team’s hard work.

Demos are a good opportunity to get early feedback on a project from the client, so small tweaks can be made before the final product is delivered.

What Makes A Good Demo?

Remember Your Audience

The people you demo to are mostly non-technical. So it’s important not to delve into the technical details of what you’ve worked on as this will not be interesting for them and might confuse them. Use non-technical language. For example, talk about clicking a button rather than sending a request to the server.

Try to see the product through their eyes. Show them what you’ve done rather than how you did it. Generally it’s best to focus on “visible” changes. Things like new buttons or changed styling. This could also include things like performance improvements like a page loading much more quickly. You can rely on their memory for what things looked like or loaded like before rather than showing a before and after.

Having said that, always think about what the appropriate level of technicality is for your audience. There are times when more technical language and topics are appropriate – for example, if you are presenting a proposal for a system architecture to a client’s Chief Technical Officer, then they will want to be given technical details so that they can assess whether the proposal is suitable. Think ahead about what matters to the audience and how technical they are, but be ready to adapt if you get asked technical questions in a non-technical presentation or vice-versa.

For this exercise, consider your trainer to be a non-technical customer.

Some changes don’t translate well for demos. With most refactoring for example – there isn’t anything to show as the behaviour should be unchanged. This doesn’t make the work any less valuable! Make sure to celebrate good “behind the scenes” work within your team, perhaps in other meetings like retros.

Keep Things Brief

Demos can be long meetings to sit through, so it’s important to keep things as brief as you can. It’s normal for some members of the team to have more to demonstrate than others in a given sprint and it’s tempting to try and fill time to take as long as everyone else. But the point of a demo is to see the whole team’s progress rather than to scrutinise individual members.

“We didn’t have time…”

A common pitfall when hosting a demo is to point out incomplete things and say things like, “this was working before” or “we ran out of time to finish this”. It’s best to stick to talking about what has been done.

Ideally anything unfinished or broken should not be visible at the point of the demo. However if something does come up unexpectedly you can talk about as something that will be implemented or fixed in a future sprint.

Last Minute Merges

It can be tempting to try and squeeze in extra features last minute before a demo. However, this is best avoided!. You run the risk of breaking things and stopping anything from being demoed. It’s much better to be missing one feature than all of them! Teams often set a cut off time where nothing can be merged unless it’s fixing a problem that would affect the demo.

Declutter Your Screen

As well as things you do want the client to see, consider if there’s anything you don’t want them to see. For example:

• Things that are private – like personal messages
• Things that could look unprofessional
• Things that will be distracting for the audience

Some useful things to check for:

• Have you closed all unnecessary tabs and windows?
• Have you turned off anything that might give you a notification – for example emails or Slack messages?

Dealing With Nerves

Presenting your work to the client can feel quite intimidating. Remember, it’s okay if things don’t go perfectly during a demo – in fact, they often don’t! Feeling well prepared can help with nerves. There are some things you can do in advance to help take the pressure off you during the demo:

• Have everything open and ready to demo before it’s your turn. So that you don’t have to worry about finding things or waiting for things to load on the spot
• Write yourself a quick list of the steps you need to take that you can quickly refer to if you lose your place while presenting.
• Practice it beforehand, so you’re confident everything works as you expect.