Vijf valkuilen bij het opschalen van Agile

Grote bedrijven zijn vooral op zoek naar snelle en eenvoudige manieren om de transitie van klassieke naar agile ontwikkeling te maken. Hoe sneller een transitie moet verlopen, hoe gevaarlijker de valkuilen zijn die over het hoofd worden gezien. Agile ontwikkeling is meer gebaseerd op duurzaamheid dan op simpelweg snel klaar zijn. Daarom draagt het management een grote verantwoordelijkheid voor het succes van de agile transitie. Een transitie die niet voor de grootste valkuilen waakt, wordt hoogstwaarschijnlijk een cargo cult. Naar buiten toe ziet de transitie er succesvol uit, maar intern blijven de voordelen van de transitie uit.

Hier hebben we vijf veelvoorkomende valkuilen op weg naar een agile organisatie samengevat:

1. Fundamentele Agiliteit

De overstap naar agile processen is makkelijk. Je dereguleert een beetje en stuurt een paar mensen op training. Daarna kunnen ze "Scrum doen" – of een andere agile aanpak kiezen. Maar als je het grote geheel bekijkt, heb je misschien 1% bereikt – 99% van de weg ligt nog voor je. De reis is nog lang. In het hart van agiliteit staat het Inspect+Adapt proces. Om dat te laten werken, heb je een bijzondere mindset nodig. Iedereen moet genadeloos in vraag stellen wat er op dat moment gebeurt – en veranderingen doorvoeren als het de verkeerde kant opgaat. Om Inspect+Adapt zinvol in de organisatie te verankeren, heb je twee dingen nodig: Eerst moet de bestaande werkwijze ontgift worden. Elementen van de bedrijfscultuur die ontwikkelaars ontmoedigen om ownership te nemen over hun processen, moeten worden verwijderd. Daarvoor moeten veel Command+Control processen overboord worden gegooid en moet het management van ontwikkelaars fundamenteel worden heroverwogen. Verandering komt er alleen als je die toelaat! Daarna moet een gezonde werkwijze worden gecreëerd. Je hebt een managementsysteem nodig dat ontwikkelaars aanmoedigt om verantwoordelijkheid te nemen voor hun eigen acties, beslissingen, veranderingen, mislukkingen en successen. Daarvoor moeten structuren en processen worden gecreëerd die de individuele bijdrage van ieder persoon oprecht waarderen – ongeacht of het management tevreden is met de richting of niet. Mensen zullen alleen hun bijdrage leveren als je ze de ruimte geeft!

Totdat het fundament voor agiliteit is gelegd, zal er geen agiliteit zijn. Teams zonder fundamentele agiliteit zullen noch voordeel halen uit agile schaling – noch eraan bijdragen.

2. Gereedschap

De ceremonies van Scrum invoeren kost slechts één dag, inclusief training en het besluit. Daarmee heb je de basis voor "agile werken". Kortetermijnplanning, regelmatige updates van het plan, productfeedback en incrementele procesverbetering zijn essentieel. Zo kunnen de developers na verloop van tijd de optimale werkwijze ontdekken. Je moet alleen heel veel tijd inplannen voor de optimalisatie als de engineering practices nog niet zijn ingevoerd. De developers moeten vertrouwd zijn met concepten als versiebeheer, Continuous Integration, testautomatisering, emergent design, TDD, BDD, pairing, code conventions – en nog veel meer dat XP te bieden heeft. Ze moeten bewust beslissen welke van deze praktijken in hun huidige context nuttig zijn. Zolang de developers deze praktijken niet kennen, kan het goed zijn dat ze "ritueel agile" zijn, maar geen echte agiliteit in de praktijk brengen. Een team zonder het juiste gereedschap kan de implementatie van geschaalde ontwikkeling zelfs vertragen.

3. Teamspirit

De vaak als zweverig afgedane teamgeest is enorm belangrijk voor systemische verbetering bij agile schaling. Veel managers denken dat persoonlijke doelstellingen (tot aan Stack Ranking toe) helpen om hoogpresterende medewerkers te krijgen. Agile schaling dient echter in de eerste plaats voor het opbouwen van een complex, adaptief systeem waarin veel mensen een bijdrage leveren. De noodzaak om bij te dragen aan het grotere geheel is veel belangrijker dan de bijdrage aan je eigen doelen. Teamgeest betekent hier dat individuen hun eigen belangen principieel ondergeschikt moeten maken om de missie van het bedrijf te bevorderen. Bij teamgeest gaat het er minder om „samen met anderen leuke dingen te doen" (bijvoorbeeld teamevents zoals raften, karten of paintball). Het gaat er in de eerste plaats om dat je er plezier in moet hebben om dingen te doen die helpen om samen vooruit te komen. Daarvoor hebben ontwikkelaars twee dingen nodig: Ten eerste, ze moeten weten hoe ze kunnen bijdragen. Omdat dit sterk afhangt van het individuele geval, ontstaat de bijdrage voornamelijk door zelforganisatie en intrinsieke motivatie. Ten tweede, ze moeten weten dat hulpvaardigheid loont. Alles wat een persoonlijk nadeel oplevert wanneer je anderen helpt bij het bereiken van een gemeenschappelijk doel, moet worden weggenomen. Een klassiek voorbeeld van „teamgeest" is voetbal: we hebben vaak gezien dat het spel niet gewonnen wordt door de beste speler. De winnaar is het beste team. In softwareontwikkeling is dat precies zo: sterren die elkaar de loef proberen af te steken, winnen niet. Je wint door krachten te bundelen, ideeën samen te brengen en gezamenlijk vooruit te gaan.

