Close

Scrum

Leer hoe je kunt scrummen als de beste

Onderwerpen zoeken

Wat is scrum?

Scrum is een framework dat teams helpt samen te werken. Net als een rugbyteam (waar de naam vandaan komt) dat traint voor een belangrijke wedstrijd, kunnen teams scrums gebruiken om door ervaringen te leren, zichzelf te organiseren terwijl ze aan een probleem werken en na te denken over hun successen en fouten om zichzelf voortdurend te verbeteren.

Hoewel de scrum waar ik het over heb meestal wordt gebruikt door softwareontwikkelingsteams, kunnen de principes en lessen worden gebruikt voor allerlei soorten teamwork. Dit is een van de redenen waarom scrum zo populair is. Scrum wordt vaak gezien als een agile framework voor projectmanagement en omvat een reeks vergaderingen, tools en rollen waarmee teams hun werk kunnen structureren en beheren.

In dit artikel bespreken we waar een traditioneel scrumframework uit bestaat met behulp van de Scrum-handleiding en David West, CEO van Scrum.org. We zullen ook bespreken hoe sommige van onze klanten deze basis loslaten om aan hun specifieke behoeften te voldoen. Daarvoor geeft onze eigen Megan Cook, Group Product Manager voor Jira Software en voormalig agile coach, tips en trucs in onze Agile Coach-videoserie:

Scrum-artikelen

[VERVOLG]

Het framework

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 mindset is. 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 een framework als scrum gebruiken om je te helpen zo te denken en om te oefenen met het ontwikkelen van agile principes in je dagelijkse communicatie en werk.

Het scrumframework is heuristisch; het is gebaseerd op continu leren en aanpassen aan veranderende factoren. Het erkent dat het team niet alles weet aan het begin van een project 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.

Het scrum framework | Atlassian Agile Coach

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.

Scrum artefacten

Laten we beginnen met de drie artefacten in scrum. Artefacten zijn iets dat we maken, zoals een hulpmiddel om een probleem op te lossen. In scrum zijn deze drie artefacten een productbacklog, een sprintbacklog en een increment met jouw definitie van 'voltooid'. Het zijn de drie constanten in een scrumteam die we blijven bekijken en herzien.

  • Productbacklog is de primaire lijst met werkzaamheden die moeten worden uitgevoerd door de producteigenaar of productmanager. Dit is een dynamische lijst met functies, vereisten, verbeteringen en correcties die fungeren als input voor de sprintbacklog. Het is in wezen de 'To Do'-lijst 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.

Tip:

Je moet net zo agile zijn met je framework als met je product. Neem de tijd die nodig is om na te gaan hoe de dingen gaan en indien nodig aanpassingen aan te brengen. Forceer iets niet alleen omdat het dan consistenter is.

Scrumceremonies of -evenementen

