Scaled Agile Framework (SAFe): wat is het? + Uitleg hoe je ermee werkt

Er is veel belangstelling voor SAFe (Scaled Agile Framework). Maar waarom? De belangrijkste oorzaak: met één team kun je prima Agile/Scrum werken, maar hoe stem je af met 5, 25 of 100 teams? SAFe is een populaire manier om je organisatie Agile in te richten. In Nederland wordt het Scaled Agile Framework onder andere gebruikt bij Air France-KLM, Philips, Stedin, ASML, UWV, VGZ en de Belastingdienst. Na het lezen van dit artikel weet je of SAFe iets voor jouw afdeling of organisatie zal zijn.

SAFe in een notendop

Het belangrijkste doel van SAFe is om grote afdelingen en organisaties in staat te stellen snel en flexibel klantwaarde te leveren. Om dit te bereiken is er geen plaats meer voor losse teams die allemaal op hun eigen eilandje opereren en weinig met elkaar communiceren. Deze silo’s veroorzaken namelijk veel vertraging.

Door SAFe te werken volg je een proces waarin er meer afstemming tussen teams plaatsvindt. De Agile mindset blijft van toepassing, alleen worden hier Lean en Systeem Denken principes aan toegevoegd. Daarnaast geeft SAFe ook eigen principes mee. Je blijft nog steeds werken volgens Agile frameworks als Scrum, Kanban, DevOps en Lean Startup, maar er worden nieuwe rollen en meetings geïntroduceerd aan de huidige multidisciplinaire Agile Teams.

Samenvattend: SAFe bouwt voort op de principes van je Agile team, maar maakt deze schaalbaar voor de grotere organisatie.

Is SAFe geschikt voor mijn afdeling of organisatie?

SAFe is een organisatieraamwerk voor middelgrote en grote bedrijven waar veel medewerkers samenwerken aan complexe producten in veranderlijke omgevingen. Denk aan een internationaal opererende bank. De techniek, wetgeving en concurrentie verandert continu. De markt is in beweging en de producten zijn enorm complex. Nu heeft de bank dit opgelost met duidelijke regels en structuren (je kunt dit ook stroperige bureaucratische processen noemen). Aan de ene kant heb je deze structuur nodig voor stabiliteit, maar aan de andere kant wil je ook snel inspelen op de behoeftes van de markt. SAFe biedt dit.

SAFe is bedoeld voor afdelingen en organisaties die met 50 of meer medewerkers samenwerken en veel afhankelijkheden hebben. Daarnaast werken de teams Agile doormiddel van bijvoorbeeld Scrum, Kanban of DevOps.

Zo hebben wij vanuit Agile Scrum Group de organisatie CowManager mogen helpen bij hun SAFe implementatie. Dit is een snelgroeiend bedrijf uit Harmelen met één duidelijk product. Een koe monitoringsysteem dat alle koeien in het weiland volgt via een sensor in het oor van de koe. Aan de hand hiervan kan de boer via een app de gezondheid van de koeien in de gaten houden en vroegtijdig actie ondernemen als de koe ziekteverschijnselen vertoont. SAFe is voor deze organisatie geschikt, omdat de verschillende teams van IT, marketing en business veel afhankelijkheden met elkaar hebben. Daarnaast is het ontzettend handig wanneer de verschillende disciplines kennis met elkaar delen.

Mocht je minder mensen hebben of zijn er weinig afstemmingsmomenten nodig? Dan kun je beter met andere schaalbare raamwerken aan de slag. Wellicht dat Scrum of Scrums, Nexus, of het Spotify-Model interessant is voor je. Het kan natuurlijk ook zijn dat opschalen van een raamwerk helemaal niet nodig is.

Wil je hierover van gedachten wisselen? Een van onze Agile Coaches denkt graag met je mee! Je kunt ons bereiken via info@agilescrumgroup.nl of bellen naar 020 2614 195

De 4 Niveaus waar je SAFe op kunt toepassen

SAFe is mede populair omdat het met herkenbare traditionele organisatorische lagen werkt. Ze zijn te vergelijken met de klassieke niveaus: operationeel, tactisch en strategisch.

De SAFe niveaus zijn: Team, Program (ART), Large Solution en Portfolio.

Team niveau

