Is Agile nog Agile als je het opschaalt?

By: Dennis van der Spoel

​Wie meer met dan 80 mensen aan een product werkt, komt niet weg met alleen Scrum als leidraad voor agile werken. Gelukkig zijn er diverse raamwerken bedacht om het agile gedachtengoed ook werkbaar te maken in grotere bedrijven. Soms worden er kleine concessies gedaan aan de autonomie van individuen omwille van de coördinatie. Dat heeft ertoe geleid dat er discussies zijn over wat nog agile is en welk raamwerk dat predicaat niet meer zou mogen dragen. Het raamwerk dat het populairst is en tevens het meest onder vuur ligt is het Scaled Agile Framework® (SAFe). Is dat terecht?
 
Als we kijken naar raamwerken als Nexus, LeSS en vooral SAFe, dan richt de kritiek zich vooral op het vermeende gebrek aan ruimte voor mensen om hun eigen werkwijze te vinden en op het vermeende gebrek aan simpliciteit. Dat hebben die raamwerken zelf veroorzaakt. Zo bestaat de SAFe Reference Guide uit 800 pagina’s, waar Scrum past op welgeteld 17 kantjes.
 
Op het eerste gezicht is SAFe dus 40 keer complexer dan Scrum. Maar dat is niet het hele verhaal. Juist het gebrek aan ‘guidance’ remt de adoptie van Scrum (en dus agile) door grotere organisaties. Scrum biedt niet overal een oplossing voor. Het idee is dat Scrum teams zelf een optimale manier van werken ontdekken. Met een enkel team gaat dat goed. Met twee of drie teams gaat dat ook vaak prima. Zodra je echt gaat schalen, werkt die samenwerking tussen teams echter niet meer. Daar verdienen adviseurs en coaches als ondergetekende dan weer goed aan, maar dat kan niet de bedoeling zijn.
 
Vergeef mij de omweg die ik nu ga maken in mijn betoog. Aan het eind van dit artikel kom ik terug op de kritiek op de belangrijkste agile raamwerken in het algemeen en SAFe in het bijzonder.

Blends

​In de praktijk zag ik vaak dat alleen software-ontwikkelteams agile werken aanvaarden en dat organisaties behoefte hebben aan overkoepelende coördinatie en financieel georiënteerde rapportage.
 
Een praktische tussenoplossing ontstond in de vorm van een mix tussen traditionele methoden om projecten te besturen en agile werken binnen de teams. Een bekende blend, die ik ook zelf vaak met succes heb toegepast, is PRINCE2 met Scrum teams. Tegenwoordig is er zelfs een aparte PRINCE2 Agile waarin deze manier van werken is gedocumenteerd. Het komt erop neer dat men de PRINCE2-rollen ‘Wijzigingsautoriteit’ en ‘Teamleider’ vervangt door de respectievelijk de Scrum-rollen ‘Product Owner’ en ‘Scrum Master’. Later wordt ook de rol van Senior User door de Product Owner ingevuld, en de rol van Senior Supplier door het scrumteam, inclusief de Scrum Master. We moeten dan wel zeker stellen dat mensen die deze rollen invullen over de noodzakelijke mindset en competenties beschikken. Verder zegt PRINCE2 niets over hoe een team moet werken, dus Scrum is ook in PRINCE2 volledig acceptabel. En voilà, de eerste stap op weg naar agile werken is gezet.
 
Agilisten zetten PRINCE2 vaak weg als een waterval-methode, maar dat is niet terecht. PRINCE2 is in principe zeer agile, ze wordt echter vaak verkeerd toegepast door organisaties die op een waterval-wijze werken. Dat noemen we dan PINO; PRINCE2 In Name Only.
 
Scrum kan in combinatie met een juiste opvatting van PRINCE2, eventueel aangevuld met MSP (Managing Succesful Programmes) en MoP (Management of Portfolios), een uitstekende tussenstap zijn om grotere organisaties kennis te laten maken met agile binnen een structuur die zij grotendeels herkennen en die nog enigszins intuïtief aanvoelt. Een alternatief wat ik ook vaak heb beproefd is AgilePM, eventueel aangevuld met AgilePgM en Agile PfM. Dit zijn op DSDM gebaseerde frameworks van het Agile Business Consortium die in hoge mate overeenkomen met de zojuist besproken tegenhangers.
 
Met beide tussenoplossingen loop je vroeg of laat tegen grenzen aan. Zolang je uitgaat van unieke opgaven (projecten en programma’s) is alles tijdelijk. Daarmee zijn ook de teams die aan die projecten werken van tijdelijke aard. Dat wordt vroeg of laat een probleem. Teams met een redelijk stabiele samenstelling raken op den duur steeds beter op elkaar ingespeeld. Als je ze dan uit elkaar haalt op het moment dat hun prestatieniveau het hoogst is, heeft dat rampzalige gevolgen voor de organisatie. Het wordt lastiger om medewerkers te motiveren en binden. Bovendien is er altijd de verleiding om medewerkers allerlei taken naast hun werk voor het project toe te delen. Sterker, vaak blijkt het projectwerk een nevenactiviteit naast het reguliere werk te zijn. Dat is fnuikend voor de productiviteit. Dus op enig moment is er de behoefte om de organisatie te kantelen en producten routinematig te laten ontwikkelen door multidisciplinaire teams in een vaste samenstelling. Verandering wordt business as usual en projecten en programma’s zijn verleden tijd.

