Wat is scrum en hoe begin ik eraan?

Mensen denken vaak dat scrum en agile hetzelfde zijn omdat scrum gericht is op continue verbetering, wat een kernprincipe is van agile. Scrum is echter een framework om werk gedaan te krijgen, terwijl agile een filosofie is. De agile filosofie draait om continue incrementele verbetering door middel van kleine en frequente releases. Je kunt niet echt 'agile gaan', want het vereist toewijding van het hele team om de manier waarop ze denken te veranderen om waarde te leveren aan je klanten. Maar je kunt wel een framework als scrum gebruiken om je te helpen zo te gaan denken en om te oefenen met het ontwikkelen van agile principes in je dagelijkse communicatie en werk.

Je kunt het verschil tussen agile en de definitie van scrum vinden in de Scrum Guide en het Agile-manifest. Het Agile-manifest schetst vier waarden:

• Individuen en interacties boven processen en tools
• Werkende software boven uitgebreide documentatie
• Samenwerken met klanten boven contractonderhandelingen
• Reageren op veranderingen boven het volgen van een plan

De definitie van scrum is gebaseerd op empirisme en lean thinking. Empirisme zegt dat kennis voortkomt uit ervaring en dat beslissingen worden genomen op basis van wat er wordt waargenomen. Lean thinking vermindert verspilling en richt zich op essentiële zaken. Het scrumframework is heuristisch: het is gebaseerd op continu leren en aanpassen aan veranderende factoren. Het erkent dat het team aan het begin van een project niet alles weet en zich door ervaring zal ontwikkelen. De structuur van scrum is bedoeld om teams te helpen zich op natuurlijke wijze aan te passen aan veranderende omstandigheden en gebruikersvereisten. Het stellen van nieuwe prioriteiten is ingebouwd in het proces, evenals korte releasecycli, zodat je team voortdurend kan leren en verbeteren.

Hoewel scrum gestructureerd is, staat niet alles vast. De uitvoering ervan kan worden afgestemd op de behoeften van elke organisatie. Er zijn veel theorieën over hoe scrumteams precies moeten werken om succesvol te zijn. Nu we echter al meer dan tien jaar agile teams helpen om werk gedaan te krijgen bij Atlassian, hebben we geleerd dat duidelijke communicatie, transparantie en inzet voor voortdurende verbetering altijd centraal moeten blijven staan bij elk framework dat je kiest. En de rest is aan jou.

• De productbacklog is de primaire lijst met werkzaamheden die moeten worden uitgevoerd en onderhouden door de producteigenaar of productmanager. Dit is een dynamische lijst met functies, vereisten, verbeteringen en oplossingen die fungeren als input voor de sprintbacklog. Het is in wezen de takenlijst van het team. De productbacklog wordt voortdurend opnieuw bekeken, opnieuw geprioriteerd en onderhouden door de producteigenaar, omdat, naarmate we meer leren of de markt verandert, items mogelijk niet langer relevant zijn of problemen op andere manieren kunnen worden opgelost.
• De sprintbacklog is de lijst met items, userstory's of bugfixes die door het ontwikkelingsteam zijn geselecteerd voor implementatie in de huidige sprintcyclus. Vóór elke sprint, tijdens de sprintplanningmeeting (die we later in het artikel bespreken) kiest het team aan welke items uit de productbacklog het zal werken tijdens de sprint. Een sprintbacklog kan flexibel zijn en kan veranderen tijdens een sprint. Het fundamentele doel van de sprint, dus wat het team wil bereiken met de huidige sprint, kan echter niet worden aangepast.
• Het Increment of sprintdoel is het bruikbare eindproduct van een sprint. Bij Atlassian laten we het increment meestal zien tijdens de einddemonstratie, waarbij het team laat zien wat er in de sprint is voltooid. Het woord 'increment' heb je misschien nog niet eerder gehoord; het wordt vaak gebruikt door het team om aan te geven dat een mijlpaal is behaald, of zelfs dat het sprintdoel of een volledige versie van een verstuurde epic is voltooid. Het hangt er helemaal vanaf hoe je teams 'Voltooid' definiëren en hoe je je sprintdoelen definieert. Sommige teams kiezen er bijvoorbeeld voor om aan het einde van elke sprint iets aan hun klanten te leveren. Hun definitie van 'voltooid' is dus 'verstuurd'. Dit is echter misschien niet realistisch als het gaat om andere teams. Stel dat je werkt aan een servergebaseerd product dat elk kwartaal naar je klanten kan worden gestuurd. Je kunt er nog steeds voor kiezen om in sprints van 2 weken te werken, maar je definitie van 'voltooid' is dan eerder een onderdeel van een grotere versie die je in zijn geheel wilt verzenden. Maar let op, hoe langer het duurt om software te voltooien, hoe groter het risico dat de software te laat geleverd wordt.

Zoals je kunt zien, zijn er veel variaties, zelfs binnen artefacten, die je team zelf kan definiëren. Daarom is het belangrijk om open te staan voor veranderingen in het bijhouden van die artefacten. Misschien zorgt je definitie van 'voltooid' juist voor meer stress bij je team en moet je pas op de plaats maken en een nieuwe definitie kiezen.

