Toepassen van Scrum als process template

Toepassen van Scrum als process template Door Robin Witteman [email protected]

Introductie van Scrum Het toepassen van Scrum is in 1986 op de Universiteit van Harvard uitgedacht door Hirotaka Takeuchi en Ikujiro Nonaka. Scrum is een term uit het rugby waarbij een team probeert een afstand te overbruggen als een eenheid en ondertussen de bal heen en weer passt. Deze techniek hebben ze vertaald in hun artikel “The New New Product Development Game” naar een nieuwe methode om producten te ontwikkelen. Productontwikkeling werd destijds als een soort estafette-race gedaan. Het stokje werd iedere keer aan de volgende afdeling doorgegeven. Bij de oplevering van het product bleek dan niet het gewenste resultaat bereikt te zijn en moest er meer tijd en geld besteed worden om alsnog tot een goed product neer te zetten. Scrum als process template kan omschreven worden als een ‘light weight’ process template. De focus ligt op het leveren van de hoogst mogelijke business waarde in de kortst mogelijke tijd. De nadruk wordt gelegd op communicatie. Het werk wordt veel en vaak als werkende software opgeleverd en geïnspecteerd. Het onderstaande plaatje geeft het verloop van een project aan. Het product bestaat uit een lijst van taken die gedaan moeten worden, de product backlog. Uit die product backlog wordt per sprint een sprint backlog gemaakt. Deze shortlist bepaalt de werkzaamheden van de betreffende sprint. Tijdens de sprint, die tussen de 2 en 4 weken lang is, worden de taken uit de shortlist opgepakt. Iedere dag wordt de dagelijkse Scrum meeting gehouden. Hierin wordt kort uitgesproken per teamlid wat gisteren gedaan is, wat vandaag gedaan wordt en wat de werkzaamheden in de weg staat. Aan het einde van de sprint wordt een potentieel op te leveren product opgeleverd.

In dit artikel zal het Scrum process template van Scrum for Team System in de voorbeelden gebruikt worden. Dit process template bestaat uit de volgende work items: -

Bug Impediment1 Product Backlog Item Sprint Sprint Backlog Item Sprint Retrospective

Toepassen van Scrum Release Als een nieuw Scrum project gemaakt wordt, dan wordt standaard een set van template Releases en Sprints gemaakt, zoals het onderstaande plaatje laat zien.

1

alles wat een team tegen houdt om productief te zijn

Releases hebben geen begin- en einddatum. Deze data worden uit de data gehaald die aan de Sprints gekoppeld zijn.

Sprint Een Sprint Work Item Type bestaat uit de volgende velden: -

Sprint Name Capacity (hours) Sprint Start Date Sprint End Date Current Status Sprint Goal History

Sprint Backlog Item Een Sprint Backlog Item Work Item Type bestaat uit de volgende velden: -

Title Area Sprint Estimated Effort (Hours) Team Task Priority Owned By Work Remaining (hours) Current Status Description History Links File Attachments

Een Sprint Backlog Item wordt gemaakt door het aan een Product Backlog taak als een gerelateerd work item toe te voegen. Op deze manier wordt de nieuwe Sprint Backlog taak automatisch gekoppeld aan de geselecteerde Product Backlog taak.

Sprint Retrospective Er zijn drie typen items: -

What Didn’t Go So Well – om vast te leggen van welke gebieden het team vindt waar het niet zo goed was als ze wilde. What We Can Do Better – acties of activiteiten die de probleemgebieden zouden kunnen helpen verbeteren. What Went Well – om aan te geven welke gebieden het team als positief tijdens de uitvoering heeft ervaren.

Het Work Item Type bestaat uit de volgende velden: -

Title

-

Sprint Number Retrospective Type Team Individual Description History Links File Attachments

De spelers Product owner

Scrum master

Users

Scrum roles

Stakeholders

Team members

“Product Owner” De “Product Owner” is verantwoordelijk voor de retun on investment (ROI) van het project. Vaak is dit een medewerker van de klant. De taken: -

Definieert de features van het product en beslist over opleverdata en inhoud Verzamelt input van de gebruikers, stakeholders en andere geïnteresseerde partijen Is verantwoordelijk voor de return on investment Geeft prioriteiten aan de features aan de hand van de marktwaarde Kan features en prioriteiten elke 30 dagen wijzigen Accepteert of wijst werk resultaten af

“Team Members” Rollen en taken samengevat: -

Multifunctioneel (tester, developer, DBA in één) Teamgrootte van 7 (+/- 2)

-

Selecteren van het doel per iteratie en specificeren van werk resultaten Hebben het recht om alles binnen de grenzen van de projectlijnen te doen om het doel van de iteratie te halen Het team organiseert zichzelf en het werk Geven demonstraties van het werk resultaat aan de Product Owner en de stakeholders

