1. Januari 2016
Scaling the agile
organization

2. Whitepaper januari 2016 • VODW2
Colofon
Dit is een uitgave van VODW.
Heeft u nog vragen of behoefte aan een nadere toelichting op dit document? Neem dan contact
op met Michael Klazema van VODW via mklazema@vodw.com of +31 33 432 64 12. De inhoud van
dit document mag niet voor andere doeleinden worden gebruikt, hergebruikt of worden verspreid
zonder toestemming van VODW.
© Copyright VODW 2016

3. Scaling the agile organization Whitepaper januari 2016 • VODW 3
Inhoudsopgave
4 Van scrumteam naar agile op schaal
5 De juiste werkvorm selecteren
7 Scrum of Scrums
12 Large Scale Scrum (LeSS)
15 Het Spotify model
19 Scaled Agile Framework (SAFe)
24 Hybride vormen van waterval en agile
26 Conclusie
27 Begrippenlijst

4. Whitepaper januari 2016 • VODW4
Agile werken in scrumteams groeide in de afgelopen jaren uit tot een
ware hype. In vrijwel iedere organisatie ontstaan kleinschalige teams
die los van de bestaande processen opereren en in korte iteraties
snel successen laten zien. Een logische stap is om daarna met meer
teams op een agile manier te gaan werken. Dit vindt vaak eerst
plaats binnen de IT-organisatie, maar in de afgelopen jaren zijn de
agile principes ook goed toegepast binnen de marketingorganisatie.
Afhankelijk van de organisatieomvang ontstaat bij een groeiend
aantal agile teams vaak ook de behoefte of noodzaak de
werkzaamheden tussen deze agile teams te coördineren. Dit hele
proces noemen we ‘scaling agile’: het op grote schaal toepassen van
agile principes in een organisatie.
Als je agile principes op grote schaal - met meer dan een paar
teams - wilt toepassen, levert dit verschillende uitdagingen op.
De scrummethodiek, die door veel bedrijven wordt gebruikt om te
experimenteren, biedt geen houvast zodra verschillende teams naast
elkaar werken aan hetzelfde eindproduct. Door een gebrek aan
overkoepelende coördinatie en overleg, ontstaat er al snel frustratie
en inefficiëntie.
Bedrijven moeten dus op zoek naar een framework om agile op te
schalen. Van dit soort frameworks lijkt er iedere dag weer één bij te
komen. Een aanpak zoals die van Spotify, initieel niet eens bedoeld
als model, gaat door de grote media-aandacht een eigen leven
leiden. Daarnaast zijn veel agile coaches of organisatieadviseurs
slechts gespecialiseerd in één model. Meer begrip van de
mogelijkheden om agile op te schalen zorgt dat je als organisatie de
goede keuze maakt.
Van scrumteam
naar agile op schaal

5. Scaling the agile organization Whitepaper januari 2016 • VODW 5
Een weloverwogen keuze begint bij het beantwoorden van een aantal
kernvragen die je een idee geven van welk type werkvorm het best
bij jouw organisatie past. Vervolgens is begrip van de verschillende
stromingen en een kritische analyse van best practices nodig.
In deze whitepaper bespreken we een aantal werkvormen. Deze
frameworks vertegenwoordigen de uitersten van alle frameworks om
agile op te schalen. Door naar de uitersten te kijken is het makkelijker
de verschillen in aanpak te beschrijven.
• Scrum of Scrums.
• Large Scale Scrum (LeSS).
• Scaled Agile Framework (SAFe).
• Het Spotify model.
• Hybride vormen van Waterval en Agile.
Handvatten bij de selectie van het juiste framework
Niet ieder framework is geschikt voor iedere organisatie. Voordat we ingaan op de sterke en
zwakke punten van de verschillende frameworks, is het belangrijk te ontdekken aan wat voor type
framework de organisatie behoefte heeft. Sommige methoden zijn namelijk bij uitstek geschikt
voor grote organisaties, terwijl je andere juist beter in kleinschalige ondernemingen kunt gebruiken.
Daarnaast richt het ene framework zich meer op principes, terwijl het andere een volledige blueprint
voorlegt en de werkwijze tot in detail beschrijft.
Ondanks deze verschillende aanpakken is het wel mogelijk de frameworks op een aantal aspecten
met elkaar te vergelijken. Onder andere Ebba Kraemer van Hansoft ontwikkelde hiervoor een
model, waarvan de basis bestaat uit een aantal kernvragen.
Zijn er veel afhankelijkheden tussen de ontwikkelteams
(intradependencies)?
Sommige teams zijn bijvoorbeeld afhankelijk van elkaar voor de release van nieuwe concepten of
aanpassingen, terwijl andere onafhankelijk van elkaar een release in gang kunnen zetten.
Zijn er veel afhankelijkheden tussen de ontwikkelteams en de rest
van de organisatie (interdependencies)?
Soms zijn teams sterk afhankelijk van de projecten en tijdlijnen van andere delen van de organisatie,
bij weinig afhankelijkheden werken zij vaak los van bestaande processen.
De juiste
werkvorm selecteren

