blog-header SAFe deel 1

SAFe heet voortaan ‘SAFe 4.0 for Lean Software and Systems Engineering’. Het raamwerk heeft nu de intentie om het innoveren en onderhouden van zowel software voor bedrijfsprocessen, als zogenaamde cyber-fysische systemen, te ondersteunen. Cyber-fysische systemen zijn combinaties van software met hardware. Denk bijvoorbeeld aan de software in mobiele zendmasten, Internet of Things, software in auto’s, vliegtuigen, etc.

Uitbreiding of verduidelijking?

Agile-puristen gebruiken deze uitbreiding als argument om te zeggen dat SAFe steeds minder de Agile-principes representeert, en steeds meer voorschrijvend wordt en niet empirisch genoeg zou zijn.Ik ben het daar totaal niet mee eens (Zie ook mijn blog: Scaling Agile). Ten eerste is het geen uitbreiding van het framework, maar een verduidelijking. Er wordt nu een laag gevisualiseerd die er altijd al in zat, zeker in versie 3.0. Alleen werd die laag nog niet gevisualiseerd. Nu dat, ter verduidelijking, wel wordt gedaan, valt iedereen (niet gehinderd door inhoudelijke kennis) er ineens overheen.

safe4-600
In de 3.0 versie werd op portfolioniveau al in het klein gevisualiseerd dat er ‘value streams’ waren met 1 of meer ‘release trains’. In de 3.0 training legde ik altijd al uit dat er 4 lagen in een hiërarchie zijn met drie verhoudingen:

  • 1 corporate portfolio op N ‘value streams’
  • 1 ‘Value Stream op N Release trains
  • 1 Release train op N teams

Wat wel nieuw is dat met het visualiseren van deze laag in de mogelijke hiërarchie tevens een nieuw requirementstype is gedefinieerd, met een bijbehorende backlog:de ‘Capability’ in de ‘Value Stream backlog’. Het moge duidelijk zijn dat dit puur bedoeld is voor zeer grote bedrijven en voor grote, modulair opgezette producten. Denk hierbij aan een Tesla met diverse systemen voor navigatie, motormanagement, mediamanagement, autopilot, battery management, etc. Of een Airbus 380, of een groot ERP systeem met vele modules.

car-case-350_1

Voor de Tesla zou een Epic kunnen zijn:
‘As Tesla driver I want to move from A to B in the most convenient and reliable way, so I can focus on more important things than driving’.

De Capability zou kunnen zijn:
‘As Tesla driver I want the car to drive automatically, so I can read the paper on my way to work’

Features zouden kunnen zijn:

  1. ‘As Tesla driver I want lane assist, so I will not crash when I fall asleep’.
  2. ‘As Tesla driver I want park assist, so I can perfectly backwards park my car without causing damage to other cars’.
  3. ‘As Tesla driver I want break assist, so I will not crash into a car in a sudden distress situation’

Story onder Feature 1 zou kunnen zijn:

‘As Tesla driver I want the car to detect the sides of the lane I am driving in, so the car can respond to this’

Nieuwe rollen

Ook nieuw zijn een aantal rollen op deze laag. Ook hier zijn de agile puristen niet over te spreken. “Waarom weer extra rolnamen? Dan gaan mensen in grote organisaties hun functies op die veelheid aan rolnamen gaan ‘plakken en mappen’?”. Dat staat inderdaad op gespannen voet met een platte organisatie, iets wat de bedoeling is van agile in de keten. Ik ben het eens met deze angst. Maar daar ben je als Agile coach altijd bij vind ik. Het heten niet voor niets ‘ROLNAMEN’. Dus 1 persoon zou in theorie meerdere rollen op zich kunnen nemen. Al zijn sommige combinaties weer niet zo gewenst. Verder kun je het framework schalen naar behoefte, dus lagen weglaten naar behoefte.