“Scrum Master” De “Scrum Master” is de persoon die verantwoordelijk is om er zorg voor te dragen dat het proces gebruikt wordt zoals het bedoeld is. De Scrum Master kan gezien worden als een vader, een coach en een scheidsrechter. Een Scrum Master is een leider en facilitator en is verantwoordelijk voor: -

Het verbeteren van de productiviteit van het ontwikkelteam door creativiteit aan te moedigen en te ondersteunen Een hechte samenwerking tussen alle rollen en functies en het verwijderen van obstakels Het beschermen van het team tegen externe onderbrekingen Het zorgdragen dat het proces gevolgd wordt Het uitnodigen van de juiste mensen voor de daily scrum meeting, iteratie reviews en planning meetings Het verwijderen van obstakels tussen het ontwikkelen en de klant zodat de klant direct het ontwikkelen van de functionaliteit aanstuurt Het leren aan de klant hoe de return on investment gemaximaliseerd kan worden en hoe hun doelen bereikt kunnen worden door gebruik te maken van Scrum Het verbeteren van de ontwikkelmanieren en ontwikkelgereedschappen zodat iedere nieuwe increment van functionaliteit potentieel op te leveren is.

Specifieke onderdelen uitgelicht Wanneer is een onderdeel klaar? Het is belangrijk dat ieder lid in het team dezelfde definitie heeft van wanneer iets klaar is. Een goed uitgangspunt daarvoor is de volgende lijst: -

Code voldoet aan de standaarden Zinnige unit testen voltooien zoals verwacht Er is gerefactord Het is ingecheckt in source control Het ‘built’ met de rest van de code De kwaliteit is getest

Een Sprint Backlog Item kan van de “In Progress” status naar de “Done” status gezet worden. “Work Remaining” wordt dan direct op “0” gezet.

Hoe om te gaan met bugs Bugs zijn van het zelfde niveau als Product Backlog Items en niet, zoals misschien verwacht, op het niveau van een Sprint Backlog taak. Een bug is een defect in een stuk code dat al eens de status van

“Done” bereikt heeft. Zodra een defect onderkend is, wordt het als bug toegevoegd als nieuw werk. De bug wordt zichtbaar gemaakt door het toe te voegen aan de Product Backlog. De Product Owner bepaalt de prioriteit.

Toepassen van Scrum als process template – als developer Na de beschrijving over het toepassen van Scrum als process template is de volgende stap het toepassen voor de developer. Wat zijn de stappen om het in een project toe te passen? Hieronder het plaatje hoe Scrum verloopt als referentie.

Stap 1: Product Backlog De product backlog is de verzameling van alle features voor het product. Deze items worden doorgaans in een User Story formaat geschreven. Dat wil zeggen dat het vanuit het oogpunt van de gebruiker geschreven wordt. De Product Owner is verantwoordelijk voor het beheer van de product backlog.

Prioriteit De items in de product backlog moeten voorzien worden van een prioriteit. Items met een hoge prioriteit moeten gedetailleerder beschreven zijn en ook een preciezere tijdschatting krijgen. De prioriteiten worden door de Product Owner gesteld.

Items invoeren Items zijn op twee manieren in te voeren. Enerzijds via Visual Studio door het toevoegen van een nieuw product backlog work item en anderzijds via Excel. Met Excel kan een connectie gelegd worden naar de Team Foundation Server. De eenvoudigste manier is vanuit de Team Explorer op de query “All Product Backlog Items” rechts te klikken en voor “Open in Microsoft Excel” te kiezen.

In Excel is dan vervolgens de mogelijkheid om met “Publish” de nieuwe work items op te slaan in de Team Foundation Server.

Stap 2: Sprint Het project wordt in meerdere Sprints verdeeld. Een Sprint beschrijft wat er in die periode globaal aan werkzaamheden gedaan zal worden en wat het einddoel is. Het Sprint work item wordt gebruikt om Sprint Backlog items te groeperen. Een sprint duurt tussen de 2 en 4 weken. De duur is over het algemeen voor alle sprints gelijk en wordt vaak op 2 weken gelegd.

Toelichting op stap 2 Voor stap 2 is de duur op 2 weken gesteld. De reden hiervoor is dat dit een mooie lengte is om de werkzaamheden in uit te voeren. Binnen deze tijd is het minder snel mogelijk om terug te vallen op het doen van zogenoemde mini-watervallen. Het voordeel daarvan is, dat agile werken daardoor bevorderd wordt. Daarnaast is de periode van 2 weken ook kort genoeg om tegen te gaan dat er iets ontwikkeld wordt, wat de klant niet voor ogen had. Het is minder erg om 2 weken werk over te doen.

Stap 3: Sprint Backlog De lijst met Product Backlog items wordt verdeeld over verschillende sprints. Deze verdeling kan op verschillende manieren gedaan worden. Het eindresultaat van een sprint is een potentieel op te leveren product, dus de verdeling moet daar rekening mee houden. Verder is het handig om de features die eenvoudig te realiseren zijn in de eerste sprint te zetten. Het team heeft dan de kans om te wennen en in te werken. Deze lijst wordt de Sprint Backlog. Elk Sprint Backlog Item wordt als related work item toegevoegd via het bijbehorende Product Backlog work item. Het veld Sprint uit het work item wordt gevuld met de desbetreffende Sprint. Het is aan het team om de Sprint Backlog aan te maken en bij te houden.

