Een wereld zonder scrum. Kun jij het je nog voorstellen? Deze agile projectaanpak is voor veel IT- en marketingafdelingen de route naar succes, waarbij een multidisciplinair team software ontwikkelt waar de business om vraagt.
In de praktijk blijkt scrum soms lastiger te zijn dan gedacht. In dit artikel deel ik vijf spelregels met je zodat je samen met het team komt tot een super scrum aanpak.
1. Stakeholders beleggen hun wensen bij de Product Owner
Het is absoluut verboden als een stakeholder zijn wensen (of eisen) via een ander pad dan via de Product Owner met het team deelt. Zelfs niet wanneer een stakeholder het budget faciliteert: dat geeft hem geen extra bevoegdheden.
Stakeholders maken hun wensen kenbaar bij de Product Owner. Deze bepaalt wat prioriteit krijgt en wat er dus gerealiseerd gaat worden. Dit betekent dat iedere stakeholder er op kan vertrouwen dat de Product Owner de juiste keuze maakt. De Product Owner kiest de opties voor webapplicatie of IT-omgeving die de meeste toegevoegde waarde voor de organisatie opleveren.
2. De Product Owner is gekwalificeerd
Om te kunnen vertrouwen op de juiste keuzes, is een bekwame Product Owner dus cruciaal. Het succes van een project valt of staat (voor een groot gedeete) met de kennis, de capaciteit en de inspanningen van de product owner. Al kun je bij een mislukt project niet altijd wijzen naar de Product Owner. Want wanneer vanuit de organisatie wordt gedacht "dat kan Pietje wel even doen, want die heeft nog wel wat tijd over", dan ligt mislukking op de loer. Een scrumproject doe je er niet even bij, en al helemaal niet in de rol van Product Owner.
Een Product Owner heeft de macht om te bepalen wat er wordt gebouwd. Het beschikbaar gestelde potje met geld wordt door hem uitgegeven. Die verantwoordelijkheid is zwaar en moet gedragen worden door iemand die capabel is voor de job. Communicatief vaardig, besluitvaardig en technisch voldoende onderlegd. Waarbij vertrouwen de allerbelangrijkste eigenschap is: je wilt niet dat de keuze van de Product Owner in twijfel getrokken wordt of bij elke beslissing wordt teruggefloten.
3. De voorbereiding wordt zorgvuldig uitgevoerd
Een goede voorbereiding is het halve werk, ook bij scrum. De voorbereiding begint niet bij aanvang van de eerste sprint, wanneer je een volledig team klaar hebt zitten om te gaan bouwen. Al veel eerder zul je aan de slag moeten.
Een goede voorbereiding bestaat op z’n minst uit een productvisie met beoogde doelstellingen. Er moet een zo volledig mogelijke backlog (met user stories) worden opgesteld.
En zeker zo belangrijk is nadenken over de volgende vraag: in welk landschap komt het te bouwen product straks terecht? Wordt het een op zichzelf staand product of moet het een plaatsje krijgen tussen andere bestaande systemen? Heb je hier nog niet over nagedacht of geen sluitend antwoord op, dan heb je een impediment (een blokkerend issue) aan je broek hangen.
Om dit te voorkomen doe je grondig vooronderzoek. Schakel daarbij eventueel de hulp in van een informatie-analist of een technisch architect.
4. Bepaal de DoR en DoD
Ze worden nog weleens vergeten: de Definition of Ready en de Definition of Done. Oftewel: wanneer kan het team met een taak aan de slag en wanneer is een taak volbracht? Beide definities zijn belangrijk, maar met name over de Definition of Done wordt nogal eens gestruikeld.
De DoD kan worden gezien als een kwaliteitszegel op het werk van het scrumteam. Het kan voor een Product Owner heel verleidelijk zijn om daarin overdreven eisen op te nemen. Maar blijf reëel. Hoe uitgebreider de omschreven eis (zoals: het opgeleverde design moet ook volledig werken in een sterk verouderde browser), hoe meer tijd het voor het team gaat kosten. En met welk doel? Juist.
5. Bepaal wanneer het product levensvatbaar is
Het punt met software is dat het nooit écht ‘af’ zal zijn. Als het aan het scrumteam ligt, blijf je eindeloos doorontwikkelen en perfectioneren. Daarom moeten stakeholders samen met de Product Owner gaan zitten voor het definiëren van een MVP: een Minimum Viable Product. Wat is de meest minimale vorm van het te bouwen product en wat kun je met goed fatsoen aan de buitenwereld presenteren?
Kijk uit dat je daarbij niet de ‘minimale vorm’ verwart met gebrekkige of slechts deels functionerende software. Een auto mét stuur maar zonder wielen kan dus geen MVP zijn. Een auto met stuur en wielen maar zonder airco, dat zou best een MVP kunnen zijn. Een MVP bevat dus voldoende functies waar een eindgebruiker ook echt mee aan de slag kan.
Enjoy!
Slaag je erin om alle valkuilen te herkennen en omzeilen, dan kun je veel plezier en genoegen beleven aan een scrumproject. Het team zelf voelt zich vaak bovengemiddeld betrokken bij het opleveren van goede resultaten en stakeholders vinden het leuk om de geboorte van het product mee te kunnen maken!
Bij GX werken we dagelijks in scrum teams met onze opdrachtgevers, bijvoorbeeld bij het implementeren van nieuwe CMS systemen. We hebben dus al heel wat scrum valkuilen voorbij zien komen. Ben je benieuwd pro-tips van mij of mijn collega's? Mail me gerust!
