Handreiking voor toepassen van Agile Scrum binnen ... AS binnen... · Dit boekje geeft geweldige...

Handreiking voor toepassen van Agile Scrum binnen Overheidsdiensten

Versie 1.0

Datum april 2012 Status definitief

Definitief 1.0| Handreiking voor toepassen van Agile Scrum binnen Overheidsdiensten | april 2012

Pagina 2 van 39

Colofon

Projectnaam Project BAS, Borging Agile Scrum Locatie Contactpersoon B. (Berend) van Duijvenvoorde

Projectmanager, Dienst Regelingen M 06-20423315 [email protected]

Bijlage(n) 1 Auteurs DR en Quintor


Inhoud

Voorblad—2 Colofon—2 Inhoud—3 Voorwoord—4 Leeswijzer—5

1 Kennis Agile Scrum—6 1.1 Inleiding—6 1.2 Scrum – een introductie—6 1.3 Rollen—7 1.4 Proces—8 1.5 Agile Ontwikkelmethodieken—10 1.6 Agile en Prince 2—11 1.7 Veel gestelde vragen over Scum en Agile—13 1.8 Begrippenlijst—14

2 Ervaring DR Agile Scrum—16 2.1 Inleiding—16 2.2 Vakgroep Agile Scrum—16 2.3 Supportteam Agile Srum—17 2.4 Handreikingen op het gebied van communicatie—21 2.5 Opleiding Agile Scrum—22 2.6 Valkuilen—25 2.7 Issues tijdens de start van een Agile Scrum project—29 2.8 Issues tijdens het uitvoeren van een Agile Scrum project—30 2.9 Evaluatie van een Agile Scrum project—31 2.10 Best Practices van Agile Scrum Projecten binnen DR—32 2.11 Ondersteunende Tooling—34

3 Bijlagen—37 3.1 Stakeholders Agile Scrum binnen DR—37

Pagina 3 van 39


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


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 2.6 - 2.7 - 2.8 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: [email protected]

Pagina 5 van 39

mailto:[email protected]


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


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


Pagina 8 van 39

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).


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


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 2001. 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 http://agilemanifesto.org/) 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 management-niveau. 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


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.

AnalyseAnalyse

Sprint 1

Sprint 0

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Beheer

Uitvoering / Scrum (Controlling a Stage en Managing Stage Boundaries Prince2)

Wat (Starting up a Project Prince2)

Hoe / Scrum (Initiating a Project Prince2)

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

Initiatinga Project

Controllinga Stage

ManagingStage

Boundaries

Closinga Project

Managing Product Delivery

Sprint 1 Sprint 2 Sprint 3

Directing a project

Directing a project

Starting up a Project

Initiatinga Project

Controllinga Stage

ManagingStage

Boundaries

Closinga 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


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


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 productontwikkel- projecten in Japan beschreven.

Pagina 13 van 39


1.8 Begrippenlijst Adaptief, projectdoelen en planningen zijn aangepast in overeenstemming met veranderende wijzigende factoren. Agile ontwikkeling, een methode voor software ontwikkeling die aanpassings-vermogen, 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


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


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


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 project-resultaten 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


Taken Toelichting ESS ADM CON

Fundamenten / toolsOpzetten Jira 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.

X

Opzetten Wiki Het supportteam richt de Wiki in met diverse algemene secties (voor procedures en richtlijnen) en secties specifiek voor projecten.

X

Accountbeheer Jira/Wiki

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.

X

Vastleggen methodiek (procedures / richtlijnen)

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.

X

Algemene interne procedures helpen aanpassen

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

X

Starten project 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.

Inrichten Jira Binnen Jira maakt het supportteam een nieuw project aan. Hierbij krijgen de juiste gebruikers de juiste rechten binnen Jira afhankelijk van de rollen.

X

Inrichten Wiki 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.

X

Organiseren analyse workshop

Het supportteam ondersteunt de Product Owner bij het organiseren van analyse workshops. X

Ondersteunen analyse workshop

Het supportteam ondersteunt de Product Owner bij het uitvoeren van analyse workshops en het opstellen van user stories.

X

Inrichten Product Backlog

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.

X

Pagina 18 van 39



Starten sprintBeschikbaarheid mensen

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)

X

Ondersteunen voorportaal

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.

X

Faciliteren 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.

X

Begeleiding sprint planning

Als de teamleden nog niet veel ervaring hebben met planning poker dan kan het supportteam ondersteunen d.m.v. coaching.

X

Verwerken sprintplanning

Het supportteam verwerkt het resultaat van sprintplanning door Jira te vullen met taken en de geschatte story points. X

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. X

Tijdens sprint (rapportage)Maken van burn down charts per (deel-) project

Het supportteam levert dagelijks voor elk team een burn down chart op per project. X

Maken van burn down charts over projecten heen

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.

X

Rapportage algemeen

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

X

Begeleiding daily standups

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.

X

Pagina 19 van 39



Begeleiding scrum of scrums

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.

X

Algemene ondersteuning

Indien er zaken georganiseerd worden voor het project of er zijn praktische impediments (testruimtes, apparatuur, etc) dan kan het supportteam hierbij faciliteren.

X

Afsluiten sprintOrganiseren 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.

X

Ondersteunen sprint retrospective

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.

X

Coaching / begeleidingOrganiseren van trainingen

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.

X

Inleiding in procedures / richtlijnen

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.

X X

Coaching algemeen

Het supportteam kan ook in algemene zin coaching verzorgen voor bijvoorbeeld Scrum Masters, Product Owners en projectleiders.

X

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


