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 structuur 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 zelf 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 structuur zoals 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 allesomvattende documentatie

• Samenwerking met de klant 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 aanpassing 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.

Het scrum-framework beschrijft een reeks waarden, principes en werkwijzen waar scrum-teams mee werken om een product of service te leveren. Het beschrijft de leden van een scrum-team en hun verantwoordelijkheden, 'artefacten' die het product en het werk om het product aan te maken definiëren en scrum-vergaderingen om het scrum-team bij het werk te begeleiden.

Een scrumteam is een klein en flexibel team dat zich toelegt op het afronden van speciale productstappen. Een scrumteam is doorgaans klein en bestaat uit ongeveer tien personen, maar het is groot genoeg om binnen een sprint een aanzienlijke hoeveelheid werk te voltooien. Een scrumteam heeft drie specifieke rollen nodig: een producteigenaar, een scrummaster en het ontwikkelingsteam. En omdat scrumteams bestaan uit mensen met meerdere functies, omvat het ontwikkelingsteam naast ontwikkelaars ook testers, ontwerpers, UX-specialisten en ops-engineers.

De scrumproducteigenaar

Producteigenaren zijn de aanprijzers hun product. Ze zijn gericht op het begrijpen van zakelijke, klant- en marktvereisten en geven vervolgens prioriteit aan het werk dat door het engineeringteam moet worden gedaan. Effectieve producteigenaren:

• Bouwen en beheren de productbacklog.

• Werken nauw samen met het bedrijf en het team om ervoor te zorgen dat iedereen de items in de productbacklog begrijpt.

• Bieden het team duidelijke begeleiding over welke functies moeten worden geleverd.

• Bepalen wanneer het product moet worden geleverd, liefst zo frequent mogelijk.

De producteigenaar is niet altijd de productbeheerder. Producteigenaren zorgen ervoor dat het ontwikkelingsteam de meeste waarde aan het bedrijf levert. Het is ook belangrijk dat de producteigenaar één persoon is. Geen enkel ontwikkelingsteam wil gemengde begeleiding van meerdere producteigenaren.

De scrummaster

Scrummasters zijn de aanprijzers van scrum binnen hun teams. Ze coachen teams, producteigenaren en het bedrijf in het scrumproces en zoeken naar manieren om de uitvoering hiervan te verfijnen.

Een effectieve scrummaster heeft diep inzicht in het werk dat door het team wordt gedaan en kan het team helpen hun transparantie en leveringsstroom te optimaliseren. Als hoofdbegeleider plant hij/zij de benodigde resources (zowel personen als logistiek) voor de sprintplanning, stand-up, sprintreview en de sprintretrospectieve.

Het scrum-ontwikkelingsteam

Scrum-teams zorgen ervoor dat werkzaamheden worden voltooid. Zij zijn de aanprijzers van duurzame ontwikkelingswerkwijzen. De meest effectieve scrum-teams zijn klein, bevinden zich op één locatie en bestaan uit vijf tot zeven personen. Een manier om de teamgrootte te bepalen is door de beroemde ‘twee pizza-regel’ te gebruiken, die bedacht is door Jeff Bezos, de CEO van Amazon (het team moet klein genoeg zijn om twee pizza’s te delen).

Teamleden hebben verschillende vaardigheden en trainen elkaar zodat niemand een knelpunt wordt in de levering van werk. Sterke scrum-teams organiseren zichzelf en benaderen hun projecten met een duidelijke ‘wij’-houding. Alle leden van het team helpen elkaar om ervoor te zorgen dat de sprint met succes wordt voltooid.

Het scrumteam bepaalt het plan voor elke sprint. Ze voorspellen hoeveel werk ze denken te kunnen voltooien aan de hand van hun snelheid in het verleden. Door de lengte van de iteratie steeds hetzelfde te houden, profiteert het ontwikkelingsteam van belangrijke feedback op het schattings- en leveringsproces, waardoor hun prognoses in de loop van de tijd steeds nauwkeuriger worden.

