Alles over de feedbackloop: zo creëer je effectieve sprints

Na weken of maanden hard werken staat eindelijk de nieuwe bestelmodule op de website live. Nu hoop je natuurlijk dat je bezoekers direct gebruik maken van je nieuwste aanwinst. Maar ondanks dat je veel tijd en moeite hebt gestoken in de ontwikkeling ervan, zie je geen effect. Bezoekers zijn gelijk weer weg. Hoe komt het dat het niet werkt? Gelukkig is hier een oplossing voor: zorg voor een feedbackloop in elke sprint.

In dit artikel beschrijf ik 2 manieren om te zorgen dat elke sprint een feedbackloop vormt voor nieuwe initiatieven, zodat teams beter onderbouwd aan de slag gaan. Hierbij zijn 2 uitgangspunten essentieel, namelijk: Outcome over Output en Jobs to be Done.

Outcome over output

Dit concept werd in 2019 geïntroduceerd door Josh Seiden. Josh geeft in zijn gelijknamige boek het volgende aan over Outcome over Ouput:

”In the old days, when we made physical products, setting project goals wasn’t that hard. But in today’s service- and software-driven world, “done” is less obvious. When is Amazon done? When is Google done? Or Facebook? In reality, services powered by digital systems are never done. So then how do we give teams a goal that they can work on?Mostly, we simply ask teams to build features—but features are the wrong way to go. We often build features that create no value. Instead, we need to give teams an outcome to achieve. Using outcomes creates focus and alignment. It eliminates needless work. And it puts the customer at the center of everything you do. Setting goals as outcomes sounds simple, but it can be hard to do in practice”.

Een verder toelichting is ook te vinden in deze webinar van Josh Seiden uit 2020.

Kort gezegd: zet je bezoeker centraal bij alles wat je doet. Dit doe je door te bouwen aan resultaten die aansluiten bij de wensen van bezoekers. Maar hoe weet je welke wensen bezoekers hebben?
De wensen en problemen van websitebezoekers kun je in kaart brengen door usability testen, design sprints, “double diamonds” en experimenteren. Hierbij is het van belang om uit te gaan van je bezoekers ’Jobs To be Done’.

Jobs to be done

Misschien heb je van dit principe gehoord, maar Jobs To Be Done is in het kort het antwoord op de vraag: Wat hoopt je bezoeker te bereiken als diegene jouw product of dienst afneemt?

“​​After decades of watching great companies fail, we’ve come to the conclusion that the focus on correlation—and on knowing more and more about customers—is taking firms in the wrong direction. What they really need to home in on is the progress that the customer is trying to make in a given circumstance—what the customer hopes to accomplish. This is what we’ve come to call the job to be done” – “Know Your Customers’ “Jobs to Be Done” door Harvard Business Review

In de praktijk zien we dat deze uitgangspunten om je klant te kennen vaak los staan van het agile/scrum proces. Dat is zonde, want dan worden er dingen gebouwd zonder feedbackloop vanuit de eindgebruiker. Met als gevolg dat je verrast zult zijn wanneer je harde werk niet het verwachte effect heeft gehad. Zoals beloofd, geef ik je in dit artikel twee opties waarmee je van iedere sprint een feedback loopt maakt. Waar ik schrijf over experimenten kun je ook onderzoeken lezen, of vice versa.

Optie 1: Een percentage aantal experimenten of onderzoeken per sprint

Er zijn organisaties die afspraken hebben gemaakt over het percentage aantal experimenten per sprint. Het is dan van belang dat iedereen in het team actief aan de doelstelling werkt. Het management stuurt het scrumteam met eventueel een CRO-specialist aan in hun doelstellingen en persoonlijke plannen onderling. Wanneer de aanpassing live gaat, wordt deze gemonitord en geanalyseerd. De uitkomsten worden meegenomen in het definiëren van de aanpassingen en features op de backlog.

Voorbeelden hiervan:
Doel: # experimenten per sprint.
Doel: 25% van de backlog is een experiment.

Valkuil: ongeduld
Er is een belangrijke ‘maar’. Het monitoren en analyseren duurt vaak 1 tot 4-5 weken, voordat de uitkomsten helder zijn. Ongeduld is in de praktijk vaak een van de grootste valkuilen bij een effectieve sprint. Door een aantal experimenten per sprint te bespreken, kan er nog steeds veel live gaan zonder de effecten te bekijken. Daarnaast komt het vaak voor dat de testen relatief klein zijn (copy/kleurtesten) omdat de sprint al volgepland is.

Optie 2: Het discovery en deliveryproces sluiten op elkaar aan

Er is ontzettend veel geschreven over het achterhalen klantwensen door middel van onderliggende stappen en onderzoek in een Discovery Sprint. Google Discovery Sprints maar eens. Daarnaast is er ontzettend veel geschreven over scrumwerken (delivery) en hoe dit toe te passen in organisaties. Een combinatie van discovery en delivery sprints zie je niet veel, terwijl ik in de praktijk zie dat hier de wrijving zit. Hoe zorg je ervoor dat het bouwen van features en nieuwe concepten niet losstaat van het uitdenken ervan met hulp van klantfeedback? Hoe monitor je wat je live zet en hoe neem je die resultaten mee in het “aan de voorkant” uitdenken van je producten? Hoe zorg je ervoor dat zoveel mogelijk wat live gaat is getest en weet wat voor effect het heeft? De volgende drie stappen zullen je helpen.

Stap 1: Blijf experimenteren met je scrumteam.
Leer wat wel/niet werkt op je huidige platformen en neem deze inzichten mee in je nieuwe concept. Heb je geen bestaande platformen, sla dan deze stap over.

Stap 2: Denk goed na over je teamsamenstelling om de beiden sprints in elkaar te laten overgaan.
Naast het development- en scrumteam, werk je ook met een tweede team met een product owner, conversie specialist, psycholoog, designer en eventueel een data analist of coordineert het product team in de feedback vanuit gebruikers en naar het development team toe. Deze teamleden verzamelen de inzichten over klanten of hun “Job To be Done”.

Stap 3: Zorg dat je in het ritme van de sprint meegaat.
Organiseer elke week een discovery sessie waarin je de uitkomst van onderzoeken combineert. In deze sessie werk je de uitkomsten uit naar designs of backlog items die opgepakt kunnen worden.

En voila: zo creëer je een continue feedbackloop!

customer experience feedback loop
Lean UX binnen een Agile omgeving, door Dave Landis

Tot slot: aanvullingen, ideeën en DiDo#40

Er zullen vast nog veel manieren zijn om steeds beter onderbouwd te werken. Ik hoor graag van je als er aanvullingen of ideeën zijn! En: we organiseren op donderdag 3 november weer een  DiDo: Results are not Learnings en daar kan jij ook bij zijn! Meld je aan via het formulier op de eventpagina. Zien we je dan?

Lotte Cornelissen - Product Director

Inmiddels ruim 17 jaar ervaring in digitale ontwikkeling, strategie & techniek. Ik ben Product Director. In deze functie combineer ik het managen van het team van geweldige experts met het ontwikkelen van nieuwe adviesdiensten. Naast mijn werkzaamheden voor Online Dialogue ben ik vrijwilliger bij de Johan Cruijff foundation en ben ik graag op pad met mijn gezin, familie en vrienden.