Skip to main content

Agile op grote schaal: hoe minder hoe beter

Agile en Scrum zijn gemeengoed. Zelfs multinationals stappen erop over. Maar past dat wel? Agile is toch juist bedoeld voor kleine organisaties? Volgens Henk Jan Huizer, Martin Vodegel en Rini van Solingen wordt het schalen van agile vaak verkeerd begrepen. Zij beschrijven acht aandachtspunten om agile toe te passen op grote schaal.

Scrum toepassen is niet meer bijzonder. Agile als begrip en Scrum als meest gebruikte aanpak zijn inmiddels mainstream. Ook grote organisaties gaan volop met agile aan de slag. Soms in een enkel project of met een paar teams, maar tegenwoordig veel vaker op grote schaal. De vraag hoe je agile doet op grote schaal is daarom erg actueel en wordt steeds vaker gesteld.
Agility op grote schaal is een systematische en gestructureerde poging om een groot aantal teams agile met elkaar te laten samenwerken. Natuurlijk volgens dezelfde principes die aan de basis liggen van agile in die team. Veel Scrum-teams hebben, wil dus helemaal niet zeggen dat er op grote schaal agile wordt gewerkt. Als het namelijk op overkoepelende schaal niet goed is geregeld, dan komen de resultaten niet sneller en wordt het geheel niet beter. En het gaat uiteindelijk om die snelheid en wendbaarheid voor de klant. Sommige organisaties spreken zich bijvoorbeeld trots uit dat ze meer dan 250 Scrum-teams hebben. Als die teams niet goed op elkaar zijn afgestemd, dan blijft de impact van deze teams voor de klant beperkt. Er zijn misschien wel 200 teams te veel.
 

Integratie

De eerste vraag in grote organisaties is hoe men de teams zodanig inricht dat ze zelfstandig kunnen werken. Doordat het bestaande IT-landschap vaak sterk verzuild is en bestaat uit vele losse applocaties, is de eerste neiging om de nieuwe agile teams te plotten op de bestaande systemen. Een enkel team krijgt dan de verantwoordelijkheid over één enkele applicatie of één component. Een team kan dan zelfstandig de planning en uitvoering doen op die applicatie, en de product-owner prioriteert het werk voor dat team. Zodoende is agile opschalen in grote organisaties vaak het verdelen van teams over systemen. Echter, de waarde voor de klant zit in de combinatie van deze systemen. Zodoende is men vaak zonder het door te hebben, een waterval van procesfasen aan het vervangen door een waterval van teams. En dan duurt het nog steeds maanden voor een nieuwe dienst of feature bij de uiteindelijke klant terechtkomt. En hoe agile is dat?

Het is van het grootste belang bij agile op grote schaal vanaf de allereerste dag de focus te leggen op het integratievraagstuk over teams heen: om zo kort mogelijke ketens van teams te maken die warde leveren voor de eindklanten. Het concept van 'end-to-end value' en 'value streams' helpt daarbij. Oook schalingsraamwerken kunnen helpen. Zo introducteert SAFe (Scaled agile Framework) bijvoorbeeld het concept 'release train'. Daarin zit het zelfstandig en snel leveren van waarde aan eindklanten door een beperkte hoeveelheid teams geborgd. Dit vereist wel aanpassingen in de organisatie die verder gaan dan bestaande teams met Scrum te laten werken.
 

"Vaak vervangt men een waterval van procesfasen door een waterval van teams"


 

Ontschalen

Men is al snel aan het schalen. De dynamiek van schaling treedt al op als je met een paar agile teams aan de slag bent. Zeker in grote organisaties waar veel afhankelijkheden aanwezig zijn. Agile werken 'verknipt' namelijk een organisatie in kleine zelfstandige teams. Daardoor is het noodzakelijk om actie te ondernemen: om planning en resultaten weer bij elkaar te brengen.

Wat het meest essentiële is, klinkt heel tegenstrijdig: 'ontschaling'. Ontschaling is een doorlopend streven om de behoefte aan agile op grote schaal te voorkomen. De complexiteit in het IT-landschap moet daarom omlaag. Alleen dan kan een situatie tot stand komen waarin een beperkt aantal teams gezamenlijk, elke twee weken, waarde voor de klant kan opleveren. Agile op grote schaal vraagt dus feitelijk niet om opschalen maar om ontschalen. Hoe moeilijk dat ook is. Alleen wanneer grote organisaties in staat zijn om, ondanks hun omvang, zeer frequent software te releasen, pas dan is agile op grote schaal echt gelukt.
 

