No More Sucky Demos

Ever seen a sucky demo? One that doesn’t start on time, with technology issues, too many people in the room, people on the phone not on mute, confusion over what stories will be demo’d and who will demo them? Let’s have no more sucky demos. Here are some thoughts on how to make that happen.

Plan It!

Decide which stories need to be demo’d well in advance of the demo. Some teams decide this before or during sprint planning. Go a little further and specify the demo script in advance, sort of the Acceptance Criteria for the completed demo. Just add that to the story description. Make it part of story grooming and the story readiness criteria (i.e. a story can’t be taken into a sprint without demo requirements specified). During planning, put a sub-task on the story for doing the demo and assign it to someone at some point during the sprint. At the very latest, decide and publish the demo plan at least 24 hours in advance. The Product Owner (PO) should have a say in that decision.

“Ok, we’ll get started in a few minutes… just waiting for a few more people to join.”

Start on time. Give no quarter. Find out how to turn off the announcement chimes (entry and exit chimes) and on-hold beeps in WebEx and GoToMeeting.

• In GoToMeeting on Mac, in the Audio pane, there is a drop-down button to turn this off. I’m told there are 3 dots in the Audio pane on Windows. Click that. It used to be an Edit button and may still be if you have an older version of GoToMeeting or GoToWebinar?
• I’ve read about how to do this in WebEx, but haven’t tried it. Check the audio settings.

“Ok, we need a few more minutes, we’re still getting set up here.”

Practice. Those doing the demo need to get exceptionally good with the tooling (Screen share, audio conference, video conference, projector/monitor, starting on time, muting, volume, changing presenter, etc.). Don’t wait for improvements to come with time. Be intentional. Have each person who will ever be involved in a demo watch the training video for presenters that are provided from gotomeeting or webex or whatever. Find such a video and have everyone watch it.

Have a GoToMeeting/WebEx kata. A Kata an exercise of scripted activities to do. Like a coding kata, have kata for everyone to practice using GoToMeeting/WebEx. They could do the practice with an intern, or together in pairs, especially in onshore/offshore pairs. It should cover give and accept presenter mode, share screen, share screen 2, stop sharing, share individual app, turn on mic, turn off mic, muting other people, turn volume up and down, set someone else as presenter, turn off entry/exit chimes, turn off on-hold beeps, etc.

“Oh, uh, I don’t know why it did that. Wasn’t expecting that.”

Rehearse. Do a dry run. Don’t surprise the PO. Your PO should see working software before the demo.

Faster Feedback

Another alternative is to have the tester/developer call for a live demo during the sprint as stories are finished. Just call the PO over and show ’em what you’ve got running.

This might not work if you have a large team or a large number of people on the PO Team or a large number of PO’s and BA’s that need to see the demo. To deal with that, maybe allocate daily demo time, kind of like PO office hours. Or only require that story’s one BA (instead of all the BAs and POs) see the demo.

Asynchronous Demos

Record it. As an alternative to a long demo with everyone in the room on the last day of the sprint, consider having the developer and tester who did the story record their demo as they finish the story, then send out the link to the recording. This will get feedback from PO’s and BA’s earlier in the sprint. This will allow Product Support and new hires to watch demos later when it is more relevant to them. It will also allow people to only watch the demos they care about.

Recording will also allow the team to do it over if it doesn’t go well the 1st time they attempt to record it.

People can still ask questions, just offline. The only downside is that everyone can’t hear the questions that others ask, but you could post the recordings on yammer or confluence or somewhere so that Q&A can be done online.

“…so now I’m going to show you… Hi. Who just joined?”

Sometimes there are too many people in the demo. Too many voices, too many side conversations. Some people don’t seem interested. Some people join the conference call late.

Consider excluding non-essential people. Make the focus of the demo to suit the needs of the BA and PO only. Disregard the secondary purpose of the demo, which often is for other people to know about recent changes. Another option to consider would be to record the demos or to have separate demos for the secondary purpose (to narrow the audience and improve focus).

Rock the House

A great end of sprint demo will turn people on to agile and increase support for your team. Do them well, or don’t do them at all.