Als je maar even Googelt op “hypothesis-driven development”, dan vind je al snel het volgende sjabloon voor hypothese-gedreven ontwikkeling:

Wij geloven dat verandering resulteert in uitkomst.
Wij weten dat we geslaagd zijn zodra we zien dat metingen.

Uit de heup geschoten een voorbeeld voor een attractiepark:

Wij geloven dat het helder tonen van actuele wachttijden in onze app resulteert in toename van mond-tot-mondreclame door ‘maximizers’.
Wij weten dat we geslaagd zijn zodra meer dan 10% van de bezoekers via de app desgevraagd aangeeft aangespoord te zijn door iemand die bij ons bekend staat als ‘maximizer’.

Zo’n hypothese betekent dat je moet weten:

  • of iemand bekend staat als een ‘”maximizer”’; en
  • met wie een ‘”maximizer”’ zijn aanbeveling heeft gedeeld.

Om dergelijke statistieken te verzamelen dien je daar dus ook voorzieningen voor in te bouwen in de app en in de achterkant.

Natuurlijk verdient zo’n hypothese slijp- en polijstwerk. De meeste waarde zit in de gesprekken over de totstandkoming van zo’n hypothese.

Bespreek de volgende vragen om veel van onze aannamen en afhankelijkheden bloot te leggen:

  • Hoe goed helpt deze hypothese ons bij het maken van de juiste keuzes?
  • Wat is er voor nodig om de meestbelovende scenario’s te realiseren?
  • Welke onbedoelde gevolgen—zowel goed als slecht—kunnen ontstaan?
  • Hoe kunnen we potentieel positieve kanten koesteren en eventuele nadelen voorkomen of verzachten?
  • Wie dienen er betrokken te zijn?

Een pittig gesprek over deze vragen leidt soms tot een hele waterval van voorlopige experimenten om de hypothese te toetsen.

Stap voor stap

Gebruik de onderstaande stappen voor elke individuele verandering:

  1. bepaal de rangorde:
    • bepaal de volgende stap;
    • houdt veranderingen waar je je nog niet toe wilt verplichten tegen—je kunt maar een beperkte hoeveelheid werk verzetten;
    • breng de discipline op om wensen die voorlopig waarschijnlijk niet bovenaan de verlanglijst verschijnen te weigeren.
  2. onderhandel over de uitzonderlijke details—dit loopt in sommige gevallen parallel met prioriteren;
  3. bewijs dat het geheel inderdaad zo haalbaar, werkbaar en bruikbaar is als je dacht;
  4. verifieer dat je de verwachte resultaten behaalt en leg inzichten vast;
  5. voer de verandering permanent in of draai deze terug.

Dergelijke processen lenen zich zeer goed voor beheer middels een kanban systeem. Er is een mooie symmetrie hier—je MVP’s en wijzigingen in de organisatie of het proces kunnen makkelijk gezamenlijk worden beheerd met behulp van gereedschappen die veel Agile teams heel vertrouwd vinden.

Wil je gelijk of wil je geluk?

Ga ervan uit dat je hypothesen en aannamen fout zijn. Je doel is om een succesvolle zaak op te zetten, niet om gelijk te krijgen. De hypothesen zijn slechts een instrument op weg naar zakelijke zin.