2.4 Handreikingen op het gebied van communicatie Binnen DR is nu een aantal jaren ervaring opgedaan met Agile Scrum . Het zijn nog een beperkt aantal projecten geweest en dus ook een beperkt aantal medewerkers en managers die kennis hebben gemaakt met de methodiek. Het doel is om steeds meer personen binnen DR kennis te laten maken met de positieve ervaringen met Agile Scrum. De Product Owner heeft als voorkeur binnen de DR toekomst: “Ontwikkelprojecten met Agile Scrum, tenzij…..” Hierna volgen een aantal handreikingen die door de vakgroep Agile Scrum verder opgepakt dienen te worden. Belangrijk hierbij is om aan te sluiten bij andere initiatieven rondom het domein ‘projecten’ zoals BedrijfInformatieplanning (BIP) en Lean Six Sigma (LSS). De communicatie zal gedoseerd in toon en frequentie moeten zijn om verfrissend te blijven en vraagt volhouden van de vakgroep. Doelgroepen en hun communicatie behoefte 1. Er is een aantal doelgroepen te onderscheiden met verschillende rollen en

behoefte in betrokkenheid bij de methodiek waarbij ook aandacht besteed wordt aan de verschillende vestigingen.

2. MT PIM is stakeholder van de methodiek Agile Scrum. Iedereen dient minimaal een basis kennis niveau te hebben.

3. MT Drive / DT nodig voor de juiste consensus, waarbij de consequenties qua inzet van capaciteit ook gerealiseerd wordt. Op moment van capaciteitsclaim moet de betreffende teammanager ook gesteund worden door de afdelingsmanager. De training voor Product Owner is cruciaal om te laten ervaren wat de rol van actiever eigenaarschap is. Daarnaast moeten zij hun eigen rol ook goed leren kennen.

4. Teammanagers vanuit de business voor begrip en steun bij de projectuitvoering. 5. Projectdeelnemers zoals Product Owner, Projectleider, Scrum Master,

teamleden. 6. Medewerkers die indirect betrokken zijn doordat een collega deelneemt aan een

AS project en dus niet beschikbaar is voor regulier werk. 7. Medewerkers die geen projectdeelnemer zijn (geweest) of indirect betrokken

zijn. Communicatie uitingen • In al uitgewerkte user stories is een aantal ‘statements’ over Agile Scrum

aangestipt die meegenomen kunnen worden in de communicatie uitingen: • Draagt bij aan cultuurverandering van DR om anders te kijken, om dingen

samen tot een resultaat te brengen. Ondersteunt de menskant van de verandering binnen DR.

• Belangrijk om je projectresultaat te verkopen met duidelijk aantoonbaar de toegevoegde waarde van Agile Scrum als gebruikte methodiek.

• Duidelijk maken in welke situatie Agile Scrum het beste van toepassing is, het beste resultaat boekt. Niet als dogma en enige ontwikkelmethodiek aanbieden.

• Indruk bestaat bij een enkele manager dat de vaste iteratie van x weken soms vertragend kan werken in een fase waar juist heel helder is wat er moet / kan gebeuren. Het vertragen lijkt te zitten in de ondersteunende activiteiten van sprintvoorbereiding, sprintplanning, oplevering, retrospective etc.

• Van de Agile Scrum methodiek hebben we nog niet voldoende kennis. Nu eerst heel zuiver toepassen om daarna met de ervaren Projectleiders & Scrum Masters te bepalen wat pragmatisch voor DR is. Dan pas mogelijk om bewust keuzes te maken wat wel of niet toepasbaar is.

Pagina 21 van 39


Tips ter verbetering van de communicatie Deze paragraaf bevat slechts handreikingen. Hieronder staat een aantal tips en vragen die de vakgroep kan gebruiken: • Basis voor Agile software ontwikkeling is het Agile Manifesto, communiceer de 4

uitgangspunten. • Welke (kern)onderwerpen wil je overbrengen bij of delen met de onderscheiden

doelgroepen? • Zorg voor een (oprechte) noodzaak waar mensen zich in herkennen waardoor ze

in beweging komen. • In te zetten middelen en expliciete keuze ‘tone of voice’ schema met overzicht

mogelijke middelen en toon per doelgroep/doelstelling. • Let er bij het opstellen van de boodschap op dat deze twee componenten heeft.

Ten eerste een inhoudelijke component (het overdragen van informatie sec), met name gericht op de benodigde kennis bij de doelgroep. En daarnaast een emotioneel aspect (stijl, ‘tone of voice’), met name bedoeld voor het veranderen van houding en gedrag bij de doelgroep

2.5 Opleiding Agile Scrum Doelgroep: Naast beginnende / onervaren scrumteamleden kan de doelgroep aangevuld worden met de wens vanuit de stakeholders om meer mensen op te leiden die niet direct aan een scrumproject beginnen. Dit levert meer begrip op en je hebt al een gedeelte van je mogelijke capaciteit opgeleid voordat je met sprint 0 begint. Met name de POB teams zullen hier profijt van hebben. Opleiding: De basisopleiding neemt 1 dag in beslag en kan op locatie worden gegeven. De training wordt geregeld via de DR Academie en vindt 1 x per maand plaats. De deelnemers ontvangen aan het eind van de dag een certificaat van deelneming. Tevens ontvangt men een digitaal naslagwerk met de inhoud van de training. Doel van de opleiding: Aan het eind van de dag kunnen weergeven wat Agile Scrum inhoudt, welke rollen er zijn en hoe het proces er globaal uitziet. Door de basisopleiding kan DR in een project beschikken over competente medewerker op het gebied van Agile Scrum. Hieronder de kenmerken van Agile die in de basisopleiding aan de orde komen en waaraan men moet voldoen. Inhoud van Agile Scrum: De deelnemer begrijpt hoe de ontwikkelmethodiek werkt: • weten wat het verschil is tussen een traditioneel en een iteratief ontwikkelproces • het kunnen benoemen van de kenmerken van Agile • inhoud van het Agile Manifesto kennen • begrijpen hoe het Scrum ontwikkelproces ingericht is • kennen van documentatie over Agile Scrum • de rollen binnen Scrum kennen

Pagina 22 van 39


Pagina 23 van 39

