Managen van agile projecten

WHITEPAPER

Managen van agile projecten Bert Hedeman

Whitepaper - Managen van agile projecten

Iedereen Agile? Nee! Agile kan absoluut eenvoudig en effectief worden toegepast in ieder project waarbij een sterke samenwerking met de gebruikers gewenst is. Maar het ontbreekt agile aan de hogere besturingslagen waardoor met agile als enige aanpak veranderingen niet kunnen worden doorgevoerd. Hoe manage je dan agile projecten, hoe zorg je voor samenhang, voor aansluiting bij de besturing van agile projecten binnen een compleet portfolio? Vanuit deze behoefte is het boek ‘Managen van agile projecten’ 1 geschreven waarbij nadrukkelijk gebruik gemaakt is van Atern; de enige agile aanpak die ook het managen van projecten beschrijft. Hier bieden de auteurs een overview van wat zij in het boek uiteenzetten. Behalve over de uitgangspunten van de Atern-filosofie en de vertaalslag naar het managen van agile projecten gaat het bovendien over de afweging waarom wel of niet agile en de positionering van het Atern-raamwerk in combinatie met andere methoden zoals PRINCE2, Scrum, Lean Six Sigma of XP. Het boek gaat verder dan deze afwegingen alleen; daar bieden zij handreikingen hoe agile projectmanagement in de praktijk in te zetten en deze optimaal te combineren met andere aanpakken.

Agile in een notendop Agile biedt een aanpak om een goed resultaat op tijd en binnen budget op te leveren door: • • • • • •

Te focussen op het op te leveren bedrijfsresultaat; Het prioriteren van de gewenste functies; Het ontwikkelen van het op te leveren resultaat in korte iteraties (timeboxes); Het incrementeel opleveren van het resultaat om vroegtijdig toegevoegde waarde te leveren; Het stimuleren van de samenwerking tussen alle bij het project betrokken partijen; Het vastleggen van kwaliteit, tijd en geld als niet-onderhandelbare normen.

Figuur 1: Agile aanpak versus traditionele aanpak

Bij agile projecten vormen zelfsturende teams de basis. Deze teams zijn volledig verantwoordelijk voor het realiseren van het op te leveren resultaat in een aantal korte iteraties. De op te leveren functies worden bepaald door de gebruikersvertegenwoordigers in samenspraak met het team. Het werk wordt uitgevoerd in vaste timeboxes van één tot enkele weken. Op het eind van iedere timebox wordt het werk beoordeeld door de gebruikers. Op het einde van iedere increment (fase) wordt een 1

Managen van agile projecten, Bert Hedeman e.a., 2014

© Hedeman Consulting 2014

pagina 1 van 10


deel van het gevraagde product opgeleverd aan de klant en in gebruik genomen. Daarom worden agile projecten ook niet beheerst op basis van tijd en geld, maar op basis van het aantal op te leveren functies binnen een vooraf gedefinieerde doorlooptijd (zie figuur 1). Soms worden increments ook wel fasen genoemd maar de essentie van een increment is toch anders dan van een fase. Een increment levert een werkend deel op van het eindresultaat. Een fase levert meestal slechts een tussenproduct op (zie figuur 2). In agile projecten is altijd sprake van een incrementele oplevering.

Figuur 2: fasen versus increments

Overigens is een veelgehoorde stelling dat agile alleen geschikt is voor IT-projecten. Dat is niet het geval. Agile kan eenvoudig en zeer effectief worden toegepast in ieder project waarbij een sterke samenwerking met de gebruikers gewenst is.

Waarom agile projecten? Te laat opleveren van de afgesproken projectresultaten zorgt vaak voor grote frustraties bij de klant en de gebruikers. Het kan zelfs een reden zijn om het project in zijn geheel af te blazen. Agile ondervangt dit probleem door juist het op tijd opleveren van het eindresultaat als uitgangspunt te nemen in de gehele projectaanpak. Een agile project wordt beheerst door het al dan niet opleveren van het aantal functies en (dus) níet door het besteden van extra tijd of geld. De ruimte in de functies wordt gevonden door de functies te prioriteren naar hun toegevoegde waarde voor de klant en het vervolgens opleveren van die functies in de volgorde van die prioriteit. De vraag is, kan dat zomaar? De ervaring leert dat in traditionele projecten vaak 60 - 65% van de opgeleverde functies niet of nauwelijks wordt gebruikt. Dit komt omdat bij het definiëren van de functies vaak alle theoretisch mogelijke alternatieven worden geïdentificeerd zonder goed te worden geprioriteerd (figuur 3).


pagina 2 van 10


Figuur 3: Gebruik van functies in traditionele projecten

