Raamwerken evolueren mee met agile

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