Proces Agile Scrum: De deelnemer begrijpt hoe de methodiek in de praktijk kan worden toegepast: • het scrumproces kunnen uitleggen • belang van sprint 0 onderkennen • gebruik maken van een productbacklog • maken van user stories • inschatting hoeveelheid werk dat in de productbacklog staat • uitvoeren sprintplanning • Daily standup • omgaan met impediments • retrospective • de wijze van opleveren / geven van demo’s • gebruik van een Definition of Ready • gebruik van een Definition of Done • het kunnen inrichten van een scrumbord • gebruik van de tool Jira • de burndown chart • verschillende types van productowners • wat is scrum of scrums en weten wanneer te gebruiken Rollen Agile Scrum: De deelnemer begrijpt wat de verschillende rollen binnen de Scrum methodiek zijn: • Product Owner (lijnopdrachtgever) • Scrum Master • Projectleider • Teamlid


2.6 Valkuilen Hieronder staan mogelijke maatregelen genoemd bij de valkuilen die zich vaak voordoen bij het uitvoeren van een project.

Situatie Valkuil Mogelijke maatregelen

Opd

rach

tgev

er Pr

oduc

t Ow

ner

Scru

mm

aste

r

Proj

ectle

ider

Team

lede

n

Supp

ort t

eam

Vakg

roep

Binnen scrum zijn alle teamleden gelijkwaardig en moeten elkaars werk kunnen doen

De verwachting hebben dat teamleden volledig uitwisselbaar zijn. In de praktijk blijken teamleden (specialisten) beperkt uitwisselbaar. Ook wringt de rol van een specialist met de teamgelijkwaardigheid

De rollen zijn vaak alleen in te vullen door specialisten, dus uitwisselbaarheid is beperkt. Zorg ervoor dat je alle specialisten (bv. analisten / ontwerpers / bouwers / testers) beschikbaar hebt binnen het team en enkele teamleden die multifunctioneel zijn. Ken en begrijp elkaars specialisme. En begrijp als specialist dat de oplossing vaak een combinatie van specialismen vraagt.

X X X

Scrum gaat er min of meer vanuit dat alle teamleden full-time beschikbaar zijn.

Starten met een niet optimale bezetting • Probeer parttimers op dezelfde dag(en) beschikbaar te hebben.• Plan niet meer in dan, dat er tijd beschikbaar is.• Laat parttimers minimaal aanwezig zijn bij stand ups, retro en demo.• Niet starten met ‘sprinten’.

X X

Het scrumproces plaatje laat niet de hele werkelijkheid zien. Scrum is een methode die gemaakt is voor de executie, de uitvoering van een project. In een grote organisatie moet er veel extra’s omheen geregeld worden.

Valkuil is om sprint 0 over te slaan en geen projectmanagement uit te voeren.

• de beginfase (sprint 0) en de eindfase (afronding) moeten wel degelijk goed en voldoende vorm worden gegeven. • Geef projectmanagement vorm en stem dit af met de productowner / opdrachtgever, denk hierbij aan de processen voor oa. het vaststellen, rapporteren over en bewaken van projectbudget en planning. En het omgaan met wijzigingen (van de productbacklog en terugkoppelingen daarover voor kosten/ haalbaarheid/ kwaliteitsimpact).• Laat een vakgroep inventariseren wat er binnen EL&I verder allemaal geregeld dient te worden om projecten goed te laten verlopen. Vergeet daarbij bestaande werkende methoden (als bijvoorbeeld Prince2) niet. Maak de relatie tussen die methode en Scrum helder.

X X X X X X

Betrokkenen

Pagina 25 van 39



Opd

rach

tgev

er Pr

oduc

t Ow

ner

Scru

mm

aste

r

Proj

ectle

ider

Team

lede

n

Supp

ort t

eam

Vakg

roep

De productowner moet volgens scrum de bevoegdheid hebben alle beslissingen te nemen namens de opdrachtgever.

Het scrumteam verwacht dat de productowner alle inhoudelijke kennis heeft en full-time beschikbaar is.

• Door de projectleider de verwachtingen managen ten aanzien van de inzet van de PO.• Instellen van een voor(bereidings)groep die de productowner inhoudelijk ondersteund.

X X

In scrum is er geen projectmanager maar is het team zelfsturend. De scrummaster is uitsluitend coach en facilitator.

De projectleider wordt scrummaster met autoriteit.De scrummaster is de projectleider met te weinig tijd beschikbaar.

Scrum vereist een andere manier van (project)management binnen DR. In kleine projecten kan de projectleider de rol van scrummaster opnemen. Bij grotere projecten niet. Er kan dan beter gekozen worden voor een rolverdeling dat de projectleider de buitenkant managed (en optreed als coach) , de scrummaster is intern naar het team gericht. Hanteer de richtlijn om deze twee rollen binnen EL&I niet door één persoon te laten vervullen.

X X X

De ontwikkelstraat moet ondersteunend zijn aan iteratief werken.

Als de ontwikkelstraat er nog niet is, kun je beter niet starten met sprint 1.

Dit vereist een moderne ontwikkelstraat (tevens geautomatiseerd testen), die in sprint 0 klaar wordt gezet. X X X

Scrum noemt ‘gedetailleerde documentatie’ minder waardevol

Een valkuil is dat het ontwerp niet verder komt dat post-it’s en tekeningen op een whiteboard. Slechte specificaties zijn een reden van projectfalen. Kosten van software zitten voor 90% in het onderhoud, waarbij documentatie een must is.In niet ICT traj

• Pas de DOD aan.• Benoem in DOD het documenteren als voorwaarde bij ieder userstorie en leg goed vast wat dat is• Benoem in iedere sprint een userstorie het documenteren als activiteit• Plan een extra sprint aan het eind om documentatie op orde te mak

X X X