De nieuwe rollen zijn:

  1. Value Stream Engineer
    De ‘Value Stream Engineer’ is identiek aan de ‘Release Train Engineer’ op program niveau (ik zou die ‘Program Increment Engineer’ hebben genoemd, omdat de verwarring vaak is dat deze rol over de releases gaat, maar dat is niet zo, hij faciliteert het ritme van de trein). Je zou ook kunnen zeggen dat dat gewoon allemaal Scrum Masters zijn, zoals LeSS ook voorstelt. Vind ik ook prima. Maar in SAFe kiezen ze ervoor het andere namen te geven. ‘What’s in a name’ zeg ik dan.
  2. Solution Architect / Engineering
    De Solution Architect, of Engineering als rol overziet de gehele solution, het product. Deze rol is vergelijkbaar met de System Architect op Program niveau weer. Ook daar vormt de architect een belangrijke rol als sparring partner van de Product Manager. Hier dus samen met de Solution Manager als rol.
  3. Solution Management
    Solution Management is het equivalent van Product Management op Program niveau weer. Ook hier zou je kunnen zeggen het zijn allemaal Product Owners, noem ze dan ook zo. Ik kom meerdere vormen van hiërarchische naamgeving tegen als het om scaling agile gaat. Wat te denken van operationeel, tactisch en strategisch Product Owner? Wederom, ‘What’s in a name’. Als je maar weet wat er wordt bedoeld, en het verwachtingen management bij de klant goed doet.
    In de ideale situatie wil je de organisatie natuurlijk zo plat hebben dat er slechts sprake is van 1 laag, en 1 Product Owner. Dus Business vertegenwoordigd door Product Owner, die 1 op 1 inhoudelijk een bouwteam aanstuurt. Dat is ideaal, maar voor sommige grote geïntegreerde producten of business processen moet je meer doen. Alles met boerenverstand blijven doen dus.
  4. Customer
    Alle toevoegingen en aanpassingen ten opzichte van versie 3.0 zijn ingegeven vanuit klanten en organisaties die SAFe hebben geadopteerd. De samenstellers van het framework doen niet anders dan luisteren naar de markt, en terug inbrengen van ‘best practices’ vanuit bestaande implementaties. Zo is ook de Customer als rol erbij gekomen. Deze ontbrak in het geheel in eerdere versies (en daar deden we het toch voor..;-)). Deze kan uiteenvallen in een interne klant, bij het aanpassen van de bedrijfsprocessen binnen 1 bedrijf (de directe klant), en de externe klant, bij het realiseren van standaard oplossingen zoals een ERP suite (indirecte klant). Het is altijd belangrijk om de klant in beeld te hebben, en vooral ook de context waarin de oplossing voor die klant gaat werken. Vandaar dat ook ‘Solution’ en ‘Solution Context’ hier worden genoemd.

Inklappen/uitklappen en de schaalbaarheid

Wat je nu ziet als je naar de website http://www.scaledagileframework.com/ navigeert is, dat je de nieuwe toegevoegde laag kunt ‘in en uitklappen’. Als je inklapt, verschijnt de oude 3.0 versie.

Hierbij smelten de requirements typen ‘Capability’ en ‘Feature’ samen, en wordt slechts het type ‘Feature’ nog maar gebruikt in een Program backlog. Analoog weer aan versie 3.0.

Als je nu deel uitmaakt van een kleine tot middelgrote organisatie, en je kijkt naar de uitgeklapte versie, klap hem snel weer dicht. Want de uitgeklapte versie zal alleen bij zeer grote ondernemingen en producten gebruikt gaan worden. Ik heb voor een bedrijf met een R&D-afdeling van 120 man 4 releasetreinen van 30 personen gerealiseerd. Hierbij zijn alleen de program -en teamlaag geïmplementeerd.

Lees de hiërarchie die ik vooraan in deze blog noem. Je kunt het framework op en afschalen zover als je wil. Je moet het op maat maken per organisatie, en zelfs per organisatie onderdeel. Dus voorkom dat je dogmatisch dit model 1-op-1 probeert te plotten op je organisatie!

Geïnteresseerd in meer kennis over SAFe? Volg de opleiding Leading SAFe ®4.6

Voor meer informatie kunt u contact opnemen via cibitacademy.nl@inspearit.com één van onze specialisten vertelt u hier graag meer over.

 

Heeft u een vraag?

Neem contact op