Je kunt het Team niveau vergelijken met het operationele niveau. Op Team niveau wordt er gewerkt met Agile Teams die bijvoorbeeld scrummen met een Product Owner, Scrum Master en Developers. Maar er zijn ook Kanban teams die werk verzetten.
Team niveau is het fundament van SAFe. Dit betekent dat je een SAFe implementatie pas wil overwegen wanneer je teams al enige tijd Agile werken. Doe je dit niet, dan is de overstap van traditioneel naar SAFe te groot en kun je een hoop weerstand en een rampzalige SAFe implementatie verwachten.

Program (ART) niveau

Hoe stem je communicatie tussen die verschillende Scrum en Kanban teams op Team niveau met elkaar af? Hoe voorkom je silo’s? En wat doe je met afhankelijkheden van werk tussen teams? Op Program niveau worden dit soort vragen besproken. Met het doel dat je van losse teams een team van teams wordt, met als gevolg een super team (‘voel je het teamgevoel al?’).

Hoe dit team van teams werkt kan ik het beste uitleggen met het voorbeeld van een trein. Stel je voor dat elke wagon van de trein symbool staat voor een Scrum team. In elke wagon wordt hard gewerkt. Daarnaast is elke wagon aan elkaar verbonden waardoor we snel, in samenhang en met hoge klanttevredenheid naar onze bestemming in het zonnige Spanje reizen. Deze trein wordt binnen SAFe de Agile Release Train (ART) genoemd.

Het team van teams (de trein), oftewel de Agile Release Train in deze organisatie levert waardevolle producten en diensten. Dit doet de ART door niet te groot en niet te klein te zijn: tussen de 50 à 125 mensen verdeeld over de diverse teams.

Om het werk binnen de ART goed af te stemmen is er om de 8 tot 12 weken een PI Planning. Hierin stemmen de Agile Teams hun toekomstig werk af en wordt de koers van de trein uitgezet. Dit laatste wordt gedaan door Business Owners. Zij zijn of vertegenwoordigen de klant en leveren de doelen aan waar de teams de komende tijd aan gaan werken.

Bij Scrum heb je de Scrum Master die verantwoordelijk is voor het proces. De Product Owner die verantwoordelijk is voor hetgeen wat er op de Product Backlog komt. En de Developers die verantwoordelijk zijn voor de kwaliteit en de technische aspecten hoe het werk wordt uitgevoerd.

Zo heb je op ART niveau ook deze verantwoordelijkheden, maar worden die gedragen door nieuwe rollen. Je hebt de Release Train Engineer die verantwoordelijk is voor het proces. Product Management die verantwoordelijk is voor hetgeen wat er op de ART Backlog komt. En de System Architect die verantwoordelijk is voor de techniek.

Het Program of ART niveau is eigenlijk al een kleine organisatie. Je kunt dus spreken van tactisch niveau als je het vergelijkt met een traditionele omgeving.

Large Solution niveau

Stel je voor dat je een ontzettend groot product hebt waar honderden mensen aan samenwerken. Dan red je het niet met slechts één ART, maar zul je meerdere ART’s aan elkaar moeten koppelen. Denk aan bedrijven zoals Boeing. Honderden medewerkers werken nauw samen om één nieuw vliegtuig te maken. Daarnaast heeft Boeing ook diverse leveranciers en partners die actief bij de coördinatie betrokken worden. Om deze complexiteit te ondervangen is een extra laag nodig: het Large Solution niveau.

Ook op dit niveau heb je iemand die verantwoordelijk is voor het proces (Solution Train Engineer), de Solution Train Backlog (Solution Management) en de techniek (Solution Architect). Het Large Solution niveau wordt nog steeds als tactisch niveau gezien als je het vergelijkt met een klassieke omgeving.

Portfolio niveau

Op het hoogste strategische niveau bespreekt het Portfolio Team met elkaar welke richting het bedrijf op moet gaan. Welke strategische thema’s selecteren we? Welk budget maken we hiervoor vrij? Hoe meten we of we dit nieuwe initiatief moeten voortzetten of stoppen?

Door op Portfolio niveau duidelijkheid te geven van de strategische doelstellingen wordt het op de niveaus eronder inzichtelijk wat de context van hun werk betreft. Zo heeft het Portfolio Team een Kanban bord met alle grote initiatieven. Zij geven prioriteit aan de meest waardevolle voorstellen. Tijdens de PI planning wordt het voor de Agile teams in de ART veel duidelijker waar de prioriteiten van het bedrijf liggen en kunnen ze hier beter op plannen.

