De onzekerheid in onze samenleving lijkt toe te nemen. Alles gaat sneller, verandert sneller, is meer verbonden met en dus afhankelijk van andere organisaties en systemen. De standaardreactie op onzekerheid is vaak: meer en beter plannen. Volgens mij is leren de enige manier om onzekerheid te verkleinen. Leren wat wel en niet werkt. Leren wat de klant wel en niet wil. En wel zo snel mogelijk. Leren doe je niet door te plannen, maar door te doen. Hoe? Het Scrum framework en het boek The Lean Startup van Eric Ries vullen elkaar op dit punt goed aan.

Laat je niet misleiden door de titel “The Lean Startup”. Hoe je als black belt je eigen bedrijf start? Nee, dit boek gaat niet over Lean Six Sigma en het woord “Startup” wordt in het boek zelf door Ries veel ruimer gedefinieerd. Gelukkig geeft ook de ondertitel aan dat het boek voor een veel grotere groep mensen interessant is: “How Constant Innovation Creates Radically Successful Businesses”.

Onzekerheid

De onzekerheid in bedrijven lijkt toe te nemen. Technieken worden complexer, afhankelijkheden nemen toe, klanten en medewerkers veranderen. Ik ben bij veel ontwikkeltrajecten betrokken geweest, maar nooit was vooraf exact duidelijk hoe onze gebruikers de software zouden gaan gebruiken. Steeds werden we verrast door hoe echte gebruikers onze software gebruikten, ondanks uitgebreide interviews met potentiële gebruikers, review sessies op basis van prototypes en de betrokkenheid van diverse domeindeskundigen en klantvertegenwoordigers. Soms was er sprake van uitloop in kosten en doorlooptijd; niet omdat we als team niet hard genoeg werkten of niet goed genoeg waren, maar omdat we geconfronteerd werden met zaken die we onmogelijk vooraf hadden kunnen weten.

Vaak is de standaard reflex: ons plan was niet goed genoeg, onze inschattingen van kosten en doorlooptijd moeten beter, we moeten gaan werken met onzekerheidsmarges, met best case en worst case scenario’s, we hadden nog een prototype moeten maken.

Volgens het Agile Manifesto dat aan de basis ligt van Scrum is het beter om meer aandacht te besteden aan “Responding to change” en minder aan “Following a plan”. Accepteer dat productinnovatie grote onzekerheden kent, ga er van uit dat je plan verandert en besteed je energie aan het snel en adequaat kunnen reageren op nieuwe omstandigheden en niet aan het opstellen van omvangrijke plannen.

Leren

De enige manier om onzekerheid te verminderen is leren. Begin zo snel mogelijk met leren en doe het zo vaak mogelijk. Vooral op dit punt voegt Ries in zijn boek zeer bruikbare inzichten toe. Met zijn leercirkel “Build – Measure – Learn” geeft hij aan dat innovaties (of nieuwe features) uitgaan van een hypothese over de toegevoegde waarde bij klanten. Je verwacht als team dat de gebruikers blij worden van de mogelijkheid om zoekopdrachten te kunnen opslaan. Begin dus met het scherp formuleren van de onderliggende hypothese. Wat doe je voor wie en waarom? Stel dan ook vast hoe je die hypothese gaat toetsen. Hoe meet je of je gebruikers echt blij worden van die feature? Vervolgens bouw je niet alleen de feature zelf, maar ook de test van je hypothese. Zodra je feature gereed is en echt gebruikt wordt kun je meten of je hypothese klopt. Het team leert hiervan en kan gebaseerd op de nieuwe informatie nieuwe hypotheses opstellen en de cirkel is compleet.

Iedere keer als je de leercirkel doorloopt leert het team. Het is dus zaak om de cirkel zo veel mogelijk te doorlopen en daarbij helpt het als één rondje door de cirkel zo kort mogelijk duurt. Dit sluit precies aan bij de iteraties in Scrum: zo kort mogelijke sprints leveren echt werkende software op, die echt gebruikt wordt.

Vraag je in het begin niet af wat de klant minimaal nodig heeft om te kunnen werken, maar wat jij minimaal nodig hebt om te kunnen leren van de klant.

Als je wilt leren van klanten die je nieuwe product echt gebruiken, hoe kun je dan zo vroeg mogelijk starten met leren? Daar komt het concept Minimum Viable Product bij kijken. Hiermee wordt de eerste, minimale versie van je nieuwe product bedoeld die je in staat stelt om te starten met de leercirkel. Scrum als framework zegt weinig over de startfase van een project en hier geeft The Lean Startup houvast. Vraag je in het begin niet af wat de klant minimaal nodig heeft om te kunnen werken, maar wat jij minimaal nodig hebt om te kunnen leren van de klant. Uiteindelijk krijgt de klant dan het meeste waarde voor z’n geld.

Minder plannen en meer leren

De kunst is dus minder plannen en meer leren. Ga eens na hoeveel tijd en energie er in traditionele organisaties gestoken wordt in het plannen en alles eromheen. Om te beginnen moet een plan worden gemaakt, meestal door beste (en dus meest schaarse) resources in de organisatie want het plan moet wel kwaliteit hebben. Vervolgens wordt het plan besproken en aangepast en nog eens besproken en nog eens aangepast. Als eindelijk wordt gestart met de uitvoering van het project, dan komen de onvermijdelijke en vaak uitgebreide rapportages om de hoek. Wat is de voortgang op het plan? Liggen we op schema? Hoe staat het met de kosten? Bij afwijkingen volgt escalatie en, als het echt tegenzit, evaluatie: waarom wijken we af van het plan en hoe komen we zo snel mogelijk terug op het geplande pad? En steeds worden onze beste mensen ingezet, want het management wil beslissen op betrouwbare informatie. Maar wat zegt het dat we 30% afwijking hebben van een baseline die een half jaar geleden werd vastgesteld door die ene briljante business analist?

Stel dat we alle tijd en energie die we in het plannen, rapporteren, escaleren en evalueren steken kunnen besteden aan het versnellen van de leercirkel. Ok. Het opstellen van een hypothese kun je zien als plannen. Het meten van je hypothese lijkt op rapporteren en leren klinkt als evalueren. Maar het grote verschil is dat je zo snel mogelijk leert wat de klant waardevol vindt en wat echt werkt.

Steven Happee helpt organisaties bij het realiseren van hun doelstellingen middels Agile Werken. Als Agile Coach, Scrum Master of Product Owner. Steven heeft een achtergrond in ICT en Bedrijfskunde.