Scrum-artefacten zijn belangrijke informatie die door het scrumteam wordt gebruikt en die helpt bij het definiëren van het product en het werk dat gedaan moet worden om het product te maken. Er zijn drie artefacten in Scrum: de productbacklog, de sprintbacklog en de stap met jouw definitie van 'voltooid'. Het zijn de drie constanten waar een scrumteam tijdens sprints en na verloop van tijd op moet letten.

• 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 sprintplanningvergadering (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, een volledige versie of 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.

Het scrumframework bevat scrumwerkwijzen, ceremonies en vergaderingen die scrumteams regelmatig uitvoeren. Bij de agile ceremonies zien we de meeste verschillen tussen teams. Sommige teams vinden het bijvoorbeeld omslachtig en onnodig om al deze ceremonies te houden, terwijl anderen ze gebruiken als noodzakelijke check-in. Ons advies is om alle ceremonies tijdens de eerste twee sprints te gebruiken en te zien hoe het gaat. Je kunt dan snel een retro uitvoeren en kijken wat je kunt veranderen.

Hieronder vind je een lijst van alle belangrijke ceremonies waaraan een scrumteam kan deelnemen:

1. De backlog ordenen: Dit evenement, dat ook wel 'backlog grooming' wordt genoemd, valt onder de verantwoordelijkheid van de producteigenaar. De belangrijkste taken van de producteigenaar zijn om het product af te stemmen op de productvisie en om voortdurend op de markt en klanten te letten. Daarom houdt de producteigenaar deze lijst bij op basis van feedback van gebruikers en het ontwikkelteam om te helpen prioriteiten te stellen. De lijst wordt dan opgeschoond en kan op elk gewenst moment worden bewerkt. Je kunt hier meer lezen over het behouden van een gezonde backlog.

2. Sprintplanning: Het werk dat tijdens de huidige sprint moet worden uitgevoerd (scope), wordt tijdens deze vergadering gepland door het hele ontwikkelteam. Deze vergadering wordt geleid door de scrummaster. Tijdens de vergadering beslist het team over het doel van de sprint. Vanuit de backlog worden vervolgens specifieke userstory's aan de sprint toegevoegd. Deze story's sluiten altijd aan bij het doel en zijn ook goedgekeurd door het scrumteam. De story's zijn dan haalbaar om tijdens te sprint te implementeren.

   Aan het einde van de planningsvergadering moet elk scrum-lid duidelijk hebben wat er in de sprint kan worden bereikt en hoe de toename kan worden behaald.

3. Sprint: Een sprint is de werkelijke periode waarin een scrumteam samenwerkt om een toename te voltooien. Twee weken is een vrij typische duur voor een sprint, hoewel sommige teams een week makkelijker te plannen vinden of een maand om makkelijker een waardevolle toename te leveren. Dave West van Scrum.org geeft aan dat hoe complexer het werk is en hoe meer onbekende factoren er zijn, hoe korter de sprint is. De keuze ligt echter bij je team en je moet niet bang zijn om iets te veranderen als het niet werkt. Gedurende deze periode kan, indien nodig, opnieuw worden onderhandeld tussen de producteigenaar en het ontwikkelteam over de scope. Dit vormt de kern van de empirische aard van scrum.

   Alle gebeurtenissen, van planning tot retrospective, vinden plaats tijdens de sprint. Zodra een bepaald tijdsinterval voor een sprint is vastgesteld, moet dit gedurende de ontwikkelingsperiode consistent blijven. Dit helpt het team om te leren van ervaringen uit het verleden en om dat inzicht toe te passen op toekomstige sprints.

4. Dagelijkse scrum of stand-up: Dit is een dagelijkse, superkorte, eenvoudige vergadering die om dezelfde tijd plaatsvindt (meestal in de ochtend). Veel teams proberen de vergadering in 15 minuten af te ronden, maar dat is slechts een richtlijn. Deze vergadering wordt ook wel een 'dagelijkse stand-up' genoemd, waarbij wordt benadrukt dat het een snelle vergadering moet zijn. Het doel van de dagelijkse scrum is dat iedereen in het team op elkaar wordt afgestemd, dat iedereen op één lijn zit met het sprintdoel en een plan opstelt voor de komende 24 uur.

   De stand-up is het moment om je zorgen te uiten over het behalen van het sprintdoel of eventuele blockers.

   Een gebruikelijke manier om een stand-up te houden is om elk teamlid drie vragen te laten beantwoorden in het kader van het behalen van het sprintdoel:
   
   • Wat heb ik gisteren gedaan?
   • Wat ga ik vandaag doen?
   • Zijn er obstakels?
   
   We hebben echter gezien dat de vergadering snel verandert in mensen die hun agenda van gisteren en de volgende dag lezen. De theorie achter de stand-up is dat het 'geklets' verandert in een dagelijkse vergadering, zodat het team zich de rest van de dag op het werk kan concentreren. Als het dus een dagelijkse agenda-uitlezing wordt, wees dan niet bang om dit te veranderen en creatief te worden.

5. Sprintreview: Aan het einde van de sprint komt het team samen voor een informele sessie om een demo te bekijken of om de toename te bekijken of te inspecteren. Het ontwikkelteam toont de backlog-items die nu 'Gereed' zijn aan belanghebbenden en teamgenoten voor feedback. De producteigenaar kan beslissen of hij de toename al dan niet vrijgeeft, hoewel in de meeste gevallen de toename wordt vrijgegeven.

   Tijdens deze beoordelingsvergadering werkt de producteigenaar ook de productbacklog bij op basis van de huidige sprint, die kan worden meegenomen in de volgende sprintplanningssessie. Voor een sprint van een maand kun je overwegen om je sprintreview tot maximaal vier uur te beperken.

6. Sprint retrospective: Tijdens de retrospective komt het team samen om te documenteren en te bespreken wat er wel en niet werkte in een sprint, binnen een project, bij mensen of relaties, voor tools of zelfs voor bepaalde ceremonies. Het idee is om een plek te creëren waar het team zich kan richten op wat er goed ging en wat er de volgende keer verbeterd moet worden. De focus ligt hierbij minder op wat er mis is gegaan.

In 2016 zijn vijf scrumwaarden toegevoegd aan de Scrumhandleiding. Deze waarden geven richting aan het werk, de acties en het gedrag van het scrumteam. Ze zijn essentieel voor het succes van een scrumteam.

Toewijding

Omdat scrumteams klein en flexibel zijn, speelt elk teamlid een belangrijke rol in het succes van het team. Daarom moeten alle teamleden ermee instemmen om taken uit te voeren die ze kunnen voltooien en dat ze niet meer werk op zich nemen dan ze aankunnen. Er moet dus regelmatig worden gecommuniceerd over de voortgang van het werk, vaak in de vorm van stand-ups.

Moed

Voor een scrumteam betekent moed simpelweg de moed hebben om de huidige toestand of iets anders in twijfel te trekken waarmee het succes van een team kan worden belemmerd. Leden van een scrumteam moeten namelijk de moed hebben en zich veilig genoeg voelen om nieuwe dingen uit te proberen. Een scrumteam moet daarbij de moed hebben en zich veilig voelen om transparant te zijn over obstakels, projectvoortgang, vertragingen, enzovoort.

Focus

De kern van de workflow voor scrumteams is de sprint, ofwel een gerichte en gespecificeerde periode waarin het team een bepaalde hoeveelheid werk voltooit. De sprint zorgt voor structuur maar ook voor focus om de geplande hoeveelheid werk te voltooien.

Openheid

Door de dagelijkse stand-up wordt een openheid bevorderd waardoor teams vrijuit kunnen praten over werk in uitvoering en problemen. Bij Atlassian beantwoorden onze scrumteams vaak de volgende vragen:

• Waar heb ik gisteren aan gewerkt?

• Waar ben ik vandaag mee bezig?

• Welke problemen heb ik?

Dit helpt om de voortgang te benadrukken en problemen te herkennen. Het helpt ook om het team te versterken wanneer iedereen vooruitgang boekt.

Respect

De kracht van een agile-team ligt in de samenwerking en het besef dat alle teamleden bijdragen aan het werk in een sprint. Ze vieren elkaars prestaties en hebben respect voor elkaar, de producteigenaar, belanghebbenden en de scrummaster.

Scrum is zo'n populair agile framework dat scrum en agile vaak onterecht worden gezien als hetzelfde. Maar er zijn nog andere frameworks, zoals kanban, wat een populair alternatief is. Sommige bedrijven kiezen er zelfs voor om een hybride model van scrum en kanban te volgen, dat de naam 'Scrumban' of 'Kanplan' heeft gekregen, wat Kanban is met een backlog.  

Zowel scrum als kanban maken gebruik van visuele methoden, zoals het scrumbord of kanban-bord om de voortgang van het werk bij te houden. Beide leggen de nadruk op efficiëntie en het opsplitsen van complexe taken in kleinere stukken met beheersbaar werk, maar hun benaderingen van dat doel zijn anders.

Scrum richt zich op kleinere iteraties met een vaste duur. Zodra de periode van een sprint is afgelopen, worden de story's of items in de productbacklog bepaald die tijdens deze sprintcyclus kunnen worden geïmplementeerd. In kanban wordt het aantal taken of het werk in uitvoering (WIP-limiet) dat in de huidige cyclus moet worden uitgevoerd echter eerst bepaald. De tijd die nodig is om deze functies te implementeren, wordt pas daarna berekend.

Kanban is niet zo gestructureerd als scrum. Behalve de WIP-limiet staat het vrij open voor interpretatie. Scrum heeft echter verschillende categorische concepten die worden toegepast als onderdeel van de implementatie, zoals sprintreview, retrospectief, dagelijkse scrum, enz. Het legt ook de nadruk op multifunctionaliteit, namelijk het vermogen van een scrumteam om niet afhankelijk te zijn van externe leden om hun doelen te bereiken. Het samenstellen van een multifunctioneel team is niet eenvoudig. In die zin is kanban gemakkelijker aan te passen, terwijl scrum kan worden beschouwd als een fundamentele verandering in het denkproces en de werking van een ontwikkelteam.

Het scrumframework zelf is eenvoudig. De regels, artefacten, gebeurtenissen en rollen zijn gemakkelijk te begrijpen. De semi-voorschrijvende aanpak neemt onduidelijkheden in het ontwikkelingsproces weg, en biedt tegelijk voldoende ruimte voor bedrijven om hun eigen draai eraan te geven.

De organisatie van complexe taken in beheerbare userstory's maakt het ideaal voor moeilijke projecten. Ook zorgen de duidelijke afbakening van rollen en geplande gebeurtenissen voor transparantie en collectief eigendom gedurende de hele ontwikkelingscyclus. Snelle releases houden het team gemotiveerd en de gebruikers tevreden omdat ze in korte tijd voortgang kunnen zien.

Het kan echter tijd kosten om scrum volledig te begrijpen, vooral als het ontwikkelingsteam gewend is aan een standaard watervalmodel. De concepten van kleinere iteraties, dagelijkse scrumbijeenkomsten, sprintreviews en het identificeren van een scrummaster kunnen een uitdagende culturele verandering zijn voor een nieuw team.

Maar de voordelen op lange termijn wegen veel zwaarder dan de initiële leercurve. Het succes van scrum bij het ontwikkelen van complexe hardware- en softwareproducten in diverse sectoren en verticalen maakt het een overtuigend framework voor je organisatie.

Bekijk deze tutorial voor meer informatie over scrum met Jira.