Scaling agile: zo schaalt u agile op over teams, programma's en portfolio's

1. Wat is scaling agile?

Scrum is ontworpen voor één team van doorgaans tien personen of minder.^[3] Het zegt weinig over wat er gebeurt wanneer dertig teams samen één product moeten uitbrengen. Scaling agile vult dat gat. Het beantwoordt vier vragen die een methode voor één team openlaat:

• Hoe plannen veel teams samen, en hoe vaak?
• Wie bepaalt de prioriteit wanneer teams om dezelfde mensen of systemen concurreren?
• Hoe worden afhankelijkheden tussen teams gevonden en beheerd?
• Hoe sluiten strategie en financiering aan op het werk dat teams doen?

U komt ook de termen agile at scale, scaled agile en enterprise agility tegen. "Scaled Agile" met hoofdletters verwijst meestal naar Scaled Agile, Inc., het bedrijf achter SAFe. Met kleine letters gaat het om de algemene praktijk die deze gids behandelt.

2. Waarom moeten organisaties agile opschalen?

De wet van Conway verklaart waarom dit structureel is en geen kwestie van inzet: "Elke organisatie die een systeem ontwerpt (in de brede zin van het woord) komt tot een ontwerp waarvan de structuur een kopie is van de communicatiestructuur van de organisatie."^[4] Als teams niet kunnen afstemmen, is dat aan het product te zien.

Ook de druk om waarde aan te tonen is toegenomen. In het 18th State of Agile Report van Digital.ai noemt 76% van de respondenten een scherpere blik op de zakelijke impact en ROI van agile, en klanttevredenheid blijft met 52% de belangrijkste maatstaf voor succes.^[5] Met opschalen verbindt het management investeringen aan wat teams opleveren, kwartaal na kwartaal.

Hetzelfde rapport laat zien dat opschalen zelden neerkomt op het ongewijzigd invoeren van één framework: 74% gebruikt inmiddels hybride, gemengde of zelfontwikkelde agile modellen.^[5]

3. Wanneer moet u agile opschalen?

Omvang alleen is niet de aanleiding. Tien onafhankelijke teams met elk een eigen product hebben geen scaling framework nodig. Vier nauw verweven teams misschien wel. Let op deze symptomen:

• Teams ronden hun sprints af, maar features komen toch te laat omdat ze op andere teams wachten.
• Integratieproblemen komen pas aan het einde van een release naar boven in plaats van elke sprint.
• Elk team geeft een ander antwoord op de vraag "wat is dit kwartaal de hoogste prioriteit?"
• Dezelfde mensen zijn aan meerdere teams tegelijk toegezegd.
• Het management vraagt om een statusrapport omdat er geen gedeeld beeld van de voortgang is.
• Er wordt per team gepland, en afhankelijkheden komen pas tijdens de oplevering aan het licht.

4. Hoe begint u met het opschalen van agile?

Er zijn twee klassieke startpunten. Opschalen bottom-up begint bij teams die al goed werken en verbindt ze met elkaar. Het bouwt voort op de echte praktijk, maar loopt vast zonder steun van het management. Opschalen top-down begint met een besluit van de directie. Het gaat sneller, maar mislukt als teams het ervaren als iets wat hun wordt opgelegd. Succesvolle invoeringen combineren beide: het management bepaalt de richting en neemt obstakels weg, en teams geven de manier van werken vorm.

Een praktische volgorde, in lijn met de SAFe Implementation Roadmap^[8]:

1. Benoem het probleem. Spreek af welk bedrijfsresultaat er vandaag onder lijdt. "We willen agile zijn" is geen reden die iemand kan meten.
2. Zorg voor een sponsor met zeggenschap over budget, prioriteiten en structuur.
3. Train eerst de leidinggevenden. Mensen kunnen geen leiding geven aan een manier van werken die ze niet begrijpen.
4. Kies één value stream waar de pijn echt is, de sponsor betrokken is en de teams bereid zijn.
5. Organiseer teams rond waarde, zodat elk team met zo min mogelijk overdrachten kan opleveren.
6. Stel een gedeelde cadans in. Dezelfde iteratielengte en dezelfde startdata voor alle teams.
7. Houd het eerste gezamenlijke planningsevent. In SAFe is dat PI Planning.
8. Voer uit, meet en stuur bij. Houd een Inspect and Adapt aan het einde van het eerste interval.^[9]
9. Lanceer de volgende groep en breid uit naar portfolioniveau zodra er meerdere draaien.

