Home » Training » Informatie » Best Practices » Scrum Best Practice

SCRUM BEST PRACTICE

Wat is Scrum?
Scrum is een flexibele manier om (software)producten te maken. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende (software) producten opleveren. Scrum is een term die afkomstig is uit de rugbysport. Bij een scrum probeert een team samen een doel te bereiken en de wedstrijd te winnen. Samenwerking is heel belangrijk en men moet snel kunnen inspelen op veranderende omstandigheden. Scrum wordt veel gebruikt bij producten waarvan de klant of gebruiker nog niet goed weet wat hij wil en waarbij men al doende leert om de eisen en wensen beter te beschrijven en in bruikbare producten om te zetten. Vaak weet men pas wat men wil als men het eerste product, het prototype, ziet en dan worden alsnog de eisen aangepast. Scrum heeft de flexibiliteit om met laat wijzigende eisen en wensen om te gaan. Scrum valt onder de Agile-softwareontwikkeling.

Geschiedenis Scrum
Scrum werd geïntroduceerd in een onderzoek door Ikujiro Nonaka en Hirotaka Takeuchi, dat begin 1986 in de Harvard Business Review gepubliceerd is. In dit onderzoek wordt beschreven dat projecten met kleine (multidisciplinaire) teams historisch gezien het beste resultaat leveren. Naar aanleiding van dit onderzoek ontwikkelde Jeff Sutherland in 1993 het scrumproces, terwijl Ken Schwaber een eigen benadering bij zijn bedrijf toepaste. Samen werkten ze dit verder uit en in 1995 formaliseerde Ken Schwaber scrum als softwareontwikkelmethode. Scrum is ontwikkeld in de USA en wordt veelal gebruikt in deels Engelstalige projecten, vandaar de Engelse terminologie.

Scrum methode

Doelstellingen Scrum
– in korte sprints snel werkende producten opleveren, waardoor snel duidelijk wordt of men goed bezig is. Dit beperkt de risico’s van langere projecten waarvan soms pas na een jaar gebruikers of klanten een resultaat kunnen zien of testen;
– snel duidelijkheid over de voortgang;
– korte lijnen, snelle communicatie, teamwerk;
– Grote betrokkenheid teamleden, concentratie op een overzichtelijk deel van een project.

Uitgangspunten Scrum
– Toewijding: de leden moeten zich er vol voor inzetten; het is geen part-time klus;
– Focus: men moet zich focussen op wat er in de sprints gedaan moet worden;
– Openheid: men moet elkaar goed op de hoogte houden van de voortgang en mogelijke problemen;
– Respect: men moet mensen met een andere achtergrond en expertise respecteren;
– Lef: men moet lef hebben om zaken te benoemen, vragen te stellen en met nieuwe oplossingen te komen.

Werkwijze Scrum
Bij scrum worden de experts bij elkaar in één team gezet, bij voorkeur ook in één ruimte, zodat er makkelijk kan worden samengewerkt. Het team wordt begeleid door een “scrummaster”, die zorgt dat het team zich aan de (scrum)regels houdt en kan doorwerken. De product-owner is de klant en voor hem/haar wordt het product gemaakt. Hij geeft ook aan wat er gemaakt moet worden. Dat gebeurt in de vorm van userstories (een soort eisen en wensen (requirements)). Deze user-stories staan op een lijst, de productbacklog. De productbacklog is door de product-owner gesorteerd op belangrijkheid. De belangrijkste user-stories staan bovenaan. De belangrijkste user-stories worden opgenomen in de sprint backlog, dat is wat men in de sprint wil gaan doen. De sprint wordt ook wel de iteratie of de scrum genoemd. In korte sprints worden de user-stories door het ontwikkelteam in kant en klare producten omgezet, inclusief documentatie en (integratie)tests. Het is dus in principe helemaal af. Aan het einde van elke sprint wordt het gewijzigde of verbeterde (software)product in de “Demo” aan de product-owner getoond. Daarna volgt nog een evaluatie waarin het team probeert lessen te trekken uit de afgelopen sprint, zodat men steeds beter wordt.

