samen
werken
Wat is Scrum?
Tegenwoordig werken vele organisaties via de Agile Scrum methodiek, waarbij (deel)producten op een efficiënte, projectmatige manier worden opgeleverd. Middels deze wendbare werkwijze wordt een flexibel werkproces nagestreefd. Maar hoe zit dit precies in elkaar?
In 1995 bedachten Jeff Sutherland en Ken Schwaber de Scrum methodiek. Zij achterhaalden welke zaken belangrijk zijn om projecten succesvol uit te voeren; zo vormen de principes, samenwerken, creativiteit en betrokkenheid de basis van Scrum. Ondanks dat Scrum oorspronkelijk werd gebruikt tijdens de ontwikkeling van software, wordt het steeds meer voor andere situaties ingezet.
Je zou Scrum als een mooi alternatief kunnen zien voor Prince2, een strak geplande werkwijze. Bij deze projectmanagement methodiek is vanaf het begin duidelijk wat er precies opgeleverd zal gaan worden. Omdat dit vaak moeilijk in te schatten is, duurt het erg lang aan een project te beginnen.
Jeff Sutherland en Ken Schwaber
Scrum biedt een uitkomst voor dit probleem.
Bij Scrum draait het erom het project te starten op basis van een overkoepelend idee dat naar gelang meer vorm krijgt. Tijdens de ontwikkeling van een product/dienst wordt steeds meer duidelijk hoe het project er precies uit gaat zien. Het gaat erom dat alle leden van het Scrum team gefocust zijn op het project zelf en niet afgeleid worden door nevenactiviteiten van de organisatie. Op korte termijn wordt daarom veel met z’n allen bereikt.
Daarnaast bestaat er continu contact met alle stakeholders, waaronder de klant die betrokken zal zijn gedurende de ontwikkeling van het product of de dienst. De verantwoordelijkheid voor deze voortdurende communicatie valt op de schouders van de Product Owner. Omdat de klant constant aangeeft of de (deel)producten naar wens zijn, kan tussentijds gemakkelijk worden bijgestuurd en zal de klant aan het einde van de sprint volledig tevreden zijn over het product of de dienst.
Waar bestaat het Scrum raamwerk uit?
Onder Scrum vallen verschillende rollen, lijsten en bijeenkomsten. Hieronder zullen allereerst alle rollen nader toegelicht worden.
De Product Owner is, zoals eerder al vermeld, verantwoordelijk voor de communicatie tussen het Development team en alle stakeholders. Daarnaast houdt deze persoon de Product Backlog up-to-date, waarbij taken van boven naar beneden geprioriteerd worden. Na het op orde brengen van de Backlog communiceert de Product Owner richting het Development team welke taken als eerst opgepakt moeten worden. De Product Owner draagt verantwoordelijkheid de waarde van het project te maximaliseren en de ROI te monitoren.
De Scrum Master draagt zorg voor een zo soepel mogelijk werkproces. Deze persoon regelt alle randzaken, zodat de leden van het Development Team ongestoord aan de slag kunnen met de geplande werkzaamheden. Denk hierbij aan een ruimte waar het team kan werken en trainingen ter bijscholing. Belangrijk om te vermelden is dat de Scrum Master niet voor ieder klein probleem op moet komen draven, het Development Team is inmiddels zelf-organiserend.
Regelmatig wordt de Scrum Master vergeleken met een projectmanager. Houd in gedachten dat deze twee rollen compleet van elkaar verschillen. Terwijl de projectmanager taken omtrent personele zaken vervult, begeleidt de Scrum Master het werkproces. Vanwege deze zorgvuldige verdeling ontstaat een transparante en vertrouwelijke omgeving om in te werken.
Het Development Team voert alle werkzaamheden uit omtrent het lopende project. Om een zo’n soepel mogelijk werkproces na te streven wordt een aantal van minimaal 3 en maximaal 9 mensen beoogd. Iedere persoon draagt op een bepaalde manier bij aan het team: het idee van het Development Team is dat deze zelf-organiserend is. Dit wil zeggen dat zij met z’n allen de opdrachten bekijken, het ontwerp van een product of service bedenken en ontwikkelen en uiteindelijk het (deel)product aan een test onderwerpen. Wanneer een sprint ten einde komt wordt van het team verwacht dat zij het project bij de klant opleveren.
Om overzicht te genereren binnen het werkproces wordt gebruik gemaakt van de volgende lijsten.
User Stories geven een beschrijving, geschreven vanuit het oogpunt van de eindgebruiker, van de werkzaamheden die vermeld worden op de Product Backlog. Een manier om dit vorm te geven is als volgt:
Als (klant) wil ik (beschrijving van het te ontwikkelen product/dienst), zodat ik (reden van ontwikkeling).
Wanneer alle User Stories geschreven zijn, worden deze verzameld op de Product Backlog. Zo hebben alle leden van het Development team in één oogopslag een overzicht van de geplande taken: hoeveel werkzaamheden moeten nog aangepakt worden, hoeveel tijd wordt hiervoor ingepland en welke User Stories hebben de hoogste prioriteit?
Op de Product Backlog staan alle werkzaamheden die gerelateerd zijn aan het op te leveren product. Om het uiteindelijke product te ontwikkelen bedenkt het team eerst welke werkzaamheden nodig zijn om dat punt te bereiken.
De Sprint Backlog heeft als doel inzicht te geven in de status van het project. Overzicht wordt gecreëerd aan de hand van drie kolommen: ‘To Do’, ‘Doing’ en ‘Done’. Bij aanvang van iedere sprintperiode – meestal 2 tot 4 weken – wordt een nieuwe Sprint Backlog gemaakt. Alle taken behoren aan het eind van de sprint onder ‘Done’ te hangen: het project is daarmee afgerond. Daarna wordt een nieuwe sprint gestart met een daarop volgend project. Al deze projecten samen vormen het beoogde product of de dienst.
Een Taak is datgene dat binnen een sprint afgerond moet worden om het sprintdoel te behalen; ofwel het (deel)project op te leveren aan de klant. Het Development team bepaalt zelf hoe de taken uitgevoerd worden, maar de Product Owner beslist welke werkzaamheden prioriteit hebben en als eerste opgepakt dienen te worden.
In de Burn-down Chart wordt in één oogopslag een overzicht van de werkzaamheden gegeven die nog opgepakt dienen te worden. Tevens wordt via deze chart duidelijk hoeveel tijd nog rest tot het einde van de sprint.
Bij het begin van een nieuwe sprint wordt met het gehele Scrum team afgesproken wanneer een item afkomstig van de Product Backlog als ‘done’ kan worden beschouwd, dit wordt de Definition of Done genoemd. Door deze checklist te handhaven zitten de Product Owner en het Development team altijd op één lijn, dit komt ten goede van een prettige samenwerking. Daarnaast hebben de vooraf bepaalde richtlijnen een snellere oplevering van projecten tot gevolg. Al met al veel mooie voordelen om een Agile werkwijze te hanteren.
Afsluitend brengen de volgende bijeenkomsten meer structuur in het verloop van het project.
Voorbeeld van een Burn-down Chart
In de Sprint Planning wordt duidelijk wat het doel van de komende sprint is: wat moet aan het eind opgeleverd worden? In deze meeting, die maximaal 8 uur in beslag mag nemen, worden taken vanuit de Product Backlog geselecteerd die zullen worden behandeld in de komende sprint. Nadat deze taken op de Sprint Backlog zijn geplaatst, zal het team samen bepalen hoe de werkzaamheden uitgevoerd zullen worden.
Tijdens de Daily Scrum worden alle leden van het Development team bij elkaar gebracht om de komende 24 door te spreken. In maximaal 15 minuten geeft iedereen opheldering over de huidige stand van zaken: hoe ver zijn zij met de werkzaamheden, wat staat er op de planning en hebben zij ergens hulp bij nodig? Op deze manier is iedereen op de hoogte van ieders werk en kan waar nodig een helpende hand geboden worden. Om ervoor te zorgen dat deze dagelijkse meeting niet uitloopt op een langdurige vergadering, wordt de Daily Scrum staand gehouden.
In de Sprint Review wordt het afgeronde (deel)product aan alle stakeholders gepresenteerd. Het is de bedoeling dat de klant feedback geeft, zodat eventuele aanpassingen opgenomen kunnen worden in de komende sprint. Door steeds deelproducten op te leveren en deze te voorzien van feedback, zal de klant bij de eindoplevering gegarandeerd tevreden zijn over het aangevraagde product of dienst.
Ook de Sprint Retrospective staat ingepland na iedere sprint. Tijdens deze meeting bespreken de leden van het Scrum team hoe de samenwerking in de afgelopen sprint is gegaan. Eventuele verbeterpunten in het werkproces kunnen worden meegenomen in volgende sprint. Kom meer te weten over de Sprint Retrospective door middel van onze animatie video.
Om in te schatten hoeveel werk gaat zitten in een bepaalde taak, wordt bij de start van een nieuwe sprint een Estimation Meeting ingepland. Het Development team komen bij elkaar om alle User Stories op de Product Backlog te voorzien van een tijdsinschatting. Vaak wordt dit gedaan aan de hand van planning poker.