6. In welke mate is het noodzakelijk dat de ontwikkelteams zelf een
hoge mate van creativiteit toevoegen aan de oplossing(en)?
Dit heeft betrekking op de vrijheid en verantwoordelijkheid die het ontwikkelteam krijgt.
Naast deze drie aspecten zien we ook grote verschillen in de mate waarin het framework
goed past binnen zeer grote organisaties, zoals banken, verzekeraars, energiebedrijven en
telecomproviders. Sommige modellen geven wel antwoord op de vraag hoe een aantal teams
samen kunnen werken als ze aan één product werken, maar bieden geen houvast als een
organisatie gelijktijdig in meerdere markten actief is met een groot aantal producten of diensten.
Tot slot is ook de complexiteit van het product bepalend voor het framework. Soms zijn bepaalde
kernproducten of -diensten heel complex of juist niet; de organisatievorm zou zich daarbij aan
moeten sluiten.
Er ontwikkelen zich continu nieuwe frameworks om agile op te schalen. Dit maakt het lastig een
goede vergelijking te kunnen maken. We analyseren een aantal bekende frameworks op de
volgende onderdelen:
• Belangrijkste doel.
• Kerncomponenten en -proces(sen).
• Hoe scoort het framework op de criteria intradepencies, interdependencies, benodigde
creatieve input, organisatiegrootte en complexiteit van het product.
• Zeer geschikt voor situaties waarin…
• Minder geschikt voor situaties waarin…
Whitepaper januari 2016 • VODW6

7. Waterval
Plan Driven
Agile
Value Vision Driven
Scope
ScopeCost
Cost
Time
Time
7Whitepaper januari 2016 • VODWScaling the agile organization
Scrum is de meest gebruikte methodiek voor individuele teams in
agile georiënteerde ontwikkelorganisaties. Als meerdere teams
in dezelfde organisatie scrum gaan gebruiken en deze teams
groter worden dan negen personen, moeten ze worden gesplitst in
meerdere scrumteams. Een logische stap is om zaken tussen de
teams te coördineren. Een Scrum of Scrums is dan vaak de meest
logische keuze: een dagelijkse of wekelijkse meeting waarin de team
‘leads’ van de verschillende scrumteams werkzaamheden met elkaar
afstemmen.
Wat is scrum?
Scrum is een van de meest gebruikte methodes waarmee je agile principes kunt toepassen in de
projecten waaraan je werkt. Scrummen is werken in kleine team s van drie tot negen mensen, die met
verschillende vaardigheden in korte periodes steeds nieuwe werkende tussenproducten afleveren en
daar feedback op organiseren, tot je samen met de klant opgewekt beslist dat je bij het eindproduct
bent (NRC Handelsblad, 2015).
In tegenstelling tot de watervalmethode staan bij scrum de hoeveelheid tijd en het budget vast, maar
is de scope (uitkomst) variabel. Scrum focust zich op het creëren van waarde in kleine stappen en
brokken, waarbij voor de efficiëntie van het team geen veranderingen plaatsvinden in het doel van een
sprint als deze eenmaal begonnen is.
Analyse van vijf frameworks
1. Scrum of Scrums

8. Product
Backlog
Refinement
Product
Backlog
Sprint
Backlog
SPRINT
1-4 weeks
No Changes
in duration of goal
Input from
end-users,
customers,
team and
other
stakeholders
Product
Owner
Sprint planning
meeting.
Team selects
how much to
commit to do by
sprint’s end
Team
Review with Product Owner
Retrospective
Potentially
Shippable
Product
Increment
Scrum Master
manages sprint
progress
Daily
Scrum
Standup
Whitepaper januari 2016 • VODW8
Kerncomponenten en processen
Er zijn een aantal essentiële personen en componenten in het scrumproces. Voordat teams beginnen
met scrummen worden het doel en de bijbehorende randvoorwaarden bepaald waar het eindproduct
aan moet voldoen. Het scrumteam moet bestaan uit mensen met verschillende expertises zoals
marketeers, IT’ers, analisten en UX-designers; afhankelijk van de expertise die nodig is om het doel
van het team te behalen. De product owner is verantwoordelijk voor wat het team doet. Hij beheert
de takenlijst (backlog) en stelt per sprint de prioriteiten in een sprintplanning. Een sprint is een korte
periode van ongeveer één tot vier weken, waarin het team naar een concreet, vooraf gedefinieerd
resultaat of tussenproduct werkt.
De scrummaster zorgt dat iedereen de manier van werken begrijpt en omarmt. Zijn taak is
ondersteunend en niet sturend zoals een manager. De scrummaster helpt bijvoorbeeld bij het
oplossen van blokkades die zorgen dat een teamlid niet productief is en maakt hier eventueel een lijst

