Scaled Agile Framework of SAFe is een framework met Agile principes en tools voor grote organisaties. De basisgedachte achter SAFe is dat het framework is, die zo goed schaalbaar is dat het zelfs een enterprise volledig kan dienen. Honderden mensen kunnen gezamenlijk Agile werken aan de strategische doelstellingen.
Scaling van Agile activiteiten is op meerdere manieren mogelijk. Je hebt bijvoorbeeld NEXUS en Scrum of Scrums, DAD, de Spotify methode en dus ook SAFe. Alle Agile scaling methodes beogen hetzelfde: organisaties kunnen door Lean en Agile te werken loskomen van belemmerende structuren en sneller waarde gaan leveren voor de klant.
SAFe is een zeer populaire scalingsmethode geworden in vrij korte tijd. Dit komt vooral omdat het zeer herkenbaar is vanuit projectmanagement methoden. De grote populariteit van het Scaled Agile Framework (SAFe) is wellicht ook te verklaren doordat SAFe aansluit bij bestaande organisatie lagen. Daarnaast biedt SAFe de mogelijkheid om op te blijven schalen tot boven de duizend medewerkers.
SAFe is een Scaling methode waar Scrum, Kanban, DevOps en Lean naast elkaar worden gebruikt. Het is handig als je al beschikt over enige kennis van Scrum voor het lezen van dit artikel.
Rollen en Events in SAFe net even anders!
Net als elk ander Framework hanteert men bij SAFe ook rollen en events. Vanzelfsprekend hebben die weer eigen benamingen gekregen. Veel van onderstaande stappen zullen herkenbaar zijn als je bekend met Agile werken en helemaal als je bekend bent met Scaling. Door de net iets andere insteek, benadering en benamingen is het best even opletten om de verschillen en overeenkomsten te zien.
Hoewel SAFe bedoelt is voor grote organisaties, is toepassing vanaf ca. 50 personen mogelijk. SAFe is schaalbaar, je hoeft als organisatie niet direct volledig in te stappen. Een organisatie kan proefondervindelijk starten en verder bouwen op de opgedane ervaringen. SAFe noemt deze mogelijkheden: Essential SAFe, Large Solution SAFe, Portfolio SAFe en Full SAFe.
In onderstaande afbeelding zie je Full SAFe volledig afgebeeld. In dit artikel ligt de focus op de beschrijving van het kernverhaal. Zodat je na lezing begrijpt hoe in hoofdlijnen de methodiek in elkaar steekt.
SAFe hanteert 4 niveaus
De vier niveaus zijn Team, Programma, Large Solution (Value Stream) en Portfolio. Die komen deels overeen met de traditionele indeling van operationeel, organisatie- en strategisch niveau in een organisatie.
1. Team
Op teamniveau is SAFe vergelijkbaar met een Scrum team of een Kanban team. Het gaat hier om het team en technical agility.
Het Team is cross functioneel en zelforganiserend. De iteratie is tweewekelijks. De bij behorende rollen zijn Product Owner, Scrum Master en Development team.
De team backlog is de verantwoordelijkheid van de Product Owner. In een planning meeting worden de User Stories voor de komende 2 weken geselecteerd. Elke dag een Daily en aan het einde van de iteratie volgt de Demo aan de Product Owner. Daarna volgt een Retrospective begeleidt door de Scrum Master om de verbetermogelijkheden te bepalen. Daarop volgt de Planning meeting en dan start de cyclus opnieuw.
2. Program
Dit is waar de Scaling begint in het Scaled Agile Framework. De sleutelwoorden zijn DevOps en Release on Demand.
Van 50 tot 125 mensen werken samen in 5 tot 12 teams om de doelen van de organisatie te bereiken. Allen werken samen in een program. Deze samenwerking is geformaliseerd in een Agile Release Train (ART). De oplevering heet Program Increments ook wel PI’s.
Een program bestaat uit 5 iteraties, waarvan vier reguliere iteraties. De vijfde is echter anders, daar kom ik later op terug. Nu eerst de beschrijving van de eerste vier iteraties.
In de Program Backlog, waarvoor de Product Manager verantwoordelijk is, worden Features opgenomen. De teams kunnen daarop de meeste van hun Team Backlogs laten aansluiten.
De verantwoordelijke voor het proces is de Release Train Engineer, die er voor zorgt dat de trein in het spoor blijft. Voor het product is dit de Product Manager en voor de techniek de System Architect.
De Business Owners stellen de doelen. In een driemaandelijkse PI planning worden deze afgestemd. De Business Owners vertalen de klantwensen naar doelen voor de komende 3 maanden. In elke PI komen alle teamleden bijeen om de visie, roadmap en de features te horen.
Elk team maakt daarna een plan met welke objectives (doelen) zij in deze PI gaan realiseren. Afhankelijkheden en risico’s met en door andere team worden hierin meegenomen. Dan ontstaat het Program Board met per team de doelen voor de komende VIER sprints. Alle teams committeren zich aan het gezamenlijke program. Daarmee verschaffen de teams duidelijkheid aan klanten en Business Owners wat er de komende PI opgeleverd gaat worden.
Scrum of Scrums
Om er zeker van te zijn dat de doelen gerealiseerd worden hebben de Scrum Masters elke 2 weken, samen met de Release Train Engineer, een Scrum of Scrums.
De demo aan het einde van een iteratie is daar een onderdeel van. Dat is tevens de demo van ‘alles’ om er zeker van te zijn dat het ene team niet vooruit loopt en/of een ander achter blijft. Omdat het één trein is, kan de trein slechts in zijn geheel vooruit komen.
De trein behoort overigens zo snel als mogelijk te gaan, daarvoor moet je de rails voor de toekomst al neerleggen. Dit noemt men de Architectural Runway. Hiervoor is de System Architect (ARCH) verantwoordelijk.
De vijfde iteratie
Na de 4 reguliere iteraties volgt de vijfde iteratie. Zoals eerder aangegeven is deze binnen SAFe anders gedefinieerd. De vijfde iteratie is een IP- iteration. Oftewel de Innovation en Planning iteratie.
Het innovatie gedeelte van de IP is de tijd voor de teams om creatieve ideeën te bedenken. Bijvoorbeeld Hackatons, Ship It days of andere brainstormtechnieken.
Planning
De planning in bestaat uit 3 zaken:
- Demo van de voortgang. De PI System demo.
- Onderhoud en inspectie van de trein. Een retrospective voor mogelijke verbeteringen.
- En de planning van de komende PI’s.
De vijfde iteratie draagt zorg voor een Estimation Guard band, waarmee zekerheden ontstaan dat de teams hun commitment ook na kunnen komen.
Als je bovenstaande leest zal dit je direct doen denken aan een (kleine) organisatie. De gelaagdheid van verantwoordelijkheden is vermoedelijk heel herkenbaar.
3. Large Solution
Business Solutions en Lean Systems zijn de bijbehorende kernwoorden van de Large Solution in SAFe.
Large Solution is volgens Lean het Value Stream niveau. Het biedt de methode om meerdere Agile Release Trains naast elkaar te laten werken. Dit gebeurt als een enkele ART niet in staat is om zelfstandig de oplossing te genereren.
De coördinatie van meerdere ARTs die gezamenlijk aan grote oplossingen gaan werken vindt plaats op een hoger niveau. Dan spreekt men over Solution Management (SM) voor content, de Value Stream Engineer (VSE) als coach en gids en de Solution Architect (ARCH) voor de techniek.
De Value Stream volgt hetzelfde ritme als de PI. En hanteert ook een planning, solution demo en inspect en adapt events voor gezamenlijke ART mogelijkheden.
Voor dit hogere niveau zijn er weer nieuwe rollen:
- Proces: Solution Train Engineer
- Product: Solution Management
- Techniek: Solution Architect
Hoewel dit niveau vrij hoog in de organisatie zit, is het nog steeds ‘organisatie niveau’. Voor het allerhoogste niveau heeft SAFe Lean Portfolio Management.
4. Lean Portfolio management.
Voor het Portfolio bepalen Epic owners, in overleg met stakeholders de prioriteiten en worden de budgetten toegekend. Het ziet er weer hetzelfde uit als bekend mag worden verondersteld, maar het is toch weer net iets anders.
De Epic owners dragen zorg voor alle onderliggende value streams. Ze schrijven de strategische thema’s van de enterprise. De allocatie van budgetten voor de verschillende value streams vinden hier ook plaats. Daarnaast worden de overschreidende Value Stream initiatieven die meerdere oplossingen beïnvloeden in de vorm van Epics gemananaged.
Nieuwe rol: Program Portfolio Management (PPM)
Veranderingen SAFe framework
Het Scaled Agile Framework (SAFe) is continue in ontwikkeling, het framework kent diverse versies die allemaal een eigen release nummer krijgen. Ook benamingen kunnen dan veranderen. Op het moment van schrijven is de huidige versie 4.6
Je begrijpt dat de SAFe een succesvol businessmodel op zichzelf is geworden. SAFe biedt inmiddels meerdere opleidingsmogelijkheden voor verschillende functies op diverse niveaus.
Samenvatting
Dit artikel is een eenvoudige beschrijving van de belangrijkste componenten van het SAFe framework. In komende artikelen zal ik dieper op het Scaled Agile Framework ingaan, zoals de voor- en nadelen van SAFe.
Om te slagen met SAFe is het noodzakelijk dat zowel de leiders en teams met een Lean-Agile mindset werken en de Safe Principes en Practices goed toepassen als de nieuwe manier van werken. Of te wel het Lean-Agile Leadership, die je terugvindt op bovenstaande afbeelding.
SAFe Leadership start veelal met training van alle betrokkenen, om er voor zorg te dragen dat de eerste Release Train goed op gang komt. Idealiter is er daarna ruimte om proefondervindelijk verder uit te bouwen, waarbij de opgedane ervaring kan worden meegenomen in het leerproces.
Een interessant artikel is: 8 uitdagingen van het opschalen van agile.