SAFe

Het SAFe model is een framework voor organisaties waarin meerdere teams werken aan (complexe) producten in een steeds veranderende omgeving. Met dit model wordt een organisatie op een Agile-wijze ingericht waarbij de focus ligt op het genereren van klantwaarde en het continu vergroten van de kwaliteit van het opgeleverde product. SAFe is een methode waarin het gebruik van Scrum, Kanban en Lean wordt gecombineerd én opgeschaald zodat meerdere teams in afstemming met elkaar werken aan het continu opleveren van waarde voor de klant.

Achtergrond en doel

In een wereld waarin veranderingen, geplande en niet-geplande, elkaar steeds sneller opvolgen is de mogelijkheid tot transformatie een steeds essentiëlere eigenschap aan het worden. Bedrijven zullen hun dienstverlening steeds sneller moeten zien aan te passen om te blijven voldoen aan klantwens, regelgeving en technologische ontwikkelingen.

Daarmee wordt de uitdaging voor de bestaande IT infrastructuur, het businessmodel en organisatorische inrichting (hiërarchie) om aan te sluiten bij de snelheid van de verandering steeds groter. Het SAFe model (Scaled Agile Framework) helpt organisaties zich zodanig te gedragen en in te richten dat kan worden aangesloten op de snelheid van de verandering van klantwens, regelgeving en technologie.

Hoe werkt SAFe?

Het SAFe model is ingericht langs een aantal vaste functionele niveaus in de organisatie. Ieder van deze niveaus is zodanig op elkaar afgestemd dat ze in dezelfde cadans werken aan het opleveren van klantwaarde.

De drie niveaus die worden gebruikt zijn:

Essential (voorheen Program en Team Level): 

SAFe gebruikt een aantal criteria die minimaal gebruikt moeten worden om via Agile teams en een Agile Release Train te kunnen produceren:

• Zelforganiserende teams bestaande uit een Product Owner, Scrum Master en Developers. Het Scrum Framework en Kanban worden gebruikt om producten op te leveren.
• Meerdere Agile teams vormen samen een Agile Release Train (ART). Deze samenwerking levert een zogenaamde Continuous Delivery Pipeline (CDP) op. In de CDP wordt in een vaste cadans een (deel)product opgeleverd.
• Het Program Increment bestaat uit vijf iteraties, in de eerste vier iteraties wordt een (deel)product opgeleverd. In de vijfde iteratie is er tijd voor een IP-iteration. Dit is de innovatie en planning iteratie. Er wordt niet aan een deelproduct gewerkt, maar de teams gaan aan zichzelf werken om creatieve ideeën te bedenken.

In de Essential-laag zijn een aantal rollen van groot belang:

• De Product Manager beheert de Program Backlog en het product. Het is zijn / haar verantwoordelijkheid dat de juiste features worden opgenomen en dat het product conform klantwens wordt opgeleverd.
• De Release Train Engineer bestuurt de Agile Release Train. Hij of zij is, vergelijkbaar met de Scrum Masters taak, verantwoordelijk voor het gehele proces en bewaakt de regels van de SAFe werkwijze.
• De System Architect ziet toe op het volgen van de kaders vanuit de architectuur.

Het product wordt het Program Increment (PI) genoemd. In een PI Planning wordt ieder kwartaal door alle teams in een ART gewerkt aan de planning. Aan het einde van de sessie wordt duidelijk waar ieder team komende drie maanden aan gaat werken.

Large Solution: Als er meerdere ART’s nodig zijn voor de ontwikkeling van een product wordt een zogenaamde Solution Train ingericht. Hierin ziet de Solution Train Engineer toe op het proces, het Solution Management ziet toe op het product en de technische kaders worden bewaakt door de Solution Architect.

Portfolio: Agile en Lean principes worden op het hoogste niveau in de organisatie toegepast om de strategische thema’s te besturen. Business Agility, de wendbaarheid van de organisatie, wordt daardoor ook op dit niveau ingebed. Epic Owners zien toe op de prioritering van de strategische thema’s, inclusief budgettering. De Enterprise Architect ziet toe op het opstellen en bewaken van de technische kaders.

Voorbeelden van toepassing

Veel grote bedrijven werken met deze methode of afgeleide methodes. Denk hierbij aan ING en Aegon. Er zijn ook bedrijven die de Agile mindset zelf verder hebben ontwikkeld binnen hun eigen ontwikkelomgeving, voorbeelden hiervan zijn Amazon en Spotify.

Alternatieven voor het SAFe model

Waar het SAFe model een vaste structuur kent met duidelijke kaders en rollen zijn er ook organisaties die nog meer verantwoordelijkheid en vertrouwen bij de teams zelf willen beleggen voor optimale wendbaarheid en klantwaarde.

Wellicht het bekendste voorbeeld hiervan is het zogenaamde Spotify model.

Kenmerken van het Spotify model zijn:

• De organisatie creëert zijn eigen model
• Gebaseerd op transparantie en vertrouwen
• Streeft naar eenvoud en weinig afhankelijkheden tussen de teams
• De procesbeschrijving is zeer summier, de samenwerking is leidend

In de structuur van het Spotify model wordt gewerkt met een inrichting van teams genaamd Squads. Deze teams hebben alle kennis aan boord voor het product dat zij moeten opleveren. De Product Owner ziet toe op de prioritering en Agile Coaches kunnen ondersteunen bij de onderlingen samenwerking. Meerdere squads vormen een Tribe.

Collega’s met dezelfde inhoudelijke kennis werkend in verschillende Squads in een Tribe komen samen om ervaringen en kennis uit te wisselen in zogenaamde Chapters.