9. Scaling the agile organization Whitepaper januari 2016 • VODW 9
van (impediment list). Deze blokkades worden bespreekbaar gemaakt in een (daily) standup. Dit is een
korte bijeenkomst, waarbij ieder teamlid aangeeft welke taken hij (die dag) gaat uitvoeren en wat zijn
blokkades zijn.
De status van de taken die de teamleden tijdens een sprint uitvoeren staat op het scrumboard. Voordat
iemand aan een taak begint, moet duidelijk zijn wat de taak inhoudt. Het scrumteam controleert de
taken hierop en scherpt ze aan. Dit noemen we een product backlog refinement. Na het uitvoeren
van de taak is er een verschil tussen ready en done. Een taak is ready als deze helder, uitvoerbaar
en testbaar is en done als deze getest is en goedgekeurd door de product owner. Alle taken die nog
moeten worden uitgevoerd voordat het eindproduct klaar is, staan op de product backlog.
De burndown chart geeft visueel aan hoeveel tijd er nog over is, afgezet tegen het werk dat nog
gedaan moet worden. Het eindproduct noemen we ook wel Potentially Shippable Product Increment.
Dit moet een zichtbare, concrete verbetering van een product of dienst zijn. Het lanceren van
‘tussenproducten’ noemen we een (product) release. Na iedere release vindt er een feedbackmoment
plaats, ook wel de sprint review genoemd. Het team laat een demo zien waar iedereen op kan
reageren. Meestal direct na de sprint review vindt er nog een retrospective plaats, waarin het team
terugkijkt op zijn prestaties en nadenkt over manieren om te verbeteren.
Doel
Het doel van Scrum of Scrums is het managen van de werkzaamheden van meerdere scrumteams
vanuit een integraal perspectief. Het zorgt voor een gezamenlijke visie op het product waaraan
gewerkt wordt. Daarnaast voorkomt het dubbele werkzaamheden (twee teams die werken aan
dezelfde user stories) en verbetert het de integratie van functionaliteiten die in verschillende teams
worden ontwikkeld. Zo voorkomt Scrum of Scrums silovorming en zorgt het voor synergie door
deling van kennis tussen de verschillende teams.
Een online marketingteam kan bijvoorbeeld Scrum of Scrums inzetten om de werkzaamheden van
de scrumteams te coördineren die verantwoordelijk zijn voor de verschillende digitale momenten
in de customer journey: de site, de verschillende apps, de selfcare omgevingen, et cetera. Scrum
of Scrums zorgt hierbij voor waarborging van een integrale, digitale customer experience over de
verschillende touchpoints die door de afzonderlijke teams worden ontwikkeld. Daarnaast zorgt
Scrum of Scrums overleg voor een hogere teamproductiviteit doordat de teams learnings met
elkaar delen.
Kerncomponenten en -processen
Per scrum wordt een ‘lead’ aangewezen die deelneemt aan de coördinerende meeting. Deze lead
kan een technisch expert zijn, een product owner, maar ook een scrummaster. Dit is afhankelijk
van de context waarin een project zich bevindt en de uitdagingen die spelen. De frequentie van de
Scrum of Scrums meeting kan wekelijks zijn, maar kan ook dagelijks plaatsvinden. De frequentie is
hierbij sterk afhankelijk van de mate van afhankelijkheid en daarbij benodigde afstemming tussen de
teams.

10. Hoe past Scrum of Scrums bij de volgende criteria
1. Afhankelijkheden tussen teams
2. Afhankelijkheden tussen team en de organisatie
3. Benodigde creatieve input
4. Organisatiegrootte
5. Complexiteit van het product
WEINIG VEEL
WEINIG VEEL
WEINIG VEEL
KLEIN GROOT
KLEIN GROOT
Whitepaper januari 2016 • VODW10
Inhoudelijk wordt tijdens een Scrum of Scrums hetzelfde proces gehanteerd als bij een
reguliere dagelijkse bespreking die ieder scrumteam normaal gesproken voert. Per team wordt
gerapporteerd op afgeronde, lopende en nog te starten taken en op afhankelijkheden. Hierbij wordt
gefocust op het oplossen van de onderlinge afhankelijkheden tussen de teams en de gezamenlijke
afhankelijkheid van andere organisatieonderdelen. De Scrum of Scrums meeting is nadrukkelijk
geen bespreking van scrummasters om te praten over de manier om het agile of scrumproces te
verbeteren.
Zeer geschikt voor situaties waarin…
• De organisatie al bekend is met de scrummethodiek. Scrum of Scrums is dan een logische
vervolgstap.
• Het aantal scrumteams dat werkt aan een grotere, gezamenlijke visie/product beperkt is
(maximaal negen teams met onderlinge afhankelijkheid). Wanneer sprake is van meer dan
negen teams die onderling moeten afstemmen, wordt de Scrum of Scrums opgesplitst en
wordt gewerkt met een scrum-of-scrums-of-scrums voor coördinatie tussen de Scrum of
Scrums.
Scrum team 3Scrum team 2Scrum team 1
Scrum of Scrums

11. Scaling the agile organization Whitepaper januari 2016 • VODW 11
Minder geschikt voor situaties waarin…
• Je behoefte hebt aan uitspraken over organisatiestructuur, processen, rollen en
verantwoordelijkheden. Een echt framework voor scaling agile kan je Scrum of Scrums
namelijk niet noemen, aangezien het eigenlijk niet meer is dan een set van coördinerende
besprekingen. Het is daarom ook geen basis voor echte agile organisatietransformatie.
• (In lijn met voorgaande) organisaties waar grote aantallen scrumteams werken en de
teams sterke onderlinge afhankelijkheden kennen. Voor coördinatie vanuit een centraal
gedefinieerde concernstrategie volstaat het enkel hanteren van een Scrum of Scrums hierbij
niet. Wel kan een dergelijk overleg een belangrijk instrument in een groter framework zijn.
Meer weten over Scrum of Scrums? Lees verder op de website van Agile Alliance.

