AgilePM in beweging

In de afgelopen 2 jaar is het hard gegaan met AgilePM. Toen ik Foundation deed was handboek 1.0 net vervangen naar 1.1. Met het assessment was handboek 1.1 net een week vervangen door 1.2. De boeken en certificering is in elk geval net zo Agile als de benadering van het model. Dus ja, ‘practice what you preach’.

Maar is het ook een meerwaarde? Wordt het meetbaar beter? De conclusie trekken we graag samen met jou.

In de afgelopen 2 jaar is het hard gegaan met AgilePM. Toen ik Foundation deed was handboek 1.0 net vervangen naar 1.1. Met het assessment was handboek 1.1 net een week vervangen door 1.2. De boeken en certificering is in elk geval net zo Agile als de benadering van het model. Dus ja, ‘practice what you preach’. Maar is het ook een meerwaarde? Wordt het meetbaar beter? De conclusie trekken we graag samen met jou.

AgilePM shifting to 2nd gear

Belangrijkste driver voor de update is dat DSDM, welke als model onder AgilePM ligt, een verandering heeft gekregen. Ze gebruiken zelf ook de ‘inspect and adapt’ manier van werken. Er is onderkend dat naast DSDM v4.2, DSDM Atern nu een meer volwassen DSDM Agile Project Framework moet komen. Dit is nu af. Hierdoor is AgilePM ook aan de beurt om dit mee te nemen en kan PRINCE2 ook haar PRINCE2 Agile straks uitrollen.

We hebben de meest belangrijke wijzigingen en hun impact eens op een rijtje gezet:

Meer ‘to the core’

Wat een heerlijke constatering dat er gekozen is voor een versimpeling van het model. In AgilePM versie 1 werd er in de ontwikkeling steevast een onderscheid gemaakt tussen Exploration en Engineering timeboxen. De essentie was wel dat je zoveel mogelijk doorgroeide naar een samenvoeging tussen deze twee timeboxen. In trainingen kun je er prima voorbeelden aan geven, maar wat is de essentie? Timebox sturing om een oplossing te laten evolueren. Dus hoe je je timeboxen ook wilt noemen, is minder relevant. Wat je maakt is wel relevant en dat is gelukkig nu een heldere essentie. Timebox is een hulpmiddel om de evoluerende ontwikkeling vorm te geven. (kom ik op terug)

Een extra aandachtspunt wil ik geven aan de deployment fase. Dit is nu echt gericht op werkzaamheden die nodig zijn voor het uiteindelijk uitrollen. Dus duidelijkheid over het in elkaar zetten van de oplossing en een helder reviewpoint om vast te stellen of dit goed is gedaan.

Maar niet alleen het procesmodel is aangepast. Ook is er gekozen om informatie meer op basis van ‘groeiende informatie’ te zien. Het outline plan van versie 1 wordt dus nu een Delivery Plan, wat gaandeweg genoeg informatie heeft voor de fase waar we nu in werken. Dus net zo evoluerend als de oplossing, aanpasbaar en schaalbaar.

Meer ‘compatible’ met andere Agile aanpakken

Door aanpassingen in Timebox en iteratieve ontwikkeling is het AgilePM naadloos te combineren met andere Agile aanpakken, zoals Scrum. De Timebox indelingen kunnen nu gestructureerd zijn (de bekende indeling van de Kickoff, Investigate, Refine, Consolidate en Close out) maar ook een vrij format hebben. Met dit vrije format is het gelijk aan de Scrum sprint en kan ook als zodanig worden toegepast.

Daarnaast is er een forse aanpassing gedaan aan het iteratief ontwikkelen. De stappen van Identify, Plan, Evolve en Review zijn aangepast naar de meer pragmatische manier van werken: Thought, Action, Conversation. De Thought geeft aan dat we nadenken over wat nodig is om te doen, Action is het voltooien van werk wat daarbij komt kijken en de Conversation is niet alleen de review of het goed genoeg is, maar als het niet goed klopt vooral het leren doorgronden van wat er nog nodig is om het passender te maken. Oftewel, het wordt weer een heldere principe kwestie, constant en duidelijk communiceren.