In tegenstelling tot traditionele projecten worden in agile projecten alle op te leveren functies geprioriteerd naar de toegevoegde waarde voor de organisatie. Overbodige functies worden niet meegenomen. Tenslotte is een belangrijk kenmerk van de agile aanpak dat het gehele team openstaat voor veranderingen en voortschrijdend inzicht. In traditionele projecten worden veranderingen vaak gezien als een probleem in plaats van een kans. Dat komt doordat de meeste projecten zijn dichtgetimmerd ten aanzien van de op te leveren functies en onder druk staan ten aanzien van zowel tijd als geld in plaats van dat zij binnen de gestelde tijd en geld een zo maximaal mogelijke toegevoegde waarde moeten leveren.

Atern-filosofie en -raamwerk De Atern-filosofie is dat ieder project moet worden afgestemd op duidelijk gedefinieerde bedrijfsdoelen en moet focussen op een vroege oplevering van producten die echt toegevoegde waarde leveren aan de bedrijfsorganisatie. Het Atern-raamwerk definieert een achttal principes: 1. 2. 3. 4. 5. 6. 7. 8.

Focus op de bedrijfsbehoefte; Lever op tijd; Werk samen; Doe geen concessies aan kwaliteit; Ontwikkel iteratief; Werk incrementeel vanuit een stevige basis; Communiceer duidelijk en continu; Zorg voor een zichtbare beheersing.

Het Atern-raamwerk wordt vervolgens weer ondersteund door Processen met gedefinieerde Producten, rollen en verantwoordelijkheden (Mensen) en aanbevolen technieken (Toepassingen). Zie figuur 4.


pagina 3 van 10


Figuur 4: Atern-raamwerk

Belangrijke technieken zijn onder andere timeboxen, gefaciliteerde workshops en het prioriteren van functies op basis van het MoSCoW-principe.

Processen Het Atern-procesmodel onderscheidt 7 processen ofwel 7 fasen (zie figuur 5). In de Pre-projectfase (1) wordt besloten het project uit te voeren. In de Haalbaarheidsfase (2) wordt nagegaan of het project vanuit zowel zakelijk als technisch oogpunt realiseerbaar en wenselijk is. In de Fundatiefase (3) wordt, zoals de naam zegt, de fundering gelegd voor de uitvoering van het project.

Figuur 5: Atern-procesmodel


pagina 4 van 10


Na de Fundatie start de uitvoering van het project. Dat gebeurt in vooraf gedefinieerde increments. Per increment wordt een werkend deel van het eindresultaat opgeleverd. Ieder increment bevat in principe de fasen Verkenning (4), Ontwerp & Bouw (5) en Implementatie (6). Na de Implementatie wordt een nieuw increment opgestart of het project afgesloten mocht aan de eisen zijn voldaan. In de Post-projectfase (7) wordt nagegaan of de geprognotiseerde baten ook daadwerkelijk zijn of worden gerealiseerd. Uitgaande van een aantal increments (N) kan de levenscyclus van een Atern-project in de tijd als volgt worden weergegeven (zie figuur 6):

Figuur 6: Atern-projectlevenscyclus

Mensen Atern maakt onderscheidt tussen de projectbesturing, het Realisatieteam en overige rollen (zie figuur 7). De projectbesturing wordt gevormd door de Bedrijfssponsor zijnde de opdrachtgever, de Bedrijfsvisionair als de vertegenwoordiger van de gebruiker op managementniveau, de Technisch Coördinator als de vertegenwoordiger van degene die het resultaat moeten opleveren en de Projectmanager, verantwoordelijk voor de coördinatie en communicatie.

Figuur 7: Atern-organisatiemodel


pagina 5 van 10


Het Realisatieteam wordt gevormd door de Teammanager, de Bedrijfsambassadeur, de Bedrijfsanalist, de Ontwikkelaar en de Tester. Essentieel binnen Atern is dat er sprake is van een zelfsturend team. De Teammanager moet er voor zorgen dat het Realisatieteam ook echt als team functioneert. De Teammanager is hierbij echter meer faciliterend en begeleidend dan manager. De Bedrijfsanalist vertaalt de bedrijfseisen naar technische oplossingen De Bedrijfsambassadeur is verantwoordelijk voor het detailleren en prioriteren van de gebruikerseisen en voor het testen van de gerealiseerde producten vanuit gebruikersperspectief. De overige rollen binnen de Atern-structuur zijn de Bedrijfsadviseur, de Technisch Adviseur, de Work-shop Moderator en de Atern-coach. De Bedrijfsadviseur is vaak een collega van de Bedrijfsambassa-deur en levert specialistische input. Datzelfde geldt voor de Technisch Adviseur maar dan alleen vanuit het leveranciersperspectief.

Producten Atern maakt gebruik van bedrijfs-, management- en specialistenproducten. Afhankelijk van het project en de omgeving kunnen producten worden samengevoegd. Net als bij PRINCE2 moet het project op maat worden gemaakt en kunnen producten worden samengevoegd (zie figuur 8). In de Pre-projectfase wordt een Nota van Uitgangspunten opgesteld. Dit document is de basis waarop het project kan worden gestart. In de Haalbaarheidsfase wordt het project vanuit zowel een bedrijfs- als een technisch perspectief getoetst en een Plan op Hoofdlijnen opgesteld.

Figuur 8: Atern-producten op maat gemaakt

In de Fundatiefase wordt de Basisbeschrijving Bedrijfssituatie opgesteld inclusief een Geprioriteerde Eisenlijst en de Bedrijfsbeschrijving en het Borgingspakket van het op te leveren Resultaat. Tevens wordt in deze fase het Realisatieplan opgesteld met de Managementaanpak en de overeen te komen procedures. In iedere timebox wordt tijdens de kick-off een Timeboxplan opgesteld. Tijdens de afsluiting van de timebox wordt een Timeboxreviewverslag opgesteld. Op het eind van het project wordt een samen-vattend Projectreviewverslag opgesteld. Tenslotte wordt tijdens de Post-projectfase een batenbeoordeling uitgevoerd en een gelijknamig verslag opgesteld.


pagina 6 van 10


Positionering Een vaak gestelde vraag is of Atern gebruikt kan/moet worden in combinatie met, of in plaats van andere methoden zoals PRINCE2, Scrum, Lean Six Sigma of XP. Deze vraag is niet eenduidig te beantwoorden. Als we kijken naar een veranderingstraject dan kunnen we meerdere bestuurslagen onderscheiden (zie figuur 10). Iedere methode/aanpak heeft daarbij zijn eigen aandachtsgebied. Daarbij is echter veel overlap tussen de verschillende methodieken. Kijkend naar de verschillende bestuurslagen is het duidelijk dat Atern en daarmee agile niet alle andere methoden en raamwerken kan vervangen. Verschillende organisaties zijn al vastgelopen op het ontbreken van de hogere besturingslagen in een veranderingstraject en komen terug op de stelling dat met agile alleen alle veranderingen opgepakt kunnen worden. Daarnaast kent iedere methode zijn eigen begrippenkader. Dat maakt het ook niet gemakkelijk methodes te combineren. Laten we inzoomen op Atern versus PRINCE2.

Figuur 10: Overzicht bestuurslagen en methodieken

Atern en PRINCE2 Het gedachtegoed van PRINCE2 en Atern komen sterk overeen. Dat is goed zichtbaar als we PRINCE2 en Atern met elkaar vergelijken. PRINCE2 gaat uit van een zakelijke rechtvaardiging, leren van ervaring, gedefinieerde rollen en verantwoordelijkheden, managen per fase, management by exception, productgerichte aanpak en op maat maken voor de projectomgeving. Allemaal zaken waar Atern ook van uitgaat. PRINCE2 gaat verder net als Atern uit van een klant-leveranciersrelatie. In de projectbesturing worden in PRINCE2 de rollen Opdrachtgever, Seniorgebruiker en Seniorleverancier onderscheiden. Dit sluit geheel aan op de rollen van Bedrijfssponsor, Bedrijfsvisionair en Technisch Coördinator in Atern.


pagina 7 van 10


In PRINCE2 komt de projectmanager de kaders overeen met de Teammanager/teams en bemoeit hij zich niet met de inhoudelijke werkzaamheden in het team. Ook dat komt overeen met de filosofie van Atern. In PRINCE2 worden in de Initiatiefase (Fundatiefase in Atern) alleen de specificaties van de belangrijkste producten opgesteld (in het Projectplan) en worden voor de opvolgende fasen de specificaties in de afzonderlijke faseplannen nader uitgewerkt. Verder gaat PRINCE2 uit van een geïntegreerde wijzigingsprocedure en van kwaliteitsreviewvergaderingen met de gebruikers direct vanaf het begin van het project. Ook dit ligt in lijn met Atern/agile. Ook qua processen sluiten de beide methoden op elkaar aan. Opstarten van een Project binnen PRINCE2 komt sterk overeen met de Haalbaarheidsfase in Atern. Initiëren van een Project in PRINCE2 komt sterk overeen met de Fundatiefase in Atern. Tijdens de uitvoering spreekt PRINCE2 over fasen. Atern spreekt over increments omdat incrementeel wordt opgeleverd. Bij PRINCE2 is dat optioneel. De uitvoering kan traditioneel worden opgepakt volgens het watervalprincipe maar ook incrementeel. PRINCE2 geeft nadrukkelijk aan dat ook fasegewijs kan worden opgeleverd. PRINCE2 kent geen Post-projectfase maar in het Batenrealisatieplan wordt wel de batenreview beschreven die in de Post-projectfase moet worden uitgevoerd. Ook qua processen sluiten de beide methoden dus op elkaar aan (zie figuur 11).

Figuur 11: Projectlevenscyclus PRINCE2 versus Atern

Zijn PRINCE2 en Atern dan helemaal niet tegenstrijdig? Natuurlijk wel. Het grootste verschil tussen de beide methoden is de andere focus. PRINCE2 is een projectmanagementmethode hoe een project te beheersen voor ieder type project. Atern is een methode die specifiek gericht is op het managen van agile projecten en daarnaast ook gericht is op het functioneren van het zelfsturende team. In dat opzicht zijn de beide methoden niet vergelijkbaar. Echter in essentie hanteren zij wel dezelfde uitgangspunten maar dan vanuit een ander vertrekpunt en met een andere begrippenset. De manager moet kiezen uit een van beide begrippenkaders en waar mogelijk waardevolle aspecten van de andere methode overnemen en incorporeren in de eigen methode.


pagina 8 van 10


Conclusies Uit de vergelijking blijkt dat PRINCE2 goed te gebruiken is in agile projecten. Je moet PRINCE2 dan echter wel toesnijden op de agile omgeving. PRINCE2 en Atern hanteren in essentie dezelfde uitgangspunten maar vanuit een ander vertrekpunt en met een andere begrippenset. Die aspecten vragen om een zorgvuldige keuze waarbij een van beide als basis wordt gebruikt. Met PRINCE2 kun je zowel traditionele projecten op basis van de watervalmethode managen als agile projecten. PRINCE2 wordt nu echter vaak gezien als een methode specifiek voor traditionele projecten en dat is onjuist. Daar doe je de methode PRINCE2 mee tekort. Vanuit de wens om maximale waarde toe te voegen aan de organisatie en om gebruikers vanaf het begin bij het project te betrekken lijkt agile zeker geen eendagsvlieg te zijn en absoluut geschikt om op maat toe te passen binnen de eigen bestaande aanpak.

Hoe nu verder Waar beginnen we? Als eerste moet worden nagegaan of projecten geschikt zijn voor een agile aanpak met zelfsturende teams, timeboxes en increments in combinatie met een geprioriteerd eisenpakket, of niet. Is dat niet zo, dan kun je er beter voor kiezen om een aantal agile technieken in de traditionele projecten op te nemen en niet volledig over te gaan op de agile aanpak. Kan er wel gekozen worden voor een agile aanpak, definieer dan eenduidige werkpakketten als scheidslijn tussen de projectmanager en het zelfsturende teams en begin dan gewoon in één project. Maar kies wel het juiste project. Fouten maken moet kunnen. En bouw van daar uit naar de rest van de teams. Tenslotte is het belangrijk te realiseren dat het niet de ene of de andere methode is. Afhankelijk van het type project kunnen verschillende methoden binnen een portfolio naast elkaar worden toegepast. Ook kun je er voor kiezen het project te managen op basis van PRINCE2 en voor de uitvoering van de werkpakketen te kiezen voor een agile aanpak zoals Scrum. Daarbij is het echter wel belangrijk dat de projectmanager meer faciliterend is dan dirigerend.


pagina 9 van 10


Over de auteurs

Bert Hedeman [email protected]

Henny Portman [email protected]

Ron Seegers [email protected]

Bert Hedeman is partner bij Hedeman Consulting en werkt als consultant en trainer en is auteur van diverse standaardwerken binnen het PM vakgebied. Henny Portman werkt binnen het PM(O) domein van ING Insurance en Investment Management en is 1 dag in de week als partner verbonden aan Hedeman Consulting. Ron Seegers is eigenaar van Projectmeester training en coaching en traint o.a. Agile PM. Hij is net als beide anderen (mede-)auteur en reviewer van diverse PM-boeken.

Vanuit de vaak gestelde vraag hoe agile projecten te managen hebben de auteurs het boek Managen van agile projecten geschreven. Daarbij is nadrukkelijk gebruik gemaakt van de Atern-aanpak. Echter die aanpak is niet één op één overgenomen. Op onderdelen wordt afgeweken. Verder is er voor gekozen alleen Nederlandse termen te gebruiken. En richten de auteurs zich in hun boek op meer dan ICT-ontwikkelprojecten alleen. Tenslotte besteden zij ook uitdrukkelijk aandacht aan hoe agile kan worden gecombineerd met andere methodieken.


pagina 10 van 10

Managen van agile projecten

Recommend Documents