Agile Schalingsframeworks

Samenvatting
Zodra organisaties inzien dat agile werkwijzen een enorme impact kunnen hebben op de time-to-market, klanttevredenheid en betrokkenheid van medewerkers, beginnen ze na te denken over het schalen van agiliteit.

Er bestaat een misverstand dat je als grote organisatie een geschaalde aanpak nodig hebt. Dat klopt niet per se, want schalen is in de eerste plaats relevant in gevallen waarin het product te groot is voor een klein team om te ontwikkelen.

Hoe je producten opsplitst en of je wel of niet schaalt, zijn waarschijnlijk belangrijkere vragen dan welk scaling framework je zou moeten kiezen. Helaas stellen te weinig organisaties zichzelf deze vragen – misschien vanwege de grote druk van consultants die scaling frameworks pushen.

Als een organisatie moet schalen, zijn er veel scaling frameworks om uit te kiezen, waaronder SAFe, LeSS, Scrum@Scale en een paar andere. Maar geen van deze frameworks zou "out of the box" toegepast moeten worden.

Wij zijn er sterk van overtuigd dat organisaties zich door deze frameworks moeten laten inspireren, maar in plaats van ze te kopiëren, zouden ze zich moeten laten leiden door een aantal principes, zoals decentralisatie van besluitvorming, Lean Thinking en empirie inclusief continue verbetering.

Om elke vorm van verandering te laten slagen, inclusief het schalen van agile werkwijzen, is het voor leidinggevenden essentieel om hun manier van werken aan te passen. Voor de meesten van hen betekent dit de overstap van werken in de organisatie naar werken aan de organisatie.

De primaire focus ligt op het empoweren (mogelijk maken van beslissingen) en enablen (opbouwen van vaardigheden voor besluitvorming) van teams en individuen. Om dit te laten slagen, moeten managers en leidinggevenden naast de systematische ontwikkeling van hun teams en teamleden ook de structuren, richtlijnen en metrics van hun organisatie gaan veranderen.

Introductie in het opschalen van agile werkwijzen

In bijna elke workshop die ik geef, vragen deelnemers me hoe je Scrum of agile teams kunt opschalen. De reden dat ze dit vragen, is dat er in hun organisaties zelden maar 10 mensen of minder werken – meestal zijn het er veel meer.

Veel van hen komen uit grote bedrijven, of het nu gaat om de financiële sector, de auto-industrie, de farmaceutische industrie of de medische technologie. In veel grote concerns hebben ze grote producten, bijvoorbeeld een auto, waaraan veel – honderden – mensen werken.

In veel grote concerns hebben ze grote producten, zoals een auto, waar veel mensen aan werken — soms wel honderden.

De misvatting daarbij is dat ze denken dat het aantal mensen automatisch leidt tot een geschaalde aanpak. Maar dat klopt niet per se. Een organisatie kan veel mensen en veel teams hebben, maar zolang elk van die teams aan een eigen product werkt, hoeven ze niet per se te schalen — tenminste niet in de traditionele agile betekenis zoals wij de term schaling gebruiken.

Wat betekent agile schaling?

Agile schaling wordt namelijk pas relevant wanneer meer dan één team aan hetzelfde product werkt. Het is de moeite waard om dit nog eens te benadrukken: meerdere teams werken aan hetzelfde product! Om vast te stellen of je een geschaalde aanpak nodig hebt, is het daarom belangrijk om eerst naar je productdefinitie te kijken.

Hoe kun je een product definiëren?

Er zijn veel manieren om hiernaar te kijken. Eén manier is vanuit het klantperspectief. Wat zien mijn klanten als product, oftewel waarvoor zijn ze bereid te betalen, bijvoorbeeld Microsoft Office?

Een ander perspectief is meer intern gericht: wat zijn de verschillende componenten van een product die we grotendeels onafhankelijk kunnen ontwikkelen, bijvoorbeeld Microsoft Excel of functionaliteiten binnen Excel.