12. Whitepaper januari 2016 • VODW12
In de basis is LeSS het Scrum framework toegepast op organisaties
met meer dan één scrumteam. LeSS combineert 10 basisprincipes
met een aantal regels voor de structuur van teams en coördinatie
tussen de teams. Een van de meest kenmerkende regels is dat
ondanks dat er meerdere teams zijn, er maar één product owner is
die de visie neerzet voor het gehele product.
LeSS is bedacht door Craig Larman en Bas Vodde en biedt niet één maar twee agile scaling
frameworks; één voor organisaties met minder dan acht teams en een aangepaste versie voor
organisaties die met meer dan acht teams werken.
Doel
Het bieden van een scrummethodiek aan teams die werken aan productontwikkeling op grotere
schaal dan een enkel scrumteam. Hierbij werken individuele teams niet onafhankelijk aan een eigen
product, maar richten zich gecoördineerd op een gezamenlijk eindresultaat voor de klant.
Kerncomponenten en -processen
Net als bij een enkel scrumteam behoudt ook de met LeSS werkende organisatie één backlog voor
alle teams en aan het einde van de sprint één concreet en tastbaar resultaat dat indien gewenst
direct ingezet kan worden.
Terwijl bij scrum de product owner zich actief richt op zowel het vullen en prioriteren van de backlog
alsmede de verduidelijking van de user stories voor het team, ligt bij LeSS vooral de nadruk op
het prioriteren. Voor de verduidelijking van de user stories is de product owner geen intermediair
meer naar de markt en de klant, maar faciliteert hij het directe contact tussen het team en de echte
klanten. Daardoor heeft hij meer tijd om het overzicht te bewaren. Zo wordt het team gedwongen
echt samen met klanten te werken en met begrip voor klanten een oplossing te ontwikkelen.
Craig Larman en Bas Vodde hebben als onderdeel van het LeSS framework ook het principe
van ‘feature teams’ geïntroduceerd. Waar in traditionele organisaties vaak gewerkt wordt met
component teams met een focus op individuele specialismen, zijn feature teams multidisciplinair
samengesteld zodat ze een compleet klantgericht product van start tot finish kunnen opleveren. De
mensen in deze teams zitten daarom ook altijd bewust bij elkaar in de buurt, zijn voor 100% van hun
tijd bezig in een team en het team is niet op projectbasis, maar ‘permanent’ bij elkaar.
Analyse van vijf frameworks
2. Large Scale
Scrum (LeSS)

13. Scaling the agile organization Whitepaper januari 2016 • VODW 13
Product Owner
Product
Backlog
Sprint
Backlog
Sprint
Backlog
Sprint
Backlog
Sprint
Backlog
Previous
Sprint
Overall Retrospective
Sprint
Planning 1
Sprint
Planning 2
Daily
Scrum
Daily
Scrum
Feature
Team
Feature
Team
Coördination Coördination
Feature
Team
Feature
Team
Scrum
Master
Scrum
Master
twoweekstwoweeks
Print review with Product Owner
Retrospective
Potentially
Shippable
Product
Increment

14. Hoe past LeSS bij de volgende criteria
1. Afhankelijkheden tussen teams
2. Afhankelijkheden tussen team en de organisatie
3. Benodigde creatieve input
4. Organisatiegrootte
5. Complexiteit van het product
WEINIG VEEL
WEINIG VEEL
WEINIG VEEL
KLEIN GROOT
KLEIN GROOT
Whitepaper januari 2016 • VODW14
Zeer geschikt in situaties waarin…
• Veel flexibiliteit en agility nodig is bij grote projecten. LeSS streeft namelijk een veel
frequentere communicatie met afvaardigingen van de verschillende teams na dan
bijvoorbeeld het SAFe framework.
Minder geschikt in situaties waarin…
• De organisatie tegelijkertijd aan meerdere producten werkt, waarbij coördinatie tussen die
producten nodig is.
• De technische architectuur en het platform dat implementatie na één sprint kan waarmaken
ontbreekt. LeSS focust namelijk op één tastbaar resultaat dat direct te gebruiken is en dat
voortvloeit uit de gezamenlijke teams.
Ondanks de redelijk uitgebreid beschreven principes en organisatiestructuur hangt LeSS sterk op
elementen uit de scrummethodiek en lijkt het in de praktijk daardoor sterk op een pure vorm van
scrum.
Meer weten over LeSS? Bekijk dan de website.

