Sinds de jaren negentig bevind ik me al in de wereld van softwareontwikkeling. Na vijftien jaar ervaring met wat men ‘waterval’ is gaan noemen, ben ik sinds 2005 bezig met scrum. Scrum was een verademing, na de afstandelijke contractgestuurde samenwerkingen uit het vorige tijdperk. Ik was vooral blij met het uitgangspunt dat je als opdrachtgever en opdrachtnemer naast elkaar staat voor hetzelfde probleem, in plaats van tegenover elkaar, waarbij je elkaar gaat zien als het grootste probleem.

Maar ook Scrum was niet zaligmakend. Net als iedereen die lang met scrum werkt, kwam ik vijf grote ergernissen tegen. Dezelfde die iedereen tegenkomt, lees de forums er maar op na.

Lange tijd zag ik deze ergernissen als ‘nadelen waar ik maar mee moest leren leven’. En zo kwam het dat ik dan ook jarenlang met deze vijf ergernissen zat opgescheept:

1. Het is nooit zeker wat er allemaal af is in een sprint
De oorzaak hiervan is vooral het feit dat bij Scrum het in detail uitwerken van de wensen onderdeel is van de sprint. Dat maakt niet alleen dat bij de start van de sprint het detailniveau onvoldoende is voor een goede schatting, maar ook dat een lastig te plannen activiteit (namelijk die detailuitwerking) in de sprint zit.

Maar al is de oorzaak simpel, het gevolg is ernstig: andere partijen durven jou en jouw planning niet meer te vertrouwen en plannen voor de zekerheid hun eigen werk er niet direct achteraan. Daarmee wordt het totale project (want je bent nooit alleen, je maakt altijd onderdeel uit van een groot geheel) veel trager dan nodig.

2. Het uitgangspunt ‘Refactoring is a fact of life’
Voor de niet-technici: refactoring houdt in dat je hele stukken code opnieuw tegen het licht houdt en opnieuw ontwerpt, op basis van voortschrijdend inzicht. Door principes als ‘fail fast’ is het net alsof fouten maken beter is dan het de eerste keer goed doen. Het zal wel dat het er nu eenmaal bij hoort, maar het is wel heel kostbaar.

3. De basis-aanname onder scrum is: je kunt vooraf niet weten wat de gebruiker nodig heeft en je kunt vooraf niet weten hoe je het technisch moet oplossen
Dat idee heeft postgevat doordat Scrum groot geworden is met applicaties voor het grote publiek, zoals Spotify en YouTube. Daar is het lastig om de reacties van het publiek te voorspellen. En dus moet je een eerste probeerversie (een MVP) maken en ga je van daaruit verfijnen en verbeteren. Gelukkig hadden we bij het vorige punt iedereen erop voorbereid dat refactoring (weggooien en opnieuw bouwen) nu eenmaal een fact of life is. Maar iedereen begrijpt: experimenteren met de gewenste functionaliteit is vreselijk kostbaar. En er zijn veel situaties waarin het helemaal niet nodig is, omdat je vaak wel degelijk kunt overleggen met je gebruikers en wel degelijk heel veel vooraf weet, als je daar even je best voor doet.

4. Schrijf niks op, doe alles mondeling
Dat is een kort-door-de-bocht versie van het uitgangspunt ‘we prefer working software over large documents’. Ik denk niet dat het de bedoeling van de grondleggers van Scrum was om alle documentatie overboord te gooien, maar op de korte termijn werkt het wel handig en lekker snel. Bovendien appelleert het aan de aversie van developers tegen documenteren. We weten allemaal hoe het gaat met documentatie: iedereen wil het krijgen, maar niemand wil het maken. Maar het maakt je afhankelijk van de kennis bij mensen in hun hoofd. Zodra het resultaat wordt getest door mensen die niet bij de besprekingen waren, of zodra er wisselingen in het team zijn, zit je in de problemen. Je kunt immers tegen de nieuwelingen niet zeggen: hier, lees dit, hier staat wat er is afgesproken. Projecten lopen vaak langer dan vijf jaar en na zo’n lange tijd zit er vaak niemand meer van de oorspronkelijke startsamenstelling nog in het team. En dus wil je écht niet alleen maar afhankelijk zijn van mondelinge informatie.

5. De product owner
Volgens het boekje is hij de uiteindelijke probleemeigenaar in de business. De persoon met mandaat en de persoon met de meeste kennis. Degene die de hele product roadmap zo uit zijn mouw schudt, die in staat is om de rol van de vroegere projectmanager over te nemen én die ongeveer de helft van zijn tijd ook nog bij de developers zit om ze van input te voorzien, wiens techneutenpraat hij bovendien in staat is te begrijpen. Dat is niet een schaap met vijf poten, dat is een hele kudde! De oplossing die vrijwel alle bedrijven hiervoor hebben, is: wijs voor deze taak iemand aan die genoeg tijd heeft. De persoon met de meeste tijd voldoet in de praktijk meestal niet aan al die andere bovengenoemde eisen. Daarmee verandert de product owner van schaap met vijf poten ineens in aangeschoten wild. In alle gevallen is de taakomschrijving van de product owner een onmogelijke opgave.

Samen met een aantal collega’s hebben we sinds een aantal jaar een andere aanpak ontwikkeld. Daarmee verzekeren we onszelf ervan niet meer in bovengenoemde vijf problemen te verzeilen. Deze zogeheten Happy Sprint Machine houdt meer in dan alleen maar: ‘laten we die dingen waar iedereen zich aan ergert, gewoon maar niet meer doen’. Nee, het gaat om een heel nieuwe aanpak. Een aanpak waarbij we – even oneerbiedig gezegd – de heiligverklaring van de developer intrekken. Eén doel, één plan, één team. Business analyse en functioneel ontwerp zijn weer terug op de kaart gezet en er wordt gedegen voorbereidend werk buiten de sprint gedaan. Tot op zo’n niveau dat het werk voor de developers overzichtelijk wordt, accuraat kan worden ingeschat en precies volgens requirements kan worden opgeleverd. Geen excuusshow aan het einde van de sprint, maar 100% behaalde sprints, waarvoor iedereen – leveranciers, developers en met goedkeuring zelfs de klant – een klein stukje van zijn vrijheid inlevert, maar iedereen er een hoop blijheid voor terugkrijgt.

Ron van Wieringen is business companion bij Twycis. Samen met Hans Gort en Arnold Pouls schreef hij onlangs De Happy Sprint Machine (Haystack, 2024). Met zijn inspirerende leiderschap, brede interesse in menselijk gedrag en knowhow van IT weet hij van softwareontwikkeling een geoliede Happy Sprint Machine te maken wat goed is voor de resultaten, voor de organisatie én voor de mensen die erbij betrokken zijn.