Een perspectief dat veel bedrijven hanteren, is geen van beide. Ze kijken eerder naar de verschillende architectonische onderdelen van een product en verdelen de teams daarop. Deze aanpak leidt meestal tot silo's en een hoop afhankelijkheden tussen de teams.

De tweede optie kan in veel gevallen leiden tot veel kleine teams die grotendeels onafhankelijk van elkaar werken, waardoor er geen formele schalingsaanpak nodig is. Maar zelfs als er wel een schalingsaanpak nodig zou zijn, is het veel eenvoudiger om de afzonderlijke teams en het teamoverstijgende werk te coördineren, omdat de productgrenzen duidelijk gedefinieerd zijn.

Hoe schalen we?

Verderop in dit artikel vatten we de meest gangbare schalingsaanpakken samen. Maar voordat we daar aankomen, willen we de vraag beantwoorden hoe we schalen en welke principes ons kunnen helpen om beter te schalen.

Elk agile team, bijvoorbeeld een Scrum-team, heeft drie verschillende verantwoordelijkheden: Wat bouwen we? Hoe bouwen we het (technisch)? Hoe werken we samen (methodiek)? Het grootste verschil tussen de verschillende schalingsaanpakken is of ze de volledige eenheid schalen, dus het Scrum-team met al zijn verantwoordelijkheden, of dat ze alleen de hoe-verantwoordelijkheden schalen.

Dit onderscheid is belangrijk omdat het direct raakt aan een van de belangrijkste agile principes, namelijk het decentraliseren van besluitvorming naar de plek waar het werk en de klantinteractie plaatsvindt. Het is ook belangrijk omdat het bepaalt hoeveel nieuwe rollen er gecreëerd worden en welke rol leiderschap buiten deze teams inneemt.

Welke soorten agile scaling frameworks bestaan er?
Er zijn veel manieren om agile ontwikkeling binnen een organisatie op te schalen. Geen van deze benaderingen dekt volledig af hoe een organisatie gestructureerd zou moeten zijn. Ze dekken meestal alleen de productontwikkelingsafdeling van een organisatie af.

Alle ondersteunende afdelingen binnen een bedrijf, zoals financiën, juridische zaken, HR en inkoop, worden door geen van de scaling frameworks afgedekt. Hoewel sommigen - ook consultants die deze frameworks verkopen - beweren dat dit wel het geval is, is dat in werkelijkheid niet zo.

In het volgende gedeelte willen we je een algemeen overzicht geven van de meest gebruikte scaling frameworks. Maar wees je ervan bewust dat 'meest gebruikt' niet hetzelfde betekent als 'het beste'. Wij zijn er sterk van overtuigd dat elk van deze frameworks een aantal duidelijke voordelen, maar ook aanzienlijke nadelen heeft.

Beter dan slechts één van de frameworks te kopiëren, is het om de kernprincipes van het opschalen van agile ontwikkeling te begrijpen en binnen je organisatie iets te creëren dat zich door regelmatige en frequente inspectie en aanpassing voortdurend doorontwikkelt. Elke organisatie is uniek in haar cultuur en uitdagingen... je manier van werken zou dat moeten weerspiegelen.

Scaled Agile Framework (SAFe)

Het Scaled Agile Framework - ook bekend als SAFe - is waarschijnlijk het best gedocumenteerde agile scaling framework. Het is bedacht door Dean Leffingwell en wordt regelmatig bijgewerkt. De nieuwste versie kun je hier bekijken.

SAFe is waarschijnlijk ook het meest prescriptieve van alle scaling frameworks. Misschien is dat de reden waarom veel grote organisaties hun scaling-reis met SAFe beginnen. Zoals eerder gezegd, betekent dat niet per se dat SAFe het scaling framework van keuze zou moeten zijn. Ik heb eerlijk gezegd nog geen succesvolle SAFe-implementatie gezien.