Aandachtspunten bij het schalen van agile

  • Schaal door focus te leggen op directe klantwaarde. Voorkom een focus op interne processen en interne bijdragen van teams. Neem daartoe value streams als uitgangspunt. Dat is namelijk de dimensie waarlangs klanten merken dat er iets verandert. Laat product-owners vanuit de business helpen bij het definiëren en prioriteren van de value streams. Zij hebben namelijk vaak het beste inzicht.

  • Vereenvoudig het IT-landschap. Het opzetten van complexe schalingsconstructies met veel rollen en processen komt vaak door het omzeilen van het echte probleem: de noodzakelijke versimpeling van een complex IT-landschap. Een belangrijke reden voor het gebrek aan snelheid zit vaak in een sterk versnipperd IT-landschap vol afhankelijkheden. Dat is op zichzelf niet zo verrassend: Conway's law uit 1967 leerde ons reeds dat de architectuur van een IT-systeem een afspiegeling is van de organisatiestructuur. Sterk verzuilde organisaties hebben zodoende ook de neiging om sterk verzuilde IT-landschappen voort te brengen. En die zijn doorgaans niet erg wendbaar. Een vereenvoudiging van het IT-landschap begint vaak bij een vereenvoudiging van de organisatie zelf.

  • Start met continuous delivery vanaf het begin. Bij agility op grote schaal heeft men vaak de neiging om het integratievraagstuk uit te stellen vanwege de complexiteit. Men begint dan met agile werken op teamniveau, waarbij elk team deelproducten oplevert maar de integratie over de teams niet of laat gebeurt. Continuous delivery zorgt ervoor dat integratie vroeg en vaak plaatsvindt. Continuous delivery is voorwaardelijk om met agile op schaal te kunnen werken. Elke ontwikkelaar moet binnen een uur feedback vanuit een automatische integratietest krijgen om integratieproblemen vroegtijdig te kunnen oplossen. Daarnaast is de continuous delivery een katalysator voor eenvoud. Het is namelijk ondoenlijk om sterk verkleefde en complexe oplossingen met continuous delivery aan te pakken. Tijdens de implementatie van continuous delivery gaan teams automatisch aan de slag met vereenvoudiging van de architectuur.

  • Gebruik een schalingsaanpak niet als blauwdruk. Pas bijvoorbeeld SAFe niet klakkeloos toe. Maak liefst een eigen schalingsmodel dat past bij de eigen situatie, de klanten, systemen en bekende knelpunten. Het Spotify-model werkt perfect voor Spotify. Het kopiëren van de schalingsoplossing van een ander werkt alleen als het probleem en de context identiek zijn en dat helaas maar zelden het geval. Maak ook niet de fout om denken en doen te scheiden. Als bijvoorbeeld SAFe wordt gebruikt, zorg er dan nog steeds voor dat de experts uit de teams meedoen op programma- en portfolioniveau.

  • Zorg dat de basis op orde is. Als teams veel onderlinge afhankelijkheden hebben, is het zaak dat teams betrouwbaar opleveren. In een keten van bijvoorbeeld vijf teams, waarbij elk team 80% van de planning haalt, bestaat de kans dat de keten niets oplevert. Bij elke sprint kan er namelijk één team zijn dat een cruciaal onderdeel niet op tijd klaar heeft, waardoor het eindresultaat niet werkt. Teams moeten dus in een schalende organisatie sterk voorslebaar zijn en proactief afstemming zoeken. Daartoe is het cruciaal om product-backlogmanagement goed op orde te hebben. Het is namelijk in de praktijk gebleken dat de meest voorkomende bron achter onvoorspelbare teams ligt in het ontbreken van een goed uitgekristalliseerde product-backlog.

  • Maak onderscheid tussen waarde- en componententeams. In de ideale situatie is elk team in staat om zelfstandig waarde voor de klanten op te leveren. Dan beslaat het team een complete value stream. In veel gevallen lukt dit echter niet en wordt om uiteenlopende redenen gewerkt met teams die een of meerdere componenten onderhouden en ontwikkelen. En al die componenten moeten dan weer geïntegreerd worden. Maak onderscheid tussen twee soorten teams: waarde/featuretemas en ondersteunende/componentteams. De eerste teams ondersteunen een value stream of een feature voor klanten. Zij leveren dus zelfstandig klantwaarde. Daarnaast kunnen er ook ondersteunende- of componentteams zijn. Zij zetten componenten of applicaties klaar die door de waarde/featureteams gebruikt kunnen worden.

  • Vergeet niet de governance aan te passen. De aanwezige governance past zelden bij grootschalig agile werken. Deze governance is namelijk een verankering van de oude verzuilde organisatie. Als een organisatie agile op grote schaal wil toepassen, dan moet de governance worden aangepast. Meestal vraagt dit om rigoureuze aanpassingen, die niet op voorhand helder zijn. Het is daarom raadzaam de governance stap voor stap te (her)ijken.

  • Installeer een 'Scaling Master'. Voorkom grote discussies en variëteit aan oplossingsvarianten. Maak iemand verantwoordelijk om het opschalen van agile te leiden. Dit is een tijdelijke rol gedurende het inrichten van grootschalig agile werken. Het invullen van die rol helpt bij het maken van een keuze en het snel doorvoeren van de benodigde veranderingen. Deze Scaling Master moet natuurlijk wel een expert zijn op het gebied van agile op grote schaal, hij moet alle boeken hebben gelezen en alle trainingen hebben gevolgd.



  •  
  •  



Auteurs: Hank Jan Huizer, Martin Vodegel en Rini van Solingen

TAGS

Copyright © 2019 Mavim B.V.