15. Scaling the agile organization Whitepaper januari 2016 • VODW 15
Spotify ’s aanpak om agile te schalen was nooit bedoeld als
framework en meer als een set van principes, maar kreeg
wereldwijde bekendheid door de diepgaande beschrijving van
Kniberg en Ivarsson. Een van de belangrijkste waarden in het model
is de mate van decentralisatie en het extreem grote vertrouwen
dat wordt gesteld in het team, dat bij Spotify een squad heet. Dit
vertrouwen wordt in de aanpak van Spotify direct vertaald naar
gedelegeerde verantwoordelijk met zeer weinig aan- of bijsturing van
hogerhand.
Een squad is een zelfsturend team dat verantwoordelijk is voor een stukje van het totale
eindproduct. De teams bestaan uit mensen met verschillende expertises, zoals marketeers,
data-analisten, IT’ers, UX-designers, et cetera. De samenstelling is afhankelijk van het doel van
het team. Door op deze manier te werken heeft Spotify, ondanks haar explosieve groei haar
aanpassingsvermogen en innovatiekracht behouden. Doel
Snelheid van innovatie en klantgerichte productontwikkeling bij Spotify.
Kerncomponenten en -processen
In eerste instantie gebruikte Spotify voor de beschrijving van haar aanpak vaak de metafoor van
de ‘mini startup’, maar nu verschuift ze de nadruk naar ‘aligned autonomy’. Doordat de nadruk
op cultuur ligt, wordt bijvoorbeeld ook de keuze van agile methodieken zoals scrum, Kanban of
LeSS overgelaten aan iedere squad. Daarnaast zijn typische managementverantwoordelijkheden
verdeeld over de rollen van squad, tribe, chapter en guild lead. Voor traditionele managers kan deze
manier van werken beangstigend zijn, omdat ze hierdoor grip verliezen op het proces en niet meer
exact kunnen voorschrijven wat er moet gebeuren.
Er zijn parallellen te trekken tussen het Spotify model en het LeSS framework, maar Spotify
heeft het model wel flink aangepast aan de eigen organisatie. Kopieer dus nooit zomaar een
populaire best practice zonder verdere analyse. Het implementeren van een framework dat op de
uitgangspunten van Spotify is gebaseerd kun je dus het beste iteratief uitrollen met als uitgangspunt
dat je zeer waarschijnlijk aanpassingen moet maken.
Analyse van vijf frameworks
3. Het Spotify model

16. Tribe Tribe
Guild
Tribe
lead
Tribe
lead
Chapter
Chapter
Product
Owner
Product
Owner
Product
Owner
Product
Owner
Product
Owner
Product
Owner
Product
Owner
Product
Owner
Chapter
Chapter
Chapter
lead
Guild
lead
Whitepaper januari 2016 • VODW16
Wat betekent Spotify
in het kader van scaling agile?
Net als bij scrum werkt Spotify met een product owner die verantwoordelijk is voor wat het team doet.
Deze persoon beheert de product backlog en stelt de prioriteiten. Een team bestaat uit vier tot negen
mensen, die verantwoordelijk zijn voor het realiseren van een vooraf vastgestelde (klantgerichte)
missie. Een squad is opgebouwd uit mensen met verschillende expertises, zoals IT’ers, marketeers,
data-analisten en UX-designers.
Als squads aan gerelateerde of dezelfde
elementen van een systeem of product werken
dan vormen ze vaak tribes. Een tribe bestaat
uit verschillende squads die doelen hebben die
elkaar raken en zorgt voor overleg tussen deze
squads. Een tribe bestaat nooit uit meer dan
150 mensen. Een tribe lead zorgt dat kennis
en inzichten tussen squads gedeeld worden,
stelt prioriteiten en alloceert de budgetten. Ook
is deze persoon het gezicht van de tribe naar
andere tribes in de organisatie.
Bij Spotify is het delen van leerervaringen
en stimuleren van innovatie over de squads
heen geregeld in informele groepen genaamd
chapters en guilds, die zich vormen rondom
bepaalde specialismes (zoals testers) of
thema’s.
Een chapter is een groep waarin mensen
uit verschillende squads, maar met dezelfde
expertise (bijvoorbeeld data-analyse) bij elkaar
komen om van elkaar te leren hoe ze met
bepaalde uitdagingen omgaan. De chapter
lead van bijvoorbeeld de chapter ‘data-analyse’
is verantwoordelijk voor de persoonlijke
ontwikkeling, coaching en performance van de
data-analisten.
Als laatste zijn er guilds: dit is een groep
mensen met verschillende interesses en
expertises uit verschillende tribes. Deze
groepen stimuleren de samenwerking en het
uitwisselen van best practices tussen de tribes.

17. Hoe past Spotify bij de volgende criteria
1. Afhankelijkheden tussen teams
2. Afhankelijkheden tussen team en de organisatie
3. Benodigde creatieve input
4. Organisatiegrootte
5. Complexiteit van het product
WEINIG VEEL
WEINIG VEEL
WEINIG VEEL
KLEIN GROOT
KLEIN GROOT
Scaling the agile organization Whitepaper januari 2016 • VODW 17
Zeer geschikt voor…
• Culturen waarin initiatief en zelf verantwoordelijkheid nemen al is ingebed.
• Organisaties (of onderdelen ervan) die (functioneel) redelijk ontbundeld zijn.
• Marktsituaties waarbij reageren op diverse consumentenbehoeften belangrijk is.
Minder geschikt in situaties waarin…
• Je behoefte hebt aan een duidelijk uitgeschreven framework wat je op jouw organisatie kunt
toepassen. Net als Lean is Spotify ‘s aanpak niet in eerste instantie gericht op het beschrijven
van processen en structuren, maar meer op cultuur. Hierdoor wordt het moeilijker het model
te kopiëren.
• De onderwerpen waar de squads zich mee bezighouden met elkaar verweven zijn of
producten gebundeld zijn. Dit kan bij een complexere, omnichannel klantreis resulteren
in een inconsistente klantervaring, omdat veel squads werken aan ervaringen in dezelfde
klantreis. Bij Spotify gebruiken ze dan ook maar een beperkt aantal kanalen.
• De organisatiecultuur nu ver afstaat van de vertrekpunten van agile. Deze organisaties zullen
veel moeite hebben zich aan te passen aan een Spotify model.
Bij de aanpak van Spotify kun je zeker parallellen zien met het LeSS framework, maar het is
aangepast aan de specifieke behoefte van de Spotify engineering organisatie. Voor meer informatie
kun je naast de eerder genoemde beschrijving ook de recent gepubliceerde tweedelige interactieve
beschrijving van de engineer cultuur bekijken.