SAFe hanteert een team-of-teams-perspectief, dat ze de Agile Release Train oftewel ART noemen. Een ART is gebaseerd op meerdere Scrum-, Kanban- of andere agile teams. Op teamniveau zijn er Product Owner, Scrum Master en developers. Op ART-niveau bestaan vergelijkbare rollen genaamd Product Management, Release Train Engineer (RTE) en System Architect/Engineer.

Dit betekent dat SAFe de volledige eenheid van een Scrum Team schaalt, inclusief de what-accountabilities, die dan bij het productmanagement liggen. Dit leidt tot aanzienlijke uitdagingen, omdat een Product Owner in SAFe niet hetzelfde is als een Product Owner in Scrum. De SAFe Product Owner is meestal iemand die de backlog op teamniveau verfijnt - wat je eigenlijk geen Product Backlog meer kunt noemen.

Een van de belangrijkste voordelen van SAFe is dat organisaties doorgaans minder weerstand bieden bij de overstap naar SAFe dan bij elk ander framework - althans, dat is mijn ervaring. Dat kan positief zijn, omdat het ertoe leidt dat organisaties de eerste stap naar verandering zetten. Maar het kan ook negatief zijn als ze denken dat het implementeren van SAFe al het einddoel is.

Een van de belangrijkste dingen om in gedachten te houden is: hoe meer een scaling-aanpak lijkt op je huidige organisatiestructuur, beleid en metrics, hoe minder het tot andere resultaten zal leiden. SAFe implementeren is dus waarschijnlijk makkelijker dan sommige andere frameworks, maar hoogstwaarschijnlijk brengt het je ook niet veel dichter bij het bereiken van je doelen.

Large Scale Scrum (LeSS)

Large Scale Scrum - ook bekend als LeSS - is een andere veelgebruikte schalingsaanpak. LeSS is bedacht door Craig Larman en Bas Vodde. Beiden zijn zeer ervaren personen en systeemdenkers. Beiden zijn ook behoorlijk eigenzinnig.

In vergelijking met SAFe schaalt LeSS alleen de hoe-delen van het Scrum Team, dat wil zeggen de developers en deels de Scrum Master. LeSS creëert in zijn eenvoudigste vorm geen Product Owner hiërarchie. Dat betekent dat een LeSS Product Owner echt een Product Owner (in de zin van Scrum) is en met meerdere teams samenwerkt om de doelen van en voor het product te bereiken.

Op basis van deze definitie heeft een Product Owner in LeSS zeer volwassen teams nodig. Volwassen in hun begrip van de klant, volwassen in hun begrip van hoe je Product Backlog Items opsplitst en volwassen in de nauwe samenwerking met stakeholders.

In vergelijking met een niet-geschaald Scrum Team, waar normaal gesproken één Product Owner het grootste deel van het Product Backlog Refinement, de klantinteractie en het stakeholder management op zich neemt, zou er in LeSS niet genoeg tijd beschikbaar zijn voor één persoon om dit voor al hun teams te doen.

Omdat ik een grote voetbalfan ben, gebruik ik vaak analogieën uit de voetbalwereld als ik met klanten spreek. LeSS implementeren is als spelen in de Champions League. Dat zou niemand moeten doen die niet al een geweldige Scrum-implementatie kan laten zien.

In vergelijking met SAFe neemt LeSS veel van de bureaucratie van grote organisaties en hun vele managementlagen weg. Dat voelt voor veel mensen oncomfortabel als ze er alleen maar naar kijken, laat staan het toepassen.

Een LeSS-implementatie is niet eenvoudig en in vergelijking met wat andere frameworks beweren, vereist LeSS waarschijnlijk de grootste verandering in de manier waarop managers leidinggeven en vereist ook de meeste focus, energie en tijd in de ontwikkeling van mensen. De overstap van componententeams naar featureteams is slechts één van de vele voorbeelden.

