Handreiking voor toepassen van Agile Scrum binnen Overheidsdiensten

Transcriptie

1 Handreiking voor toepassen van Agile Scrum binnen Overheidsdiensten Versie 1.0 Datum april 2012 Status definitief

2 Colofon Projectnaam Locatie Contactpersoon Bijlage(n) 1 Auteurs DR en Quintor Project BAS, Borging Agile Scrum B. (Berend) van Duijvenvoorde Projectmanager, Dienst Regelingen M b.van.duijvenvoorde@minlnv.nl Pagina 2 van 39

3 Inhoud Voorblad 2 Colofon 2 Inhoud 3 Voorwoord 4 Leeswijzer 5 1 Kennis Agile Scrum Inleiding Scrum een introductie Rollen Proces Agile Ontwikkelmethodieken Agile en Prince Veel gestelde vragen over Scum en Agile Begrippenlijst 14 2 Ervaring DR Agile Scrum Inleiding Vakgroep Agile Scrum Supportteam Agile Srum Handreikingen op het gebied van communicatie Opleiding Agile Scrum Valkuilen Issues tijdens de start van een Agile Scrum project Issues tijdens het uitvoeren van een Agile Scrum project Evaluatie van een Agile Scrum project Best Practices van Agile Scrum Projecten binnen DR Ondersteunende Tooling 34 3 Bijlagen Stakeholders Agile Scrum binnen DR 37 Pagina 3 van 39

4 Voorwoord Je hebt de eerste bladzijde opengeslagen van het boekje Handreiking voor toepassen Agile Scrum binnen Overheidsdiensten. Misschien uit nieuwsgierigheid, misschien uit nood geboren. Hoe dan ook: met dit boekje willen we je op weg helpen en begeleiden in jouw Agile Scrum project. Het afgelopen anderhalf jaar heeft Dienst Regelingen de eerste ervaringen opgedaan met deze aanpak. En met succes! We kunnen met trots zeggen dat we unieke samenwerking in projecten hebben zien ontstaan en ook bijzondere resultaten. Maar ook de keerzijde hebben we gezien. Je doet Agile Scrum niet zomaar even. Dat is wel de grote valkuil: onvoorbereid aan een Agile Scrum traject beginnen. De spreuk Mislukken in je voorbereiding is voorbereiding van je mislukking gaat dan zeer waarschijnlijk op. Met alle gevolgen van dien. We hebben ook gemerkt dat het niet eenvoudig is om met Agile Scrum te werken. Het vraagt kennis door training, goede begeleiding van een Scrum Master en zeker ook iets van je houding en gedrag. Dit boekje geeft geweldige handvatten voor het werken met Agile Scrum: valkuilen, lessons learned, randvoorwaarden en nog veel meer. Allemaal geput uit de ervaringen die we bij DR daadwerkelijk hebben opgedaan, aangevuld met de nuttige toevoegingen van onze externe begeleiders in dat proces. We zijn dan ook voor dit boekje niet over één nacht ijs gegaan: een heus Agile Scrum project (Borging Agile Scrum) heeft dit resultaat opgeleverd. Met dank aan de projectleden: Berend van Duijvenvoorde, Ben Bruinsma, Geert de Boer, Marian Huizing, Lisette Kemper en Jan van Beek (Quintor). Dit boekje gaat helpen, daar zijn wij als Product Owners van dit project, heilig van overtuigd. We hopen dat hiermee de ontwikkeling van Agile Scrum bij DR zich zal doorzetten. Fouten maken mag daarbij uiteraard. Maar: je hoeft niet steeds dezelfde fouten te maken, er is keus genoeg! Dit boekje kan alvast veel fouten voorkomen maar bovenal begeleiding en inspiratie geven voor een mooi en resultaatgericht Agile Scrum project. Wij kunnen je van harte aanbevelen het boekje verder te lezen. Veel plezier en wijsheid daarbij! Februari 2012, Harry Boer Stefan Drenth Pagina 4 van 39

5 Leeswijzer Deze handreiking gaat over de ontwikkelmethodiek Agile Scrum. De methodiek is internationaal en er is voor gekozen om de engelse termen te blijven gebruiken. De handreiking bestaat uit twee delen. Het eerste deel is bedoeld als kennisbron over de methodiek Agile Scrum. De vraag; Wat is Agile Scrum en hoe doe je dat? wordt beantwoord. In het tweede deel staat de ervaring die binnen Dienst Regelingen met Agile Scrum is opgedaan centraal. Met de ervaringen uit meerdere projecten is veel geleerd over het handig toepassen van Scrum. In dit deel zijn een aantal lijsten opgenomen (paragraaf en 2.10), die met ervaring van scrumleden uit nieuwe projecten aangevuld kunnen worden. Deze documenten zijn in beheer van het Support Team Agile Scrum en zijn gepubliceerd op Pleio, het gaat om: Valkuilen die zich vaak voordoen bij het uitvoeren van een project met mogelijke maatregelen Issues tijdens de start van een Agile Scrum project Issues tijdens het uitvoeren van een Agile Scrum project Best Practices van Agile Scrum Projecten binnen DR Mocht je vragen, opmerkingen of aanvullingen hebben of mee willen discussiëren, neem dan contact op met: de leden van de vakgroep via PLEIO, DR Agile Scrum Community het Support Team Agile Scrum via PLEIO, Dienst Regelingen of via de postbus mailto: Pagina 5 van 39