Rollen Scrum
Bij Scrum worden de volgende drie hoofdrollen onderkend:

Product-Owner
De Product-Owner (producteigenaar) is de opdrachtgever / klant. Hij heeft het meeste belang bij het (software)product dat gemaakt wordt. Hij zorgt dat de rekening betaald wordt. Hij / zij beheert ook de product backlog, de Product-Owner bepaalt wat er moet gebeuren en in welke volgorde. In principe wordt gestart met het belangrijkste, waar het meeste voordeel mee te behalen is, en wat boven aan de product backlog staat.

Ontwikkelteam
Het ontwikkelteam is multidisciplinair samengesteld en is verantwoordelijk voor het afleveren van het (software)product aan het einde van elke sprint. Het team bestaat meestal uit 3 tot 9 personen. Het team organiseert zichzelf. Het team analyseert, ontwerpt, ontwikkelt, test en documenteert en zorgt ervoor dat er aan het eind van een sprint een kant en klaar product is, dat in principe in productie genomen kan worden.

Scrummaster
De Scrum Master begeleidt het ontwikkelteam door te zorgen dat het juiste scrumproces gevolgd wordt. Hij verzorgt ook eventuele trainingen. De scrummaster is in charge van alle vergaderingen. Ook regelt hij de voorzieningen zoals een werkruimte, hardware en software. De scrummaster zorgt ervoor dat het team niet lastiggevallen wordt door derden die met extra eisen tussendoor komen of die bijvoorbeeld tijdelijk capaciteit nodig hebben uit het team. De scrummaster is geen projectmanager. Hij regelt bijvoorbeeld niet de personele zaken zoals selectie, beoordeling en beloning van de mensen. Dit bevordert de openheid en samenwerking.

Scrum Vergaderingen

Daily scrum
Elke dag is er de “Daily scrum” of “Stand-up”. Deze vergadering kent de volgende regels:
– Alle leden van het ontwikkelteam hebben zich voor de vergadering voorbereid;
– De vergadering start precies op tijd, ook als niet iedereen aanwezig is;
– De vergadering is elke dag op precies dezelfde tijd en plaats, meestal 9:00 uur in de projectkamer.
De vergadering duurt maximaal 15 minuten, korter mag ook. De vergadering wordt staande gehouden: “stand-up”, zodat de duur daardoor al snel tot 15 minuten wordt beperkt. Vergelijkbaar met een overleg tussen sporters aan het begin van bijvoorbeeld een rugbywedstrijd. Bezoekers zijn welkom maar normaal gesproken spreken alleen de leden van het ontwikkelteam, de scrummaster en product-owner. Normaal gesproken houdt men een rondje waarbij elk teamlid drie vragen beantwoordt:
– Wat heb je gedaan?
– Wat ga je doen?
– Zie je ook problemen/uitdagingen (impediments), heb je hulp nodig, zijn er dingen die voor andere teamleden van belang zijn?

Aangezien de vergadering een duur van maximaal 15 minuten heeft, zullen grotere problemen buiten de vergadering worden besproken. De vergadering is net lang genoeg om één kopje koffie, staande, op te drinken.

Backlog refinement
De user stories die op de backlog staan moeten worden opgesteld en uitgewerkt en daarom is het belangrijk om goed te begrijpen van de product-owner en via hem van de rest van de organisatie, wat hij nu precies wil.
Zaken die in eerste instantie nog vaag zijn, zoals een “gebruikersinterface ontwikkelen”, of “management rapportages”, kunnen mogelijk ook opgesplitst worden in kleinere beter en beter behapbare onderdelen, zoals “gebruikersinterfaces voor verschillende groepen gebruikers”, “financiële overzichten” en “commerciële overzichten”. Dit maakt het mogelijk om na te denken over de beste oplossing, zodat ook ingeschat kan worden hoeveel tijd het kost om het gevraagde te maken. Hierdoor wordt het ook mogelijk om acceptatiecriteria vast te leggen. Mogelijk moet zelfs nog aanvullend onderzoek gedaan worden in de vorm van zogenaamde “spikes”.