Van Epic naar User Stories met Connected Kanban

Connected Kanban is een manier om van grote strategische doelen naar User Stories te gaan. De verschillende Kanban boarden op Portfolio, Large Solution, Program (ART) en Team niveau zijn met elkaar verbonden. Dit gebeurt met Epics, Capabilities, Features, User Stories en Enablers.

Epics

Je begint met de grote, strategische doelen die je als organisatie wilt bereiken. Deze grote doelen worden Epics genoemd. Stel je bijvoorbeeld voor dat je organisatie het idee heeft om een nieuw digitaal platform te lanceren om eigen medewerkers opleidingen aan te bieden. Dit grote doel is je Epic. Op Portfolio niveau wordt deze Epic op de Portfolio Backlog geplaatst.

Capabilities of Features

Deze Epics zijn nog te groot om door een team op te lossen. Sterker nog het kan zijn dat een Epic verdeeld wordt over meerdere ART’s op Large Solution niveau. Kortom de Epic moet worden opgeknipt in zogeheten Capabilities. Dit zijn Backlog Items die op de Solution Train Backlog worden gezet.

Deze Capabilities kunnen vervolgens op Program niveau worden opgesplitst in Features. Mocht het Large Solution niveau niet bestaan dan ga je van Epics direct naar Features.

Om een voorbeeld te geven: onze Epic van het digitale platform heeft als Capability ‘het ontwikkelen van de gebruikersinterface’, terwijl een feature de ‘zoekfunctie’ kan zijn.

User Stories

Een Feature wordt opgeknipt in User Stories. Dit is ook het niveau waar men op Team niveau mee aan de slag kan. Voor de Feature van het toevoegen van een zoekfunctie, is de User Story: “Als Marketeer binnen ons bedrijf wil ik mijn zoekresultaten kunnen filteren op onderwerp, zodat ik geen onnodige informatie hoef door te nemen”.

Enablers

Dit zijn backlog items die noodzakelijk zijn voor de infrastructuur, onderzoek of andere werkzaamheden die blokkades of toekomstige werkzaamheden kunnen vertragen. Enablers voegen niet direct waarde toe voor de eindgebruiker. Maar zonder Enablers ga je in de toekomst tegen verouderde code of techniek aanlopen. Dit wordt binnen SAFe met een duur woord de Architectural Runway genoemd.

Een voorbeeld van een Enabler kan het opzetten van een nieuwe server zijn zodat alle video’s op ons digitale platform snel afspelen.

De verschillende rollen binnen SAFe

Hieronder geven we kort een overzicht van de voornaamste en de meer bijzondere rollen die binnen SAFe worden toegepast.

Team rollen

• Scrum Master / Team Coach: Binnen SAFe wordt de Scrum Master ook soms de Team Coach genoemd. Deze persoon is net zoals in Scrum verantwoordelijk voor het proces. Hij of zij faciliteert de Events en staat ten dienste van het team en coacht daarbij. Daarnaast kan de Scrum Master of Team coach ook helpen bij het toepassen van bijvoorbeeld Kanban en de principes en regels van SAFe overbrengen.
• Product Owner: De Product Owner is vergelijkbaar als in Scrum en is verantwoordelijk voor het beheren en prioriteren van de Product Backlog op Team niveau, contact met stakeholders en het maximaliseren van de waarde.
• Agile Team: Dit zijn de Developers en ze zijn net als in Scrum verantwoordelijk voor de kwaliteit van het werk en bepalen hoe dat gedaan wordt.

Program (ART) rollen

• Release Train Engineer: Dit is de Scrum Master voor de ART. Deze persoon is verantwoordelijk voor het proces op Program niveau. Hierbij komt ook het faciliteren van de ART events kijken zoals de PI planning, PI system demo, Art Sync en Inspect and Adapt (I&A).
• Product Manager: Verantwoordelijk voor het definiëren van de Features en de ART Backlog. De Product Manager is soms één persoon, maar wanneer deze rol door een team van Product Managers wordt vervuld praten we over Product Management.
• System Architect: Vroeger werd deze persoon de System Engineer genoemd. De System Architect is verantwoordelijk voor de technische architectuur en visie van de ART. Ze zorgen ervoor dat de techniek tussen de verschillende teams is afgestemd. Architecten zijn vaak de bedenkers van Enablers.
• Business Owners: Dit zijn de belangrijkste stakeholders van de ART. Zij worden ook actief betrokken bij diverse events en bij de ontwikkeling van producten en diensten. Business Owners zijn verantwoordelijk voor de return on investment.
  

