De 4 belangrijkste valkuilen van agile scaling

De afgelopen jaren omarmden steeds meer organisaties de principes van agile werken. Niet alleen in de wereld van softwareontwikkeling (waar de agile-principes het eerst werden toegepast), maar ook steeds vaker in de zakelijke dienstverlening.

Niet verwonderlijk: agile maakt organisaties wendbaarder en flexibeler, en zorgt ervoor dat ze sneller kunnen inspelen op veranderingen in de markt en in hun omgeving. Het resultaat: een kortere time-to-market en een overall betere performance.

Agile scaling: opschalen

De implementatie van agile-methodes als Scrum en Kanban vindt in eerste instantie plaats op teamniveau. Ze spelen soepel in op veranderende omstandigheden en krijgen de ruimte om te experimenteren en van elkaar te leren.

Ben je erin geslaagd om agile op teamniveau goed te laten werken? En lukt het om de belofte van een betere performance daadwerkelijk te verzilveren? Dan ontstaat bij veel organisaties de wens om agile verder op te schalen: naar meerdere agile-teams, of zelfs naar de organisatie als gehéél. Maar in de praktijk blijkt dat niet altijd eenvoudig.

Wat zijn de belangrijkste valkuilen bij agile scaling?

Valkuil 1: Scaling zien als doel op zich

De eerste stappen op het agile-pad verlopen goed. Het agile-team draait lekker. De teamleden hebben zich de nieuwe werkwijze goed eigen gemaakt en weten daadwerkelijk waarde toe te voegen. Opschalen maar!

Bij veel organisaties gaat het zo. Ze beginnen op kleine schaal met werken volgens de agile-principes. Vervolgens willen ze snel opschalen aan de hand van frameworks als Nexus, Spotify, SAFe (Scaled Agile Framework) en LeSS (Large Scale Scrum). Soms geven organisaties en teams al meteen aan dat ze bijvoorbeeld graag SAFe willen werken. Het opschalen wordt al snel een doel op zich.

Daarmee wordt voorbijgegaan aan een elementaire vraag: wat willen we eigenlijk bereiken? Vanuit het antwoord op die vraag kun je bepalen hoe agile werken hier een bijdrage kan leveren.

Wie goed nadenkt over de vraag of agile scaling daadwerkelijk waarde toevoegt, voorkomt dat opschalen een doel op zichzelf wordt. In sommige situaties is het mogelijk dat één team zelfstandig klantwaarde kan leveren. Dan is scaling niet nodig.

Valkuil 2: Meteen té veel willen

Heb je goed nagedacht over de vraag waaróm je wil opschalen? Heb je een helder doel voor ogen? En heb je goed voor ogen welk schalingsmodel goed bij je ambities past?

Trap dan niet in de valkuil om meteen té veel te willen. Het agile-gedachtegoed draait immers om experimenteren en het creëren van een permanente leercyclus. Wil je in één keer van nul naar honderd? Dan is de kans groot dat je je doel voorbij schiet. Bij agile scaling draait het om een transformatie van je organisatie. Zo’n transformatie kost veel tijd, dus neem die tijd ook.

Wees je er daarbij bewust van dat het doel tussentijds kan veranderen; agile draait immers om wendbaarheid en om het voortdurend incorporeren van leerervaringen in je werkwijze. Meer dan een ‘stip op de horizon’ gaat het bij agile werken om een ‘streep op de horizon’: de richting is duidelijk, het exacte eindpunt vaak nog niet. Een belangrijke reden om voortdurend te checken of je nog op koers ligt.

Valkuil 3: Niet werken vanuit waarde

Organisaties die nadenken over agile scaling, vergeten vaak het grotere plaatje. De eerste ideeën die ontstaan rusten vaak niet op waarde, maar op bestaande structuren en hiërarchie. Logisch, omdat dit de bestaande realiteit is voor de mensen in de organisatie. Maar te vaak is er geen goed zicht op hoe de afzonderlijke teams in samenhang bijdragen aan het hogere doel en op de waarde die ze leveren aan de klant of burger.

Daardoor nemen teams nog te veel beslissingen puur vanuit hun eigen blikveld. En hebben ze te weinig oog voor de afhankelijkheden tussen teams. Er zijn dan uiteindelijk wel meerdere teams actief die agile werken, maar de initiatieven hangen te weinig samen. Daardoor ontstaat suboptimalisatie en verdwijnt het hogere doel langzaam uit zicht.

Niet voor niets is systeemdenken een belangrijk element binnen veel agile scaling-methodes. Systeemdenken brengt de afhankelijkheden tussen teams in kaart. Het helpt je om de onderlinge samenhang en afstemming tussen de verschillende teams de bewaken. En het voorkomt dat de afzonderlijke agile-teams als los zand aan elkaar hangen.

Valkuil 4: De organisatie onvoldoende meenemen

Agile op teamniveau goed doorvoeren is vaak al een flinke klus en zeker niet iets dat je ‘zomaar’ even doet. Agile grijpt behoorlijk in op je organisatie. Het vergt een andere manier van organiseren, met andere processen, een gewijzigde besturing en andere rollen.

Dit alles vraagt ook om ander leiderschap. Soms wordt de hiërarchisch manager binnen agile automatisch ook de ‘product owner’, zonder dat er feitelijk iets verandert. Terwijl het bij agile onder de streep gaat om niets minder dan een totale transformatie van de werkwijze van je team.

Zodra je agile verder gaat uitrollen binnen je organisatie, wordt die transformatie-opdracht alleen maar groter. Des te belangrijker om de menselijke kant vooral niet te vergeten. Als medewerkers niet goed doorgronden waaróm ze agile moeten gaan werken, is elke transformatie gedoemd te mislukken.

Bovendien draait agile zoals gezegd om experimenteren en leren. Een veilige leeromgeving, waarin mensen fouten mogen maken, is dan onontbeerlijk. Als mensen zich in dat opzicht niet veilig genoeg wanen, zullen ze ook niet snel geneigd zijn om de omslag naar een agile werkwijze te maken.