Binnen de watervalmethode zou dit de analysefase genoemd worden. Bij scrum heeft men dit overleg vrijwel wekelijks, gedurende het gehele project. Dit proces is niet het belangrijkste scrum proces, maar in de loop van de tijd toegevoegd om te zorgen dat de zaken op de backlog voldoende kwaliteit hebben (dus duidelijk genoeg zijn), om in de komende sprint opgenomen te worden.

Scrum of scrums
Als er meerdere scrum teams zijn, is een overleg tussen deze teams nodig. Het gaat dan om de punten waarop men met elkaar te maken heeft zoals bijvoorbeeld de interfaces. Dit overleg wordt normaal gesproken aansluitend aan de daily scrum gepland. Elk team stuurt een vertegenwoordiger naar het overleg.
De agenda is ongeveer hetzelfde als bij de dagelijkse scrum, namelijk:
– Wat hebben jullie gedaan sinds de vorige meeting?
– Wat gaan jullie nu doen?
– Gaat alles goed of hebben jullie problemen / vertraging?
– Zijn er zaken die voor ons van belang zijn, waar we last van zouden kunnen hebben?

Sprint planning
Aan het begin van de sprint vindt een sprint planning overleg plaats. In principe worden de bovenste, belangrijkste user-stories van de product backlog in de sprint opgenomen. Het ontwikkelteam moet expliciet zeggen dat alles duidelijk is en dat zij denken dat de planning haalbaar is. Taken worden dan vervolgens verder binnen het ontwikkelteam verdeeld.

Demo
In de “Demo” wordt het product getoond dat af is. Eventueel wordt ook aangegeven wat niet gelukt is om af te krijgen in deze sprint. De Demo duurt maximaal 4 uur. Het hele sprint team is aanwezig plus eventueel andere geïnteresseerden. Een borrel na afloop is een goede gewoonte!

Evaluatie / Retrospective
De evaluatie is bedoeld om te leren van wat goed en fout ging met als doel om als team nog beter te worden. Alle teamleden zijn dan ook aanwezig. Het overleg duurt 3 uur en wordt geleid door de scrum master. Men maakt een rondje en iedereen zegt wat goed en fout ging.

Product backlog
De product backlog is een overzicht van werkzaamheden die nog moeten gaan plaatsvinden. Dit worden in andere software ontwikkelmethoden de requirements genoemd, de eisen en wensen. De product backlog bestaat uit alles wat van belang is om mee te nemen in de sprint zoals eigenschappen, fouten uit vorige releases, niet functionele eisen zoals navigatie, kleur, “look en feel”, snelheidseisen etcetera. De product-owner is de eigenaar van deze lijst en bepaalt de volgorde. In principe staan de belangrijkste eisen bovenaan, maar ook een andere volgorde is mogelijk. Hierbij spelen zaken als risico, waarde voor de organisatie, datum waarop iets nodig is, wettelijke eisen en dergelijk een rol. De zaken op de lijst worden normaal gesproken weergegeven in de vorm van een user story. Hierin staat WAT er gemaakt moet worden WAAROM en voor WIE. Iedereen kan er informatie aan toevoegen, maar de product-owner is en blijft verantwoordelijk voor de juistheid van de lijst. Er staan ook ruwe schattingen bij van de waarde voor de organisatie en van de ontwikkelkosten. Voor het inschatten van de ontwikkeltijd kan gebruik gemaakt worden van wat binnen scrum “planning poker” genoemd wordt.

