Van trend naar gevestigde orde: Scaling Agile

(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:

1. de snel veranderende economie (Dus behoefte aan een snellere ‘Time to Market’;
2. toenemende complexiteit in IT landschappen (Technische schuld en koppelingen);
3. het niet meer passen van het klassieke besturingsparadigma op de vele Scrum teams in IT;

is het bedrijf breed opschalen van agile en lean werkwijzen van een trend naar een feit geworden. Gaan bedrijven hier niet aan, dan wordt het hun dood, als ze al niet doodgaan aan de lean start ups die hen snel voorbij kunnen 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 zullen steeds wendbaarder dienen te 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: https://newgility.eu/2015/04/19/van-scrum-team-naar-agile-organisatie-deel-5/

De frameworks

Je ziet nu de scaling frameworks als paddestoelen uit de grond komen. Allemaal geven ze een voorzet om de principes van agile, Scrum, lean op te schalen naar enterprise niveau. Reeds bekende Frameworks zijn:

1. LeSS (Large Scale Scrum) van Craig Larmann en Bas Vodde;
2. NeXuS (Scaled Professional Scrum) van Scrum.org (Ken Schwaber);
3. Spotify, wat eigenlijk geen framework is, maar een afspiegeling van de Spotify Organisatie op een gegeven moment;
4. SAFe (Scaled Agile Framework) van Dean Leffingwell.

Naar mijn mening hebben al deze frameworks 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 op een paar 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 team projecten, dus het opschalen van werken met scrum in 1 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 (‘Lean portfolio management’ en ‘Lean budgeting’), hetgeen in de praktijk moeilijk door te voeren is ivm jarenlang ingesleten financiële controle processen. De overige frameworks kennen dit niet.
• Omdat SAFe al een mogelijke hiërarchie (van werkvoorraden) laat zien, is het gevaar dat dit dogmatisch door een ‘blauwe’ organisatie wordt geïmplementeerd en geprojecteerd als organisatielagen van de bestaande organisatie. 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 team projecten 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 verander bereidheid 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 lostaten 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 her structurering 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, er is maar één aanpak die hier werkt, en dat is het agile implementeren van agile werkwijzen. 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 organisatie verbetering/verandering moeten gaan doen, en dat is per definitie géén status quo!