Hieronder vind je een lijst van alle belangrijke ceremonies waar een scrumteam aan zou kunnen deelnemen:

1. Organiseer de backlog: Dit evenement heet ook wel backlog grooming en is de verantwoordelijkheid van de producteigenaar. De belangrijkste taken van de producteigenaar zijn om het product te sturen volgens de productvisie en een constante vinger aan de pols te hebben bij de markt en de klant. Daarom onderhoudt hij/zij deze lijst met behulp van feedback van gebruikers en het ontwikkelingsteam om prioriteiten te stellen en de lijst opgeruimd en op orde te houden om er op elk gewenst moment aan te kunnen werken. Lees hier meer over het onderhouden van een gezonde backlog.

2. Sprintplanning: het werk dat moet worden uitgevoerd (scope) tijdens de huidige sprint wordt tijdens deze vergadering gepland door het hele ontwikkelteam. Deze vergadering wordt geleid door de scrummaster en het team beslist over het doel van de sprint. Vanuit de productbacklog worden vervolgens specifieke userstory's aan de sprint toegevoegd. Deze story's komen altijd overeen met het doel en het scrumteam is het er ook over eens dat ze haalbaar zijn om te implementeren tijdens de sprint.
   
   Aan het einde van de planningsvergadering moet elk scrumlid duidelijk weten wat er in de sprint kan worden geleverd en hoe de veranderingen kunnen worden gerealiseerd.

3. Sprint: Een sprint is de werkelijke tijdsperiode waarin het scrumteam samenwerkt om een increment te voltooien. Twee weken is een vrij standaard lengte voor een sprint, hoewel sommige teams vinden dat een week makkelijker is of juist een maand nodig hebben om een waardevol increment te voltooien. Dave West, van Scrum.org adviseert dat hoe complexer het werk en hoe meer onbekende factoren, hoe korter de sprint zou moeten zijn. Maar je team bepaalt, en je moet niet bang zijn om te veranderen als iets niet werkt! Gedurende deze periode kan het bereik indien nodig opnieuw worden bepaald in overleg met de producteigenaar en het ontwikkelingsteam. Dit vormt de kern van de empirische aard van scrum.
   
   Alle evenementen, van planning tot retrospective, vinden plaats tijdens de sprint. Zodra een bepaald tijdsinterval voor een sprint is vastgesteld, moet deze gedurende de ontwikkelingsperiode consistent blijven. Dit helpt het team om te leren van ervaringen uit het verleden en dat inzicht toe te passen op toekomstige sprints.

4. Dagelijkse scrum of stand-up: Dit is een dagelijkse, superkorte vergadering die steeds op hetzelfde tijdstip (meestal ‘s ochtends) en op dezelfde plek plaatsvindt en zo eenvoudig mogelijk is. Veel teams proberen de vergadering binnen 15 minuten af te ronden, maar dat is slechts een richtlijn. Deze vergadering wordt ook wel een ‘dagelijkse stand-up’ genoemd, waarin wordt benadrukt dat het kort moet zijn. Het doel van de dagelijkse scrum is dat iedereen in het team weet waar ze aan toe zijn, wat het sprintdoel is, en wat het plan is voor de komende 24 uur.
   
   De stand-up is het moment om eventuele zorgen over het behalen van het sprintdoel of blockers te uiten.
   
   Een gebruikelijke manier om een stand-up te houden is door elk teamlid drie vragen te stellen in het kader van het bereiken van het sprintdoel:
   
   Wat heb ik gisteren gedaan?
   • Wat ben ik van plan vandaag te doen?
   • Zijn er obstakels?
   
   We hebben de vergadering echter snel zien omslaan in een situatie waarin mensen alleen voorlezen wat er gisteren en de volgende dag op de agenda staat. De theorie achter de stand-up is dat alle overleg tijdens een dagelijkse vergadering plaatsvindt, zodat het team zich de rest van de dag kan concentreren op het werk. Als de stand-up dus verandert in een dagelijkse lezing van de agenda, wees dan niet bang om dingen aan te passen en creatief te zijn.

5. Sprintreview: Aan het einde van de sprint komt het team samen voor een informele sessie om een demo van het increment te bekijken of te inspecteren. Het ontwikkelingsteam toont de items uit de backlog die nu 'voltooid' zijn aan belanghebbenden en teamgenoten voor feedback. De producteigenaar kan beslissen of het increment al dan niet wordt geleverd, hoewel dit in de meeste gevallen wel wordt gedaan.
   
   Deze reviewmeeting is ook het moment waarop de producteigenaar de productbacklog opnieuw indeelt op basis van de huidige sprint. Dit kan worden meegenomen naar de volgende sprintplanningsessie. Voor een sprint van één maand is het het beste om je sprintreview maximaal vier uur te laten duren.

6. Sprintretrospective: De retrospectieve is het moment waarop het team samenkomt om te documenteren en te bespreken wat wel en niet werkte in een sprint, een project, mensen of relaties, tools of zelfs bepaalde ceremonies. Het idee is om een plek te creëren waar het team zich kan richten op wat goed is gegaan en wat er de volgende keer verbeterd moet worden, en niet zozeer op wat er mis is gegaan.