5. Hoe beoordeelt u of u klaar bent voor scaling agile?

Opschalen versterkt wat er al is. Het DORA-onderzoek van 2025 zegt hetzelfde over AI en omschrijft het als "een versterker die de bestaande sterke en zwakke punten van een organisatie uitvergroot."^[10] Een scaling framework gedraagt zich net zo. Het zorgt ervoor dat goede teams beter op elkaar zijn afgestemd en maakt zwakke werkwijzen heel snel zichtbaar.

6. Wat zijn de belangrijkste methoden en frameworks voor scaling agile?

Scaled Agile Framework (SAFe)

SAFe organiseert teams in Agile Release Trains, elk "een langlopend team van agile teams" van doorgaans 50 tot 125 personen^[11], die samen plannen in een Planning Interval van 8 tot 12 weken.^[16] Het kent vier configuraties: Essential, Large Solution, Portfolio en Full SAFe.^[17] Essential SAFe bevat "de minimale elementen die Agile Release Trains nodig hebben om oplossingen op te leveren"^[18] en is waar de meeste organisaties beginnen. Grote oplossingen waarvoor meerdere trains en leveranciers nodig zijn, gebruiken een Solution Train.^[19]

SAFe 6.0 blijft de nieuwste genummerde versie. Scaled Agile werkt het framework nu doorlopend bij en introduceerde in juni 2026 AI-Native SAFe.^[20] Volgens de eigen cijfers zijn er meer dan twee miljoen getrainde professionals.^[21] SAFe past bij organisaties die duidelijke rollen, governance en een verbinding tussen strategie en oplevering nodig hebben. De gebruikelijke kritiek is dat het zwaar is, dus begin met Essential SAFe en voeg alleen toe wat een probleem oplost dat u echt heeft.

Large-Scale Scrum (LeSS)

LeSS past Scrum voor één team toe op veel teams: één product, één Product Owner, één product backlog en één sprint. Basis-LeSS dekt tot acht teams van elk ongeveer acht personen, en LeSS Huge reikt tot een paar duizend mensen aan één product.^[6] LeSS Huge is bedoeld voor invoeringen met meer dan acht teams.^[22] LeSS voegt heel weinig rollen toe en vraagt in plaats daarvan om vereenvoudiging van de organisatie, waardoor het op papier licht is en in de praktijk veeleisend. Lees meer over hoe LeSS werkt.

Scrum@Scale

Scrum@Scale, van Scrum-medebedenker Jeff Sutherland, verbindt teams via een Scrum of Scrums. De gids stelt dat "het optimale aantal teams in een Scrum of Scrums 4 of 5 is"^[13], en grotere organisaties herhalen het patroon als een Scrum of Scrum of Scrums. Het definieert een Scrum Master-cyclus en een Product Owner-cyclus en laat de meeste werkwijzen aan de organisatie over.

Nexus

Nexus, van Scrum.org, is "een groep van ongeveer drie tot negen Scrum-teams die samenwerken om één product op te leveren."^[14] Het voegt een Nexus Integration Team en een beperkt aantal events toe om afhankelijkheden en integratie te beheren. Het is een logische stap voor organisaties die al voor Scrum hebben gekozen.

Disciplined Agile (DA)

Disciplined Agile, nu onderdeel van het Project Management Institute, is een toolkit en geen enkelvoudig proces. Het beschrijft doelen en de opties om die te bereiken, en vraagt teams hun eigen manier van werken te kiezen. Het past bij organisaties met uiteenlopende contexten, bijvoorbeeld een mix van agile, lean en traditionele oplevering. Bekijk ons overzicht van Disciplined Agile Delivery.

Het Spotify-model (squads en tribes)

Het Spotify-model komt uit een paper uit 2012 waarin wordt beschreven hoe Spotify was "opgeschaald naar meer dan 30 teams in 3 steden" met squads, tribes, chapters en guilds, waarbij tribes tot ongeveer 100 personen beperkt bleven.^[15] Het was een beschrijving van één bedrijf op één moment en is nooit als framework gepubliceerd. Neem de ideeën over autonomie en communities of practice over, en verwacht niet dat het u vertelt hoe u over teams heen plant. De belangrijkste elementen bespreken we hier.

Hoe kiest u een scaling framework?