6 1 Kennis Agile Scrum 1.1 Inleiding In dit eerste deel wordt de lezer meegenomen in de Agile Scrum methodiek. Binnen DR, onder meer met ondersteuning vanuit Quintor, worden steeds meer projecten op deze wijze uitgevoerd. Als aanvulling op het Handboek Projectmatig Werken passeren in een notendop de belangrijkste zaken rondom Agile Scrum. 1.2 Scrum een introductie De basis van Scrum is de Sprint, een periode van 3 tot 4 weken waarin het team werkt aan een vooraf vastgesteld Sprintdoel. Tijdens de Sprint werkt het team aan taken die in de Sprint Backlog zijn gedefinieerd. Deze taken worden uit de Product Backlog gehaald. De Product Backlog wordt in het begin van het project opgesteld door de Product Owner en bestaat uit alle functionaliteiten die in het project moeten worden ontwikkeld. Rondom de Sprint is een aantal meetings georganiseerd: de Sprintplanning, Daily standup, Demo en Retrospective. Voor het faciliteren van deze meetings is de Scrum Master verantwoordelijk. Afbeelding 1: Agile Scrum in een notendop Pagina 6 van 39

7 1.3 Rollen Het SCRUM TEAM Het Scrum team zorgt ervoor dat de functionaliteit uit de Sprint Backlog tijdens de Sprint wordt ontworpen, ontwikkeld en getest. Het team bestaat doorgaans uit 5-9 personen. Een grootte die, door ervaring en onderzoek aangetoond, het meest effectief is. Het team is zelforganiserend en de leden hebben een gezamenlijke verantwoordelijkheid voor de resultaten. De PRODUCT OWNER Een Product Owner verzamelt alle wensen en eisen t.b.v. het product en prioriteert de te ontwikkelen functionaliteit in de Product Backlog. Hiermee vertegenwoordigt de Product Owner de stem van de klant en zorgt ervoor dat het Scrum team bezig is met de voor de klant op dat moment belangrijkste functionaliteit. De Product Owner is vaak de klant, maar kan ook iemand zijn vanuit de interne organisatie. De functie vereist uitgebreide kennis over business processen. De Product Backlog is zichtbaar voor de hele organisatie zodat iedereen zich bewust is van wat er is te verwachten in toekomstige versies van het product. De SCRUM MASTER De Scrum Master zorgt ervoor dat het team de best mogelijke omstandigheden heeft voor het realiseren van het Sprintdoel. Het oplossen van de problemen en belemmeringen die binnen het team bestaan is de verantwoordelijkheid van de Scrum Master. Ook faciliteert de Scrum Master het Scrum-proces binnen het team. Hiermee is de Scrum Master probleemoplosser en coach. Tijdens de Sprint organiseert de Scrum Master dagelijks een Standup. Na elke Sprint organiseert de Scrum Master een Demo, Retrospective en Sprintplanning voor de volgende Sprint. Ook zorgt de Scrum Master voor een goede voorbereiding van deze meetings. Pagina 7 van 39

