Wat is het Schaalbare Agile-raamwerk (SAFe)?

Waarom is SAFe^® nuttig? 

SAFe biedt organisaties een richtlijn (of routekaart) om hen te helpen tijdens hun groeitraject. Het introduceert het raamwerk op teamniveau en bouwt dit uit tot het hogere managementniveau, of het portfolioniveau of programmaniveau. 

Naast de routekaart is er speciale training die organisaties kunnen volgen. SAFe biedt een uitgebreide kennisbasis voor specifieke agile rollen, zoals scrummasters, producteigenaren, architecten en het agile team als geheel.

Is SAFe^® een methodologie of een raamwerk?

Zoals de naam al aangeeft, is SAFe een zeer aanpasbaar raamwerk. Omdat het wereldwijd door ten minste 1.000.000 professionals en 20.000 ondernemingen wordt gebruikt, zou SAFe waarschijnlijk niet zo’n brede aantrekkingskracht en wereldwijde acceptatie hebben als het een rigide methodologie was.

Dat gezegd hebbende, is dit een zeer veelgestelde vraag, omdat methodologie en raamwerk in het dagelijks taalgebruik vaak door elkaar worden gebruikt. Ter ondersteuning van mijn antwoord op deze vraag is het nuttig om de woorden van Michael Wood uit zijn artikel over methodologie versus raamwerk in gedachten te houden:

Over het algemeen creëren raamwerken een structuur van wat er moet gebeuren, maar laten ze het aan de uitvoerder over om de beste manier te bepalen om het “wat” uit te voeren, terwijl een methodologie alles tot in detail beschrijft: wat er moet gebeuren, wanneer het moet gebeuren, hoe het moet worden gedaan en waarom.

Michael Wood

SAFe^®-principes

Omdat SAFe organisaties een manier biedt om agile op te schalen naarmate hun organisaties groeien, sluiten de grondslagen ervan aan bij agile, lean productontwikkeling en systeemdenken. Zo biedt het niet alleen begeleiding aan een agile team, maar aan ‘teams van teams’.

Er zijn 10 lean-agileprincipes waarop het raamwerk is gebaseerd:

1. Hanteer een economisch perspectief: Richt zich op het concept om vroeg en regelmatig waarde aan klanten te leveren. Een economisch perspectief benadrukt ook de noodzaak om rekening te houden met alle kosten (risico's, productie, operationele kosten en ontwikkeling) en te werken binnen goedgekeurde budgettaire kaders
2. Pas systeemdenken toe: Vereist inzicht in de systemen waarin de organisatie die de oplossing creëert zelf een systeem is en de oplossing eveneens een systeem is (het project, het product)
3. Ga uit van variabiliteit; behoud opties: Draait om het concept om niet vroeg in de ontwikkeling één ontwerp of één set vereisten vast te leggen, maar in plaats daarvan een reeks ontwerpen of vereisten te hebben en echte gegevens (uit experimenten en tests) te gebruiken om de opties te beperken
4. Bouw stapsgewijs op met snelle, geïntegreerde leercycli: Volgt het concept om werk in kleinere (frequentere) delen op te leveren en voort te bouwen op het eerdere werk
5. Baseer mijlpalen op objectieve evaluatie of werkende systemen: Evalueer werk dat in ontwikkeling is op verschillende momenten gedurende de agile ontwikkelingslevenscyclus om te beoordelen of wat er wordt ontwikkeld economische voordelen zal opleveren en geschikt zal zijn voor gebruik
6. Visualiseer en beperk werk in uitvoering (WIP), verklein batchgroottes en beheer de wachtrijlengte: Zoals de naam al aangeeft, richt dit principe zich op het stellen van een limiet aan het werk dat mensen of teams op een bepaald moment toegewezen hebben gekregen (om overbelasting te voorkomen en ervoor te zorgen dat het werk en de oplevering gelijkmatig verlopen)
7. Pas een ritme toe; stem af op planning over domeinen heen: Volg een patroon waarbij je je voor de planning tussen teams onderling afstemt
8. Maak de intrinsieke motivatie van kenniswerkers vrij: Begrijp dat het nodig is om autonomie, duidelijke beperkingen en obstakels te bieden en een cultuur van betrokkenheid voor je teamleden te creëren
9. Decentraliseer de besluitvorming: Om snel te handelen en vaker te leveren, moeten beslissingen worden gedecentraliseerd en moeten degenen die het dichtst bij de situatie staan de beslissingen kunnen nemen
10. Organiseer rond waarde: Organiseer teams niet rond specifieke functies (bijvoorbeeld ontwerp, testen, enzovoort), maar rond multidisciplinaire teams en klant- en bedrijfswaarde.

Het opgeschaalde agile raamwerk implementeren^® 

Stap 1: De juiste mindset hebben

Om SAFe te gaan implementeren, moet een organisatie de ambitie hebben om haar bedrijfsagiliteit te verbeteren en bereid zijn een Lean-Agile-mindset te omarmen.

Lean-Agile combineert overtuigingen, principes en acties uit het Agile Manifest en Lean-denken. Het is de transformatie van een vaste mindset naar een groeimindset, waarbij professionals klaar zijn om te experimenteren, zich door anderen te laten inspireren, mogelijkheden te verkennen, uitdagingen aan te gaan en mislukkingen te omarmen.

Het doel van Lean is om in zo weinig mogelijk tijd maximale waarde aan klanten te leveren en tegelijkertijd de hoogst mogelijke kwaliteit te bieden. Lean-denken kan als volgt worden gedefinieerd:

• De waarde van het product specificeren
• Voor elk product een waardestroom definiëren
• Een ononderbroken waardestroom creëren
• De klant de waarde laten aantrekken
• Streven naar perfectie

Stap 2: Een waardestroom definiëren 

Een waardestroom is een reeks stappen (en organisatorische onderdelen) die nodig zijn om waarde aan een klant te leveren: vanaf de eerste aanleiding tot het ontvangen van het uiteindelijke product of de uiteindelijke dienst. Dit is bijzonder belangrijk bij het implementeren van SAFe.

SAFe richt zich op het optimaliseren van de waardestroom om een continue waardestroom te leveren door mensen rond waardestromen te organiseren, zodat mensen en teams naadloos samenwerken in plaats van in silo's of segmenten.

Als een bedrijf bijvoorbeeld gepersonaliseerde keramische koffiemokken maakt die via de website worden verkocht, kan een waardestroom er als volgt uitzien:

In het bovenstaande voorbeeld zijn alle processen die nodig zijn om waarde te leveren vanaf het moment waarop de klant de bestelling voor zijn koffiemok plaatst tot het moment waarop hij de zending ontvangt, georganiseerd om ervoor te zorgen dat de waarde blijft stromen.

Stap 3: De Agile Release Train (ART) instellen

Een Agile Release Train (ART) is een combinatie van meerdere agile teams. Ze zijn opgebouwd rond een waardestroom en worden geacht voortdurend waarde te leveren door oplossingen te ontwikkelen die eindgebruikers en de klant ten goede komen.

SAFe draait om de coördinatie van meerdere agile teams, en een ART omvat alle mensen die nodig zijn om het product of de dienst te ontwikkelen, testen en implementeren. Een ART bestaat doorgaans uit 50–125 mensen of 10–12 verschillende agile teams (met een teamgrootte van 8 tot 10 mensen).

Een ART is multifunctioneel en bevat alle mensen en organisatorische middelen die nodig zijn om een volledige set producten of diensten voor een klant te ontwikkelen, bouwen en leveren. Afhankelijk van de omvang van een organisatie kunnen er meerdere ART's zijn (denk aan grootschalige organisaties met meer dan 500 mensen).

Stap 4: Verschillende rollen in SAFe definiëren^®

Net als bij elke organisatiestructuur zijn bepaalde rollen vereist en moeten deze worden toegewezen. In SAFe zijn de rollen op het niveau van het individuele agile team vergelijkbaar met die in een klein agile team, maar zijn er enkele extra rollen en belanghebbenden:

• Scrum Master: faciliteert agile bijeenkomsten en neemt belemmeringen weg
• Product Owner: is verantwoordelijk voor de productbacklog en bepaalt de prioriteit van de items daarin
• Scrumteamleden: voltooien items met prioriteit uit de backlog en leveren resultaten om waarde voor klanten te creëren
• Release Train Engineer (RTE): binnen de SAFe ART is dit de programmamanager en coördinator voor de agile teams
• Systeemarchitecten/-ingenieurs: in zowel technische als niet-technische organisaties helpen systeemarchitecten en ingenieurs bij de product- of softwareontwikkeling door een solide architecturale basis voor de oplossing te bieden

Stap 5: Een programmabacklog voorbereiden voor de Agile Release Train

Je hebt je ART opgezet en beschikt nu over meerdere agile teams. Om te helpen coördineren wat er wordt ontwikkeld of gebouwd, maak je een programmabacklog aan.

Een programmabacklog bevat de functies, epics, gebruikersverhalen, functionaliteit en architectuurwerkzaamheden (systemen) die nodig zijn om de waardestroom te ondersteunen en waarde voor klanten te leveren. 

Een gemeenschappelijke backlog vereist de inbreng van veel ART-rollen, zoals de Release Train Engineer en Product Owners, evenals van anderen, zoals productmanagement en de leiders van de organisatie. Een productbacklog helpt ook bij de volgende implementatiestap: bepalen wie wat en wanneer doet.

Stap 6: Planning van de programma-increment (PI) en ART-synchronisaties

In de laatste stap moet je plannen wie het werk uitvoert en wanneer. In SAFe wordt deze gebeurtenis Planning van de programma-increment (PI) genoemd. Dit staat centraal in SAFe, wordt regelmatig uitgevoerd en biedt de mogelijkheid om afstemming te bereiken met de volledige ART.

Een PI kan elke gewenste duur hebben, maar duurt doorgaans 3 maanden (12 weken). Hierdoor zijn 6 sprints van 2 weken mogelijk waarvoor teams moeten plannen. Dit gebeurt doorgaans in aanwezigheid van de volledige ART (inderdaad, alle agile teams).

Vanwege de omvang is PI-planning meestal een evenement van twee dagen dat het volgende omvat:

• Een presentatie van de bedrijfscontext, strategische doelen en missie
• Afzonderlijke sessies voor de agile teams, waarin ze hun plan opstellen met items uit hun teambacklog en de gemeenschappelijke programmabacklog
• Presentatie van conceptplannen door alle agile teams
• Beoordeling door het management en gesprekken over het oplossen van problemen
• Afzonderlijke teamsessies om hun plannen aan te passen en af te ronden
• Presentatie van de definitieve plannen en een vertrouwensstemming
• Beoordeling van programmarisico's en herziening van het plan (indien nodig)

Na afronding van de PI-planning gaan coördinatie en samenwerking door. Gedurende de PI komen vertegenwoordigers van de agile teams (de PO en Scrum Master) samen met de RTE regelmatig bijeen voor een ART-synchronisatie om de voortgang van de agile teams te beoordelen en afhankelijkheden, problemen of blokkades te identificeren die coördinatie vereisen. Dit kan op elk moment tijdens een PI plaatsvinden, maar elke 2 weken (of aan het einde van elke sprint of iteratie) is een goede frequentie.

Welke hulpmiddelen worden gebruikt in SAFe^®?

Omdat SAFe gebruikmaakt van andere agile methodologieën, zoals Scrum en Kanban, zijn er verschillende hulpmiddelen die agile teams kunnen gebruiken wanneer ze met SAFe werken.

Voor enkele aanbevolen hulpmiddelen die voor SAFe kunnen worden gebruikt, kun je beginnen met onze lijsten met Agile hulpmiddelen en Agile projectmanagementsoftware.

Aangezien wordt aanbevolen om PI Planning op locatie (face-to-face) uit te voeren, worden ook de volgende hulpmiddelen aanbevolen:

• Grote evenementruimte waar de volledige ART kan samenkomen en in teams kan werken
• Whiteboards of grote flip-overvellen
• Whiteboardmarkers
• Post-its/zelfklevende notities (gebruikt om items uit de teambacklog weer te geven)
• Snacks & versnaperingen (want wie houdt er nu niet van snacks 😊)

SAFe^® & andere Agile-methodologieën

Ik hoop dat je hebt genoten van het Agile-feest en van de kennismaking met onze nieuwe feestgast SAFe. Zoals je misschien hebt gemerkt, heeft SAFe eigenlijk veel gemeen met enkele andere gasten, zoals Scrum en Lean. Het is het begin van een geweldige relatie!

Als je organisatie groeit en het beheren van meerdere Agile-teams ingewikkeld begint te worden, kun je SAFe misschien overwegen uit te nodigen voor je feest. Als je vragen hebt, neem dan gerust contact met me op via LinkedIn of Twitter.

Voor andere hybride projectmanagementmethodologieën en hulpmiddelen kun je je abonneren op de nieuwsbrief van The Digital Project Manager. Wil je meer? Bekijk dan ons lidmaatschap!

^®SAFe en Scaled Agile Framework zijn geregistreerde handelsmerken van Scaled Agile, Inc.