Enkele van de meer bekende componenten van het scrumframework zijn de reeks sequentiële evenementen, ceremonies of bijeenkomsten die scrumteams regelmatig uitvoeren. Bij de 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 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 tijdens de huidige sprint moet worden uitgevoerd (scope) wordt tijdens deze bijeenkomst gepland door het hele ontwikkelingsteam. Deze bijeenkomst wordt geleid door de scrummaster en is de plek waar het team het sprintdoel bepaalt. Specifieke userstory's worden vervolgens toegevoegd aan de sprint vanuit de productbacklog. Deze story's komen altijd overeen met het doel en zijn ook volgens het scrumteam haalbaar om te implementeren tijdens de sprint.

    Aan het einde van de planningsmeeting moet voor elk scrumlid duidelijk zijn wat er in de sprint kan worden afgeleverd en hoe het increment kan worden geleverd.

  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. Dagelijks scrum of stand-up: Dit is een dagelijkse superkorte bijeenkomst die steeds op dezelfde tijd plaatsvindt (meestal 's ochtends) en zo eenvoudig mogelijk is. Veel teams proberen de vergadering binnen 15 minuten af te ronden, maar dat is slechts een richtlijn. Deze bijeenkomst 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 hij of zij aan toe is, weet 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 knelpunten te uiten.

    Een veel voorkomende manier om een stand-up te houden is een waarbij elk teamlid drie vragen beantwoordt 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 meeting echter snel zien omslaan naar mensen die alleen kijken naar wat er gister en vandaag 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. Dus als de stand-up verandert in een dagelijkse lezing van de agenda, wees dan niet bang om dingen aan te passen en creatief te worden.

  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.

Drie essentiële rollen voor een succesvolle scrum

Een scrumteam heeft drie specifieke rollen nodig: producteigenaar, scrummaster en het ontwikkelingsteam. En omdat scrumteams cross-functioneel zijn, omvat het ontwikkelingsteam naast ontwikkelaars ook testers, ontwerpers, UX-specialisten en ops-ingenieurs.

De scrumproducteigenaar

Producteigenaren zijn de aanprijzers van 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 productmanager. Producteigenaren zorgen ervoor dat het ontwikkelingsteam de meeste waarde levert voor het bedrijf. Het is ook belangrijk dat de producteigenaar één persoon is. Geen enkel ontwikkelingsteam wil gemengde signalen ontvangen van meerdere producteigenaren.

De scrummaster

Scrummasters zijn de aanprijzers van scrum binnen hun team. Ze coachen teams, producteigenaren en het bedrijf in het scrumproces en zoeken naar manieren om de uitvoering 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 middelen (zowel personen als logistiek) voor de sprintplanning, stand-up, sprintreview en de sprintretrospectieve.

Het scrum-ontwikkelingsteam

Scrumteams krijgen het voor elkaar. Ze zijn de aanprijzers van duurzame ontwikkelingspraktijken. De meest effectieve scrumteams 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 het werk. Sterke scrumteams 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, kanban en agile

Scrum is zo'n populair agile framework dat scrum en agile vaak verkeerd worden begrepen, en wordt gedacht dat ze hetzelfde zijn. Maar er zijn andere frameworks, zoals kanban, wat een populair alternatief is. Sommige bedrijven kiezen er zelfs voor om een hybride model van scrum en kanban te gebruiken, wat de naam "Scrumban" of "Kanplan" heeft gekregen, oftewel Kanban met een backlog.

Zowel scrum als kanban gebruiken visuele methoden zoals het scrumbord of het kanbanbord om de voortgang van het werk bij te houden. Beide benadrukken efficiëntie en splitsen complexe taken in kleinere stukken met beheersbaar werk, maar hun benaderingen naar dat doel zijn anders.

Scrum richt zich op kleinere iteraties met een vaste lengte. Zodra de tijdsperiode voor een sprint is bepaald, worden de story's of items uit de productbacklog bepaald die tijdens deze sprintcyclus kunnen worden geïmplementeerd. Bij kanban wordt echter eerst het aantal taken of het werk in uitvoering (WIP-limiet) bepaald dat in de huidige cyclus moet worden voltooid. 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 deze vrij open voor interpretatie. Scrum heeft echter verschillende vaste categorische concepten als onderdeel van de implementatie, zoals sprintreview, retrospectieve, dagelijkse scrum, enz. Hierin is ook cross-functionaliteit noodzakelijk, zodat een scrumteam niet afhankelijk is van externe personen om hun doelen te bereiken. Het samenstellen van een cross-functioneel team is niet eenvoudig. In die zin is kanban gemakkelijker aan te passen, terwijl scrum kan worden beschouwd als een fundamentele verschuiving in het denkproces en het functioneren van een ontwikkelingsteam.

Maar.. waarom scrum?

Het scrumframework zelf is eenvoudig. De regels, artefacten, events 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 beheersbare userstory's maakt het ideaal voor moeilijke projecten. Ook zorgen de duidelijke afbakening van rollen en geplande events voor transparantie en collectief eigendom gedurende de hele ontwikkelingscyclus. Snelle releases houden het team gemotiveerd en de gebruikers tevreden omdat ze in korte tijd vooruitgang 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.

Claire Drumond
Claire Drumond

Claire Drumond is a marketing strategist, speaker, and writer for Atlassian. She is the author of numerous articles published on the Trello and Atlassian blogs and is a regular contributor to various publications on Medium including HackerNoon, Art+Marketing, and PoetsUnlimited. She speaks at tech conferences around the world about agile, breaking down silos, and building empathy.

Up Next
Sprints