18. Whitepaper januari 2016 • VODW18

19. Scaling the agile organization Whitepaper januari 2016 • VODW 19
SAFe is wellicht het meest bekende en meest gestructureerde
framework voor het inzetten van agile op grote schaal. Het
framework gaat uit van drie organisatieniveaus: portfolio, program en
team. Het beschrijft voor ieder niveau rollen en processen. Daarnaast
is het framework van SAFe constant in ontwikkeling. Versie 4.0 ging
op 3 januari dit jaar live en de vijfde SAFe iteratie zal ongetwijfeld
binnenkort weer starten.
Doel
De nadruk ligt in eerste instantie op samenwerking en afstemming op enterpriseniveau, met als
belangrijkste onderdeel een bedrijfsbrede, meerdaagse release planningsessie die veelal ieder
kwartaal plaatsvindt. Dit is het antwoord van SAFe op een van de kernvraagstukken van scaling
agile: hoe stem je in een organisatie met veel agile werkende teams de afhankelijkheden tussen
verschillende teams af? En hoe zorg je vervolgens voor de aansluiting met de business strategie?
Deze planningsessie is een soort Scrum of Scrums, alleen dan met alle teamleden en met meer
centrale regie over welke teams welke prioriteiten oppakken.
Kerncomponenten en -processen
In SAFe wordt op het hoogste niveau (portfolio) gerelateerd werk samengevoegd onder bepaalde
strategische thema’s. Aan die thema’s worden twee typen projecten, epics genoemd, gekoppeld die
concrete invulling geven aan die thema’s. Business epics zijn klantgeoriënteerde initiatieven, zoals
de lancering van een nieuw product. Architectuur epics zijn bedrijfsbrede technologie-initiatieven
zoals het openstellen van functionaliteit via API’s. Samen vormen deze epics de portfolio backlog.
Op het middelste niveau (program) wordt bepaald wat de functionele componenten zijn van de
releases. Op operationeel niveau (team) wordt ten slotte gewerkt aan user stories, backlog beheer
en het implementeren van nieuwe functionaliteit.
Analyse van vijf frameworks
4. Scaled Agile
Framework (SAFe)

20. Whitepaper januari 2016 • VODW20
Features
Features
Features
Business
Owners
3. Team
Backlog
4. Gezamenlijke
release
Product
Management
Vision
Roadmap
Functional
experts
Scrum/Agile
Master
Product
Owner
Agile Team
Functional
experts
Scrum/Agile
Master
Product
Owner
Agile Team
Functional
experts
Scrum/Agile
Master
Product
Owner
Agile Team
Agile release train
Program
Backlog
1.
Epics
Product
Management
2. Kwartaal release
planning
Business Owners
Functional experts
Scrum/Agile
Master
Product
Owner
Features
Features
Features
3. Team
Backlog
Product
Management
Vision
Roadmap
Pr
Ba
1.
E

21. Scaling the agile organization Whitepaper januari 2016 • VODW 21
Business Epic Business EpicArchitectual Epic
Program
portfolio
management
Portfolio
Metrics
Strategic
Themes
Epic
owners
Enterprise
architect
Portfolio
Backlog
Kanban
Value Streams deliver solutions
Portfolio Portfolio vision
Budg
ets
Agile release train
Agile release train
Agile release train
Epics
Epics
Epics
Program
Backlog

22. Hoe past SAFe bij de volgende criteria
1. Afhankelijkheden tussen teams
2. Afhankelijkheden tussen team en de organisatie
3. Benodigde creatieve input
4. Organisatiegrootte
5. Complexiteit van het product
WEINIG VEEL
WEINIG VEEL
WEINIG VEEL
KLEIN GROOT
KLEIN GROOT
Whitepaper januari 2016 • VODW22
Zeer geschikt in situaties waarin…
• Scrum of Scrums in combinatie met één product owner niet meer volstaat. SAFe biedt
structuur bij het opschalen van de agile organisatie, met name als het de IT organisatie
overstijgt. Dit framework geeft bovendien meer houvast op het niveau van programma-
management dan LeSS of Spotify.
• Er behoefte is aan een betere voorspelbaarheid met betrekking tot de inhoud van releases.
Ieder team neemt namelijk voor een aantal sprints een deel van de backlog voor zijn rekening
en in principe is de scope van de release daarmee vastgezet.
• Er behoefte is aan een geleidelijke invoer van het model. Anders dan het LeSS of Spotify
model start SAFe namelijk vaak met een enkel strategisch speerpunt van de organisatie.
• Nu nog erg in silo’s wordt gewerkt. Deze aanpak past dus vaak goed bij grote, meer
traditionele organisaties.
• De organisatie nu nog moeite heeft twee keer per jaar een substantiële verbetering van
producten of diensten in de markt te lanceren.
Minder geschikt in situaties waarin…
• Er behoefte is aan agility van de organisatie en de teams. Een deel van de agility gaat namelijk
verloren, omdat voor een aantal sprints wordt vastgelegd welk team verantwoordelijk wordt
voor een aantal items op de backlog. Zaken die af zijn, gaan minder vaak dan bij andere
werkvormen onmiddellijk live, maar wachten vaak tot de lancering die elk kwartaal staat
gepland. Dat betekent niet dat geen ‘continuous delivery’ mogelijk is (IT-taal voor continue
verbetering aan de site maken) of plaatsvindt binnen SAFe, maar meer dat er voor bepaalde
features of user stories afhankelijkheden kunnen zijn waardoor iets moet wachten tot het
einde van de release.
• De organisatie al in staat is om minimaal maandelijks nieuwe software of online
systeemcomponenten te lanceren. Het gaat hier dan niet om cosmetische verbeteringen
aan de user interface, maar daadwerkelijk nieuwe functionaliteit. Dan biedt SAFe misschien
teveel structuur.