Sprint backlog
In de sprint backlog staat wat er tijdens sprint wordt gedaan. De sprint backlog wordt samengesteld uit de bovenste items van de product backlog. Het ontwikkelteam bepaalt wat ze kunnen doen gebaseerd op hun snelheid in de vorige sprints. Gebruikelijk is dat de items op de sprint backlog geschreven worden op post-its. Er zijn dan drie kolommen, “to do”, “in progress”, “done”. Soms met een vierde kolom “testing”. Zodoende is voor iedereen duidelijk wat de status is. Het ontwikkelteam bepaalt zelf wie wat doet, of eigenlijk kiezen de leden zelf wat ze (kunnen en willen) oppakken van de todo-lijst. Dit bevordert dat het team zich ermee verbonden voelt, dat ze zich ervoor willen inzetten, en dat het hun product wordt. Er kunnen na de start geen items meer toegevoegd worden aan de sprint, behalve door het ontwikkelteam zelf. Nadat de sprint klaar is, wordt de Product Backlog nog eens tegen het licht gehouden en kunnen prioriteiten en dus de volgorde wijzigen.

Acceptatiecriteria / definition of done
In de “Definition of done” staat wat er is afgesproken over hoe men een product oplevert. Dit heeft betrekking op bijvoorbeeld de eisen aangaande documentatie (Engelstalig), testen (getest door gebruikers en de afdeling beheer, op welke apparaten/webbrowsers), de locatie (op de acceptatieomgeving) etcetera.

Verbetering / Increment
De “verbetering” (increment) is een lijst van alle gerealiseerde verbeteringen / veranderingen aan het product. Deze lijst wordt bij elke sprint, aan het eind van de sprint bijgewerkt. Hierop staan alleen items die voldoen aan de “definition of done”. Dit overzicht moet in een vorm zijn die bruikbaar is voor de klant / product-owner. De lijst kan nodig zijn om verdere investeringen in het project te verdedigen en om aan buitenstaanders / klanten / dealers / overheid, duidelijk te maken wat men tot nu toe bereikt heeft. Of deze lijst gebruikt en gepubliceerd wordt, ligt aan de product-owner.

Burn down Chart
De burn down chart van de sprint hangt meestal aan de wand in de projectkamer. Op die manier is voor iedereen direct duidelijk hoeveel er nog gedaan moet worden. Doordat deze chart dagelijks wordt bijgewerkt is direct duidelijk hoe het ervoor staat. Er zijn ook andere typen van “burn down charts” in gebruik, bijvoorbeeld de release burn down chart. Hierop staat hoeveel er nog gedaan moet worden voor de volgende release van het product. Uiteraard er vanuit gaande dat een “release” in meerdere sprints gerealiseerd wordt. Ook bestaat er een alternative release burn down chart, deze heeft in principe dezelfde functie, maar geeft extra de wijzigingen aan door het meer/minder werk, inzichtelijk door voortschrijdend inzicht.

Begrippen
Producteigenaar (ProductOwner): de verantwoordelijke voor de productbacklog, waarmee de prioriteiten van de belanghebbenden naar voren komen zodat het werk van het ontwikkelteam waarde heeft voor de organisatie.

Scrummaster: de verantwoordelijke voor het scrumproces, de persoon die ervoor zorgt dat alles goed loopt en men maximaal profiteert van de voordelen van scrum.

Ontwikkelteam: een groep van specialisten verantwoordelijk voor het ontwikkelwerk en de realisatie van een in principe kant en klaar product(uitbreiding).

Sprint burn down chart: een grafiek waarmee de dagelijkse voortgang van de sprint wordt weergegeven.

Release burn down chart: een grafiek waarmee wordt aangegeven wat er al van de productbacklog klaar is en wat er nog gedaan moet worden.

Productbacklog (Product backlog): een lijst met op hoog niveau de eisen/wensen voor het product.

Sprintbacklog (Sprint backlog): een lijst met taken die tijdens de sprint moeten worden uitgevoerd.

Sprint: een periode van 1 tot 4 weken waarin men een aantal zaken van de productbacklog oppakt. Dit is een time-box.