• Veel teams, meerdere producten, sterke governance of regelgeving: SAFe.
• Eén product, tot acht teams, bereidheid tot organisatieverandering: LeSS.
• Scrum is ingeburgerd en u wilt het uitbreiden: Nexus of Scrum@Scale.
• Gemengde opleveringsmethoden in de organisatie: Disciplined Agile.
• Geen enkel framework past: dan hoort u bij de meerderheid. Neem een gedeelde cadans, gezamenlijke planning, zichtbare afhankelijkheden en een vaste review, en bouw van daaruit verder.

Wat u ook kiest, de mechaniek is vergelijkbaar: een vast gezamenlijk planningsevent, een manier om afhankelijkheden te zien, een teamoverstijgende sync en een review van de resultaten. Voor een diepere vergelijking van hoe elk framework plant, bekijkt u het overzicht van agile scaling-modellen en onze vergelijking van scaling-modellen.

7. Wat zijn de voordelen van scaling agile?

• Afstemming. Elk team werkt vanuit dezelfde prioriteiten, die op een vaste cadans worden ververst.
• Voorspelbaarheid. Toegezegde doelstellingen afgezet tegen opgeleverde doelstellingen geven het management een cijfer waarop het kan vertrouwen, interval na interval.
• Minder verrassingen. Afhankelijkheden en risico's worden tijdens de planning besproken, niet tijdens de oplevering ontdekt.
• Snellere besluiten. Afwegingen worden gemaakt door de mensen die over de informatie beschikken, in het planningsevent.
• Betrokkenheid. In het State of SAFe-onderzoek van Scaled Agile uit 2025 onder 1,200 professionals meldde 68% een aanzienlijke of enige stijging van de medewerkerstevredenheid. Dit is het eigen onderzoek van de leverancier.^[23]
• Bedrijfsresultaten. Het rapport van het Business Agility Institute uit 2025 stelde vast dat organisaties die hun volwassenheid in business agility verhoogden een stijging van 10.3% in omzet per medewerker zagen, tegenover 5.1% voor alle organisaties.^[24]

Klanten van Kendis beschrijven dezelfde effecten in de praktijk. KBC stapte in 2018 over op SAFe en gebruikt Kendis voor doelstellingen en risico's, en Electrolux voert PI Planning uit met gedistribueerde teams.

8. Wat zijn de uitdagingen bij scaling agile?

Het 17th State of Agile Report noemt als grootste belemmeringen aan de businesskant weerstand tegen verandering of een cultuurbotsing (47%), onvoldoende deelname van het leiderschap (41%), ontoereikende steun van het management (38%) en businessteams die agile niet begrijpen (37%).^[1]

Onvolledig begrip van het framework

Wie het vocabulaire overneemt zonder de principes, krijgt de meetings en niets van de voordelen. Train leidinggevenden en teams, en coach tijdens de eerste twee planningscycli.

Leiderschap dat sponsort maar niet meedoet

Als leidinggevenden de gezamenlijke planning overslaan of buiten de planning om werk blijven toewijzen, leren teams dat het plan vrijblijvend is. Leidinggevenden moeten in de ruimte aanwezig zijn en daar de afwegingen maken.

Mindset en cultuur veranderen

Opschalen vraagt van managers dat ze overstappen van het aansturen van taken naar het stellen van doelen en het wegnemen van obstakels. Die omslag duurt langer dan welke procesverandering ook en is het punt waarop de meeste invoeringen vastlopen.

Afhankelijkheden tussen teams

Afhankelijkheden zijn op schaal de grootste bron van vertraging. Maak ze zichtbaar tijdens de planning, geef elke afhankelijkheid een eigenaar en een datum, en bespreek ze in elke sync. Zie beheer van afhankelijkheden.

Gedistribueerde en hybride teams

Het meeste kenniswerk is inmiddels hybride. Gallup meldt dat per mei 2026 52% van de Amerikaanse werknemers met een functie die op afstand kan worden uitgevoerd hybride werkt en 26% volledig op afstand.^[25] De richtlijn van SAFe is dat agile teams "nog steeds succesvol kunnen zijn en hoge prestaties kunnen leveren" wanneer de leden niet op dezelfde plek zitten^[26], mits planning, werkafspraken en tooling daarop zijn ingericht. Onze gids voor remote PI Planning legt uit hoe.

Tools die bij het team ophouden

Tools op teamniveau laten een sprint goed zien en een train slecht. Wanneer het teamoverstijgende beeld in spreadsheets staat, is het de dag na de planning al verouderd. Hoofdstuk 11 beschrijft waar u op moet letten.

9. Hoe lang duurt het om agile op te schalen?

Dit zijn schattingen voor uw planning en geen gepubliceerde benchmarks. Wat de doorlooptijd bepaalt:

• Volwassenheid bij de start. Teams die Scrum of Kanban al goed toepassen, schalen veel sneller op.
• Betrokkenheid van het leiderschap. Actieve sponsors verkorten elke stap.
• Architectuur. Nauw verweven systemen betekenen meer afhankelijkheden om te beheren.
• Omvang en regelgeving. Meer teams en meer governance betekenen dat er meer moet veranderen.
• Tooling. Een gedeeld overzicht over teams heen scheelt in elke cyclus weken aan handmatige rapportage.

Denk in planning intervals. Verwacht dat het eerste stroef verloopt, het tweede beter gaat en dat echte voorspelbaarheid vanaf het derde of vierde komt. Opschalen is nooit af. Elk interval eindigt met een review die verandert hoe het volgende verloopt.^[9]

10. Hoe meet u succes bij scaling agile?

SAFe verdeelt meten in resultaten, flow en competentie, en benoemt zes flow metrics: distribution, velocity, time, load, efficiency en predictability.^[2]

Kendis rapporteert deze metrics op basis van live boarddata. Zie flow metrics, program analytics en Inspect and Adapt.

11. Welke tools heeft u nodig om agile op te schalen, en waar moeten de data staan?

Teamtools hebben teamoverstijgende weergaven gekregen, met beperkingen die u moet kennen:

• Jira Plans. Het Program board is alleen beschikbaar in Jira Cloud Premium en Enterprise^[28], en afhankelijkheidslijnen worden voor maximaal tien werkitems tegelijk getoond.^[29]
• Azure DevOps Delivery Plans. Een plan toont maximaal 20 teambacklogs over projecten heen.^[30] Microsoft documenteert hoe u Azure Boards voor SAFe configureert.^[31]
• Jira Data Center. Atlassian heeft het einde van de levensduur van Data Center aangekondigd, waarbij abonnementen en bijbehorende Marketplace-apps op 28 maart 2029 aflopen.^[32] Planningstools die als Data Center-app draaien worden hierdoor geraakt, dus ga na hoe uw scaling tooling wordt geleverd.

Wat een scaling tool u bovenop die weergaven moet bieden: een gedeeld planningsbord, beheerde afhankelijkheden, doelstellingen met bedrijfswaarde, een risicoregister, het volgen van scopewijzigingen en rapportage over voorspelbaarheid, zonder dat teams de tool hoeven te verlaten die ze al gebruiken.

Dataresidentie voor Europese organisaties

Een teamoverstijgend plan bevat uw roadmap, releasedata, bij naam genoemde personen en bekende risico's. Waar het wordt opgeslagen is zowel een juridische als een technische vraag:

• AVG (GDPR). Doorgifte van persoonsgegevens naar buiten de EU is alleen toegestaan onder de voorwaarden van hoofdstuk V.^[33]
• Schrems II. In 2020 verklaarde het Hof van Justitie het EU-VS-privacyschild ongeldig.^[34]
• Data Privacy Framework. De opvolger staat doorgifte toe aan deelnemende Amerikaanse bedrijven^[35] en is in september 2025 door het Gerecht in stand gehouden.^[36] In oktober 2025 is hoger beroep ingesteld bij het Hof van Justitie.^[37]
• DORA. Sinds 17 januari 2025 moeten financiële entiteiten contracten met ICT-dienstverleners hebben waarin staat waar data worden verwerkt en opgeslagen.^[38]
• NIS2. Beveiliging van de toeleveringsketen, inclusief de relaties met dienstverleners, maakt deel uit van de verplichte maatregelen voor risicobeheer.^[39]
• Data Act. Deze verordening is sinds 12 september 2025 van toepassing en bevat regels die overstappen tussen cloudaanbieders eenvoudiger maken.^[40]

Hosting in de EU bij een Europese aanbieder is de eenvoudigste manier om deze vragen buiten uw toolselectie te houden. De Kendis European Cloud draait op OVHcloud in Frankfurt, Duitsland, waarbij projectdata in de EER worden opgeslagen en verwerkt en er geen Amerikaanse cloudaanbieder in de hostingketen zit. Een in de VS gehoste Global Cloud op AWS en een self-hosted optie zijn ook beschikbaar. Kendis is ISO/IEC 27001-gecertificeerd, en voor klanten in de financiële sector is een DORA Schedule beschikbaar. Zie beveiliging en compliance en AVG.