Steeds meer organisaties hebben kennisgemaakt met scrum: een agile projectaanpak waarbij een multidisciplinair team software ontwikkelt waar de business om vraagt.

Helaas gaat scrum in de praktijk nog vaak mis, omdat een aantal spelregels niet goed wordt nageleefd. Daarom deel ik graag een top 5 van regels, waarvan ik meer dan eens heb gezien dat het stuk voor stuk flinke struikelblokken zijn.

1. Stakeholders beleggen hun wensen bij de Product Owner

Het is een stakeholder absoluut verboden om zijn wensen (of eisen) via een ander pad dan de Product Owner bij het team in te brengen. Ook als een stakeholder het budget faciliteert, geeft hem dat geen extra bevoegdheden.

Stakeholders moeten hun wensen melden bij de Product Owner. Die bepaalt wat prioriteit krijgt en gerealiseerd gaat worden. Elke stakeholder moet er dus op vertrouwen dat de Product Owner de juiste keuzes maakt die de meeste toegevoegde waarde voor de business opleveren.

2. De Product Owner is gekwalificeerd

Het hebben van een goede Product Owner is cruciaal. Ik heb helaas maar al te vaak gezien dat het (deels) mislukken van een scrumtraject kan worden toegerekend aan de Product Owner. En dat hoeft niet eens altijd zijn schuld te zijn. Want de gedachte is vaak: we hebben nou eenmaal een Product Owner nodig en Pietje heeft wel wat tijd om het erbij te doen.

Een Product Owner heeft de macht om te bepalen wat er wordt gebouwd. Het beschikbaar gestelde zakje met geld wordt door hem uitgegeven. Die verantwoordelijkheid is zwaar en moet gedragen worden door iemand die geschikt is voor de job. Dus communicatief vaardig, besluitvaardig, technisch voldoende onderlegd. En voldoende vertrouwd door iedereen zodat hij niet bij elke beslissing wordt teruggefloten.

3. De voorbereiding wordt zorgvuldig uitgevoerd

Een goede voorbereiding is het halve werk, ook bij scrum. Die begint dus niet bij aanvang van de eerste sprint, wanneer je een volledig team klaar hebt zitten om te gaan bouwen, maar al veel eerder.

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: 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? Komt dat antwoord te laat, dan heb je een impediment (een blokkerend issue) aan je broek hangen. Om dit te voorkomen, doe je grondig vooronderzoek, eventueel geholpen door een informatie-analist en een technisch architect.

Moet je een nieuw cms uitzoeken en breekt het zweet je uit? Download onze tips  & tricks!

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, waardoor het voor een Product Owner heel verleidelijk is 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 de sterk verouderde browser Internet Explorer 8), hoe meer tijd het voor het team gaat kosten.

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 wat je met goed fatsoen aan de buitenwereld kunt presenteren?

Daarbij moet ‘minimale vorm’ niet worden verward 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!

tips & tricks - nieuw CMS selecteren

<< Back

Posts containing: