In deze blog een korte beschouwing en mijn persoonlijke mening over Prince2 Agile, afgezet tegen de opkomst van het fenomeen scaling agile, en meer specifiek het Scaled Agile Framework.
De opkomst van agile werken, die niet meer te stuiten is, heeft ervoor gezorgd dat de organisatie die Prince2 onderhoud (AXELOS) recentelijk uitkwam met Prince2 Agile.
Het combineert de klassieke manier van project management met agile als gedachtengoed, en de vele agile frameworks die er zijn.
Introductie Prince2 Agile
Hierna enkele opsommingen van zaken die Prince2 agile als uitgangspunten hanteert:
Prince2 Agile dekt de volgende thema’s af:
- Progress
- Business Case
- Organization
- Quality
- Plans
- Risk
- Change
Het hanteert de volgende principes:
- Continue zakelijke rechtvaardiging
- Leren van ervaringen
- Gedefinieerde rollen en verantwoordelijkheden
- Managen per fase
- Management by exception
- Productgerichte aanpak
- Aanpassen aan projectomgeving
Prince2 Agile zegt over Agile: ‘Prince2 Agile regards Agile as a ‘family of concepts, behaviours, frameworks and techniques’.
Onder concepts noemen ze:
- Prioriteren
- Iteratief
- Incrementeel
- Inspect & Adapt
- Kaizen
Onder behaviours noemen ze:
- Transparantie
- Samenwerken
- Communicatie
- Zelforganisatie
- Exploratie
Onder frameworks noemen ze:
- Scrum
- Kanban
- DSDM
- SAFe
- Lean
- Lean start-up
Onder techniques noemen ze:
- User story
- Time box
- Burn chart
- Retrospective
Die combinatie van de klassieke manier van project management met agile als gedachtengoed resulteert in een taart met de volgende gelaagdheid:
Beschouwing
Ik ben zelf projectmanager geweest, en heb Prince2 trainingen gedaan, projecten volgens prince2 uitgevoerd. Ik vind het goed dat Prince 2 Agile uitgaat van agile principes en concepten, en inspeelt op een meer flexibele uitvoering.
Ik vind het echter vrij simplistisch om te zeggen we passen Prince2 toe ‘as is’, en voor de delivery mag je er elk agile framework onder plakken. Dan hebben ze nog niet begrepen dat bijvoorbeeld met agile het vaste scope denken wordt verlaten, en dat het SAFe framework uitgaat van het feit dat je geen projecten meer doet. Wel zeggen ze dan dat je een greenfield ontwikkeling van een product met Prince2 agile kunt doen, en als die gereed is het overdragen aan de staande SAFe organisatie die als ‘business as usual’ verdere innovatie en onderhoud op het product zal uitvoeren. Ook dat laatste ben ik geen voorstander van.
Dus als ik het vanuit mijn huidige praktijk met de ook blijvende trend Scaling Agile beschouw, dan moet ik de volgende kanttekeningen plaatsen:
- Een gegeven in de markt is dat de klassieke besturing van los staande projecten van tijdelijke aard, met stuurgroepen en klassieke KPI’s als uitputting versus begroot, niet meer werkt als je grootschalig alle projecten agile gaat uitvoeren, vandaar dat scaling agile zo booming is;
- Werken in projecten (ze zeggen wel vaste teams, maar voor de duur van het project, daarna desintegreert zon team weer? of laat je ze overgaan in die onderhoudstrein?) vergt een dubbele (projecten) boekhouding. En dat brengt een enorme overhead met zich mee;
- SAFe gaat uit van vaste teams binnen domeinen (value streams), die voor (IT gedreven bedrijven) onbepaalde tijd releases voor business producten of business processen realiseren;
- Deze vaste teams, georganiseerd in organisatieonderdelen met vaste kostenplaats budgetteer je per half jaar, je gaat gewoon uit van de salariskosten, geen dubbele projectenboekhouding meer;
- Komt er binnen een domein behoefte aan een geheel nieuw product, zoals ontwikkeling van een app, dan kun je ook kiezen voor het gelijk inbedden van een nieuw team in de vaste SAFe structuur die de greenfield ontwikkeling van de app doen. Stel die trein dan samen met teams met een kern van eigen medewerkers, aangevuld door eventueel leveranciers;
- Op deze manier beweeg je de resourcing als een mammoettanker mee met de aanwas of het opdrogen van de backlogs in de flow van eisen voor een release trein;
- Zie de scope van zo een app project als een Epic, die een release trein ingaat, die voor de greenfield ontwikkeling een extra team optuigt die een mix is van mensen uit bestaande teams met domeinkennis en nieuwe mensen;
- Hiermee voorkom je die dubbele boekhouding, en het onttrekken van resources aan vaste release treinen, wat weer hun productiviteit beïnvloed.
Mijn eindconclusies, wederom gezien door de bril van scaling agile:
- Voor organisaties die wat minder IT gedreven zijn (wat steeds minder voorkomt) en organisaties die zeer weinig onderhoud hebben op hun IT landschap (wat ook weinig voorkomt omdat iedereen zeer veel technische schuld in hun IT landschappen heeft), zou ik losse projecten, en dus Prince2 Agile, aanbevelen.
- Voor niet IT projecten zoals het organiseren van een Dance festival: Prince 2 agile zeer geschikt!
- Voor intensief IT gedreven organisaties raad ik aan om, als ze agile willen gaan, en als ze competitief willen blijven of wendbaarder worden, om SAFe te omarmen en de organisatie van business tot infra te structureren naar value streams. Dat betekent GEEN projecten meer (en dus geen Prince2 agile, want SAFe en projecten nog daarnaast, of parallel, dat bijt elkaar). Binnen die value streams draaien release treinen met multi disciplinaire teams met de volgende voordelen:
- Multi disciplinaire teams zijn eigenaar (en voelen zich ook zo) van het product (intrinsieke motivatie);
- Multi disciplinaire teams voeren innovatie én onderhoud uit in 1 team (dus ook bij greenfield ontwikkeling: ‘shared code ownership’ vanaf de eerste coderegel);
- Multi disciplinaire teams bouwen domeinkennis op en behouden deze;
- Multi disciplinaire teams bouwen een referentie kader op voor een nieuwe vorm van voorspelbaarheid die intensieve planning- en begrotings- inspanningen vooraf overbodig maken op den duur;
- Geen start stop wachttijden meer voor het starten en stoppen van projecten;
- Geen stuurgroepen meer, en dus dure rapportages die niet bijdragen aan de business value
- Geen exception reports meer (sturing gaat op business value en productiviteit, niet meer op kosten, want die zijn vast);
- Geen ‘Project Cost Accounting’ meer;
- Vele overleg structuren die compleet overbodig worden;
- Impliciet terugdringen van technische schuld;
- Impliciete continue procesverbetering;
- Meebewegen van de resourcing van release treinen op een half jaarlijks ritme (mammoet tanker) analoog de product life cycle.