23. Scaling the agile organization Whitepaper januari 2016 • VODW 23
Ondanks de uitwerking van het framework op drie niveaus is SAFe nadrukkelijk ontwikkeld als
antwoord op de problematiek van zeer grote organisaties bij het inzetten van agile en dus minder
geschikt voor kleinere organisaties met een beperkt aantal teams.
Een van de belangrijkste zichtbare verschillen is dat SAFe echt gericht is op periodiek face-to-face
overleg met alle leden van alle teams te faciliteren, terwijl LeSS een veel frequentere communicatie
met afvaardigingen van de verschillende teams nastreeft. LeSS zou daardoor misschien iets beter
passen in een omgeving waar veel flexibiliteit (en agility) nodig is en SAFe iets beter bij grotere
traditionele organisaties met meer legacy systemen die langzaam veranderen en meer afstemming
noodzakelijk maken.
Meer informatie over SAFe vind je hier.

24. Whitepaper januari 2016 • VODW24
Naast de verschillende methodieken en frameworks om agile
op grote schaal in te zetten is het belangrijk te onderkennen dat
sommige organisaties onbewust of bewust soms ook met hybride
vormen van agile en traditionele watervalaanpakken werken. De
literatuur praat dan over ‘wet agile’, ‘the agile waterfall’ en ‘the
agile waterfall hybrid’. De puristen vinden dergelijke combinaties
controversieel en niet passen, maar er zijn situaties te bedenken
waarbij het de beste oplossing kan zijn. Bijvoorbeeld bij bedrijven
die zowel software en hardware ontwikkelen in een product- of
dienstenconcept. Of bedrijven die bepaalde fasen in een proces op
een watervalmanier willen aanpakken en andere meer iteratief...
Een goed gedocumenteerde case is in 2013 beschreven door Erick Bergmann en Andy
Hamilton over Schneider Electric. Bij Schneider Electric werken de softwareteams volgens agile
principes en de hardware-ontwikkelingsteams en het gehele productmanagementteam volgens
watervalaanpak.
De agile softwareontwikkeling vindt nog steeds iteratief plaats, van conceptontwikkeling en
feasibility studies tot aan validatie en productie. Afstemming met de product roadmap en hardware
development teams is veelvuldig, zowel bij het opstellen van requirements tot aan integratietesten
tussen hardware en software.
Het nadeel is natuurlijk dat de softwareteams zich moeten houden aan de harde deadlines uit het
projectplan, maar dat de gehele organisatie wel sneller een beter product in de markt kan zetten
omdat de software iteratief wordt ontwikkeld.
Doel
Organisaties die bewust langdurig een hybride structuur kiezen hebben meestal als doel meer
efficiëntie en slagkracht te creëren voor onderdelen van de organisatie die met kortere iteraties en
hogere innovatiesnelheid willen opereren en tegelijkertijd de voordelen van de watervalmethode
behouden voor andere organisatieonderdelen.
Analyse van vijf frameworks
5. Hybride vormen van
waterval en agile

25. Scaling the agile organization Whitepaper januari 2016 • VODW 25
Zeer geschikt in situaties waarin…
• Organisaties zowel aan hardware als software werken.
• Software wordt ontwikkeld die niet of niet makkelijk via continuous delivery aan klanten kan
worden gegeven en waarbij dus veel planning vooraf nodig is.
• Requirements moeten worden goedgekeurd door externe partijen, zoals
overheidsinstanties.
Minder geschikt in situaties waarin…
• De overgrote meerderheid van de ontwikkelteams hoofdzakelijk aan online systemen zoals
websites en mobile apps werkt.
• De marktsituatie snelle en veelvuldige aanpassing van het product of de dienst vereist.
Hoe past de hybride vorm bij de volgende criteria
1. Intradepencies
2. Interdependencies
3. Benodigde creatieve input
4. Organisatiegrootte
5. Complexiteit van het product
WEINIG VEEL
WEINIG VEEL
WEINIG VEEL
KLEIN GROOT
KLEIN GROOT