Large Solution rollen

• Solution Train Engineer: Vergelijkbaar met de Release Train Engineer, maar dan voor de Solution Train. Dit is nodig omdat het afstemming bevat voor de honderden of zelfs duizenden medewerkers. Waaronder ook de afstemming tussen leveranciers.
• Solution Management: Deze rol wordt vaak door meerdere Solution Managers ingevuld die verantwoordelijk zijn voor de Capabilities op de Solution Train Backlog.
• Solution Architect: In het verleden werd deze rol de Solution Engineer genoemd. Een Solution Architect is verantwoordelijk voor de visie en technische uitdagingen van de Solution Train. Deze functie doe je meestal ook gemeenschappelijk in een team van Solution Architecten.

Portfolio rollen

• Lean Portfolio Manager: Deze rol is niet officieel een SAFe rol. Binnen SAFe wordt wel gesproken over Lean Portfolio Management. Dit is een team bestaande uit iedereen die nodig is om het portfolio management in goede banen te laten verlopen. Dit kunnen bijvoorbeeld Enterprise Architects, Release Train Engineers en Product Management zijn, maar nog veel meer. In de praktijk is er toch vaak één iemand die de rol van Scrum Master pakt binnen het Portfolio Management team en die persoon wordt dan de Lean Portfolio Manager genoemd.
• Epic Owners: Verantwoordelijk voor het initiëren en definiëren van Epics, waarbij ze ook een Minimum Viable Product (MVP) opstellen. Ze maken zich hard voor dit initiatief en volgen ook nauwlettend de voortgang van de Epic binnen het portfolio.
• Enterprise Architect: Zorgt voor strategische technologische richting over het gehele portfolio. Zij initiëren vaak de Enabler Epics.
• VMO: Value Management Office (VMO). Ondersteunt het Lean Portfolio Management door het faciliteren van bijvoorbeeld dashboards en rapportages. Om uiteindelijk betere strategische beslissingen te kunnen nemen.

Andere rollen binnen SAFe

• SPC (SAFe Practice Consultant): In eerdere versies van SAFe, werkt de SPC de SAFe Program Consultant genoemd. De SPC is verantwoordelijk voor het trainen, coachen en implementeren van SAFe in de organisatie. Lees hier meer over de SAFe Practice Consultant (SPC).
• Agile Coach: Deze rol is binnen SAFe niet gedefinieerd. Alleen, in onze ervaring blijkt dat er bijna altijd Agile Coaches rondlopen. Deze hebben dan als rol om Scrum Masters, Product Owners of Release Train Engineers te helpen om hun rol te pakken en meer Agile te denken. Agile Coaches hebben vaak ook een overlappende rol met Lean-Agile Leaders en zijn onderdeel van LACE.
• Lean-Agile Leaders: De Lean-Agile leaders zijn de leiders van de Lean-Agile mindset en spelen daarom ook een belangrijke rol bij het succes van een SAFe implementatie. Dit zijn mensen die het mandaat hebben om bedrijfsprocessen te veranderen. Zij nemen de leiding binnen een SAFe transformatie.
• LACE: Lean-Agile Center of Excellence (LACE) is een team dat een Agile of SAFe transformatie ondersteunt en begeleidt. Dit wordt soms ook het veranderteam van de organisatie genoemd.
• System team: Dit team ondersteunt de Agile Release Train (ART) door het bieden van technische tools en omgevingen. Zo zorgen ze onder andere voor een infrastructuur en integratie van het werk dat de verschillende teams opleveren. Het voordeel is dat de Agile Teams zich kunnen concentreren op hun werk. Je zou het ook een integratieteam kunnen noemen.
• Shared Services Team: Dit team bestaat uit specialisten die niet in één Scrum team zitten. Zo zal een privacy of cybersecurity expert te weinig werk hebben om in een normaal Scrum Team mee te draaien. Bovendien is deze expertise in andere teams ook nodig. Het Shared Services Team is een team van specialisten.
• Community of Practice (CoP): Dit zijn medewerkers die een gemeenschappelijk vakgebied of interesse delen en eens in de zoveel tijd met elkaar vergaderen om kennis te delen. Dit kan bijvoorbeeld een CoP van Scrum Masters zijn of een CoP van Data Engineers.

