Hoe kan Scaled Agile Framework je helpen agility te verspreiden in je organisatie?

Scaled Agile Framework (SAFe)

Scaled Agile Framework (SAFe) was onlangs toe aan versie 4.0. In de woorden van de makers levert het raamwerk “knowledge for the people building the world’s most important systems.” 

De populariteit van Dean Leffingwell’s Scaled Agile Framework (SAFe) maakt het vinden van een bijpassende training of consultant makkelijk. Er zijn veel artikelen, handleidingen video’s online te vinden. Het certificeringsproces is helder en goed doorontwikkeld.

Leffingwell schreef het boek Scaling Software Agility op basis van best practices voor grote ondernemingen. Dat boek stond aan de basis van SAFe. In november 2016 komt Leffingwell’s nieuwe boek, SAFe® 4.0 Distilled: Applying the Scaled Agile Framework® for Lean Software and Systems Engineering uit. Een overzicht.

SAFe schrijft organisaties die willen overstappen op het raamwerk precies voor wat er gebeuren moet. Een valkuil is om zonder verder na te denken alle elementen toe te passen. Je moet wel begrijpen wat je aan het doen bent om niet, zoals bij elke method of raamwerk kan gebeuren, te verzanden in loopgraafoorlogen rond jargon, en zwart-witdenken. Kun je een leek makkelijk uitleggen wat teamwork, program work, business epics, technical epics en een scala aan metrieken inhouden, inclusief rationale? Complexiteit kan dan maar zo de kracht van eenvoud, dat zo nadrukkelijk aan de basis van Agile ligt, teniet doen.

A fool with a tool is still a fool

Introductie van SAFe

Het grafische overzicht op de startpagina van Scaled Agile Framework‘s website, of de enorme posters van SAFe kunt vinden in kantoortuinen, zijn overweldigend. Henrik Kniberg, een ster voor het voetlicht brengen van de essentie van diverse agile aanpakken, houdt het bij onderstaande afbeelding.

Een team in SAFe bestaat uit 8-10 mensen. Het team is zelfvoorzienend om software af te leveren. Het team regelt end-to-end de vertaling van requirements naar geteste code en deployment in de benodigde omgevingen. Verschillende teams creëren samen wat SAFe een Release Train noemt. Dat kan een project of een programma zijn, een bundeling van elementen die samen toegevoegde waarde hebben, een product of dienst vertegenwoordigen. Het is wat de opdrachtgever een projectresultaat noemt, zonder te weten welke componenten nodig zijn om dat neer te zetten.

In SAFe termen bestaat een Release Train uit een 50-125 individuen bestaand team van teams. Zoals een echte trein rijdt de Release Train volgens dienstregeling. Vertrek- en aankomsttijden kan een organisatie zelf flexibel inrichten. Komt er elke maand, kwartaal of halfjaar een release van een Program Increment? SAFe ziet het liefst dat alle mensen voltijds met focus werken aan de realisatie van dat Program Increment, ongeacht de organisatorische ophanging van de mensen. Het idee van de (tijdelijke) matrixorganisatie is dus ook bij SAFe van toepassing.

Een Portfolio is een verzameling van deze Program Increments, het totale budget dat in een IT-afdeling aan softwareontwikkeling wordt bested. SAFe onderkent Program Portfolio Management en ziet daar graag de verantwoordelijkheid voor de strategie en beslissingen over inzet van mensen en middelen.

Als team aan de slag en met de Release Train mee

Elke Release Train – 50-125 mensen – ontmoeten elkaar aan het begin van elke release cycle om Program Increment Objectives te stellen en de vertaalslag te maken naar doelstellingen voor elk niveau om het Program Increment mogelijk te maken. Zo’n gezamenlijke planningsbijeenkomst duurt 2 dagen en heeft naast een gedragen plan enkele andere voordelen. Teamvorming, face-to-faceafstemming en toetsing van risico’s en impediments wordt op dat moment en dus voorafgaand aan het echte uitvoerende werk gedaan.

Als de teams in gezamenlijkheid hebben gepland en hun commitment voor het resultaat hebben gegeven, is er voor het programmamanagement een klein coördinatieteam nodig, in SAFe termen het releasemanagement team, bestaand uit een Release Train Engineer (program facilitator, hoofd scrum master, Product Management en wellicht enkele ondersteunende stafleden rond bijvoorbeeld architectuur en testen. Dit team komt wekelijks bij elkaar.

Voor de borging van kwaliteit van software stelt SAFe een aantal practices voor zoals een emergent architecture, continuous integration en Test Driven Development. Verder zijn klassieke eXtreme Programming technieken als pair work (niet alleen programming), refactoring (verbeteren van bestaande code) en collectief eigendom ingebed.

SAFe op portfolioniveau

Op portfolioniveau kijkt SAFe naar de mogelijkheid van de IT-organisatie om daadwerkelijk nieuwe, werkende software te leveren en deze te onderhouden of te beheren. SAFe heeft diverse metrieken daarvoor. Denk aan employee engagement, customer satisfaction, agility, time-to-market, kwaliteit en de samenwerking met externe partners. SAFe raadt burn-up charts aan om de voortgang van een individuele epic te meten en een staafdiagram voor het gerealiseerde e nog te verrichten werk om de voortgang van epics onderling te kunnen vergelijken.

Veel organisaties die met agile ontwikkeling bezig zijn, concentreren zich op team niveau met sprints of iteraties. SAFe richt zich nadrukkelijk op programmaniveau, waarbij 5-15 teams betrokken zijn.

Is SAFe wel goed?

Scrum grondlegger Ken Schwaber suggereerde in een blogpost UnSAFe at any Speed in 2013, dat SAFe in wezen Rational Unified Process (RUP) in een nieuw jasje is. IBM’s RUP is geen blijvertje gebleken, en dus hebben de RUP-mensen de agile omgeving opgezocht. Dean Leffingwell, de drijvende kracht achter SAFe, was een senior vice president bij Rational Software Corporation (nu een IBM-divisie). Veel contributors to SAFe hebben ook een Rational of IBM-achtergrond. Er is aangegeven dat waar de Agile Software Movement uit de praktijk geboren is, RUP, SAFe en andere modellen een theoretische basis hebben. Al zou Schwaber gelijk hebben, is dat erg?

Het lezen van de beschrijving van SAFe geeft een ander beeld. Net zoals veel andere agile aanpakken, leunt ook SAFe op Scrum, XP en Kanban. SAFe is daarmee minstens op tientallen jaren praktijkervaring gestoeld. Je kunt wel stellen, dat SAFe als zodanig ook maar een tussenstap, een manier om schaalbaarheid van agile werken mogelijk te maken is, dat ten onrechte wordt vermarkt als eindoplossing.

Is SAFe slecht? Dat hangt ervan af. Als je organisatie baat heeft bij een ‘volg de regels’ aanpak, is SAFe waardevol. Als het voortbrengingsproces van software al volwassen is, en je meer op de lijn van ‘aanpassen van regels’ of ‘negeer de regels’ zit, moet je niet SAFe, maar een lichtgewicht, niet-voorschrijvend raamwerk kiezen. SAFe kan een goede stap zijn in de overgang naar bedrijfsbreed agile toepassen. Daarna moet de organisatie uitvinden welke verbeterstappen gezet moeten worden. Dat vereist wel begrip van de context.

Benieuwd naar onze SAFe trainingen?

Of heb je vragen over dit vakgebied of één van onze trainingen? Neem gerust contact met ons op. We helpen je graag!