Sprint 0 niet afgerond Onder (politieke) druk wordt gestart zonder dat sprint 0 voldoende is afgerond. Daardoor krijgt scrum niet een eerlijke kans.

• Overtuig je opdrachtgever / productowner dat het minder toegevoegde waarde heeft om te starten als de randvoorwaarden van sprint 0 niet zijn ingevoerd. Vaak heeft dit een direct effect op de doorlooptijd.• Bereid je voor op een rommelige sprint 1.

X X X X X

Scrum is geen ontwikkeltemplate of een roadmap naar succes.

De verwachting dat Scrum alle problemen oplost. Manage de verwachting.Scrum is een basis proces wat moet worden aangevuld met ontwikkel en business kennis. Het is ‘a way of thinking’:• Ontwikkel business value• Ontwikkel werkende software• Voorkom ‘waste’• Ken de snelheid van je team.

X X X X X

Betrokkenen

Pagina 26 van 39


Pagina 27 van 39


Opd

rach

tgev

er Pr

oduc

t Ow

ner

Scru

mm

aste

r

Proj

ectle

ider

Team

lede

n

Supp

ort t

eam

Vakg

roep

Te snel willen Dat projecten gestart worden zonder ondersteuning en borging dat het ook echt Agile Scrum wordt uitgevoerd.

Bewaak dat er geen projecten Agile scrum 'in name only' starten. X X X X X X X

Klantparticipatie / Business Value Onvoldoende rekening met de eindgebruikers en business value

Hou er voldoende rekening mee, door wie de software en/of producten uiteindelijk gebruikt gaat worden. Betrek bij voorkeur die personen in het project, creëer toegevoegde waarde.

X X X

Scrum proces moet naar de letter en de intentie worden toegepast.

Projecten die starten met slechts onderdelen van het scrumproces

Implementeer het volledige scrumproces, evalueer regelmatig aan de hand van een checklist. Scrum schrijft een minimale set punten voor. Laat je iets weg dan werkt het niet meer.

X X X X X X

De burndown op Scrum bord onvoldoende bijhouden

Teamleden onvoldoende bewust bezig met werken aan en afronden van 1 specifieke userstorie om daarna pas volgende op te pakken

• In de Daily stand up één voor één de userstorie in progress / review doornemen. • Maak werkzaamheden van de voorgaande + komende dag heel expliciet. • Automatiseer indien mogelijk het maken van de burndown in de tooling (Jira) en print die dagelijks voor de Daily Standup

X X

De PO en het scrum-team zijn allemaal sterk gefocust op het realiseren van de resultaten (functionaliteit).

De in de DOD vastgelegde kwaliteitseisen worden onvoldoende nageleefd en de resultaten worden niet met de afgesproken kwaliteit opgeleverd.

• Regelmatig door medewerkers buiten het team laten checken of de resultaten met de afgesproken kwaliteit worden gerealiseerd.• Zorgen dat iedereen de gemaakte afspraken serieus neemt en elkaar erop wijzen als afspraken niet na worden gekomen.

X X X

Managers begrijpen of weten niet goed waar het team mee bezig is en hoe het bezig is.

Managers helpen onvoldoende de impediments op te lossen en geven te weinig aandacht aan het team.

• Geef alle managers een training en maak duidelijk wat je van de managers verwacht (min. 1x per wk je gezicht laten zien en oprecht belangstelling tonen)• Managers aanspreken op het belang hiervan• Managers ruim tevoren uitnodigen voor de demo’s en ze erop aanspreken als ze niet komen opdagen.

X X X

Scrum is niet alleen om software te ontwikkelen

Scrum als een “hard” software traject te zien • Bepaal van te voren of een niet software traject geschikt is om met agile scrum uit te voeren.• Indien dit een goede optie is zorg dan dat scrum master gevoel heeft voor de zachte kant van dit proces. (zachte kant is het deel wat sterk afhangt van de menselijk samenwerking zoals een proces)

X X X X

Betrokkenen


2.7 Issues tijdens de start van een Agile Scrum project Hieronder staan mogelijke maatregelen genoemd bij de issues die zich vaak voordoen bij het opstarten van een project. Waarbij de cijfers van Kans en Impact staan voor: 1 = zeer laag, 2 = laag, 3 = middel, 4 = hoog en 5 = zeer hoog Issues tijdens de start van een project

Issue Kan

s Im

pact

Ris

ico

Mogelijke maatregelen Opd

rach

tgev

erPr

ojec

tleid

erSc

rum

mas

ter

Noodzaak om te starten zonder dat sprint 0 is afgerond / onvoldoende tijd om voor te bereiden

4 5 20 Start tijdig met een project - borg dit structureel in de organisatie X

Team incompleet 4 4 16 Claim tijdig resources XProject Start Architectuur niet klaar

4 4 16 Claim tijdig capaciteit, begin direct met het opstellen van PSA in sprint 0 X

Definition of Done niet klaar 4 4 16 Organiseer vroegtijdig een workshop, een eerste versie moet in een middag kunnen worden opgesteld

X

Ontwikkelomgeving (technisch) niet beschikbaar

3 5 15 Claim tijdig resources, escaleren bij leverancier, elders uitbesteden X

Productowner vertegenwoordigd de business niet goed

3 5 15 Overtuig je opdrachtgever, dat alleen de juiste productowner kan zorgen voor een goed projectresultaat

X X

Projectplan nog niet definitief 4 3 12 Start tijdig met het maken van een projectplan en maak deze in sprint 0 definitief

X

Definition of Ready niet klaar 4 3 12 Organiseer vroegtijdig een workshop, een eerste versie moet in een middag kunnen worden opgesteld

X

Scrumleden nog onvoldoende opgeleid in Scrum

3 3 9 Zorg voor tijdige opleiding, uiterlijk sprint 0 X

Userstories niet ready voor sprint 1

2 4 8 Installeer een voorbereidingsgroep X

Projectopdracht /scope niet duidelijk