Permanent veranderraamwerk ​

​Daarmee ontstaat de behoefte aan een permanent veranderraamwerk voor de organisaties die nog weinig ervaring hebben met agile. Ziedaar de groeiende populariteit van raamwerken als Nexus, LeSS, SAFe en Spotify. Mensen die thuis zijn in de materie zien vooral de overeenkomsten tussen deze raamwerken. Mensen die meer op afstand staan raken in verwarring doordat elk raamwerk een andere invalshoek kiest en ander jargon hanteert. De kern van elk raamwerk wordt overwegend gevormd door het Agile Manifesto en de Scrum Guide. Om de coördinatie over meerdere teams te voeren wordt meestal gebruik gemaakt van een of meer extra coördinatie-lagen waarin geselecteerde mensen uit de laag eronder, of mensen die apart zijn belast met deze coördinatietaken, volgens dezelfde agile principes hun coördinerende werk doen. Een soort scrumteam voor scrumteams dus.
 
Op elk niveau is er een afgeleide rol van de ‘product owner’, die het werk prioriteert. Ook is er op elk niveau een ‘scrum master’, die de werkwijze bewaakt, aandachtspunten agendeert en de bijeenkomsten faciliteert. Daarnaast zijn er natuurlijk de mensen die het werk voor dat niveau uitvoeren.
 
In de basis is het dus makkelijk om agile op deze manier schaalbaar te maken en dit principe kom je dan ook bij meerdere raamwerken tegen. De meeste organisaties hebben voldoende aan twee of drie niveaus van een raamwerk. Zelden zie ik organisaties die de meest uitgebreide variant nodig hebben.

Onderlinge afstemming

​De misvatting die ik soms tegenkom is dat er top-down regie wordt gevoerd over wat er geproduceerd wordt. Het is waar dat er een zekere mate van alignment plaatsvindt, maar die wordt niet opgedrongen. Elk niveau geeft op gezette tijden aan het onderliggende niveau een geprioriteerde wensenlijst door, maar is zich ervan bewust dat dit slechts een deel van het werkaanbod betreft dat door het onderliggende niveau aan hun werkvoorraad wordt toegevoegd. Prikkels tot verandering komen uit alle geledingen van de organisatie en daarbuiten. Lokaal wordt zelfstandig de uiteindelijke prioriteit bepaald op basis van beschikbare informatie. Daarbij staat het organisatiebelang voorop. Het is logisch dat de bedrijfsleiding inspraak wil in de prioriteitstelling, maar het is de bedoeling dat dit gebeurd door voortdurend de productvisie en strategische intenties onder de aandacht te brengen en niet door besluiten te nemen die beter lager in de organisatie kunnen worden genomen.
 
Wanneer je met heel veel mensen aan iets werkt is er ook een zekere mate van onderlinge afstemming nodig. Sommige raamwerken kiezen voor vaste momenten waarop die afstemming plaatsvindt. Hierdoor ontstaat een vast ritme, waaraan alle teams zich conformeren. Bij agilisten wil dit nog wel eens op weerstand stuiten, omdat het voor onafhankelijke teams gebruikelijk is dat zij hun eigen werkwijze en ritme bepalen. Wanneer je echter met meerdere teams aan iets werkt, is het handiger om synchroon te lopen. Zo kan na elke iteratie het geïntegreerde product getest en gedemonstreerd kan worden. Dat is met name van belang wanneer er naast softwareteams ook hardwareteams aan het product werken. Binnen die cadans zijn teams volkomen vrij om hun eigen agile werkwijze te kiezen. Het maakt over het algemeen niet uit of ontwikkelteams werken op basis van Scrum, Kanban of wat anders. Alleen de integratiepunten en gezamenlijke planningsmomenten staan vast.

“Welk raamwerk moet ik kiezen?”

​“Waarom zijn er zoveel verschillende raamwerken om agile werken schaalbaar te maken?” Dit is een vraag die ik vaak krijg, gevolgd door “en welke moet ik kiezen?”
 
Ooit ontbrak het aan een goed raamwerk. Verschillende teams wereldwijd zijn het wiel in de praktijk gaan uitvinden. Elke groep documenteerde de eigen best-practices en wil nu hun ontdekking te gelde maken. Daarbij proberen ze elkaar ondertussen in kwaad daglicht te stellen.
 
