Tien valkuilen van scrum uit de praktijk

Auteur
Carolien Koesen
Datum

In steeds meer organisaties zijn scrum-teams aan het werk om software te ontwikkelen. Ook buiten de ICT-sector hanteren werkgroepen vaker de scrum aanpak bij de uitvoering van de dagelijkse werkzaamheden. Scrum is populair, maar geen wondermiddel. Je moet er hard voor werken.

In deze blog geef ik tien valkuilen waar ik tegenaan ben gelopen tijdens de ontwikkeling van een website. Voordat ik ze bespreek geef ik kort aan wat scrum inhoudt.

Wat is scrum?

Scrum is een raamwerk, waarin een multidisciplinair team iedere twee tot vier weken een stuk werkende software oplevert. Een andere naam voor de korte iteratie is sprint. Tijdens iedere sprint levert het team de user stories op die op de sprintplanning staan. Een user story beschrijft een functionaliteit die waarde oplevert voor de stakeholders. Aan het einde van de sprint demonstreert het team het resultaat aan de stakeholders en maakt het plannen voor de volgende iteratie.

Het scrumboard geeft overzicht over de taken die binnen de sprint open staan en al gedaan zijn. De product owner bepaalt de prioriteiten en heeft mandaat om besluiten te nemen. Parallel aan de werkzaamheden voor de sprint bereidt het team de volgende sprints voor. Deze voorbereiding vindt plaats tijdens zogenaamde refinement-sessies.

Valkuil 1: user stories zijn te groot

Als user stories te groot zijn, dan heeft het team te veel werk en kan het aan het einde van de sprint geen resultaat tonen. Dit kun je voorkomen door user stories op te delen. In zijn blog 8 useful strategies for splitting large user stories (and a cheatsheet) legt Christiaan Verwijs uit hoe je dit kunt doen. Christiaan Verwijs helpt organisaties bij de implementatie van scrum.

Valkuil 2: taken zijn te groot

Aan het begin van een sprint splitst het team de user stories op in taken. Iedere taak krijgt een Post-it op het scrumboard. Als taken te groot zijn, dan blijven Post-its dagenlang op dezelfde plek op het scrumboard hangen. Je benut dan onvoldoende het positieve effect van de ‘zichtbare voortgang’. Het is niet helder waar een teamlid mee bezig is. De voortgang van de sprint is onduidelijk.

De oplossing is om taken kleiner te maken. Een taak mag niet groter zijn dan één dag werk. Als je een user story opdeelt in taken, vergeet dan niet de test- en automation-werkzaamheden mee te nemen.

Valkuil 3: user stories zijn niet diep genoeg uitgewerkt

Als user stories niet diep genoeg zijn uitgewerkt in de refinement-sessies, dan maken teamleden binnen de sprint aannames die ze onderling vergeten te communiceren. Het gevolg is dat niet iedereen meer dezelfde kant op gaat. Er is veel overleg nodig om de details in te vullen. Vaak blijft er onvoldoende tijd over voor de realisatie.

De oplossing is om alleen user stories in de sprint op te nemen die voldoen aan de definition-of-ready. Constateer je dat tijdens de sprintplanning het team geen gedragen inschatting kan geven? Stel de user story dan uit. Zorg er wel voor dat je altijd een reserve user story achter de hand hebt om alsnog in de sprintplanning op te nemen.

Valkuil 4: user stories worden binnen de sprint niet in de volgorde van prioriteit opgepakt

Als teamleden user stories niet in de volgorde van prioriteit oppakken en als de sprint te groot is (valkuil 1), dan zijn alle user stories aan het einde van de sprint niet helemaal af. Het team kan geen demo geven.

De oplossing is om ze in volgorde van prioriteit op het scrumboard te hangen. De user story met de hoogste prioriteit hangt bovenaan het scrumboard, de user story met de een-na-hoogste prioriteit hangt op de tweede plek, enzovoorts. Iedereen in het team kan zien wat het belangrijkste is. Tijdens de dagelijkse voortgang-bespreking kunnen teamleden er direct op toezien dat nieuwe taken in de goede volgorde gebeuren.

Valkuil 5: focus op individuele taken