Groepen ontwikkelaars zonder teamgeest verspillen hun energie aan „bezigheid". Een geschaalde groep die geen team is, benut slechts een fractie van haar potentieel voor het bereiken van het gemeenschappelijke doel!

4. Transparantie

Veel organisaties falen door een gebrek aan kennis van het totale systeem. Ze kunnen niet globaal optimaliseren. Klassieke obstakels voor transparantie bestaan op alle niveaus: van de ontwikkelaar die niet weet hoe het werk van een collega hem beïnvloedt, tot de manager die niet kan zeggen wat de absolute prioriteit nummer 1 is. Dit gebrek aan transparantie leidt tot veel problemen. Het begint bij de ontwikkelaar die onbewust het werk van zijn collega's torpedeert en reikt tot hele teams die aan de verkeerde dingen werken. Niets hiervan is wenselijk, en hoe vaker dit gebeurt, hoe kritischer en belangrijker het is om de transparantie te vergroten. Sommige organisaties verspillen bijna hun volledige capaciteit aan het managen van problemen die door een gebrek aan transparantie zijn veroorzaakt. In zulke situaties is "afbeulen" waarschijnlijk een betere omschrijving dan "schaling". Er zijn veel manieren om de transparantie zo ver te vergroten dat schaling zinvol wordt. Een aantal daarvan zijn:

• Een Kanban opzetten – dat iedereen kan zien!
• Een centraal backlog waar alle teams uit putten
• Collective Code Ownership als basis voor "communicatie door code"
• Andons inzetten: Build Monitoring en "Stop the Line" op basis van geautomatiseerde tests
• Gezamenlijke Planning en gezamenlijke Reviews, waarin alleen het geïntegreerde product wordt getoond

Transparantie is omgekeerd evenredig met overhead en problemen. Of anders gezegd: bij agile schaling is transparantie evenredig met de ROI. Agile teams die transparantie missen, leveren geen zinvolle bijdrage aan de bedrijfsdoelen.

5. Focus

In veel organisaties is een van de grootste problemen een verkeerde focus op bezettingsgraad: men beheert werk en brengt taken naar de medewerkers. De onderliggende aanname is dat je waarde creëert door iedereen maximaal "bezig" te houden. In een agile organisatie is het precies andersom: wij brengen de mensen naar het werk dat de moeite waard is om te doen. We weten dat er geen positief verband bestaat tussen waardecreatie en bezettingsgraad. We richten ons op het opleveren van een bruikbaar product – dingen af krijgen. Een klassiek probleem in veel organisaties is dat door de poging medewerkers volledig te bezetten, veel dingen "in bewerking" zijn: daarvoor heb je task-switching en coördinatie nodig. Maar zelfs in de meest triviale scenario's leidt het resulterende verlies van focus tot een enorm verminderde ROI en significant toenemende doorlooptijden: we besteden te veel tijd aan het uitzoeken waarom niets afkomt – en te weinig aan het daadwerkelijk afkrijgen van dingen. Het kernidee achter focussen is: het kost aanzienlijk minder om eerst het verkeerde te doen en daarna het juiste – dan twee dingen tegelijk te doen. Hoe triviaal dat ook klinkt, het is moeilijk om te realiseren: de hele organisatie heeft een duidelijk gesorteerde lijst van doelen nodig, en elk doel moet eenduidig geprioriteerd zijn. Er is precies één enkele prio 1. Vervolgens moet "Work in Progress" strikt begrensd zijn. Focus vereist dat managers hun houding fundamenteel heroverwegen: je moet accepteren dat "stilstand" minder kost dan overbelasting. Je kunt ook niet alles tegelijk krijgen. Ongefocuste teams zijn weliswaar "goed bezet", maar uiterst ineffectief. Hoe minder gefocust, hoe langer ze nodig hebben om waarde te creëren.

De valkuilen bij het opschalen van Agile

„Agile opschaling" die zich geen zorgen maakt over de bovengenoemde valkuilen, wordt hoogstwaarschijnlijk een cargo cult. Naar buiten toe ziet de transitie er succesvol uit, maar intern blijven de voordelen van de transitie uit. Voor succesvolle agile transities is het een gangbare aanpak om ervaren experts aan boord te halen die al „aan het front hebben gevochten" en de valkuilen al kennen.

Om de valkuilen in een opgeschaalde omgeving te omzeilen, raden we aan:

• Management-ondersteuning voor de transitie. Om de valkuilen te dichten, moet er behoorlijk wat in de organisatie op z'n kop worden gezet. Dat vereist onvoorwaardelijke steun van het management.

• Een Agile Transition Team (ATT) opzetten, waarin zowel managers als ontwikkelaars zitten. Het ATT heeft een duidelijke veranderings-backlog, waar iedereen gezamenlijk aan werkt.

• Executive Coaching voor de sleutelpersonen in de transitie. Daartoe behoren lijnmanagers net zo goed als Product Owners en Scrum Masters. De externe coach moet ervaring hebben met agile scaling!

• Technisch Coaching helpt de teams om sneller de juiste tools en vaardigheden in handen te krijgen: dat betaalt zich heel snel terug in een kwalitatief beter product!

• Een adviseur inhuren om de transitie te leiden. Deze persoon moet precies weten wat hij of zij doet en compromisloos te werk gaan. Hij of zij moet de bevoegdheid hebben om ook impopulaire veranderingen door te voeren.

• Opleiding voor iedereen op het gebied van agiliteit. In een veilige trainingsomgeving is de impact van de transitie veel makkelijker over te brengen.