Innoveren op de wetenschappelijke manier

Auteur
Mark Platvoet
Datum

De software-industrie kent veel vaste patronen en werkwijzen. Om echt te kunnen innoveren moeten we die loslaten. Laten we bewijzen wat echt werkt volgens de wetenschappelijke methode.

Ideeën zijn goedkoop

Wat zijn we toch fantastisch als mens, we hebben zoveel nieuwe leuke ideeën. Het kost velen weinig moeite een verfrissende gedachte in de groep te gooien. Ideeën zijn nagenoeg gratis. Het uitwerken een idee is echter alles behalve gratis.

Omdat de uitwerking van een idee kostbaar is moeten we zo snel mogelijk het kaf van het koren scheiden. Dat begint met een kritische houding. Mensen die onderling een idee bespreken en kritische vragen stellen. Enkel het idee dat de eerste test doorstaat behouden we. Hoe sneller we een aantal ideeën van de hand kunnen doen hoe minder we daarna hoeven te valideren. We willen onze tijd vooral besteden aan de goede ideeën.

De overgebleven ideeën moeten worden gevalideerd. Zijn ze echt de moeite waard? Dat kunnen we niet gokken, want een gok is en blijft een gok. Ongeacht wie de gok maakt. We moeten het valideren. Het is dan verleidelijk om een Proof of Concepts op te tuigen. Direct een hoop code te schrijven. Duurder kan haast niet. Ook valideren betekent dat we op zoek gaan naar een zo snel en goedkoop mogelijke manier om ons idee te testen. Werk het bijvoorbeeld uit op papier. Het idee moet getest worden, niet de kennis van de ontwikkelaar.

Lead-time: van idee naar business value

Hoe snel kunnen we eigelijk een idee omzetten naar daadwerkelijk business value? Vraag je eens af wat er allemaal bij komt kijken om het meest eenvoudige idee dat je hebt op in een productieomgeving te krijgen en waardevol te laten zijn. Zet alle stappen eens op stickies. Maak het zichtbaar.

Moet er budget worden aangevraagd? Wanneer komt het op de backlog? Wanneer wordt het door het team opgepakt? Zijn er formele release en test momenten? Afhankelijkheden van andere afdeling? Echt elke stap die nodig is om het in de handen van de gebruikers te krijgen. Als je dat inzichtelijk hebt, heb je de lead-time.

De eerste keer dat ik deze exercitie deed schrok ik wel even. Er gaat toch meer tijd in zitten dan ik gevoelsmatig zou hebben gezegd. Wat nog opvallender is aan de resultaten is waar de meeste tijd in zit: het proces, de ceremonie om het ontwikkelen heen. Verschillende meetings, rapportages, het halen van mandaat bij stakeholders. Allemaal vanzelfsprekende activiteiten die wel degelijk tijd kosten. Een aanrader dus om eens voor een van je eigen projecten inzichtelijk te maken.

Continuous Delivery

Het doel van Continuous Delivery is om zo snel mogelijk waarde toe te voegen. Daarvoor moeten de lead-time drastisch verkorten. Het is dan verleidelijk om direct naar de techniek te grijpen: automatische builds, deploys, tests, enzovoorts. En natuurlijk, het helpt je om de lead-time te verkorten. Het is dus zeker iets dat aandacht verdient.

Automatiseren is een middel. We moeten dus oog hebben voor het gehele proces. Er is daar veel tijdswinst te halen. Zoals ik al eerder schreef schrok ik van de hoeveelheid ceremonie om de projecten heen. Durf daar ook kritisch naar te kijken.

Waarvoor dient nu eigenlijk die urenrapportage? Hoe voegt dat waarde toe? Dat zijn de vragen die we ons moeten blijven stellen bij alles wat we doen. Want dat is de essentie van Continuous Delivery, het weghalen van dat wat niet bijdraagt aan het eindresultaat.

Hypothesis Driven Development

Ik heb al een aantal keer gesproken over waarde toevoegen. Voorlopig zijn we er gemakshalve ook vanuit gegaan dat alles wat we doen waarde toevoegt. Er is echter maar 1 manier om dat zeker te weten en dat is meten. Onze expertise is immers een goed uitgangspunt maar zeker geen bewijs.