8 De PROJECTLEIDER De Projectleider krijgt van de stuurgroep de verantwoordelijkheid en bevoegdheid voor de dagelijkse gang van zaken in het project. Hiervoor stelt hij het projectplan op en regelt de bemensing en middelen. De projectleider kan beslissingen nemen binnen de grenzen zoals aangegeven door de stuurgroep. De belangrijkste verantwoordelijkheid van de projectleider is het zekerstellen dat het project de gewenste producten oplevert, binnen tijd, binnen budget en volgens de afgesproken kwaliteit. De projectleider faciliteert het Scrum team door impediments op te lossen die buiten het Scrum team liggen. Voor de Scrum Master is hij coach en ondersteuner. Ook faciliteert de projectleider de Product Owner bij het maken van keuzes en hij rapporteert de voortgang aan de stuurgroep. De projectleider vergewist zich ervan dat het project conform de afspraken wordt beheerst en uitgevoerd en managet risico s en budget. 1.4 Proces De PRODUCT BACKLOG De Product Backlog is een geprioriteerde lijst van alle user stories (stukjes functionaliteit) die in het project moeten worden ontworpen, ontwikkeld en getest. Deze lijst wordt voor de start van het project door de Product Owner samengesteld en mag tijdens het hele project worden gewijzigd. De items die als hoogst geprioriteerd staan worden verder in detail uitgewerkt. De items die lager op de lijst staan blijven in algemene bewoordingen totdat zij door de Product Owner belangrijk genoeg worden gevonden om in de komende Sprint op te pakken. De SPRINT BACKLOG De Sprint Backlog is de lijst van user stories die in de komende Sprint moeten worden ontworpen, ontwikkeld en getest. Dit zijn de hoogst geprioriteerde user stories uit de Product Backlog. De Sprint Backlog wordt tijdens de Sprintplanning samengesteld en mag tijdens de Sprint niet worden gewijzigd. Welke user stories in de Sprint Backlog komen te staan is afhankelijk van welke prioriteit de user story heeft en de beschikbare tijd van het team. Voor stories in deze backlog geldt dat ze moeten voldoen aan de Definition of Ready. De SPRINTPLANNING Bij de Sprintplanning zijn het team en de Product Owner aanwezig. Tijdens de Sprintplanning wordt het doel van de komende Sprint vastgesteld in de vorm van een Sprintdoel en Sprint Backlog. De Product Owner heeft tijdens de Sprint Planning de verantwoordelijkheid om het team de inhoud van de user stories uit te leggen en het Sprintdoel te formuleren. Het team heeft de verantwoordelijkheid te berekenen welke user stories zij kan oppakken in de Sprint (afhankelijk van de beschikbare tijd, velocity en inschatting van de zwaarte van de opgenomen user stories). Pagina 8 van 39

9 De DAILY STANDUP Elke dag, op hetzelfde tijdstip, komen het team en de Product Owner bij elkaar voor een Daily Standup. Deze meeting duurt maximaal 15 minuten en gebeurt staand. Tijdens de Daily Standup geeft elke deelnemer aan de hand van de user stories antwoord op de volgende vragen: Wat heb je gedaan sinds de laatste Standup? Wat ga je doen tussen nu en de volgende Standup? Loop je tegen problemen aan die je belemmeren in de uitvoering van je werk? De eerste twee vragen geven de deelnemers inzicht in de voortgang van de Sprint c.q. het project. De derde vraag levert een lijst van belemmeringen op die de Scrum Master samen met de projectleider moet opheffen. Iedereen kan deelnemen en luisteren tijdens de Standup, maar alleen de Scrum Master, Product Owner en de teamleden mogen spreken. Eventuele discussiepunten en het maken van afspraken worden geparkeerd tot na de Standup. De DEMO Aan het eind van de Sprint geeft het team een Demo aan alle stakeholders van het project, waarin getoond wordt wat er de afgelopen Sprint is opgeleverd. Het doel van de Demo is het ontvangen van feedback op de ontwikkelde functionaliteit. Deze feedback wordt door de Product Owner verzameld, geprioriteerd en op de Product Backlog geplaatst. Belangrijk is dat alle stakeholders bij de demo s vertegenwoordigd zijn. De RETROSPECTIVE Na de Demo voert het team samen met de Product Owner een Retrospective uit. Tijdens de Retrospective worden de ervaringen van de afgelopen Sprint besproken en worden er actiepunten voor de komende Sprint geformuleerd. Elke deelnemer geeft antwoord op de volgende vragen: Wat ging er goed en moeten we in de komende Sprint behouden? Wat ging er minder goed en kunnen we in de komende Sprint verbeteren? Welke actiepunten voor de komende Sprint kunnen we hieruit formuleren? De BURNDOWN CHART De Burndown Chart is een grafiek die laat zien hoeveel werk er nog gedaan moet worden in de Sprint om het Sprintdoel te halen. Op de x-as staat het aantal dagen van de Sprint, op de y-as het aantal story points of user stories dat in de Sprint Backlog is opgenomen. De groene lijn geeft aan welk deel van de stories afgerond zijn. Pagina 9 van 39