26. Whitepaper januari 2016 • VODW26
Door in iets meer detail de doelen en kernprocessen van de
verschillende frameworks te analyseren en ze te vergelijken op basis
van een aantal criteria zoals intradepencies, interdependencies,
benodigde creatieve input, organisatiegrootte en complexiteit van
het product wordt het duidelijker dat de keuze van een framework
organisatiespecifiek is.
Daarnaast spelen de huidige en gewenste organisatievorm en de processen een rol. Te denken
valt aan het aantal teams en hun locatie (verspreid of allemaal in één gebouw), de frequentie
waarmee nu en idealiter in de toekomst aanpassingen moeten worden uitgevoerd en de behoefte
en noodzaak aan centrale aansturing. Uiteraard kan ook de huidige (marketing)technologie-
architectuur een beperkende factor vormen. Is het nu überhaupt mogelijk snel een verbetering in
productie te nemen, of vergt dat afstemming met andere afdelingen en teams en een planning van
maanden?
Bovendien is het goed te beseffen dat op papier je best veel verschillen kan vinden in de
verschillende frameworks, maar dat in de realiteit organisaties die bijvoorbeeld LeSS of SAFe
gebruiken veel overeenkomsten vertonen. Bijvoorbeeld door het gebruik van een mix van feature en
component teams.
Deze whitepaper is een introductie op de theorie achter scaling agile met handvatten om het juiste
model te selecteren. Met deze inzichten en het overzicht van de agile scaling frameworks kunnen
de meeste organisaties wel concluderen dat één van de reeds gedefinieerde modellen goed bij hun
situatie past. Als we vasthouden aan de agile filosofie dan is het ook goed mogelijk om iteratief op
een model verder te ontwikkelen.
Los van bovenstaande vijf frameworks, zijn er nog vele andere methodes en principes voor het
schalen van agile. DAD, RAGE, Scrum at Scale, Scaled Professional Scrum, DSDM, Enterprise
Scrum en XSCALE worden niet in deze whitepaper besproken, maar zijn wel de moeite waard om te
analyseren.
Conclusie

27. Scaling the agile organization Whitepaper januari 2016 • VODW 27
Burndown chart: grafiek die aangeeft hoeveel tijd er nog
over is afgezet tegen het werk wat nog gedaan moet worden.
Chapter: groep waarin mensen uit verschillende squads,
maar met dezelfde expertise (bijvoorbeeld data-analyse) bij
elkaar komen om van elkaar te leren hoe ze met bepaalde
uitdagingen omgaan.
Chapter lead: persoon die verantwoordelijk is voor de
persoonlijke ontwikkeling en coaching bij problemen waar
experts tegenaan lopen en performance van squadleden.
(Daily) standup: korte bijeenkomst waarbij ieder teamlid
aangeeft welke taken hij (die dag) gaat uitvoeren en wat zijn
blokkades zijn.
Product owner: persoon die verantwoordelijk is voor wat
een scrum team of squad doet. Deze persoon beheert de
product backlog en stelt de prioriteiten op basis van de visie
en doelstellingen van het team, zodat het team maximale
waarde creëert voor de volgende release.
Potentially shippable product increment: het product dat
een scrumteam oplevert.
(Product/sprint) backlog: to do lijst met alle taken die nog
gedaan moeten worden om het vastgestelde doel te bereiken.
Product backlog refinement: aanscherping van taken
zodat deze duidelijk genoeg zijn om mee te beginnen.
(Product) release: het lanceren van (tussen)producten om
te testen, zodat het team gericht verbeteringen kan doen en
prioriteiten kan stellen voor de volgende sprint.
Retrospective: terugblik van het team op zijn prestaties,
waarbij de teamleden nadenken over hoe zij dingen in de
volgende sprint anders of beter kunnen doen.
Scrumboard: bord waar alle taken en de bijbehorende
status op staan.
Scrummaster: zorgt dat iedereen de manier van werken
begrijpt en omarmt. Zijn taak is ondersteunend en niet
sturend zoals een manager. De scrummaster helpt
bijvoorbeeld bij het oplossen van blokkades die zorgen dat
een teamlid niet productief is en maakt hier eventueel een
lijst van (impediment list). De scrummaster is geen project
manager met managementautoriteit.
Scrumteam: multidisciplinair team dat bestaat uit mensen
met verschillende expertises, zoals marketeers, IT’ers,
analisten en UX-designers, die samen toewerken naar een
gezamenlijk einddoel.
Sprint: korte periode van ongeveer één tot vier weken,
waarin het team naar een concreet, vooraf gedefinieerd
resultaat of tussenproduct werkt.
Sprint review: feedbackmoment waarbij een team de
output van de sprint presenteert in een demo en beoordeelt.
Squad: team dat bestaat uit vier tot negen mensen, die
end-to-end verantwoordelijk zijn voor het realiseren van
een vooraf vastgesteld (klantgericht) doel. Een squad is
opgebouwd uit mensen met verschillende expertises, zoals
IT’ers, marketeers, data-analisten en UX-designers.
Tribe: groep die bestaat uit verschillende squads die doelen
(purposes) hebben die elkaar raken en zorgt voor overleg
tussen deze squads. Een tribe bestaat nooit uit meer dan
150 mensen.
Tribe lead: persoon die zorgt dat kennis en inzichten tussen
squads gedeeld worden, stelt prioriteiten en alloceert de
budgetten. Ook is deze persoon het gezicht van de tribe
naar andere tribes toe.
User story: beschrijven van een product- of dienstkenmerk
vanuit het perspectief van de eindgebruiker, bestaande uit
het type gebruiker, wat hij wil en waarom.
Begrippenlijst

28. Margot Schreuders
mschreuders@vodw.com
in/margotscheuders
Michael Klazema
mklazema@vodw.com
in/klazema
Vragen of opmerkingen over dit document? Of wil je weten welk
framework het best bij jouw organisatie past? Neem dan contact op
via onderstaande gegevens.