Als een teamlid zegt: “Ik heb precies gemaakt wat er in het design staat.”, dan is die persoon gefocust op de eigen taken. Hij werkt op een eilandje en voelt zich niet verantwoordelijk voor het resultaat van het team als geheel.

Je kunt dit gedrag doorbreken door een teamsessie te beleggen waarin je met elkaar vaststelt wat de gemeenschappelijke doelen en verantwoordelijkheden zijn. Zie je teamleden na verloop van tijd in oud gedrag terugvallen? Herhaal dan deze sessie.

Valkuil 6: team streeft naar perfectie

Als het team naar perfectie streeft, dan gaat kostbare tijd verloren aan details die een geringe waarde voor de stakeholders hebben. Omdat het lang duurt voordat je een functionaliteit oplevert, krijgt je te laat feedback. Perfectionisme is de vijand van productiviteit.

Een oplossing is om de 80/20 regel te hanteren. Steef ernaar dat wat je doet voor 80% goed is. Stop met de 20% die je besteedt aan perfectioneren. Het nieuwe credo luidt: Goed genoeg is de nieuwe perfectie.

Valkuil 7: team vergeet de definition-of-done

In de haast om werkbare software op te leveren voor de demo, hebben teams de neiging om taken te vergeten. Ze testen de software niet (door) en documenteren de gerealiseerde functionaliteiten niet. De product owner heeft geen gelegenheid om de software goed te keuren.

De oplossing is tweeledig: hang de definition-of-done zichtbaar op de muur van de scrumruimte. En plaats alle taken op het scrumboard. Merk je dat deze maatregelen onvoldoende effect sorteren? Organiseer dan een extra teamdemo op de dag voor de ‘echte’ demo. Je hebt dan nog een dag om alle losse eindjes af te werken.

Valkuil 8: miniwaterval binnen de sprint

Binnen de sprint komt het wel eens voor dat het ene teamlid pas aan de slag kan nadat het andere teamlid klaar is. Collega’s wachten op elkaar. Tijdens de ontwikkeling van software zijn er altijd afhankelijkheden. De front-end ontwikkelaar en de designer wachten totdat de content klaar is; de tester wacht op de oplevering. Je kunt het wachten niet uitbannen, je kunt het wel minimaliseren. Dit doe je door componenten kleiner te maken.

Valkuil 9: stakeholders missen overzicht

Stakeholders hebben behoefte aan overzicht. Vooral aan het begin van het project als de header, footer en hoofdnavigatie van een website nog niet beschikbaar zijn, dan is het voor stakeholders moeilijk om gedemonstreerde functionaliteiten in een context te plaatsen. Ze missen het overzicht. Het gevolg is dat de stakeholders geen goede feedback kunnen geven. De demo schiet dan zijn doel voorbij.

De oplossing is om tijdens de demo tijd in te ruimen om de context van iedere functionaliteit te schetsen. Laat visueel zien hoe de bezoeker deze op de website bereikt.

Valkuil 10: stakeholders verwachten dat het team de feedback direct oppakt

Stakeholders die niet vertrouwd zijn met scrum verwachten dat het team de feedback direct verwerkt. Als stakeholders in de volgende demo niets terug zien van de terugkoppeling die ze hebben gegeven, dan worden ze ontevreden. De product owner kan dit voorkomen. Door actief de verwachtingen van de stakeholders te managen. Kom iedere demo terug op wat er de vorige keer besproken is.

Conclusie

Als je met scrum aan de slag gaat, dan merk je vroeg of laat dat bepaalde dingen niet lekker gaan. Misschien ben je in een valkuil gelopen die ik hierboven heb genoemd. Misschien loop je in een andere valkuil. Fouten maken is oké. Scrum hoeft niet naar de letter te worden uitgevoerd. Onderzoek waar het mis gaat en pas het proces aan.

Training Scrum Essentials

Agile- en scrumprincipes kan je niet alleen toepassen op software development, maar ook op businessafdelingen, zoals marketing of e-commerce. Scrum/agile helpt je in te spelen op de snel veranderende wereld en meer gebruik te maken van de kennis van professionals in je organisatie.

Lees meer over het trainingsaanbod van de dienst Agile Transitioners van Mirabeau.

Tags

Scrum Agile Project Management