How to run a great Sprint Demo

What: Once a sprint, we have a company-wide Sprint Demo, where engineers can show off the work they’ve done in the previous sprint. It’s pretty casual. No powerpoints or vaporware allowed, just live demos of working product (which could be new user-facing functionality, or a command-line tool for internal usage).

Just as sprints deliver small iterations of work, there’s no feature too small to demo. We’ve had engineers show off everything from “I got a new server up… see, you can hit this URL and it gives you a Welcome page!” to “We finally put the finishing touches on this huge multi-month project”…and both receive the same thunderous applause and kudos from the company.

Who: Invite the entire company. It’s essential for Senior Management to attend and participate, to show that this is a valuable use of everyone’s time (which it is… See “Why” below). Our CEO has a running bit where he says “This is awesome!! When can we fucking sell this?” at least once per sprint.

How/Where: Ours are in the lunchroom right after lunch (we have free catered lunch every day…and we’re hiring). If we weren’t already getting fed, I’d bring some snacks or drinks. Any common area where the entire company can gather, with a monitor large enough for all to see what’s going on. It’ll depend on the size of your company. We’ve needed to add more A/V as we’ve grown: larger monitor, Hangouts for remote folks, wireless microphones for participants to ask questions, etc. But it started with just a few people around a monitor, so don’t let A/V scare you off.

Why: It’s really about recognizing the hard work that the dev team puts in, sprint after sprint. One downside of iterative development is that it’s rare when a huge chunk of work is pulled out of the oven, unlike in sales where they go dark for months and then land a huge deal with champagne and liquid shrimp. When devs present their work, they can show off what they’ve accomplished and get recognized by the rest of the team. It’s so simple and light-weight that few people realize it’s a fortnightly venue for dev recognition! Also, it’s a low-pressure way for devs to practice public-speaking skills (see below).

More general best-practices:

Here are a few other things I’ve learned that will make the demo run more smoothly…

• Create a sign up sheet accessible to all, and have folks sign up ahead of time. Then you’ll know the agenda.
• Coach your teammates on how to prepare for giving a demo (especially the introverts). A lot of this is public-speaking best-practices, but few devs have exposure to these skills…
  • Have them practice the demo
  • Have URLs ready so they can walk up to the demo laptop and type them in
  • If applicable, get on the Google Hangout (if presenting remotely or from their own computer)
  • Increase their font size, until it seems ridiculous
  • Speak up
  • Repeat audience questions to make sure everyone heard them
  • Before going into the demo itself, address the Whys: “Why was this built?”, “What customer (or internal) pain-point does this solve?”
• The person giving the demo has the floor, so as MC it’s your job to maintain order. It rarely happens, but sometimes audience members are really excited to jump in with a question/anecdote/etc.
• Other best-practices for meetings apply too: take longer discussions offline, keep things positive and constructive, etc.

Conclusion

Hope this helps! Let me know if you have any questions. It’s a great investment of one hour per sprint, and a fun tradition.