8 Scrum valkuilen uit de praktijk

-

Je begint als scrum master aan een project. Je hebt een ready-to-go team, een goed gevulde backlog en je stories zijn ingeschat. So far, so good! Toch?

Je project start en in de eerste sprint bepaal je dat je een content pagina wilt hebben met diverse soorten content, zoals quote’s en linkjes, et cetera. De focus van het project is content first en user experience first. Zo blijf je de website doorontwikkelen totdat je er na een half jaar bij een usability test achter komt dat je geen grid in de webpagina’s hebt?! Hoe kan dit? Een grid zorgt immers voor overzicht, duidelijkheid en consistentie. Hoe heeft het kunnen gebeuren dat dit over het hoofd is gezien?

Valkuil 1 Onduidelijke NFR’s

Bespreek met het development team team wat de randvoorwaarden (Non-Funtional Requirements) zijn om een goede future-proof website te ontwikkelen. Dit kan al in sprint 0 waardoor er mogelijk technische taken ontstaan die in de eerste sprint opgepakt kunnen worden. Deze levert misschien niet meteen een product op wat je kunt presenteren aan je stakeholders maar zorgt voor de langere termijn voor bijvoorbeeld een stabiel of gemakkelijk te onderhouden website.

Valkuil 2 Beslissingen zonder het team

Een voor de hand liggende maar nog steeds veel voorkomende valkuil is dat de product owner beslissingen neemt zonder deze te overleggen met het projectteam. Vaak worden designs niet besproken of voorgelegd aan het ontwikkelteam of pas op een moment waarop er geen aanpassingen meer mogelijk zijn. Hierdoor moeten er vaak extra werkzaamheden plaatsvinden die een grote impact kunnen hebben. Een kleine design aanpassing kan immers al een flinke impact hebben op de ontwikkeling.

Valkuil 3 Geen tijd voor rework

Net zoals jij gaandeweg wellicht meer inzicht krijgt in het project, zo krijgen ontwikkelaars ook meer inzicht in de ontwikkeldecode. Het is daarom belangrijk om af en toe een sprint te plannen waarop ontwikkelde code herschreven of geoptimaliseerd kan worden. Dit kan er voor zorgen dat de code compacter of slimmer wordt en dat bijvoorbeeld onderhoud of doorontwikkeling vereenvoudigd wordt.

Valkuil 4 Iedere sprint iets kunnen tonen

Het development team team wordt misschien gefinancierd door diverse stakeholders in je organisatie. Deze staan te springen om te zien wat er iedere sprint wordt opgeleverd en dus wil je in iedere sprint iets nieuws laten zien. Maar laat je niet verleiden om iedere sprint alleen visuele dingen te laten zien. Als je development team twee weken bezig is geweest met een complexe functionaliteit, mag dit ook gewoon aan de stakeholders gepresenteerd worden. Wellicht dat dit lastiger is omdat er veel in de code gebeurd maar laat wel zien waarin de tijd is geïnvesteerd.

Valkuil 5 Te grote user stories

Voorkom dat je te grote user stories in de sprint gaat opleveren. Je ziet daardoor als buitenstaander weinig vooruitgang en het zorgt ervoor dat het development team geen eindstreep ziet. Beter is om grote user stories om te zetten in Epics en deze vervolgens op te splitsen in nieuwe kleinere user stories. Deze kunnen vervolgens weer gesplitst worden in taken en sub-taken. Dit zorgt er voor dat er naast meer grip en inzicht komt er ook haalbare doelen gesteld kunnen worden.

Valkuil 6 First time right

First time right is alleen mogelijk als je de user stories klein genoeg maakt. Beter is door progressive enhancement je product gaande weg te verbeteren. Ten eerste weet je beter nadat iets klaar is of het de oplossingen was die je zocht. En ten tweede zorgt het ervoor dat het ontwikkelteam beter kan inschatten wat er nodig is om de oplossing te verbeteren.

Daarnaast voorkom je ook dat kostbare tijd verloren gaat met het perfectioneren van zaken terwijl het voor de stakeholders al lang acceptabel is.

Valkuil 7 Aannames

Aannames worden door het development team gedaan als user stories nog niet goed of ver genoeg zijn uitgewerkt. Tijdens refinementsessie is het belangrijk dat de vragen die gesteld worden ook beantwoord worden. Als er veel vragen of onduidelijkheden zijn over stories is het raadzaam om een user story vaker dan een keer te behandelen tijdens een refinement. Dit zorgt ervoor dat alle vragen van tafel zijn en dat alle teamleden weten wat er van hen verwacht wordt tijdens het ontwikkelen. En dat er een realistische schatting gemaakt kan worden hoeveel effort het kost om iets te ontwikkelen.

Valkuil 8 Iedereen zijn eigen eiland

Om als scrum team succesvol te zijn is de nummer 1 prio van ieder team; iedereen dezelfde focus. Daardoor voelen alle team leden zich verbonden en verantwoordelijk voor het opgeleverde resultaat. Als Scrum master is het daarom extra belangrijk om een cultuur te creëren die voor ieder team lid comfortabel is, om successen te vieren met het team, en om ervoor te zorgen dat iedereen dezelfde focus heeft.

Wat zijn jouw ervaringen met het ontwikkelen van een website met een scrum traject? Waar liep jij tegenaan of wat is jouw gouden tip? Ik hoor het graag!