Dat betekent niet dat LeSS slecht is. Als ik zou moeten kiezen voor één van deze frameworks voor mijn organisatie of voor mijn klanten, zou het waarschijnlijk LeSS zijn. Maar LeSS heeft ook de meeste betrokkenheid van het topmanagement nodig en de meeste tijd om de teams erop voor te bereiden. Het zal waarschijnlijk ook tot de meest significante resultaten leiden.

Voor productontwikkelingsinitiatieven die meer dan 8 teams vereisen, heeft LeSS een speciale configuratie genaamd LeSS Huge. Het enige verschil is dat LeSS nu ook de Product Owner rol schaalt. Er is nog steeds één Product Owner, maar voor verschillende gebieden zijn er zogenaamde Area Product Owners.

Scrum@Scale

Scrum@Scale is uitgevonden door Dr. Jeff Sutherland, een van de medeoprichters van Scrum. Net als bij SAFe schaalt Scrum@Scale de volledige eenheid van een team, dus zowel het Wat als het Hoe.

De laag boven het Scrum Team heeft een Chief Product Owner en een Scrum of Scrums Master. Er is een Product Owner-cyclus die leidt naar het Executive Meta Scrum (EMS) en een Scrum Master-cyclus die leidt naar het Executive Action Team (EAT).

Net als LeSS hecht Scrum@Scale veel waarde aan het decentraliseren van de besluitvorming naar de teams. Jeff Sutherland zelf is een groot voorstander van het idee dat de Product Owner verantwoordelijk is voor het creëren van waarde voor de klant en niet slechts iemand die aan een Backlog werkt.

De Scrum@Scale Guide documenteert vrij goed hoe het framework in de basis werkt. Af en toe wordt het wat cryptisch, maar de essentie is dat Scrum@Scale een fractale aanpak is voor het schalen van werkende Scrum Teams. Daarom zou het ook niet het startpunt voor elk bedrijf moeten zijn. Eigenlijk kun je dat over alle schalingsframeworks zeggen.

Nexus

Nexus is ontwikkeld door de andere medebedenker van Scrum, Ken Schwaber. Als framework lijkt het erg op LeSS, hoewel er één duidelijk verschil is, namelijk het Nexus Integration Team. Verder schaalt Nexus – net als LeSS – in de eerste plaats de Hoe-verantwoordelijkheden en houdt het vast aan één enkele Product Owner. Meer over Nexus kun je hier lezen.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery – ook wel bekend als DAD – is uitgevonden door Scott Ambler en Mark Lines. Ik ben geen expert op het gebied van DAD en heb – hoewel ik met veel organisaties samenwerk – nog nooit gezien dat het in de praktijk wordt toegepast. Dat wil niet zeggen dat DAD niet wordt gebruikt en niet werkt, alleen dat ik het niet heb gezien. Je kunt hier meer erover lezen.

Spotify-model

Dit is een interessant model. De belangrijkste mensen achter het Spotify-model – een van hen is mijn vriend Henrik Kniberg – zeggen dat er niet zoiets bestaat als het Spotify-model. Toch verkopen veel van de grote adviesbureaus dit aan hun klanten. Ze praten over Tribes, Squads en Guilds, terwijl de meesten van hen (eigenlijk allemaal) nog nooit een voet bij Spotify hebben gezet om te zien of en hoe dit "model" werkt.

Het Spotify-model klinkt leuk en cool, Spotify is tenslotte een leuk en cool bedrijf. Maar past dit model van een Scandinavische muziekstreaming-startup – zelfs als het zou bestaan – werkelijk bij een Duits telecombedrijf, een Zwitsers farmaconcern of een Amerikaanse verzekeraar? Persoonlijk betwijfel ik dat sterk.