We moeten onze aannames testen. Komt de realiteit overeen met de verwachting die we hadden? Bij het opstellen van onze stories moeten we dus wetenschappelijker te werk gaan. Een manier om dat te doen is met stories in het formaat zoals dat uit Hypothesis Driven Development. En ik zeg "een manier" omdat ook dit gewoon een middel is, geen doel. Een story ziet er bijvoorbeeld zo uit:

  • We denken dat het responsive maken van de website
  • Zal leiden tot meer bezoek vanaf mobiele devices.
  • We hebben vertrouwen om door te gaan wanneer we een stijging van 5% in bezoek vanaf mobiele devices zien

Het belangrijke is dus dat we een test hebben, "een stijging van 5% in bezoek vanaf mobiele devices zien", die aangeeft wanneer onze hypothese voldoende bewezen is om deze route vervolgen. Het is dus zaak dat we zo snel mogelijk een test in de handen van de eindgebruikers krijgen, want dan kunnen we meten en dus testen.

Want uiteindelijk is het de meting, de behoefte, van de eindgebruiker die telt. Ons gezond verstand is vooral een goed startpunt.

Experimenteren

We moeten meer gaan experimenteren, de wetenschappelijke methode toepassen op alles. Op proces, op techniek, op elkaar. Het is een houding, een agile houding. Het is hét verschil tussen agile zijn en Agile doen. Volg je braaf de regels van Scrum of meet je wat werkt, snij je weg dat wat niet werkt en verbeter je wat wel werkt?

We moeten experimenteren. Niet enkel op techniek vlak, maar vooral ook op proces vlak. Dat moet de norm zijn, niet de uitzondering.

Bedrijfscultuur moet om

"We moeten innoveren", roept de CEO enthousiast. Innoveren, het toverwoord van de laatste jaren. Wat de CEO werkelijk zegt is: "Jullie moeten gaan innoveren". Vergelijkbaar met de celibataire priester die zegt: "Gaat heen en vermenigvuldig u."

Innoveren is geen taak die je aan iemand mee kunt geven. Het is een bedrijfscultuur waarin falen een leermoment is, geen afschrijving. Elke manager, van hoog tot laag, moet zelf ook innoveren. Het voorbeeldgedrag vertonen. Anderen uitdagen om zichzelf, processen en producten te verbeteren.

De babbelbox vraagt: "Wanneer heeft u voor het laatst geïnnoveerd?"

Denk Groots

Elke innoverende en experimenterende organisatie heeft wel een doel nodig. Een vergezicht om naartoe te werken. Anders hebben we straks geslaagde experimenten die op zichzelf prachtig zijn maar geen coherent geheel zijn. En dan ben je niet maximaal waarde aan het creëren.

Tijd voor een groots plan. Denk het (nu nog) onmogelijke, zet onrealistische doelen. Maak het voor iedereen helder waar we met zijn allen naartoe willen. Stel bij alles wat je doet de vraag of het je helpt je doel sneller te bereiken. Zo nee, dan doe je het niet.

Leer snel. Test wederom je ideeën en verifieer of het inderdaad helpt je doel sneller te bereiken. En begin uiteraard meteen. Een test in de handen van je eindgebruikers is waardevol, een businessplan in de hand van je manager niet.

"Powerpoints go to Sharepoint to die". The new world is a living artefact (with stickies). - Barry O'Reilly

Focus dus op zaken die echt waarde toevoegen en dat gaat enkel met een stip op de horizon.

Recap

We zijn geneigd te werken op basis van aannames. We besteden veel tijd aan activiteiten die niet bijdragen aan het primaire doel. De eindgebruiker is de lakmoesproef en gezond verstand en expertise een goed startpunt. Wees wetenschappelijk in je aanpak. Maak inzichtelijk wat werkt en snij weg dat wat niet werkt.

Inspiratie

Mijn betoog is een samenstelling van de volgende workshops en presentaties die ik heb bijgewoond op de Gotocon 2016 te Amsterdam.

  • Dave Farley - Continuous Delivery Workshop
  • Molly Dishman - Work Smart, Not Hard
  • Barry O'Reilly - Enterprise Just Got Entrepreneurial
  • Ted Neward - Psychology, Philosophy and Programming
  • Dave Farley - Farley's Laws
  • Mark Platvoet - en een beetje van mezelf

Tags

Innovation