En waarom vonden we dit ook alweer een goed idee?
Het maken van rationele keuzes en de documentatie ervan is een onderbelicht element in het ontwerpproces en in de (corporate) startup. Dat kan tot veel gedoe en rework leiden. Hoe voorkom je dat?
‘Waarom hebben we toen ook weer gekozen voor deze flow?’ Het is een vraag die zomaar op kan komen in je Corporate Startup. ‘Dat hebben we toen geleerd in interviews, geloof ik’, zegt iemand. Maar welke interviews? En hoe significant was die data? En is dat nog actueel, nu we zaken hebben aangepast? Wat waren eigenlijk onze alternatieven? En op basis van welke argumenten hebben we toen besloten voor deze? Het voelt nu eigenlijk als zo’n vreemde oplossing.
En dan hebben we het nog maar over vragen van het team zelf. In de meeste Corporate Startups spelen er ook nog eens allerlei stakeholders een rol. Denk aan de verantwoordelijk managers of misschien zelfs de RvB. En die waren niet zelf bij de besluitvorming.
Als de doelen wel gehaald worden is er zelden iemand die de gemaakte keuzes en de argumentatie nog eens fijntjes wil uitdiepen. Maar als dat niet het geval is, zijn team en stakeholders vaak geïnteresseerd in besluitvorming, niet zelden over allerlei details. ‘Maar waarom heb je toen dan ook deze flow gekozen, terwijl de concurrent juist zo’n succes heeft met die andere oplossing?’. ‘Nou, eeehm…’ en je kijkt je teamgenoten hulpbehoevend aan.
Het liefst zou jezelf terugteleporteren naar dat moment voor het scrumboard of aan tafel. Of realistischer; het even ergens opzoeken. Maar de reden dat je het niet allemaal hebt verwerkt tot vuistdikke documentatie, is dat je als corporate startup graag Lean en Agile wilt werken. We willen dus geen grote documenten schrijven, of paginalange Corporate Decision Making Balanced Score Cards invullen. Daarvoor waren we nou juist op een andere manier gaan werken, toch?
In dit blog breek ik een lans voor rationele besluitvorming en Agile documentatie.
Rationele besluitvorming
Allereerst gaat het natuurlijk om de besluitvorming zelf. Hoe rationeel worden de beslissingen in jouw startup genomen? Vaak vliegen de argumenten over en weer de tafel, en wordt in een vrij magisch proces naar een beslissing gewerkt. Zo, dat is gedaan, en nu hup, weer aan het werk!
In mijn ervaring is het werk júist die beslissingen nemen. Het ontwerpproces is in de basis een opeenvolging van divergeren (de breedte zoeken) en convergeren (versmallen). En met name dat laatste vraagt dat er keuzes gemaakt moeten worden. Ontwerpen is: keuzes maken.
En vergis je niet; dat is het moeilijkste dat er is. Want er zijn verschillende perspectieven, uiteenlopende belangen, argumenten op verschillende niveaus en onzekerheden bij elk alternatief.
Daarnaast spelen de omstandigheden waaronder een beslissing genomen wordt vaak een rol. ‘Kom, laten we snel even kiezen voor de lunch!’ is vast een herkenbaar fenomeen. Of ‘We hebben gisteren ook al zoveel tijd verluld!’
Tenslotte spelen er vaak ook ego’s mee. Niet menselijks is de beslisser vreemd. ‘Vorige keer deden we óók al wat jij voorstelde’. Of ‘wie heeft hier nou voor gestudeerd, jij of ik?’ Aan dat soort argumenten willen we natuurlijk zo min mogelijk tijd besteden.
En hoewel ik een groot fan ben van beslissingen nemen op intuïtie, is dat in mijn ervaring in veel gevallen geen interessante oplossing in dit soort ontwerpprocessen. In mijn werk op de TU Delft is scientific reasoning met nadruk een van de vaardigheden die we designstudenten aanleren. Rationele keuzes dus.
Besluitvorming in vier stappen
De beste en snelste manier om dat te doen is met Plussen en Minnen. Het kost je hooguit twintig minuten. Hoe?
Stap 1: Alternatieven
Iemand schetst de alternatieven naast elkaar, liefst snel en beknopt. Wat zijn de opties waar we uit kunnen kiezen? Is dat helder voor iedereen? Waar is nog nadere detaillering nodig? Het is belangrijk dat de alternatieven gelijkwaardig zijn uitgewerkt, en niet het ene een matig geschetst vat vol onzekerheden is en het andere een glimmende en glanzende productieklare dummy. Houd het Agile, en besteed er niet meer tijd aan dan noodzakelijk om de keuze te maken. Timeboxen werkt ook hier uitstekend.
Stap 2: Divergeren
Iedereen in het team neemt vervolgens drie minuten om voor zichzelf te divergeren — dus ‘breed’ te gaan — op de voor- en nadelen van elke oplossing, en schrijft die op rode en groene post-its. Je zal ontdekken dat er veel, originele en bruikbare argumenten op tafel komen. Meer dan wanneer je gelijk begint met het bespreken van de voordehandliggende argumenten.
De post its plak je vervolgens per persoon — eventueel met een toelichting — op het bord bij de verschillende alternatieven, en cluster je even. Samen vul je nog even aan waar nodig. Stop zodra alles duidelijk is. Dit duurt al met al een minuut of vijf.
Stap 3: Wegen
Vaak tellen niet alle argumenten even zwaar mee. Je moet het dus eens worden over een weging. Hoe vaak de verschillende argumenten op het bord hangen kan een indicatie zijn, maar dat hoeft niet per se. Misschien zijn dat gewoon de nobrainers waar mensen nou eenmaal het eerste op komen. je kan een weging aan de verschillende argumenten geven. Zet er dan bijvoorbeeld een, twee of drie uitroeptekens op. Dit duurt een minuut of vijf.
Stap 4: Besluitvorming
Als er een optie duidelijk met kop en schouders bovenuit steekt, kan je die kiezen. Lekker dan! Als er geen optie bovenuit steekt, dan zijn er een paar mogelijkheden.
Optie één: je mist nog informatie. In dat geval schrijf je helder op een post-it welke info je nog nodig hebt, wie die gaat regelen, en wanneer de beslissing opnieuw gepland staat. Denk aan acties als ‘Nog uitzoeken wat de impact op de serverbelasting is’, ‘uitrekenen wat dat voor de businesscase betekent’ of ‘valideren of gebruikers het wel begrijpen.’
Een andere mogelijkheid is dat de opties écht aan elkaar gewaagd zijn. Dan heb je dus een ander besluitvormingsproces nodig. ‘Gooi een dobbelsteen’, zeg ik wel eens. Gevoelsmatig een vreemde keuze om zoiets belangrijks aan het toeval over te laten, maar ja, als de uitkomst daarna opeens niet goed voelt zijn de opties kennelijk misschien tóch niet gelijkwaardig.
Die FOBO (Fear of Better Options) kan je maar bezig houden. Zo raad ik overigens ook iedereen die na 15 minuten Zooveren nog steeds niet kan kiezen uit de twee skichalets aan om even kop of munt te doen. Als het echt iets uitgemaakt had, had je immers al gekozen.
Documenteren kan écht Agile
Rationele besluitvorming is één, maar als we het niet documenteren staan we drie maanden later nog steeds met de vraagtekens op het gezicht.
Maar hoe documenteren we de besluitvorming? We willen er niet teveel tijd aan besteden, want we zijn Agile.
In scrum maken we vaak een fotootje van de schetsen op het bord met de plussen en minnen erbij en knallen die in Slack. Lekker snel, geen moeite en aardig terugvindbaar.
Je kan er voor de handigheid wat tags bij typen die slaan op de beslissing en waarvan je verwacht er later op te gaan zoeken. Het hoeft er niet goed uit te zien, want dat kost alleen maar tijd.
Maak van besluitvorming een ritueel
Besluitvorming leent zich bij uitstek om een ritueel van te maken. Met een duidelijk format, een duidelijke timebox, en een duidelijke manier van vastleggen. Je kan mijn voorzet volgen, maar het is agile, dus inspect & adapt naar hartelust.
Tenslotte: je neemt in je innovatieproces zomaar tientallen bewuste beslissingen per dag. Voor welke gebruik je dit ritueel nou? Ik zou zeggen: voor díe beslissingen die je verwacht in de toekomst terug te willen zoeken. Beeld je in dat je over drie maanden met je team vertwijfeld naar je product staart, voor de RvB staat of bij je investeerder aan tafel zit. Is dit dan de keuze waar iemand naar gaat vragen? Dan weet je nu hoe je zorgt dat je niet met je mond vol tanden staat.