Gelukkig beweert niemand bij Spotify dat dit model universeel toepasbaar is... eigenlijk beweren ze niet eens dat het binnen Spotify werkt. Als je goed luistert naar wat Henrik in zijn video's vertelt over de ontwikkelaarscultuur bij Spotify, hoor je hem zeggen dat het allemaal geweldig klinkt, maar dat er nog steeds een hoop problemen bij Spotify zijn en dat ze continu werken aan het verbeteren van hun manier van werken. Er is dus niet hét model bij Spotify... er zijn alleen momentopnames.

Hoe kun je je organisatie agile opschalen?

Wanneer we met organisaties werken, is ons doel om hen te helpen begrijpen dat ze weliswaar veel inzichten en inspiratie kunnen halen uit verschillende scaling frameworks, maar dat het belangrijkste is om een aantal fundamentele principes van het opschalen van agile productontwikkeling te begrijpen en vervolgens de organisatie voortdurend in de richting van deze principes door te ontwikkelen.

Enkele van de belangrijkste principes die we bekijken zijn de volgende:
Schaal niet op als het niet hoeft – dat wil zeggen: voordat je over opschaling nadenkt, kijk eerst of je je product zo kunt opsplitsen dat kleine eenheden er onafhankelijk aan kunnen werken, waardoor opschaling overbodig wordt
Elk team en het team-van-teams zijn zo opgesteld dat ze idealiter klantwaarde leveren en klantgericht zijn
Lean Thinking toepassen, oftewel verspilling verminderen door het beperken van work-in-progress, rigoureus prototypen (Discovery) en frequente klantfeedback
Continue verbetering van de werkwijze door regelmatige en frequente team- en teamoverstijgende retrospective meetings
Decentraliseer de besluitvorming zo veel mogelijk door duidelijkheid te creëren en competenties binnen de teams te ontwikkelen
Omarm de onzekerheid en creëer een empirische mindset, zowel voor wát er gebouwd wordt als voor hóe het gebouwd wordt

Deze lijst is verre van volledig. Maar als een organisatie en haar leiderschapsteam deze principes ter harte nemen, hebben we gezien dat ze de organisatorische wendbaarheid, de klanttevredenheid én de betrokkenheid van medewerkers enorm verbeteren.

Wat moeten leidinggevenden weten over agile opschaling?

In te veel gevallen heb ik meegemaakt dat leidinggevenden geloven dat ze niet meer nodig zijn zodra een organisatie richting agility beweegt. Dit is een van de redenen waarom veel leidinggevenden zich verzetten tegen organisatorische veranderingsinitiatieven – de angst om hun status of zelfs hun baan te verliezen.

Ik geloof dat geen enkele organisatorische verandering zal plaatsvinden zonder het management, zowel het top- als het middenmanagement. Deze groepen zijn degenen die áán de organisatie werken, in tegenstelling tot alle anderen die voornamelijk ín de organisatie werken.

De organisatie zelf is als een product. Ze moet ontwikkeld worden. En gezien de snel veranderende omgeving voor de meeste bedrijven, is het mijn vaste overtuiging dat elk bedrijf – net als de meeste producten – een work in progress is, oftewel continu verbeterd moet worden. Dit is de taak van managers/leiders binnen de organisaties.

Voor de meeste leiders betekent dit dat hun werk aanzienlijk verandert. Voor degenen die hun teams tot nu toe micromanageden, betekent het dat ze de teams moeten empoweren en in staat stellen om steeds meer beslissingen zelf te nemen. Voor degenen die direct betrokken waren bij productbeslissingen, betekent het dat ze moeten kiezen of ze in een productgerichte rol willen blijven of willen overstappen naar een rol in organisatieontwikkeling. In elk geval moeten de meeste managers/leidinggevenden aanpassen wát ze doen en hóe ze het doen – de meesten moeten een persoonlijke agile leader journey doorlopen.

Op basis van onze ervaring is het echt nuttig om een model te hebben dat je helpt om je persoonlijke reis systematisch te structureren en stap voor stap te doorlopen met behulp van een geweldige coach. Als je meer wilt weten over hoe dat werkt, bekijk dan onze certified Agile Leadership Trainings.