Welk raamwerk je moet kiezen, hangt af van je situatie. Agile puristen vinden vaak dat je zelf je werkwijze moet vinden en ontwikkelen, en dus weg moet blijven van deze raamwerken. Mijn antwoord is dat het niet zo veel uitmaakt, al heb ik een lichte voorkeur voor SAFe. Ik ben het deels met de puristen eens. Een raamwerk is een basis van waaruit je iteratief je eigen werkwijze verder kunt ontwikkelen. Het voorkomt dat je zelf de weg moet gaan die de eerste pioniers, die soms jarenlang hebben geëxperimenteerd, hebben afgelegd. Met een raamwerk kun je die achterstand sneller inlopen. Maar zie het nooit als doel of eindstation. Het is hoogstens een basisstation aan de voet van de berg.

SAFe ​

​Waarom spreek ik een lichte voorkeur uit voor SAFe? Ik vind het belangrijk dat een raamwerk genoeg houvast biedt voor mijn opdrachtgevers. Een agile transitie is al lastig genoeg. Het ene raamwerk is wat uitgebreider dan het andere, en het ene raamwerk is praktischer of organischer dan het andere. Veel randvoorwaarden voor agile werken, zoals DevOps en Continuous Delivery, zijn al in het SAFe raamwerk opgenomen. Dat geldt ook voor een aantal XP practices voor software-ontwikkeling. Een purist zegt dat het voorschrijven van werkwijzen niet agile is. Mijn stelling is dat het een prima vertrekpunt biedt om die eigen werkwijze te ontwikkelen. Zonder geautomatiseerd testen en deployen word je niet agile, dus waarom dat niet gewoon meenemen?
 
Wat SAFe verder voor heeft op andere raamwerken zijn de terugkerende grootschalige tweedaagse planningsbijeenkomsten. Dat stuit in eerste instantie vaak op veel weerstand. Waarom elk kwartaal met zo veel mensen plannen en afstemmen? Kan dat niet efficiënter? In mijn ervaring is zo’n gezamenlijke afstemming vele malen effectiever dan afstemming via afvaardiging. Er komt veel energie los en iedereen krijgt dezelfde informatie uit eerste hand. Vragen worden direct beantwoord en de wijsheid van de hele groep wordt aangewend om knelpunten ter plekke op te lossen en afhankelijkheden te onderzoeken. Bovendien krijgt iedereen de gelegenheid om aan te geven hoeveel vertrouwen men heeft in de haalbaarheid van de doelen voor de komende periode.
 
Bij afstemming door afvaardiging, waar veel raamwerken voor kiezen, zie ik vaak dat de afgezanten na de planning nog weken tussen teams laveren om zaken te verduidelijken en afstemming te zoeken. Ook voelen teamleden zich niet altijd eigenaar van een planning waartoe zij door een ander zijn verplicht. Dat komt de productiviteit niet ten goede.

Raamwerk als doel of als opstapje

Uiteindelijk staat niets je in de weg om te beginnen met een willekeurig raamwerk en daaruit je eigen weg te vinden. Daarbij is de context ook belangrijk voor de keuze. Kijk vanuit welke achtergrond een raamwerk is ontwikkeld. Zo zou ik voor het ontwikkelen van een nieuwe mobiele app eerder kiezen voor het Spotify-model dan voor SAFe.
 
“Is het niet heel ingewikkeld om een raamwerk te leren gebruiken?” Nee, dat valt reuze mee. Zelfs een uitgebreid raamwerk als SAFe houdt het bij twee dagen training. Wel is de timing van de training en begeleiding door ervaren coaches en adviseurs de eerste periode cruciaal. Verder is het van belang dat het hogere management actief participeert in de cultuurverandering. Ja, we starten een cultuurverandering. Door de nieuwe werkwijze eindeloos en consistent te repeteren ontstaan nieuwe gewoontes en nieuw gedrag, en daarmee een nieuwe cultuur. Dat stuit in het begin op veel weerstand.
 
Dan kom ik nu terug op de vraag of agile nog agile is als je het opschaalt. Dat hangt ervan af. Als je het raamwerk ziet als doel en het dogmatisch invoert, dan is dat strijdig met de agile-filosofie. Zie je het raamwerk als een opstapje aan het begin van je ontdekkingsreis, dan zeker wel.

​Tot slot

Dit artikel verscheen eerder in druk in ‘Projectie’, vakblad voor projectmanagement van ipma-nl en online op issuu.com met de tags IPMA Nederland - Vakblad Projectie #5 / 22 oktober, 2018. Zie hieronder.
 
Een Engelse vertaling vindt u hier.
 
Dennis van der Spoel Consulting helpt organisaties wendbaarder te worden zonder met alle winden mee te waaien. Ons adviesbureau specialiseert zich vooral in de transitie naar een moderne manier van werken met respect voor de bestaande praktijk. Richt uw vragen aan ons via het contactformulier op deze website.