Configuraties van SAFE: waar moet ik bij een SAFe implementatie beginnen?

Het is niet nodig om als gehele organisatie direct over te stappen op SAFe. Dit kan stapsgewijs en op basis van ervaringen die worden opgedaan. Dat is wel zo Agile. SAFe kan op verschillende manieren worden toegepast. Daarom zal je bij de ene organisatie SAFe alleen zien op Team en Program niveau, terwijl een andere organisatie alle vier niveaus in gebruik neemt. Hier bespreken we wanneer je welk niveau wil toepassen, oftewel voor welke SAFe configuratie je kiest.

Essential: Zoals de naam al suggereert is dit niveau essentieel en kun je niet SAFe werken zonder dit niveau. Hierin zit het Team niveau en Program (ART) niveau.

Large Solution: Deze SAFe configuratie is voor aanzienlijke groepen medewerkers die samenwerken aan grote en complexe oplossingen (denk aan de vliegtuigen van Boeing). Meerdere Agile Release Trains werken met elkaar samen om het product te ontwikkelen. Er wordt samengewerkt op Team niveau, Program niveau en het overstijgende Large Solution niveau.

Portfolio: Portfolio SAFe wordt vaak gebruikt met de SAFe Essential configuratie. Door op strategisch niveau met een visie, strategische thema’s en grote initiatieven te komen kun je veel duidelijkheid en context bieden op Essential niveau.

Full SAFe: Hierin zitten alle eerder beschreven configuraties van SAFe verwerkt. Het is de meest uitgebreide versie. Deze configuratie is geschikt wanneer organisaties verschillende grote complexe producten ontwikkelen. Denk aan multinationals.

Meer weten over hoe je SAFe kunt implementeren in de organisatie? Lees hier over de SAFe Implementatie Roadmap.

Certificering: investeren in jezelf en jouw organisatie

Scaled Agile Framework is ontwikkeld door Dean Leffingwell en voor het eerst gepubliceerd in 2011. Sinds de introductie hebben er verschillende updates plaatsgevonden, met als doel het raamwerk te blijven verbeteren.

Wil jij weten wat SAFe is? Leer SAFe kennen tijdens onze compacte tweedaagse Leading SAFe training. Verder heb je de mogelijkheid om examen te doen en het SAFe Agilist certificaat te halen waarmee je je kennis kunt aantonen.

Daarnaast bieden we alle deelnemers van de Leading Safe training een ontwerpdoos aan. De doos bevat een werkvorm waarmee je op overzichtelijke wijze jouw SAFe implementatie ontwerpt. Bekijk de inschrijfpagina of deze actie nog steeds van toepassing is.

Mocht je de Leading SAFe training al gevolgd hebben en vind je SAFe Portfolio interessant? Volg dan de tweedaagse SAFe Lean Portfolio Management training. Als je slaagt voor je examen kun je hiervoor het SAFe Lean Portfolio Manager certificaat behalen.

Bronnen:

Scaled Agile Framework

Ook interessant:

• Welke SAFe certificering past bij jou?
• DevOps Praktijken in SAFe
• Over de rol van het management bij transformaties?
• Wat is het verschil tussen Doing Agile en Being Agile?

Vind je dit artikel interessant?

Volg ons op LinkedIn (we delen onze blogs met je)

Over de auteur: Rob Koppenaal

Rob is Agile coach en trainer. Met zijn ervaring uit informatiekunde, toegepaste cognitieve psychologie, datingcoach, Product Owner en Scrum Master / Agile Coach van vele teams geeft Rob het theoretische kader met praktische oefeningen om blijvende veranderingen te realiseren. Met het resultaat dat er een hoop wordt gelachen en cursisten met motivatie en kennis naar huis gaan. Naast anderen helpen te ontwikkelen, is Rob ook altijd bezig met zichzelf te verbeteren.