Some refurbished parts

In de overview vallen wat wijzigingen op die ogenschijnlijk niet zoveel aanpassingen in denkwijze tot gevolg hebben. In het procesmodel is de rol van de Business Analist veranderd van blauw (waarom was dit eigenlijk blauw, het is geen projectmanagement aspect?) naar de combinatie van oranje (Business interest) en groen (Technical interest) om aan te geven dat hij van deze 2 domeinen afkomstig kan zijn.

Een leuke andere wijziging is in MoSCoW prioritering. Het is in versie 1 een beetje binnengeslopen als vuistregel: 60-20-20. Maar dit was oorspronkelijk niet zo bedoeld. Dus heeft de DSDM Consortium er helderheid aan gegeven. Must have items in het project, increment of timebox mag maximaal 60% zijn, Could have’s zijn normaliter rond de 20% (Contingency) om los te laten als het werk niet realiseerbaar is. Maar als de must have’s 50% zijn, dan kan dit best 30% Should have items zijn. De Must have’s en de Could have’s zijn dus wel formeel vastgezet, met de Should haves kun je dus het gat vullen tussen deze twee.

Een andere aanpassing is de Project Appoach Questionairy, die nu niet ‘slechts’ een assessment is, maar meer tips geeft hoe het project op basis van de uitkomsten op maat gesneden kan worden. Oftewel, welke mate van Agile in dit geval een passende manier van werken is.

Aanvullingen in AgilePM 2.0

Wat AgilePM nu ook doet, is meer instrumenten aanbieden in de technieken die gebruikt kunnen worden. User Stories, al lang bekend bij andere Agile werkvormen, worden nu beter toegelicht. Ook het gebruik van T-shirt planning en Storypoints, zelfs planpoker en meten met velocity wordt meegenomen in de instrumentaria. Uitputtend in technieken? Nee dat niet, maar wel de ‘cherry on the cake’ als het gaat om het afmaken van deze 2.0.

Betere scheiding tussen Foundation en Practitioner

In de guide is een directe scheiding zichtbaar die laat zien wat je voor AgilePM Foundation nodig hebt en welke verdiepingslagen er in de Practitioner inzichten zitten. Dit laat zich niet alleen zien in het handboek, wat duidelijk uit 2 delen bestaat. Maar ook in de examens is dit goed zichtbaar. De practitioner guide wordt echt vanuit Projectmanagement ingestoken, en wordt goed gepositioneerd: Digging Deeper.

En wat mist er dan nog?

Is er dan nog iets wat mist? In mijn ogen is er nog een hoofdstuk wat ontbreekt: hoe om te gaan met projecten waar een groot aantal Solution Development Teams met elkaar samenwerken. Er wordt in de eerste hoofstukken (soort van) naar verwezen maar het komt niet uit de verf. Experts als Keith Richards geven aan dat de Scrum hier onvoldoende voor aan boord heeft (Scrum of Scrums werkt zelden echt goed) en dat er dan meer volwassen projectmanagement nodig is om dit goed te doen. Maar dit had best in een hoofdstukje of bijlage wat meer kunnen worden aangegeven. Maar aan de andere kant, het is denk ik voor ons als trainer erg leuk om te kijken hoe we dit in de trainingen optimaal uitleggen en de relatie met andere modellen gaan optimaliseren.

Conclusie

Overall ben ik erg te spreken over de aanpassingen aan AgilePM. Er is meer structuur dan de oude versie, het is meer in perspectief gezet door een scheiding te maken tussen wat AgilePM is (Foundation) en hoe je er mee werkt (Practitioner). Ook is er meer meegenomen van de technieken die in Agile werkvormen als normaal worden gebruikt. Een waardevolle update waar we weer even mee toe kunnen!

Alle afbeeldingen © APMG International