Spike: een korte periode waarin in een time-box een onderzoek gedaan wordt. Bijvoorbeeld om een prototype te maken of te testen of iets mogelijk is.

Lichtkogel (Tracer Bullet): een lichtkogel (tracer bullet) is een spike waarmee men probeert te onderzoeken wat de mogelijkheden zijn van de gekozen projectarchitectuur, technologie en best practice. Het resultaat is een stukje programmatuur. Het is misschien de ontwikkeling van een klein onderdeel, maar het is geen wegwerpprogrammatuur. Het kan in het verdere proces gebruikt worden. Het is een “Proof of concept” en ook een “Prototype”, bedoeld om inzicht te krijgen in de nieuwe architectuur, technologie en werkwijze. De naam komt uit het leger, daar gebruikt men lichtspoormunitie om het spoor van de kogels te volgen en eventueel de richting te corrigeren.

Taken: aan het begin van de sprint worden de stories van de productbacklog uiteengerafeld tot taken. Aan een taak hangt een planning in uren. Een taak mag volgens de theorie maximaal 12 uur zijn, maar meestal spreekt men af dat taken maximaal een dag (8 uur) duren.

Definition of Done (DoD): de afvinkcriteria waaraan iets moet voldoen om klaar te zijn. In veel gevallen is bijvoorbeeld een eis dat alle regressietests succesvol zijn afgesloten.

Velocity: de snelheid van het team, wat het team kan doen in één sprint. De snelheid kan worden berekend op grond van de gerealiseerde snelheid in vorige sprints, gemeten in story punten, met behulp van een burn down chart. Dit is een richtlijn voor het team en omgeving om goed in te kunnen schatten hoeveel men kan doen en wat men kan verwachten.

Impediment (Obstakel): alles wat in de weg staat van een efficiënt proces.

Sashimi: een rapport waarin is aangegeven dat iets “klaar” is.

Abnormal Termination (Abort): indien nodig kan de product-owner (producteigenaar) een sprint voortijdig stoppen. De product-owner kan dit doen met input van het team, scrummaster of management. Het kan bijvoorbeeld zo zijn dat het management de sprint wil stoppen omdat externe omstandigheden het doel van de sprint niet meer nuttig maken. Als een sprint op deze manier gestopt wordt is het vervolg dat men in een vergadering uitlegt waarom dit nodig was, tevens is er dan weer een nieuwe “Sprint planning vergadering” om de volgende sprint te plannen.

ScrumBut: een ScrumBut is een uitzondering op de “echte” Scrumwerkwijze, waarbij het team scrum heeft aangepast aan hun eigen behoefte.

Pair programming: het in tweetallen werken aan een probleem. Dit is een intensieve samenwerking waarmee men van elkaar leert en samen iets probeert op te lossen wat te moeilijk is voor een persoon omdat kennis of vaardigheden ontbreken. Men kan hierbij gebruik maken van elkaars expertise.

Refactoring: het opnieuw programmeren van een bepaald onderdeel om het beter (onderhoudbaar) te maken.

Storypoint: worden gebruikt in planning om de omvang van een klus (story) aan te geven. Door een bekende korte klus 1 of 2 punten te geven kunnen grote klussen ingeschat worden als bijvoorbeeld driemaal zo lang of tienmaal zo lang.

Timeboxing: een methode waarbij men een afgesproken tijd, (time-box), neemt om iets te doen. Zodoende kan iets ook niet uitlopen. Men kan bijvoorbeeld voor het testen afspreken dat men drie dagen neemt om te zoeken naar fouten. Of men kan afspreken om per gebruiker twee dagen training te geven. Vergaderingen kunnen een begintijdstip en een eindtijdstip hebben.

Triangulation: een planningsmethode waarbij men vanuit verschillende gezichtspunten tot goede schattingen hoopt te komen. Voornamelijk door met elkaar te praten over waarom men denkt dat iets een bepaalde tijd gaat duren.

Eerstvolgende startdata Agile Foundation:

_____ _____ _____
_____ _____ _____