2 4 8 Overtuig je opdrachtgever, dat alleen een duidelijke opdracht leidt tot goed resultaat met business value

X

Scrum toepassen op een project wat zich er niet voor leent

3 2 6 Andere ontwikkelmethodiek gebruikenX

Kick off niet gehouden 2 2 4 XWerkplekken /projectruimte niet beschikbaar

1 3 3X

Aannames niet getoetst 1 3 3 X X

Pagina 29 van 39


2.8 Issues tijdens het uitvoeren van een Agile Scrum project Hieronder staan mogelijke maatregelen genoemd bij de issues die zich vaak voordoen bij het uitvoeren van een project. Waarbij de cijfers van Kans en Impact staan voor: 1 = zeer laag, 2 = laag, 3 = middel, 4 = hoog en 5 = zeer hoog Issues tijdens het uitvoeren van een project

Issue Kan

s Im

pact

Ris

ico

Mogelijke maatregelen Prod

uct O

wne

rPr

ojec

tleid

erSc

rum

mas

ter

Userstories niet ready waardoor te veel discussie

3 4 12 Userstory uit de sprint halen, ready maken en in een volgende sprint plannen. Bespreek bij retrospective

X

Teamleden worden deels uit het scrumteam gehaald en elders ingezet.

3 4 12 Resources full-time claimen, escaleren bij opdrachtgever X

Team incompleet 3 4 12 Niet meer inplannen dan beschikbare tijd, rekening houden met dat niet alle expertises aanwezig zijn.

X

OTAP omgeving onvoldoende operationeel / werkend

3 3 9 Escaleren, elders of lokaal een omgeving gebruiken X

Werken aan scrum / samenwerken kost tijd in sprint 1 & 2, onvoldoende ingecalculeerd

3 3 9 In sprint 1 en 2, rekening houden met een lagere velocity X

Productowner staat te ver af van het team / kan onvoldoende tijd maken voor het team

3 3 9 Tijd claimen bij productowner, productowner overtuigen dat zijn inzet cruciaal is. Bespreek bij retrospective. X X

De demo toont geen werkende software

3 3 9 Gebruik een checklist of scrum wel voldoende geimplementeerd is. Bespreek bij retrospective

X

Eindgebruikers onvoldoende aangehaakt

2 4 8 Organiseer workshops, benoem een afgevaardigde van de gebruikers als productowner, neem gebruikers op in het team

X X X

Te optimistische sprintplanning

2 4 8 Plan de volgende sprint minder ambitieus, bespreek in de retrospective X

Het team is 'disrupted / controlled' door buitenstaanders

2 4 8 Bespreek dit met degene die intervenieert en wijs erop dat hij invloed kan uitoefenen bij de productowner, niet bij het teamlid. X

In de daily stand up komen de impediments onvoldoende naar voren

2 3 6 Bespreek dit in de retrospectiveX

Definition of Done is niet bereikbaar in een sprint ( te grote userstories)

2 3 6 Maak userstorie kleinerX

Aannames niet getoetst 2 2 4 X

Pagina 30 van 39


2.9 Evaluatie van een Agile Scrum project Om op eenduidige wijze de Agile Scrum projecten te kunnen evalueren is het onderstaande format ontwikkeld. Hiermee kan op eenduidige wijze de evaluatie uitgevoerd worden en kan op gelijke wijze zicht komen op de resultaten van een project. Beste allemaal, In het kader van lerende organisatie wil ik graag een evaluatie houden. Ik zou het fijn vinden als je op de onderstaande punten aan wil geven wat ging goed en wat zou beter kunnen. Onderwerp

Wat ging goed Wat zou beter kunnen. Mogelijk met aanbevelingen

Rol van Product Owner

Rol van Scrum Master

Rol van Scrumteamlid

Rol van Projectleider

Ondersteuning vanuit DICTU

Ondersteuning vanuit externe partij

Ondersteuning vanuit DR

De locatie(’s)

De demo’s

De daily standup

De retrospective bijeenkomsten

De sprintplanningen

De voorbereidingen om te kunnen starten met sprint 1

Duidelijkheid m.b.t. de specificaties

De samenwerking

……

Algemene vragen: Wat vind je van het gebruik maken van de methode Agile Scrum?

Voordelen: Nadelen:

Pagina 31 van 39


2.10 Best Practices van Agile Scrum Projecten binnen DR Zoals in het voorwoord staat, fouten maken mag daarbij uiteraard. Maar: je hoeft niet steeds dezelfde fouten te maken, er is keus genoeg! Vandaar hierbij de opsomming van de best practices.

nr Omschrijving Best Practice Onderdeel Opd

rach

tgev

erPr

oduc

t Ow

ner

Proj

ectle

ider

Scru

mm

aste

rSc

rum

team