10 1.5 Agile Ontwikkelmethodieken Er bestaan verschillende Agile ontwikkelmethodieken waarvan Scrum de meest gebruikte methodiek is. De verschillende Agile methodieken hebben een aantal kenmerken die steeds weer terugkomen: een nauwe samenwerking tussen business en IT het werken in korte iteraties het kunnen omgaan met veranderingen in projecten De basis van Agile softwareontwikkeling is het Agile Manifesto, gepubliceerd in Utah in Hierin staat het volgende: Individuen en interactie boven processen en tools Werkende software boven uitgebreide documentatie Samenwerking met de klant boven contract onderhandelingen Reageren op verandering boven het strikt volgen van een plan Wat rechts staat is waardevol, maar wat links staat is waardevoller (Bron: Manifest voor Agile Software Development De Agile methodieken zijn een reactie op ontwikkelprocessen die er in theorie goed uitzien, maar in de praktijk niet goed werken. Waar oudere methoden een poging doen in de onzekere toekomstige behoeften van de klant te voorzien, zijn Agile methoden adaptief en kunnen zich dus direct aanpassen aan veranderende omstandigheden. De Agile methodieken zijn daarom omschreven als empirisch. Ze zijn volledig gebaseerd op de praktische ervaringen en werkwijzen die zich bewezen hebben te werken. Een ander belangrijk uitgangspunt is eenvoud en Lean Thinking. Dit houdt bijvoorbeeld in dat er geen tijd wordt besteed aan het schrijven van onnodige documentatie, maar alleen aan documentatie die ook daadwerkelijk wordt gebruikt. Andere Agile methode Een andere Agile methode is Lean Development, die voortvloeit van de ust-in-time en Lean Productie concepten. Lean Development richt zich meer op de organisatie van de ontwikkelactiviteiten van het gehele bedrijf op managementniveau. Deze Agile-methoden kunnen worden beschouwd als aanvulling op elkaar, waar: Lean Development de gehele ontwikkeling binnen de organisatie behandelt; Scrum gaat over hoe het project is georganiseerd en gepland. Pagina 10 van 39

11 1.6 Agile en Prince 2 DR maakt gebruik van Prince 2 (P2) als projectmanagement methodiek. De ontwikkelmethodiek Agile Scrum sluit daarbij goed aan. AS biedt alleen een methodiek en regels voor de fase waarin de uitvoering wordt gedaan. Voor de voorbereiding (met sprint 0) en de overgang naar beheer schrijft AS niets voor. De templates van P2 zijn voor die fasen (b.v. de PID bij de voorbereiding) te gebruiken. In de afbeelding hieronder zijn de fases in een AS project geprojecteerd op die van P2. Analyse Sprint 0 Sprint 1 Sprint 2 Wat (Starting up a Project Prince2) Hoe / Scrum (Initiating a Project Prince2) Uitvoering / Scrum (Controlling a Stage en Managing Stage Boundaries Prince2) Sprint 3 Sprint 4 Sprint 5 Beheer Beheer (Closing a Project Prince2) Afbeelding 2 : Uitvoering Agile Scrum project en Prince 2 project methodiek Hoe binnen een P2 project de sprints van Scrum vallen, wordt in onderstaande afbeelding weergegeven. Het rode blok is het deel van een P2 project waar scrum toegepast wordt. Directing a project Starting up a Project Initiating a Project Controlling a Stage Managing Stage Boundaries Closing a Project Managing Product Delivery Sprint 1 Sprint 2 Sprint 3 Directing a project Afbeelding 3 : Uitvoering sprints binnen Prince 2 project methodiek Pagina 11 van 39

12 Om binnen Prince 2 software te ontwikkelen is Scrum een van de mogelijkheden, naast Waterval en Innovation Lab. Hieronder staat een opsomming van criteria om de best passende methode in (software) ontwikkeling te kiezen. Afbeelding 4 : Keuze software ontwikkelmethodiek binnen Prince 2 Pagina 12 van 39

13 1.7 Veel gestelde vragen over Scum en Agile Is er niet een aanzienlijk risico dat Scrum uit de hand loopt en iedereen doet wat hij wil? Uit ervaringen met een grote hoeveelheid aan verschillende projecten blijkt dat dit niet gebeurt. De reden hiervoor is dat de principes eenvoudig te begrijpen zijn en het team elke 3 á 4 weken zichtbare resultaten oplevert. De gedeelde verantwoordelijkheid voor alle onderdelen van de code maakt ook dat de Scrum Teamleden meer gemotiveerd zijn om zich routines en regels eigen te maken. Ook het ingebouwde lerende effect tijdens standups en retrospectives zorgt ervoor dat er continu bijsturing plaats vindt. Kan Scrum alleen worden gebruikt voor kleinere projecten? Nee, de methode kan worden opgeschaald door het samenstellen van een groot project bestaande uit verschillende kleinere teams. Een zogenaamde Scrum van Scrums kan bestaan uit honderden programmeurs, functioneel ontwerpers, functioneel beheerders, testers en gebruikers in tientallen Scrum Teams georganiseerd. Hoe begin je? Een veel voorkomende manier van het starten van een Scrum Project is het volgen van een training Agile/Scrum of Scrum Master. DR biedt deze cursus aan. Een ander alternatief is om een pilot project te starten en daar iemand met ervaring vanuit een vorig Scrum project in te plaatsen, die een rol als mentor voor het team, de Scrum Master en Product Owner heeft. Wat gebeurt er als je niet op tijd klaar bent? Je doet altijd op de afgesproken tijd de demo van wat klaar is. Scrum staat niet toe dat een einddatum wordt gewijzigd! Als je de Sprint niet haalt, verwijder je items uit de Sprint Backlog en de Product Owner bepaalt zelf wat er dan met de overgebleven stories gedaan moet worden. Als je ruimte over hebt kan de Product Owner meer user stories in de Sprint Backlog plaatsen. Moet de lengte van een Sprint 3 á 4 weken zijn? Niet persé, maar het moet wel het gehele project hetzelfde zijn. Daarbij komt dat de ervaring leert dat 3 á 4 weken een goed compromis is tussen een comfortabel werktempo en aanpassingsvermogen. Wat is er gebeurd met de projectleider? Scrum heeft geen rol met deze titel. Dit wil niet zeggen dat de rol van projectleider niet meer nodig is. De rol krijgt wel een andere invulling, namelijk meer richting het omgevingsmanagement en het faciliteren van het team. Binnen DR is gekozen om naast de Scrum Master ook een projectleider aan te stellen. Wordt Scrum alleen voor software ontwikkeling gebruikt? Helemaal niet! De methode kan worden aangepast voor alle verschillende soorten projecten, bijvoorbeeld het verwezenlijken van doelen uit een afdelingsplan. Waar komt het woord Scrum vandaan? Scrum is een rugby term voor de hechte schouder-aan-schouder positie van een rugby team die zij vormt om samen de bal vooruit te bewegen. Het woord werd voor het eerst gebruikt door Takeuchi en Nonaka in een beroemd artikel gepubliceerd in de Harvard Business Review waarin zij de meest succesvolle productontwikkelprojecten in Japan beschreven. Pagina 13 van 39

14 1.8 Begrippenlijst Adaptief, projectdoelen en planningen zijn aangepast in overeenstemming met veranderende wijzigende factoren. Agile ontwikkeling, een methode voor software ontwikkeling die aanpassingsvermogen, korte paden tussen ideeën en uitvoering en vereenvoudigde vormen van samenwerking benadrukt. Voorbeelden zijn o.a. Lean Development en Scrum. Burndown Chart, een grafiek die laat zien hoeveel werk er nog gedaan moet worden in de Sprint om het Sprintdoel te halen. Daily Scrum, korte, dagelijkse vergaderingen (± 15 minuten) met de Scrum Master en het Scrumteam. Het doel is elkaar op de hoogte houden van de voortgang van de Sprint en het opheffen van belemmeringen. Demo, een informele bijeenkomst aan het einde van een Sprint waarin het team de resultaten van de afgelopen Sprint presenteert aan alle Stakeholders en geïnteresseerden van het project. Empirisch, gebaseerd op ervaring. Product Backlog, de huidige "to-do list " dat de projectdoelstellingen (user stories) en prioriteiten daarvan bevat. Beheerd door de Product Owner. Product Owner, de persoon die verantwoordelijk is voor de Product Backlog en er voor zorgt dat het team bezig is met de voor de business op dat moment belangrijkste functionaliteit. Projectleider, de persoon die verantwoordelijk is voor het zekerstellen dat het project de gewenste producten oplevert, binnen tijd, binnen budget en volgens de afgesproken kwaliteit. Hij faciliteert de Product Owner en het Scrum Team. Release Backlog, hetzelfde als een Product Backlog, maar beperkt tot een release van het product. Retrospectieve, vergadering die plaatsvindt na elke Sprint. De Scrum Master, Product Owner en het Scrum Team geven aan wat goed ging en wat er verbeterd moet worden in de volgende Sprint. Scrum Master, de teamleider "van het Scrum Team. Scrum Team, iedereen die nodig is om de Sprint Backlog te kunnen ontwerpen, ontwikkelen en testen. Een Scrum Team is zelforganiserend, een formele teammanager ontbreekt hierin. Sprint, een iteratie van 3 á 4 weken waarin het Scrum Team zich concentreert op het realiseren van de doelstellingen gedefinieerd in de huidige Sprint Backlog. Sprint Backlog, een to-do lijst voor een Sprint. Bestaat uit de user stories die door de Product Owner zijn gedefinieerd als het hebben van de hoogste prioriteit. De Sprint Backlog wordt definitief gemaakt tijdens de Sprintplanning meeting door de Product Owner en het team. Pagina 14 van 39

15 Timebox, een periode waarin iets moet worden uitgevoerd. Termijnen mogen niet worden overschreden. Voorspellend, projectdoelstellingen en planningen gebaseerd op een prognose van externe factoren die in het begin van het project gemaakt worden. Pagina 15 van 39

16 2 Ervaring DR Agile Scrum 2.1 Inleiding In dit tweede deel wordt de lezer meegenomen in ervaringen die binnen DR zijn opgedaan met de Agile Scrum methodiek. Binnen DR, onder meer met ondersteuning vanuit Quintor, worden steeds meer projecten op deze wijze uitgevoerd. De ervaringen van DR zijn aangevuld met ervaringen van Quintor bij andere opdrachtgevers. Hiermee werden de best practices direct in de praktijk toegepast. De ervaringen bij DR neemt Quintor weer mee bij andere opdrachtgevers. In dit deel wordt eerst de organisatie van Scrum binnen DR toegelicht bij de vakgroep en het support team en de handreikingen voor communicatie die project BAS heeft opgeleverd. Daarna staan de handvatten voor de uitvoering van Agile Scrum projecten genoemd in de vorm van lijsten en formats. 2.2 Vakgroep Agile Scrum Voor de borging van Agile Scrum binnen DR is een vakgroep opgericht. Deze vakgroep moet zorgen dat de hierna genoemde stappen om tot borging te komen, worden uitgevoerd. De vakgroep heeft tot doelstelling om er voor te zorgen dat: In 2012 binnen DR de bekendheid met Agile Scrum groeit; Kennis van en ervaring met Agile Scrum in stand wordt gehouden en wordt geborgd; Er een leereffect ontstaat in het werken met Agile Scrum. De vakgroep gaat de volgende activiteiten uitvoeren en/of organiseren: Per jaar een 2-3 tal thema bijeenkomsten waar mensen kennis kunnen maken met de Agile Scrum methodiek zodat de interesse hiervoor verder wordt vergroot; op Intranet regelmatig informatie over Agile Scrumzaken plaatsen; zorgen dat vragen uit de organisatie worden behandeld en beantwoord; desgevraagd op teamoverleggen presentaties verzorgen. Voor de langere termijn zijn er een aantal activiteiten onderkend die door deze vakgroep opgepakt kunnen worden: Uitwisseling van kennis en ervaringen op dit gebied van Agile Scrum tussen de beoefenaren hiervan; Uitwisselen van kennis en ervaringen met onder meer de community Agile Overheid ; Het doen van verbetervoorstellen aan het management voor de manier waarop binnen EL&I / DR Scrum toepast zou kunnen worden; Het organiseren van Agile/Scrum informatiedagen/workshops; Het inrichten en onderhouden van een Agile/Scrum online community op PLEIO; Het uitwerken van DR specifieke zaken m.b.t. de toepassing van Agile/Scrum; Het opbouwen en onderhouden van relaties met instituten en met de eigen beroepsgroep. Pagina 16 van 39

17 Bemensing vakgroep De vakgroep bestaat uit alle medewerkers binnen DR die iets hebben met Agile Scrum, van enkel interesse tot en met veel werkervaring. Het advies is om een trekker / voorzitter van de vakgroep te benoemen met 1 of 2 mensen die de voorzitter ondersteunen bij het organiseren c.q. regelen van activiteiten vanuit de vakgroep. Hoeveel tijd deze mensen kwijt zijn om taken voor de vakgroep te verrichten is nog moeilijk in te schatten. Voorstel 1 dagdeel per week. Voor het inzichtelijk maken van de daadwerkelijke tijd die aan de vakgroep wordt besteed is het goed dat hier ook een tijdschrijfcode voor komt. 2.3 Supportteam Agile Srum Het supportteam is opgericht om beginnende Scrum Teams te kunnen ondersteunen met een vliegende start van het project. Doelstelling Agile Scrum Supportteam Het Agile Scrum supportteam is een faciliterend en ondersteunend team. Het ondersteunt Agile Scrum Teams met het opstarten en draaien van projecten. Zo kunnen de projectteams zich concentreren op het realiseren van de projectresultaten en hoeven ze zich niet bezig te houden met randvoorwaardelijke zaken. Het supportteam heeft geen controlerende taak. Het zal het project niet controleren op het ontbreken van bepaalde documenten. Verder zal ook niet op inhoud worden gecontroleerd. Het supportteam zou bijvoorbeeld een team er wel op kunnen wijzen dat user stories niet in de juiste vorm geschreven zijn, maar het zal niet (kunnen) zeggen dat een user story fout is. De reden hiervoor is dat de verantwoordelijkheid voor de resultaten en de kwaliteit van het werk bij de Scrum Teams en de Product Owners moet blijven liggen. Het supportteam moet ook geen instituut op zich worden, dat zichzelf in stand houdt. Het bestaat puur als een ondersteunend en faciliterend team. Naarmate de volwassenheid van het scrum proces binnen de organisatie toeneemt, kunnen taken van het supportteam teruggebracht worden. Bij de hierna genoemde taken, kan ook gelezen worden helpen bij. Overzicht taken Per taak is aangegeven in welke categorie deze valt: ESS: essentiële taken die goed ingericht moeten zijn om te zorgen dat het Agile Scrum proces soepel en consistent loopt. ADM: Basis administratietaken die ook prima door de Scrum Teams zelf opgepakt kunnen worden. CON:Consultancy taken die meer over de inhoud van het proces gaan en ook veel meer kennis vragen van degenen die verantwoordelijk zijn voor deze taken. Pagina 17 van 39

18 Taken Fundamenten / tools Opzetten Jira Opzetten Wiki Accountbeheer Jira/Wiki Toelichting Het supportteam zet een structuur op waardoor teams hun eigen stories en voortgang eenvoudig kunnen beheren. Maar het geeft het supportteam ook de mogelijkheid om over projecten heen de voortgang te kunnen rapporteren. Het supportteam richt de Wiki in met diverse algemene secties (voor procedures en richtlijnen) en secties specifiek voor projecten. Het is belangrijk dat de juiste mensen de juiste rollen krijgen binnen Jira/Wiki, Aan deze rechten zitten ook functies verbonden in de tools. Het supportteam richt deze rollen en accounts in en beheert deze gedurende de projecten. ESS ADM CON Vastleggen methodiek (procedures / richtlijnen) Algemene interne procedures helpen aanpassen Het supportteam draagt er zorg voor dat de procedures (bijv. documentatie, vastleggen user stories, sprint planning, retrospective, etc.), richtlijnen (bijv. Definition of Ready, Definition of Done, etc) en templates (SAD, PSA, FO, TO, etc) zijn vastgelegd en dat projectleden ze eenvoudig kunnen vinden. Het supportteam kan de organisatie ondersteunen bij het aanpassen van de afgesproken procedures, regels en technieken zodat ze aansluiten bij wat teams nodig hebben en de teams faciliteren. Ook kan het supportteam er mede voor zorgen dat de binnen de Scrum-teams gebruikte processen en tooling goed aansluiten bij wat er in de rest van de organisatie gebeurt en afgesproken is Starten project Inrichten Jira Inrichten Wiki In overleg met de projectleider wordt bepaald hoe het project gaat heten en welke personen/rollen betrokken zijn. Dit wordt gebruikt bij de verdere inrichting. Binnen Jira maakt het supportteam een nieuw project aan. Hierbij krijgen de juiste gebruikers de juiste rechten binnen Jira afhankelijk van de rollen. Het supportteam richt een aparte sectie in op de Wiki voor het project volgens een standaard structuur. Hier kan het team zijn documentatie kwijt. Teamleden krijgen hiervoor rechten om pagina's aan te passen of alleen in te kunnen zien. Organiseren analyse workshop Ondersteunen analyse workshop Inrichten Product Backlog Het supportteam ondersteunt de Product Owner bij het organiseren van analyse workshops. Het supportteam ondersteunt de Product Owner bij het uitvoeren van analyse workshops en het opstellen van user stories. Het supportteam richt de Product Backlog in Jira initieel in. De resultaten van de analyse workshops worden in overleg met de Product Owner verwerkt. Ook tijdens het project kan het supportteam helpen bij het onderhouden van de productbacklog. Pagina 18 van 39

19 Taken Starten sprint Beschikbaarheid mensen Ondersteunen voorportaal Toelichting Voor het maken van haalbare sprintplanningen is het nodig om te weten hoeveel uren er in de sprint beschikbaar zijn. Het supportteam houdt dit per team bij o.b.v. een centrale vakantieplanning (bijv. via de Wiki of HR) Het voorportaal wordt gebruikt om per team user stories voor te bereiden voor de volgende sprint. Op basis van prioriteit worden deze stories door een aantal ontwerpers uitgewerkt zodat bij het starten van de sprint een stuk voorwerk al is afgerond. Het verdelen van de stories naar de juiste voorportalen (per team) kan door het supportteam gedaan worden in samenspraak met Product Owner. ESS ADM CON Faciliteren sprintplanning Begeleiding sprint planning Verwerken sprintplanning Voor dat een sprint gestart kan worden moet er eerst een sprintplanning uitgevoerd worden. Het supportteam ondersteunt hierbij door een lijst van geprioritiseerde user stories voor de verschillende teams op te leveren. Het supportteam kan daarbij de Product Owner ondersteunen om te zorgen dat dit op tijd gereed is. Daarnaast moeten er natuurlijk ruimtes gereserveerd worden en moeten de verschillende hulpmiddelen (zoals poker planning kaarten) geregeld worden. Als de teamleden nog niet veel ervaring hebben met planning poker dan kan het supportteam ondersteunen d.m.v. coaching. Het supportteam verwerkt het resultaat van sprintplanning door Jira te vullen met taken en de geschatte story points. Inrichten scrum bord Als er gebruik wordt gemaakt van een fysiek scrum board, dan kan het supportteam per sprint de user stories uitdraaien en eventueel de scrum boards bijwerken. Tijdens sprint (rapportage) Maken van burn down charts per (deel-) project Maken van burn down charts over projecten heen Rapportage algemeen Begeleiding daily standups Het supportteam levert dagelijks voor elk team een burn down chart op per project. Op aanvraag kan het supportteam ook burn down charts maken over projecten heen. Zo kan voor een programmamanager inzichtelijk gemaakt worden wat de voortgang van een heel programma is. Ook andere rapportages kan het supportteam faciliteren.bijvoorbeeld lijsten van impediments en bugs, cijfers voor Prince2 rapportages of specifieke selecties uit de Product Backlog. Dit soort vragen komen dan niet meer terecht bij Product Owner of Scrum Master Zeker bij nieuwe teams is coaching tijdens daily standups erg waardevol. Als de Scrum Master nog niet ervaren is, kan de begeleiding door het supportteam helpen om het proces goed te laten verlopen. Ook als het proces goed loopt, is af en toe meekijken en puntjes op de i zetten waar het proces dreigt af te wijken zinvol. Pagina 19 van 39

20 Taken Begeleiding scrum of scrums Algemene ondersteuning Toelichting Het supportteam is aanwezig bij de Scrum of Scrums en kan de resultaten bundelen en op de Wiki plaatsen. Inhoudelijk blijven natuurlijk de Scrum Masters verantwoordelijk, maar organisatorische impediments worden door het supportteam opgepakt in samenspraak met projectleider. Indien er zaken georganiseerd worden voor het project of er zijn praktische impediments (testruimtes, apparatuur, etc) dan kan het supportteam hierbij faciliteren. Afsluiten sprint Organiseren demo Het supportteam reserveert een ruimte met bijbehorende audio/visuele hulpmiddelen. Ook worden de juiste mensen uitgenodigd. Indien meerdere teams tegelijk een demo geven dan kan het supportteam ook over de teams heen het programma coördineren. Ondersteunen sprint retrospective Coaching / begeleiding Organiseren van trainingen Inleiding in procedures / richtlijnen Coaching algemeen Het supportteam kan ondersteunen tijdens de sprint retrospective sessies. Naast het vastleggen van de afspraken kan het supportteam ook vanuit hun proceskennis helpen bij het bepalen van verbeteringen en eventueel verbeteringen uit de retrospective verwerken in het proces. Deze bevindingen kunnen vastgelegd worden, zodat na verloop van tijd inzichtelijk wordt of teams steeds tegen dezelfde punten aanlopen. Op die punten zullen dan maatregelen bedacht moeten worden. Voor nieuwe projectmedewerkers die weinig of geen ervaring hebben met Agile scrum kan het supportteam trainingen organiseren. Eventueel kan dat inhouse als het om meerdere mensen gaat. Daarnaast moeten nieuwe projectmedewerkers een inleiding krijgen over de manier waarop Agile Scrum is geïmplementeerd en waar de verschillende tools en documenten te vinden zijn. Het supportteam kan deze mensen snel wegwijs maken en ook tijdens het traject als vraagbaak optreden. Het supportteam kan ook in algemene zin coaching verzorgen voor bijvoorbeeld Scrum Masters, Product Owners en projectleiders. ESS ADM CON Bemensing supportteam Het supportteam moet uit minimaal 2 Agile coaches bestaan en een administratieve kracht. Dit is mede afhankelijk van de gekozen scope. Deze mensen moeten een algemene scrumtraining gevolgd hebben, eventueel aangevuld met Scrum Master en/of Product Owner training. Enige ervaring als Scrum Master of Product Owner is natuurlijk ook gewenst. Daarnaast is uitgebreide kennis van Wiki en Jira noodzakelijk. Zodra de organisatie meer ervaring krijgt met Scrum, kan het supportteam een aantal taken afstoten. Met name de consultancy en coaching taken zullen dan minder worden. Verwachte inzet is uiteraard sterk afhankelijk van de gevraagde ondersteuning. Het zal afhangen van het aantal projecten dat Agile Scrum wordt opgepakt. Daarnaast hangt het af van de gevraagde ondersteuning per project. Voor het inzichtelijk maken van de daadwerkelijk tijd die aan het supportteam wordt besteed is het goed dat hier ook een tijdschrijfcode voor komt. Pagina 20 van 39