Development

Raamwerken evolueren mee met agile
Orde in de overvloed aan agile raamwerken.
Orde in de overvloed aan agile raamwerken.
Agile is nu ruim 20 jaar in gebruik bij softwareontwikkelaars. Het gebruik van agile ontwikkelt door en het aantal raamwerken dat het ondersteunt óók. Henny Portman schept wat orde in deze enorme hoeveelheid vaak uiteenlopende raamwerken.
Er zijn naar schatting minstens 100 agile project-, programma- en portfoliomanagementraamwerken. Ik heb de ontwikkeling van agile raamwerken de afgelopen jaren op de voet gevolgd en mijn ‘Bird’s eye view on the agile forest' (zie figuur)[1] opgebouwd en daarbinnen een evolutie van raamwerken onderkend:
- Pilotfase: raamwerken ter ondersteuning van één team.
- Engineering-fase: focus op vaardigheden binnen een team.
- Opschaling naar meerdere teams.
- Opschaling naar organisatie: portfoliomanagementraamwerken.
- Herstelfase: raamwerken met focus op de agile mindset, de agile cultuur.

Figuur 1 Bird’s eye view on the agile forest
Raamwerken ter ondersteuning van één team
Deze pilotfase begon al aan het eind van de 20e eeuw. Het Manifest voor agile softwareontwikkeling, overeengekomen door 17 mensen in Utah (2001), bestaat uit vier waarden en twaalf principes om een antwoord te formuleren op de veel te trage softwareontwikkeling. Het Agile Manifest bracht structuur en is het uitgangspunt voor de meeste agile benaderingen.
Enkele belangrijke kenmerken voor agile manieren van werken die één team ondersteunen zijn:
- Permanent of tijdelijk team.
- De grootte van het team.
- Motivatie van de teamleden.
- Autonomie van het team.
- Wekelijkse of tweewekelijkse oplevering of continue oplevering.
Enkele voorbeelden van raamwerken of methoden die een team ondersteunen zijn: Scrum (timeboxed), Kanban (continue oplevering) en DevOps.
Engineering-fase: focus op vaardigheden binnen een team
Op een bepaald moment werd duidelijk dat deelname van het team aan een Scrum- of Kanban-training niet voldoende was om de gewenste resultaten te bereiken. Dit werd duidelijk gesteld in het Manifest voor Software Craftmanship. Bijvoorbeeld niet alleen werkende software maar ook goed ontworpen en onderhoudbare software.
Om succesvol te zijn moet je een geschikte omgeving hebben, bijvoorbeeld in de cloud met tools als Azure of Amazon Web Services. Je applicatiearchitectuur moet releases of continue oplevering ondersteunen (ooit geprobeerd een gebruikersacceptatietest van drie maanden uit te voeren in een sprint van twee weken?). Dit betekent dat je een continue integratie en continue in productienemen (CI/CD) pijplijn nodig hebt, en/of een microservices architectuur.
Naast de geschikte omgeving moet je teamleden hebben die in die omgeving moeten kunnen werken. Deze teamleden, nu vaak engineers genoemd, moeten beschikken over de juiste ervaring met de ontwikkelomgeving en de vaardigheden om alle ondersteunende tools te gebruiken (bv. GitHub, GitLab, Chef, Jenkins, Argo). Boven op deze omgevingsvaardigheden moeten de teamleden verschillende manieren van werken begrijpen, zoals testgestuurde ontwikkeling (TDD), paarsgewijs programmeren en refactoring.
Opschaling naar meerdere teams
Nu een individueel team de meerwaarde kan aantonen van het gebruik van een agile aanpak zou je de volgende stap kunnen zetten naar opschaling naar meerdere teams. Hier vinden we drie benaderingen.
- Alle teams zijn autonoom.
- Verschillende teams moeten samenwerken om een compleet product of dienst op te leveren.
- Tijdelijke (project)structuur met zowel tijdelijke niet-agile teams als (permanente) agile teams.
Om met het laatste te beginnen. Wat moet je doen als je een initiatief wilt brengen naar een team, maar er is geen team om het initiatief te accepteren, of het team mist de competenties om de verandering door te kunnen voeren? Dan moet je een team bouwen en het team naar het initiatief brengen. En wie kan zo'n team bouwen? Een project- of programmamanager. Veel organisaties maken een overgang naar een agile manier van werken en ontslaan hun project- en programmamanagers. Binnen zes maanden worden er weer project- en/of programmamanagers aangenomen, soms met een andere functietitel, maar die hetzelfde doen.
Enkele voorbeelden van raamwerken of methoden die deze tijdelijke hybride structuur ondersteunen zijn PRINCE2 Agile, AgilePM, AgilePgM, en Disciplined Agile Delivery (DAD).
Het is ook mogelijk dat je meer dan 9 mensen nodig hebt om een product of dienst te ontwikkelen en te onderhouden. In dat geval moet je een team van teams of een keten van teams samenstellen. Maar er is een grens aan hoeveel mensen met elkaar kunnen samenwerken. De Britse antropoloog Robin Dunbar vond een correlatie tussen de hersenomvang van primaten en de gemiddelde sociale groepsgrootte en dat staat bekend als het getal van Dunbar. Het getal van Dunbar is een voorgestelde cognitieve grens aan het aantal mensen (ongeveer 150) waarmee men stabiele sociale relaties kan onderhouden - relaties waarin een individu weet wie elke persoon is en hoe elke persoon zich verhoudt tot elke andere persoon. Agile benaderingen die een team van teams ondersteunen, bieden coördinatiemechanismen tussen de teams en vergemakkelijken het managen van afhankelijkheden. Om integratie van het werk van elk team mogelijk te maken is een cadans en synchronisatie tussen alle teams noodzakelijk.
Betrokkenheid
Verschillen tussen de raamwerken zijn gerelateerd aan de betrokkenheid van alle teamleden zoals wel/niet iedereen aanwezig tijdens tijdens planningssessies, het gebruik van enkelvoudige of meervoudige horizons (bijvoorbeeld SAFe met team- en programma-iteraties versus LeSS of Nexus met een enkele sprint horizon), het gebruik van een enkele of gecascadeerde backlogs (bijvoorbeeld SAFe met epic, feature en story backlogs versus LeSS of Nexus met één backlog en het gebruik van één product owner of hiërarchie van product owners.
Als je meer dan 150 mensen nodig hebt om één product te bouwen en te onderhouden, heb je een structuur van teams van teams van teams nodig. In de medische apparatuurindustrie zijn bijvoorbeeld opstellingen met 30 tot 40 teams die aan één product werken (fysieke onderdelen, hardware, software, commercieel materiaal, ...). Voorbeelden van deze benaderingen zijn SAFe, LeSS Huge, en Nexus+.
In het geval van autonome, onafhankelijke teams is er geen behoefte aan synchronisatie, cadans of het managen van afhankelijkheden tussen de teams. Deze teams kunnen hun eigen manier van werken kiezen en hebben allen hun eigen product owner. Enkele voorbeelden van raamwerken om deze teams te ondersteunen zijn AgileDS en Spotify.
Opschaling naar organisatie: portfoliomanagement
Nu het is opgeschaald naar de teams, is de volgende fase om te kijken wat die teams doen of zouden moeten doen. Je hebt dan agile portfoliomanagementraamwerken nodig om dit proces te faciliteren. Waarschijnlijk ligt een aanpak die zowel permanente agile teams als tijdelijke projecten ondersteunt het meest voor de hand. En bestaande portfoliomanagementkaders of -methoden kunnen dit aan, zolang de horizon waarover toezeggingen worden gedaan niet te lang is (bijvoorbeeld elk kwartaal) zodat op wijzigingen makkelijker kan worden ingespeeld. Aspecten waarop onderscheid wordt gemaakt zijn de wijze van prioritering zoals multicriteria-analyse, MoSCoW, WSJF (relatieve schatting) en het gebruik van een al dan niet op zichzelf staand portfoliomanagementraamwerk. Enkele voorbeelden zijn MoP, AgilePfM, SAFe en Disciplined Agile (DA).
Herstelfase
Agile werkwijzen zijn niet altijd succesvol. 70% van de agile transformaties mislukt. Je vraagt je af: hoe kan het dat het bij de buren wel lijkt te werken? En daarin ligt een deel van het antwoord. Elke organisatie is anders. Wat voor de één werkt, werkt misschien niet voor de ander. Cultuur maakt of breekt je agile transformatie. Of zoals de CEO van Spotify het zegt: "Jullie zijn allemaal welkom om te komen kijken hoe wij werken, maar als je het Spotify-model wilt kopiëren, moet je Spotify worden". Een van de belangrijkste redenen is dat de organisatiecultuur niet aansluit bij de noodzakelijke agile cultuur en mindset. Denk bijvoorbeeld aan de psychologische veiligheid binnen en tussen teams. Kijk naar de besluitvorming. Waar mogelijk moeten teams hun eigen beslissingen kunnen nemen (decentrale besluitvorming). Om een paar onderwerpen te noemen.
De herstelfase ondersteunt de noodzakelijke agile cultuur en benadrukt waar het uiteindelijk om gaat: de samenwerking tussen mensen. Zonder samenwerking is er geen team en dus geen resultaat. Enkele voorbeelden zijn AgileShift (Axelos/PeopleCert) en OpenSpace Agility (OSA) Deze raamwerken staan dus niet op zichzelf maar ondersteunen de hiervoor genoemde raamwerken om binnen je organisatie de juiste agile cultuur en mindset te bewerkstelligen.
Toekomst
"Learn the rules like a pro, so you can break them like an artist"- Pablo Picasso
De komende jaren zullen data, big data, data-analyse en kunstmatige intelligentie steeds belangrijker worden. Ik voorzie een volgende hype met door data en AI gedreven projectmanagement- en oplevermethoden.
Methodenoorlog
Rechtvaardigt deze evolutie het aantal raamwerken? Ik zou zeggen van niet. Ivar Jacobson noemt dit de methodenoorlog. Methoden beschermen hun eigen werkwijzen of aanpakken. Anderen kunnen ze niet 1:1 gebruiken maar herschrijven de werkwijzen om ze binnen de methode te passen. Ze zitten gevangen in hun eigen methode en worden met hand en tand bestreden door een 'goeroe'. Bovendien worden niet alle methoden ondersteund met praktijkcases. Verder denk ik dat commerciële belangen ook een enorme invloed hebben op de ontwikkeling van benaderingen. Een voorbeeld: Ken Swaber en Jeff Sutherland, de grondleggers van Scrum, hebben altijd beweerd dat Scrum voldoende is om producten te bouwen en te onderhouden. Maar, denk ik, beïnvloed door het commerciële succes van SAFe en LeSS, kwamen beiden met hun eigen aanpak met Nexus en S@S, inclusief websites, gidsen, trainingen, certificeringsprogramma's enzovoort.
Bijgaande tabel geeft een eerste indicatie om tot een keuze te komen (waarbij alleen de meest gebruikte raamwerken zijn genoemd):
Teamstructuur |
Raamwerk |
Voor een permanent autonoom team |
Scrum, Kanban |
Voor een tijdelijk project |
AgilePM, PRINCE2 Agile |
Voor een tijdelijk programma |
AgilePgM |
Voor een keten van permanente teams (per kwartaal plannen, meer structuur) |
SAFe |
Voor een keten van permanente teams (per sprint plannen, minder structuur) |
LeSS |
Portfoliomanagement |
SAFe, AgilePfM |
Dit artikel is ook gepubliceerd in het magazine van AG Connect (januari 2023). Wil je alle artikelen uit dit nummer lezen, zie dan de inhoudsopgave.
is eigenaar van Portman PM[O] Consultancy (henny.portman@gmail.com). Hij is auteur van onder andere: Scaling agile in organisaties, en Agile with a smile. Samen met Rini van Solingen werkt Henny momenteel aan een praktijkboek over Agile Portfolio Management dat naar verwachting eind 2022 verschijnt.