1 Een eigen ruimte voor het team met voldoende middelen (pc's, scrumboard, whiteboard, flipover, telefoon, overlegtafels, presentatiemateriaal, etc) is een must

MiddelenX

2 Laat anderen, dan teamleden die de sprint uitvoeren, de volgende sprint voorbereiden

Sprint-voorbereiding X

3 Probeer de productbacklog in sprint 0, op userstorie nivo te definieren, ipv het nivo epics of thema's. Indien er veel epics en thema's in de productbacklog staan onderken dit, je zult dan meer effort moeten steken in de voorbereiding van de sprints.

Sprint 0

X X

4 Onderzoek de Product Backlog op afhankelijkheden tussen Userstories

Sprint 0 X X

5 Vóór het opstellen van een Product Backlog moet eerst de productvisie worden

X

gedeeld.Sprint 0 X X

6 De Product Owner moet bij de Sprintplanning aanwezig zi

X

jnSprint planning X

7 Houdt bij de sprintplanning rekening met de benodigde expertise

Sprint planning X X

8 Doe geen aannames, maak expliciet wat er gevraagd wordt, check of het mogelijk is of voer een PoC uit

Ready maken X X

9 Geen wijzigingen tijdens de uitvoering van een sprint, in de sprintbacklog. Bij de volgende sprintplanning kan er gewijzigd worden

Sprint uitvoering X

10 Opleverdata op vaste momenten in het hele Agile Scrumtra

X

jectDemo X

11 De Product Owner moet bij de Demo aanwezig zijn Demo X12 Prioriteer de vervolgacties uit de retrospective en pak de 3

belangrijkste op in de volgende sprint.Retrospective X

13 Retrospective, methode van prioriteren van verbeter-punten gebruiken om niet de discussie opnieuw te horen

Retrospective X

14 Schrijf op geeltjes 2 goede punten en 2 verbeterpunten. Laat het Scrumteam in een cirkel voor de flipover staan. Nu licht ieder teamlid steeds 1 geeltje kort toe en plakt het op de flipover. Het volgende teamlid doet het zelfde totdat iedereen alle geeltjes heeft toegelicht en geplakt. Dit versnelt de retrospective als geheel.

Retrospective

X X X X

15 Het werken met userstories leent zich minder voor onderzoeksopdrachten

Agile Scrum methodiek X

16 In een al gedefinieerde praktijkproef kunnen aandachtsgebieden worden meegenomen.

Algemeen X X

17 In het begin van een project heeft een scrummaster meer tijd nodig om "in" te komen, daarna kan er meer productie geleverd worden

AlgemeenX

18 De PO moet zijn/haar rol goed oppakken door er te staan namens de organisatie met volledig mandaat

Algemeen X

Pagina 32 van 39


nr Omschrijving Best Practice Onderdeel Opd

rach

tgev

erPr

oduc

t Ow

ner

Proj

ectle

ider

Scru

mm

aste

rSc

rum

team

19 Het kan zijn dat vanwege inhoudelijk verschil van kennis, voor verschillende userstories ook verschillende PO's worden ingezet (om inhoudelijk te kunnen worden bevraagd)

Algemeen

X

20 Waak over belangenverstrengeling bij PO. (bv bij prioritering eigen belang boven organisatie belang)

Algemeen X

21 Altijd deelname aan een standup, ook als je die dag niet ingepland bent. Kan ook telefonisch of via skype

Algemeen X

22 Bij overleg goed timeboxen en regie voeren om bij het onderwerp te blijven. Anders te veel verlies van tijd.

Algemeen X

23 Iedereen dient wel Agile Acrum opgeleid te zijn Algemeen X24 Iedereen dient wel toegang te hebben tot shares en

software als JIRA en het weten te gebruikenAlgemeen X

25 Bij parttime werken is het een overweging waard om niet al je uren in het lab te steken. Er blijft dan geen tijd over om dingen te doen die je moet doen maar niet direct aan het lab zijn gelieerd .

Algemeen

X X X X

26 Over het algemeen kan gezegd worden dat de inzet van betrokkenen groot was. Het werken in een Scrumteam kost veel energie, maar het levert ook veel energie op. Dat was heel mooi om te ervaren.

Algemeen

X X X X X

27 Het gebruik van basiselementen van Agile Scrum werd als een goed hulpmiddel beschouwd om tot resultaten te komen. De ervaring leert inmiddels dat deze werkwijze voor een goede teamspirit zorgt, het levert een positieve houding op van de medewerkers. Scrum stimuleert samenwerking en de teams werden na verloop van tijd steeds meer zelfsturend.

Algemeen

X X X X X

28 Vanuit de multidisciplinaire samenwerking met deelnemers uit alle vestig-ingen van DR en DICTU is een groot onderling netwerk ontstaan. Mensen weten elkaar nu sneller te vinden. Vooral het samenwerken werd als heel plezierig ervaren en dat gaat het beste als je bij elkaar zit. Het zorgde ook voor een goede werksfeer.

Algemeen

X X X X X

29 De ontwikkeling die mensen doormaken, zowel inhoudelijk als procesmatig is groot te noemen. Je ziet mensen groeien in kennis en je neemt veranderingen in hun gedrag waar.

Algemeen

X X X X X

30 Het opleveren werd regelmatig op heel creatieve manier ingevuld. Van het tonen van werkende software tot aan zeer creatieve manieren van opleveren.

AlgemeenX X X X X

31 De betrokkenheid vanuit de business, door de Product Owners, werd als goed bestempeld. De fysieke afstandsproblemen werd niet als problematisch ervaren

AlgemeenX X X X X

32 Het houden van een dagelijks startmoment wordt als zeer positief ervaren en wordt nu ook bij andere teams toegepast.

AlgemeenX X X X X

33 Het zoeken naar mogelijkheden ipv afremmen door onmogelijkheden te benoemen, creatieve manier van werken, het meedoen ipv toekijken.

AlgemeenX X X X X

34 Direct feedback krijgen, openstaan voor alle suggesties Algemeen X X X X X35 De dagelijkse standup, de scrum, wijze van rapporteren,

sparren met elkaar, beelden delen, timeboxen, tijd is tijd;Algemeen X X X X X

Pagina 33 van 39


2.11 Ondersteunende Tooling Advies tooling en gebruik Om de teams een goede standaardomgeving te bieden die hen bij projecten kan ondersteunen heeft project BAS advies opgesteld over de tooling en het gebruik daarvan.

nr Onderwerp MO

SC

OW

Co

mp

lexit

eit

Motivatie1 Geautomatiseerd builden / continues

integrationM 1 Verhoogd productiviteit van ontwikkelaars

met 20%. 2 Versiemanagement op code M 1 Voorkomt testbevindingen in een later

stadium.3 Agile management software

(backlogmngt, burndown, voortgangsbewaking, planning, tracability…)

M 2 Geeft elk teamlid inzicht in de actuele status van de userstories, maakt sturing mogelijk.

4 Teamcollabiration (documentmngt, wiki, multi-bestanddeling, zoeken, versiebeheer)

M 2 Een 'must' voor het scrumteam om elk moment up-to-date informatie te hebben en de laatste document versie beschikbaar te hebben. Bevorderd bovendien communicatie en samenwerking.

5 Documentatie standaarden M 3 Eenduidige standaard, uitwisselbaarheid, beheersbaarheid

6 Modelleringstools (voor ontwerpers/ analisten)

M 3 Eenduidige standaard, uitwisselbaarheid, beheersbaarheid

7 OTAP <1wk operationeel (alternatieve opzet bij externe ontwikkelstraat)

M 5 Noodzakelijk om vanaf sprint 1 te kunnen ontwikkelen.

8 KA - omgeving / office / pc's werkruimte

M 5 Noodzakelijk om toegang te krijgen tot de ICT omgeving.

9 Unit-testen / geautomatiseerd testen S 1 Verhoogd productiviteit van testers met 20%

10 Babbelbox S 1 Noodzakelijk bij daily stand-ups voor teamleden / productowner die niet fysiek aanwezig kan zijn. Makkelijk om overleggen te regelen.

11 Extern benaderbaar ontwikkelomgeving.

S 5 Maakt het mogelijk om vanaf willekeurige locaties te werken aan userstories.

12 Webcam / direct messaging (bij meerdere locaties)

S 5 Vereenvoudigd de communicatie tussen locaties

13 Kwaliteitsbewaking op software C 1 Automatische bewaking van ontwikkelde code, voorkomt testbevindingen in een later

14 Standaard IDE (integrated development enviroment)

C 2 Voorkomt dat ontwikkelaars elk hun eigen ontwikkelomgeving hebben.

15 Single sign-on C 5 Beperkt het aantal accounts en wachtwoorden, maakt zaken laagdrempelig en beheersbaar.

Pagina 34 van 39


Keuze ondersteunende tooling Er is een inschatting gemaakt welke van de drie mogelijke ondersteunende tools (PLEIO, samenwerkingsruimte van het Rijk en KIS) het meest geschikt is om bij een Agile project in te zetten, zodat deze bij een te starten project vanaf het begin ingezet kan worden. Hieronder staat in een schema weergegeven wat de mogelijkheden van de verschillende toolings zijn.

gebr

uiks

vrie

ndel

ijkhe

id

toep

assi

ngsm

ogel

ijkhe

den

docu

men

tenb

ehee

rw

iki

twitt

er

sam

enw

erki

ng m

et J

IRA

aktie

lijst

afbe

eldi

ngen

prik

bord

proj

ect t

aken

Blog

sev

enem

ente

n

Samenwerkings ruimte van het Rijk - + + + - - + + + + - -PLEIO + + - + + - + + + - + + rood betekent niet gebruiken

KIS (confluence) + + + + + + + + + + + + moet wel de nieuwste versie gebruikt gaan worden

Advies is insteken op KIS confluence met de nieuwste versie en anders gebruik gaan maken van Samenwerkingsruimte van het Rijk. PLEIO valt af i.v.m. slecht documentbeheer. NB! Samenwerkingsruimte van het Rijk kent geen autorisaties toe aan externen.

Pagina 35 van 39


Overzicht benodigde dienstverlening bij tooling DR vraagt het applicatiebeheer op de Atlassian Suite aan, bestaande uit de onderstaande producten: • Greenhopper for Jira versie 5.8.6. • Jira Enterprise versie 4.4.4 • Confluence (KIS) versie 4.1.3 • Callserver (Babbelbox) Scope Binnen de scope valt onderstaande dienstverlening: 1. Incidentenmanagement: Het oplossen van verstoringen en beantwoorden van

complexere functionele vragen. 2. Probleemmanagement: Het oplossen van structurele issues en repeterende

incidenten middels structurele oplossingen. 3. Change/Releasemanagement:

• Doorvoeren van wijzigingen op Atlassian Suite n.a.v. incidenten of problemen m.b.v. een patch of een release

• Doorvoeren van wijzigingen n.a.v. bekende problemen aangegeven door de productleverancier m.b.v. een patch of een release

• Doorvoeren van wijzigingen om de Atlassian Suite up-to-date te houden • Doorvoeren van wijzigingen op aangeven van DR i.v.m. aanpassingen in de

infrastructuur 4. Support/Beheer: Het bieden van telefonische, e-mail en remote-access

ondersteuning via een helpdesk of soortgelijke faciliteit. 5. Nader af te spreken;

• Operating System en Database; • Functioneel beheer; • Account- en rechtenbeheer.

Gevraagde Service Niveau Basis dienstverlening

Pagina 36 van 39


3 Bijlagen

3.1 Stakeholders Agile Scrum binnen DR 1) Wie zijn de stakeholders bij toepassing van Agile Scrum? 2) Wat zijn de belangen van een stakeholder? 3) Wat is de toegevoegde waarde voor een stakeholder bij invoering van Agile

