scaling the agile organization - vodw.com€¦ · scaling the agile organization hitepaper januari...

28
Januari 2016 Scaling the agile organization

Upload: phamkhanh

Post on 15-Sep-2018

236 views

Category:

Documents


0 download

TRANSCRIPT

Januari 2016

Scaling the agile organization

Whitepaper januari 2016 • VODW2

ColofonDit 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 [email protected] 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

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

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

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 frameworkNiet 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

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

WatervalPlan Driven

AgileValue & 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

ProductBacklog Refinement

ProductBacklog

SprintBacklog

SPRINT1-4 weeks

No Changesin duration of goal

Input from end-users, customers, team and other stakeholders

ProductOwner

Sprint planning meeting.

Team selects how much to commit to do by sprint’s end

Team

Review with Product Owner

Retrospective

PotentiallyShippableProductIncrement

Scrum Master manages sprint progress

DailyScrumStandup

Whitepaper januari 2016 • VODW8

Kerncomponenten en processenEr 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

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.

DoelHet 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 -processenPer 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.

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

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.

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.

DoelHet 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 -processenNet 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)

Scaling the agile organization Whitepaper januari 2016 • VODW 13

Product Owner

ProductBacklog

SprintBacklog

SprintBacklog

SprintBacklog

SprintBacklog

PreviousSprint

Overall Retrospective

SprintPlanning 1

SprintPlanning 2

DailyScrum

DailyScrum

FeatureTeam

FeatureTeam

Coördination Coördination

FeatureTeam

FeatureTeam

ScrumMaster

ScrumMaster

two w

eekstw

o weeksPrint review with Product Owner

Retrospective

PotentiallyShippableProductIncrement

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.

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 -processenIn 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

Tribe Tribe

Guild

Tribelead

Tribelead

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.

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.

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.

DoelDe 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 -processenIn 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)

Whitepaper januari 2016 • VODW20

Features

Features

Features

BusinessOwners

3. TeamBacklog

4. Gezamenlijke release

ProductManagement

Vision

Roadmap

Functional experts

Scrum/AgileMaster

Product Owner

Agile Team

Functional experts

Scrum/AgileMaster

Product Owner

Agile Team

Functional experts

Scrum/AgileMaster

Product Owner

Agile Team

Agile release train

ProgramBacklog

1.

Epics

ProductManagement

2. Kwartaal releaseplanning

Business Owners

Functional experts

Scrum/AgileMaster

Product Owner

Features

Features

Features

3. TeamBacklog

ProductManagement

Vision

Roadmap

ProgramBacklog

1.

Epics

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

PortfolioBacklog

Kanban

Value Streams deliver solutions

Portfolio Portfolio vision

Budgets

Agile release train

Agile release train

Agile release trainEpics

Epics

Epics

ProgramBacklog

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.

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.

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.

DoelOrganisaties 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

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

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

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

Margot [email protected]

in/margotscheuders

Michael [email protected]

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.