Scaling Agile - Van trend naar gevestigde orde
Een visie op de trend en de verschillende scaling frameworks
De trend
Na 50 jaar op dezelfde manier IT bedrijven zien we eindelijk een kentering.
Door de druk van…
- de snel veranderende economie - dus een behoefte aan een snellere time-to-market;
- de toenemende complexiteit in IT-landschapen (technische schuld en koppelingen);
- het niet meer passen van het klassieke besturingsparadigma op de vele Scrum teams in IT;
…is het bedrijfsbreed opschalen van agile en lean werkwijzen van een trend tot een realiteit geworden. Gaan bedrijven hier niet in mee, dan wordt het hun einde. Als ze al niet het loodje leggen vanwege de lean start ups die ze links en rechts voorbij streven.
Bedrijven en producten worden steeds meer ‘IT driven’. En om nog maar zo een grote trend te noemen, daarna nog meer ‘Data driven’.
Organisaties moeten steeds wendbaarder worden als ze op alle veranderingen in willen spelen. Niet alleen qua processen en werkwijzen, maar de gehele organisatie zal aan constante verandering en verbetering onderhavig dienen te zijn. (Continuous organization improvement, zie ook mijn blog‘van Scrum team tot Agile Organisatie deel 5).
De frameworks
Je ziet nu de scaling frameworks als paddestoelen uit de grond schieten. Allemaal geven ze een voorzet om de principes van agile, Scrum, lean op te schalen naar enterprise niveau. Bekende Frameworks zijn:
- LeSS (Large Scale Scrum) van Craig Larmann en Bas Vodde;
- NeXuS (Scaled Professional Scrum) van Scrum.org (Ken Schwaber);
- Spotify, wat eigenlijk geen framework is, maar een afspiegeling van de Spotify Organisatie op een gegeven moment;
- SAFe (Scaled Agile Framework) van Dean Leffingwell.
Naar mijn mening hebben al deze frameworks ca. 80% overlap. Allemaal stoelen ze op agile en lean principes. En allemaal schalen ze Scrum werkwijzen op door hier een hiërarchie van te maken. Verschillen zitten hem in naamgeving, details, en mate van visualisatie van mogelijke hiërarchieën. Commerciële drijfveren polariseren deze modellen alsof ze totaal verschillend zouden zijn. Ik focus dus op de overeenkomsten:
Onderwerp/Framework |
LeSS |
SAFe |
Spotify |
SPS (NeXuS) |
Team van teams |
Requirements group |
Release train (50-125) |
Tribe (150) |
Nexus (9*9) |
Basis werkwijze |
Scrum |
Scrum XP |
Scrum |
Scrum |
Basis principes |
Agile |
Lean / Agile / Flow |
Agile |
Agile |
Allemaal bouwen ze een hiërarchie van de Scrum werkwijze, alleen bij SAFe is al een voorbeeld hiërarchie gevisualiseerd.
Allemaal vormen ze een team van teams om gezamenlijk geïntegreerde oplossingen te kunnen realiseren die domeingericht zijn. Allen noemen ze die teams van teams anders.
Allemaal gebruiken ze Scrum als basis werkwijze.
Aan alle frameworks liggen dezelfde principes ten grondslag, die iets zeggen over een houding en gedrag dat noodzakelijk is om zo te kunnen werken, laat staan te kunnen opschalen.
Interpretatie van de term ‘scaling’
Bij NeXuS bedoelen ze met de term scaling agile het uitvoeren van multi-teamprojecten, dus het opschalen van werken met scrum in één team, naar het geïntegreerd werken met Scrum met meerdere teams.
Ikzelf zie scaling meer als trend dat een agile manier van werken langzamerhand meer en meer over de gehele organisatie wordt toegepast, inclusief de business en het aanpassen van de organisatie structuur daarvoor. Daarmee wordt het een equivalent van de term ‘Enterprise agility’. Zoals het Scaled Agile Framework ook afdekt.
Dus eigenlijk is de vraag meer: ‘Wil je agile werken beperken tot de IT met multi-teams die gezamenlijk op een agile wijze werken, of wil je agile uitbreiden naar de gehele organisatie?’
Welke interpretatie je er ook aan geeft (en ik ben meer een generalist, dus mij maakt het niet zoveel uit), een organisatie die hieraan begint dient zich bewust te zijn van het verschil, en zichzelf een agile ambitie te stellen.
Haken en ogen, kanttekeningen, voor- en nadelen
Er zijn natuurlijk wel degelijk verschillen en kanttekeningen te maken, teveel om op te noemen. Ik licht er een paar toe:
- SAFe kent als enige ook een oplossing voor het besturingsvraagstuk, hetgeen in de praktijk moeilijk door te voeren is in verband met jarenlang ingesleten financiële controle processen. De overige frameworks kennen dit niet.
- Omdat SAFe al een mogelijke hiërarchie laat zien, is het gevaar dat dit dogmatisch door een ‘blauwe’ organisatie wordt geïmplementeerd en geprojecteerd op de bestaande organisatiestructuur en werkwijze. Hier moeten implementatie deskundigen zeer alert op zijn. We weten wellicht nog wel dat dit met RUP destijds ook is gebeurd, en daarom is men hier zo allergisch voor (veel te veel reeds voorgeschreven, en organisaties laten dan na om het kleiner te maken of op maat te maken naar hun situatie). Ergste is nog dat Dean Leffingwell destijds ook bijdragen heeft geleverd aan RUP.
- Versie 4.0 van SAFe laat een extra hiërarchie zien, die in 3.0 ook al zat, maar niet werd gevisualiseerd. Hierdoor zeggen de puristen dat SAFe alleen nog maar groter en meer voorschrijvend is geworden. Een goede consultant kijkt hier echter dwars doorheen, een gemiddelde medewerker of manager zonder agile ervaring echter niet.
- NeXuS heeft het dus alleen over multi-teamprojecten en hoe dit op te lossen, en past Scrum bijna elementair fractaal toe. Zie de volgende (fractal) figuur die ik ervoor heb gemaakt.
- LeSS en NeXuS hebben beiden een minimaal model. En zij propageren juist om alles minimaal te houden en zo plat mogelijk. Behoud dezelfde rolnamen, ongeacht het niveau in hiërarchie, behoud dezelfde eventnamen, etc. Dus deze frameworks eisen van een organisatie dat zij zelf bouwen aan de hiërarchie, vanuit de bestaande concepten van Scrum. Dit vergt van een organisatie al zeer veel creativiteit en kennis en ervaring met agile en Scrum, en dat is er vaak niet. Dan moet men leunen op de adviseurs. Andersom, zoals toegelicht bij SAFe, is het gevaar dat men een reeds gevisualiseerde hiërarchie 1 op 1 wil implementeren. Hierbij is ook leunen op goed advies noodzakelijk.
Wijze van implementatie
Afhankelijk van de ambitie en veranderbereidheid van een organisatie kun je meer als ‘big bang’ implementeren, of staps- en fasegewijs. Het spotify model is een voorbeeld van ‘big bang’. Je begint met de structuur zo neer te zetten, en dan beginnen. Dit is erg disruptief aan de ene kant, aan de andere kant versterkt dit wel het aanpassen en adapteren van de nieuwe werkwijze, en het loslaten van het oude. Ook Craig Larmann van LeSS zegt: eerst de nieuwe structuur rigoureus neerzetten, en dan beginnen. Bij bedrijven die niet gelijk over reorganisatie of herstructurering willen praten is dit moeilijker. Moeten we ze dan niet helpen? Als ik dat niet zou doen, had ik geen werk. Of je nu met een ‘big bang’, of stapsgewijs, of afdeling voor afdeling implementeert, wij hebben één aanpak die altijd werkt, en dat is het agile implementeren van agile frameworks. Het implementeren van agile frameworks is geen doel op zich, maar slechts een middel voor organisaties om de in het begin genoemde economische veranderingen het hoofd te kunnen bieden.
Gevestigde orde
Waarom van trend naar gevestigde orde? Ik vind nogmaals dat grote bedrijven die niet de wendbaarheid nastreven om de snel veranderende economie het hoofd te kunnen bieden niet zullen overleven. Overheidsinstanties daargelaten. Scaling agile, of enterprise agility zal dus gevestigde orde worden. Gevestigde orde riekt wellicht weer teveel naar een status quo, maar ik bedoel ermee dat organisaties standaard aan continue organisatieverbetering moeten gaan doen, en dat is per definitie géén status quo!
inspearit heeft een handige aanpak voor agile implementeren van agile (ook als pdf te downloaden). Hierin komt ook ons Scaled Agile Maturity Model ter sprake, waar ik een volgende blog aan zal wijden.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile of lees hier meer Agile gerelateerde blogs.