Scrum? 4) Wat zijn de eventuele weerstanden bij het verder implementeren van Agile

Scrum? 1) Wie zijn de stakeholders bij toepassing van Agile Scrum? Vanuit de Product Owner is aangegeven dat het MT PIM, stakeholder is van de methodiek Agile Scrum. Uit gesprekken met de Team Managers van PIM blijkt dat zij enerzijds het MT Drive / DT ook als belanghebbende zien om hiermee de juiste consensus binnen de organisatie voor Agile Scrum te krijgen. Anderzijds ook de teammanagers vanuit de business (PPU) om begrip en steun te hebben bij de uitvoering van projecten op Agile Scrum wijze. 2) Wat zijn de belangen van een stakeholder? • DR heeft veel ontwikkeltrajecten waarin veel verspilling in geld en resultaat is.

Agile Scrum zorgt dat kosten en tijdstip van in productie name voorspelbaarder zijn.

• Agile Scrum heeft korte cyclus, beperkte scope, is zeer resultaatgericht; er staat een werkbaar resultaat.

• De business wordt goed betrokken bij projectresultaat samen met de ontwikkelaars.

• Het effect op medewerkers die deelgenomen hebben aan een Agile Scrum project is bijzonder positief. Leren anders om te gaan met werk, sturen op resultaat binnen een bepaalde periode, grote betrokkenheid bij resultaat.