Toelichting op stap 3 De reden om in de eerste sprint de eenvoudige taken op te pakken, is al genoemd, namelijk inwerken en wennen. Ik wil hierbij benadrukken, dat dit een fijne manier van starten is. De druk is nog laag en de mogelijkheid om kennis op te doen over het op te leveren eindresultaat is dan nog zeer aanwezig.

Stap 4: Werkzaamheden tijdens de Sprint Tijdens de Sprint zijn de developers met de Sprint Backlog work items aan de slag. Elke developer die een work item op pakt, verandert de status naar ‘In Progress’. De werkzaamheden voor dat specifieke work item kunnen tijdens het inchecken aan het betreffende work item worden gelinkt. Zo worden de werkzaamheden gekoppeld, zodat later terug te vinden is welke code bij welke feature hoort. Als een item klaar is, kan de status naar ‘Done’ gezet worden.

Toelichting op stap 4 Een opmerking over sprints waarin te veel werk zit: dit wordt aan de Product Owner voorgelegd met het verzoek voor advies over welke items geschrapt kunnen worden uit de lopende Sprint. Een opmerking over sprints waarin te weinig werk zit: dit wordt eveneens aan de Product Owner voorgelegd met het verzoek voor advies over welke items uit de Product Backlog toegevoegd zouden kunnen worden. Een opmerking over sprints waarvan wordt ingezien dat deze niet haalbaar zijn: deze kunnen geannuleerd worden. Na het annuleren wordt een nieuwe Sprint Planning sessie gehouden.

Stap 5: Sprint afronden Aan het eind van de sprint is het zaak dat alle ontwikkelde code getest is en de bugs opgelost zijn, zodat de Sprint Review kan plaats vinden. De Sprint Review bestaat uit het demonstreren van het product van de sprint door de teamleaden aan de Product Owner, klanten en eventueel management. Na de Sprint Review wordt er geëvalueerd waar in de volgende Sprint aan gedacht

moet worden. Vervolgens kan de volgende Sprint weer beginnen met het samen stellen van de Sprint Backlog op basis van de verworven inzichten.

Stap 6: Release Sprint Na een aantal Sprints is het product volwassen genoeg om daadwerkelijk opgeleverd te worden. Daar is de Release Sprint het geschikte moment voor. In deze Sprint wordt geen extra functionaliteit meer toegevoegd. De taken die wel binnen deze Sprint vallen zijn bijvoorbeeld: -

De code naar de productie omgeving deployen Productie data vullen Rollback scenario

Het team is verantwoordelijk voor het opleveren van het product.

Toelichting op stap 6 Het uitvoeren van een Release Sprint is niet een eenmalige sprint, waarna het product klaar is. Het is veel interessanter om het product, zodra het mogelijk is, al op te leveren. Het is voor de Product Owner aan te raden om te streven naar “early & often” release sprints. Oftewel zo snel als mogelijk en zo vaak als mogelijk het product opleveren. Dit levert naast mogelijk Return on Investment ook reacties van gebruikers op. Deze kunnen toekomstige sprints beïnvloeden. Ik kan dus niet genoeg benadrukken om dit toe te passen.

Conclusie Early & often... Dat is waar het eigenlijk allemaal om draait. Scrum gaat er volledig over om alles zo vroeg mogelijk te communiceren, ontdekken, herkennen, erkennen, melden, bijschaven, aanpassen, omgooien en dat alles ook zo vaak mogelijk. Om maar even een voorbeeld te nemen, situatie A: Een ontwikkelaar vindt tijdens het project een methode om een bepaald probleem aan te pakken. Deze methode kost twee dagen om te implementeren. De ontwikkelaar meldt dit niet aan de andere teamleden, want hij is druk bezig. Andere teamleden zitten vervolgens te wachten op de oplevering van het deel van de ontwikkelaar en gaan wat anders doen of zijn zelf bezig om het probleem aan te pakken, aangezien het nog niet is opgelost. Situatie B: Een ontwikkelaar vindt tijdens een sprint een methode om een bepaald probleem aan te pakken. Deze methode kost twee dagen om te implementeren. De ontwikkelaar meldt dit tijdens de Scrum meeting. Andere teamleden kunnen direct profiteren van de methode voor eigen gebruik zodra deze klaar is, maar het is ook mogelijk om rekening te houden met eigen werkzaamheden die afhankelijk zijn het werk van de ontwikkelaar. Als er “early & often” gecommuniceerd wordt, zoals in situatie B, kan het team meedenken en de werkzaamheden er op aanpassen.

Agile, Early & often