Vijf tips voor remote demo’s

Het geven van demo’s (bijvoorbeeld als onderdeel van de Sprint Review, waarbij je nieuwe features laat zien) is een vak apart. Bij iChoosr, mijn huidige project, doen we dat deels remote. Het kan natuurlijk altijd beter, maar het loopt nu ook al vrij soepel. Wat we geleerd hebben vat ik voor je samen in een aantal tips!

Context

Bij ons project gebruiken we Scrum, met sprints van één week. Iedere week leveren we dus werkende, vernieuwde software op. Tijdens de Sprint Review geven we een demo van wat er allemaal veranderd is.

De stakeholders bij de demo zijn verspreid over een aantal locaties. Per locatie zitten er tussen de 1 en 8 personen. Op een locatie met meerdere personen zit men in een vergaderruimte waar één persoon de video call op een groot scherm voor de rest toont.

Belangrijk hierbij is vooral dat de demo ‘Semi-Remote’ is. Anders gezegd: het is zeer anders dan wanneer iedereen op een andere locatie zit. Op bepaalde manieren is het daarmee extra moeilijk om goede demo’s te doen. Bijvoorbeeld omdat de verleiding groot is om ‘vluchtiger’ te praten met mensen naast je, waardoor remote mensen het niet kunnen volgen en dan afhaken. Dit gevaar zie je ook terug in een aantal van de tips.

Tips!

Deze lijst is niet uitputtend natuurlijk. Demo’s geven lijkt enorm op presentaties geven, dus de tips voor ‘content’ laat ik over aan andere blogposts. Hieronder wil ik vooral de aandacht vestigen op tips omtrent ‘vorm’.

Tip 1: Regel perfect werkende Audio en Video

Dit lijkt een no-brainer, maar dat is het niet! Let namelijk vooral op dat er staat: ‘perfect werkende’, en niet ‘perfecte’ A/V. Het is makkelijk in de verleiding te raken een “ultieme” A/V opzet proberen te behalen. Maar te vaak krijg je dan dit:

“Sorry, we need some time to fix our A/V issues…”

Dodelijk! Ik gebruik liever de mic en lullige speakertjes uit mijn laptop, dan dat ik mijn stakeholders 3 minuten laat ‘genieten’ van stilte, knallende pieptonen, echo’s, en ander gedoe.

Begrijp me niet verkeerd: ik ben dol op een goed werkende geavanceerde opzet. Eentje met een briljante speakerphone met perfect geluid, en een webcam waarop iedereen te zien is. Maar een matig werkende versie daarvan: weersta de verleiding! Ga liever voor een perfect werkende opzet, dan een poging tot ‘perfectere’ opzet.

Tip 2: Verifieer je opzet

Eerste keer? Heb je onbekende A/V hardware of software? Doe dan een test call minstens een uur van tevoren. Ga niet je opzet regelen vlak voor of tijdens de demo!

Elke keer: minimaal 5 minuten van tevoren de zaken opzetten. Zorg dat je klaar bent om te gaan zodra de stakeholders aanhaken. Hun feedback is belangrijk voor jou en je project, dus maak het zo fijn mogelijk om erbij te zijn!

Als je bijna wilt beginnen: doe een laatste check. Vraag of iemand op een remote locatie kan bevestigen dat je goed te verstaan bent en of je screenshare goed werkt.

Tip 3: Demo alleen wat werkt

Demonstreer alleen dingen die werken! En zorg dus dat je weet wat werkt. Kortom: oefen de demo kort van tevoren, en streep dingen die nog niet werken eruit.

Wij doen Scrum met sprints van een week, en als je liever Kanban doet kun je ook regelmatig demo’s doen. Kortom: een feature die nog (net) niet af is komt de week erop wel. Wees hierbij zeer streng voor jezelf: raak liefst nooit in de verleiding om ‘bijna af’ te demonstreren. (Je kunt eventueel wel noemen dat je nog bezig bent met bepaalde feature.)

Tip 4: Herhaal vragen en behandel ze kort

Feedback en vragen zijn essentieel bij de Sprint Review: daar gaat het nou juist om! Als je een vraag krijgt, herhaal of beter nog parafraseer die vraag dan, want:

• Je weet zeker (zie tip 2!) dat iedereen jou goed kan horen, dus dan weet iedereen wat de vraag is en verlies je niet de aandacht van mensen.
• Indien nodig kun je vragen (voor of na je antwoord) of de parafrasering goed hebt gedaan, en dus of je de vraag hebt begrepen (worst case heb je een andere interessante vraag beantwoord).
• Je kunt context geven tijdens het parafraseren, en de vraag beter beantwoordbaar maken.
• Het geeft je tijd om na te denken over een goed antwoord.

Behandel de vraag vervolgens kort, en vergeet niet:

• Met mate is “moeten we uitzoeken” een prima antwoord
• Verontschuldig niet, maar leg uit: “Die feature hebben we nog niet maar kunnen we zeker bouwen” is een prima antwoord

Oh, en niet iedereen heeft interesse in langgerekte discussie over losse punten. Dus het is prima om een punt af te kappen en later in kleinere setting op terug te komen.

Tip 5: Kijk opnames terug

Eerst tijd voor een bekentenis: deze tip mag ik zelf wel wat meer opvolgen…

Idealiter neem je demo’s op (kost bijna niets met de juiste tooling). Kijk vervolgens ook de opnames van je eigen demo’s terug.

Oké, het kan heel ongemakkelijk zijn om jezelf terug te horen, maar het is wel heel leerzaam. Hier zijn wat dingen die ik heb geleerd waar ik op moet letten:

• De audio was met bepaalde tools niet optimaal (dit merk je enkel als iemand op een andere locatie, of evt de server, de opnames maakt)
• Ik moet werken aan ehmmm… het gebruik van bepaalde ehmmmm… stopwoorden
• Mensen op remote locaties zien je lichaamstaal en gebaren niet (wijs dingen aan met je muis, niet met je vingers!)
• Sommige applicaties moet ik inzoomen, want de tekst is niet leesbaar als A/V artefacten optreden bij tijdelijk slechte connecties.

En er is vast nog meer. Zoals ik zei: ik moet hier aan werken!

Tot slot

Remote demo’s kunnen heel goed werken. Maar dat gaat niet vanzelf! Het is verleidelijk om vooral bij de inhoud van een demo te blijven: te focussen op de content. Maar de content komt alleen uit de verf als de vorm klopt!

De bovenstaande punten zijn mijn belangrijkste aandachtspunten, na een paar maanden ‘oefenen’. Maar net als bij Agile Development: blijven verbeteren is belangrijk! Dus als je nog andere tips voor me hebt: kom maar door!