• Draagt bij aan cultuurverandering van DR om anders te kijken, om dingen samen tot een resultaat te brengen. Ondersteunt de menskant van de verandering binnen DR.

Let op: • nu is / wordt op verschillende locaties al op Agile Scrum wijze gewerkt. In

Roermond nog niet het geval, wens is geuit om ook betrokken te worden. • De juist gemandateerde Product Owner beschikbaar hebben op zowel beleid,

proces als technisch gebied. Hoe zorgt de Product Owner voor de juiste back-up (oude “stuurgroep”) om beslissingen te nemen en dat op hoog niveau in de organisatie de medeverantwoordelijkheid wordt gevoeld voor het project.

• Belangrijk om je projectresultaat te verkopen met duidelijk aantoonbaar de toegevoegde waarde van Agile Scrum als gebruikte methodiek.

• Scherp maken wanneer een project wel of niet volgens Agile Scrum werkt, of slechts werkvormen toepast. Het kan verkeerde reclame opleveren!

• De Agile Scrum methodiek hebben we nog niet voldoende kennis van. Nu eerst heel zuiver toepassen om daarna met de ervaren Projectleiders & Scrum Masters

Pagina 37 van 39


te bepalen wat pragmatisch voor DR is. Dan pas mogelijk om bewust keuzes te maken wat wel of niet toepasbaar is.

3) Wat is de toegevoegde waarde voor een stakeholder bij invoering van Agile Scrum? • Met alle betrokkenen aan het begin van project helder wat de uitgangspunten

zijn, welk resultaat moet echt en wat is nice to have? • Zeer bruikbaar als het einde onzeker is of de weg er naar toe waarbij onderweg

nog keuzes gemaakt moeten (kunnen) worden; typische DR trajecten (!?) • Snel van grof naar fijn, van onzekerheid naar zekerheid of juist naar het

expliciet maken van de onzekerheid. • Het samen werken, fysiek bij elkaar aanwezig. • De methodiek dwingt tot afstemming; vaste stappen in ontwikkelingen Let op: • Vraagt in de uitvoering van project wel veel discipline van de teamleden incl.

een goede Scrum Master. • De methodiek vraag veel van de deelnemers qua beschikbaarheid. • Het toepassen van Agile Scrum heeft een aantal voordelen (toegevoegde

waarde) maar voorkomt dat dit de redenen zijn om te kiezen voor de projectmethodiek. Zoals communicatie met stakeholders, betrokkenheid opdrachtgever en sneller tot producten komen.

• Vraagt juiste betrokkenheid DICTU en achterliggende mantelpartijen. Agile Scrum staat nl. haaks op “outsourcen” van werkzaamheden.

• Meer aandacht in sprint 0 voor inzet & opleiding capaciteit om op stoom met sprint 1 te beginnen.

• Op benodigde competenties scherp blijven en geen zwakte bod doen, om het project maar te laten starten. Voor verschillende werkzaamheden van functies (FAB, ontwerper etc) ook echt andere competenties nodig. Niet zomaar uitwisselbaar.

• Voorkom dat Agile Scrum een toverwoord wordt als oplossing voor alle problemen; “Een goede projectleider met LBV, (Logisch Boeren Verstand), kan het ook”

• Indruk bestaat bij een enkele manager dat de vaste iteratie van x weken soms vertragend kan werken in een fase waar juist heel helder is wat er moet / kan gebeuren. Het vertragen lijkt te zitten in de ondersteunende activiteiten van sprintvoorbereiding, sprintplanning, oplevering, retrospective etc.

• Hoe de aandacht voor medewerkers en managers. 4) Wat zijn de eventuele weerstanden van de stakeholder bij het verder implementeren van Agile Scrum? Uit de gesprekken met de teammanagers PIM kwam naar voren dat er geen weerstand tegen de methodiek is, mits het niet als dogma en enige ontwikkelmethodiek wordt aangeboden. Het is van belang om duidelijk te maken in welke situatie Agile Scrum het beste van toepassing is, het beste resultaat boekt. Het project zou kunnen helpen door het opstellen van een lijst met heldere criteria om de keuze “wanneer Agile Scrum te gebruiken” te maken. De Product Owner heeft als voorkeur binnen DR de toekomst: “Ontwikkelprojecten met Agile Scrum, tenzij…..”

Pagina 38 van 39


Pagina 39 van 39

Om weerstand in de rest van de organisatie te voorkomen is de behoefte genoemd om de methodiek breder uit te dragen: 1. Consensus van het hoger management (MT Drive en DT) voor de Agile Scrum

methodiek, waarbij de consequenties qua inzet van capaciteit ook gerealiseerd wordt. Op moment van capaciteitsclaim moet de betreffende teammanager ook gesteund worden door de afdelingsmanager. De training voor Product Owner is cruciaal om te laten ervaren wat de rol van actiever eigenaarschap is.

2. In trainingen, ook voor (nog) niet projectmedewerkers. Eerst binnen PIM (met name de POB teams) daarna UB en PPU en de rest van DR. Hierbij doelgroepen voor implementatie expliciet maken.

3. De communicatie zal gedoseerd in toon en frequentie moeten zijn om verfrissend te blijven en vraagt volhouden van de projectgroep en (zodra die er is) de vakgroep.

Handreiking voor toepassen van Agile Scrum binnen ... AS binnen... · Dit boekje geeft geweldige...

Documents

Transcript of Handreiking voor toepassen van Agile Scrum binnen ... AS binnen... · Dit boekje geeft geweldige...