Erik Philippus is software- en systeemarchitect, Agile-coach, Scrum-trainer en bijna-pensionado.
Voor de tweede keer in korte tijd heb ik een artikel zitten lezen met gekromde tenen. Eerst een opiniestuk in de laatste Bits&Chips dat de vloer aanveegt met Scrum omdat – zo beweert de auteur – de opdrachtgever op geen enkele manier kon nagaan of hij aan het eind waar voor zijn geld zou krijgen. En nu een artikel in de laatste Mechatronica&Machinebouw met de veelzeggende titel: ‘Agile in een complexe omgeving is gekkenwerk’, dat Agile afschildert als ‘houtje-touwtje, ongecontroleerd, niet voorbereid en niet voldoende overdacht’.
En dat terwijl het speerpunt van de Agile-werkwijze toch is om in nauw overleg met opdrachtgevers en gebruikers producten op te leveren met een zo hoog mogelijke gebruikerswaarde in vooral complexe en innovatieve omgevingen. Waar gaat het dan toch mis? Ik heb daar mijn gedachten eens over laten gaan.
Twee geloven
Tijdens mijn overpeinzingen moest ik opeens denken aan een artikel dat Jaap van Rees, een van mijn leermeesters van het eerste uur, al in 1982 heeft geschreven: ‘De methode doet het niet’. Een welhaast profetische visie, want ook in het huidige tijdsgewricht waarin Agile mainstream is geworden, doet de methode het klaarblijkelijk nog steeds niet. Hoe komt het dat we decennialang de ene aanpak na de andere uit de grond stampen, terwijl het onderhand duidelijk mag zijn die niet (vanzelf) werken, zelfs niet (of juist niet?) als we ze nauwgezet volgen.
Op zich is het begrijpelijk – en ik denk ook wel terecht – dat we een methodiek beoordelen op praktijkresultaten, en niet op veelbelovende principes, innovatieve inzichten of juichende beloftes. Deze maatstaf hanterend, verliest de Agile-werkwijze toch behoorlijk veel van zijn glans. Ik schat zelf dat ongeveer de helft van de bedrijven die trots beweren agile te werken, daar in feite nog mijlenver vanaf zitten, en de term ‘agile’ als een hip laagje vernis gebruiken boven op een aanpak die is gebaseerd op het traditionele controle-denken, met het maximaliseren van de voorspelbaarheid als heilige graal.
Device lifecycle management for fleets of IoT devices
Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .
En ook dat is te begrijpen, want de mens is niet hardwired voor Agile. Ons krokodillenbrein schrikt zich een ongeluk als het ‘onzekerheid moet omhelzen’. Volwassen mensen houden van voorspelbaarheid en zekerheid – vooral in een hectische en onzekere omgeving. Zeker een oldschool manager zal niet snel afwijken van het gebaande pad en de vertrouwde, overzichtelijke watervalmethode opgeven. Zet zo iemand aan het roer in een (beoogde) agile werkomgeving en het gaat geheid fout. Want met schijnzekerheid loop je een keer tegen de lamp.
Zo heb ik een paar jaar geleden bij een grote multidisciplinaire organisatie meegemaakt dat de scrumteams zo’n 75 procent van hun tijd bezig waren met brandjes blussen, waardoor geen enkel project op tijd werd opgeleverd. Ik was aangetrokken als Scrum-coach en dacht dat ik de knuppel in het hoenderhok gooide toen ik tijdens een bijeenkomst zei tegen de verzamelde ontwikkelafdeling: ‘Volgens mij doen jullie waterval met gele briefjes op de muur.’ Tot mijn niet geringe verbazing begonnen mensen te knikken: ‘Ja, dat doen we inderdaad.’ Later zag ik dat de organisatie grote affiches had laten drukken met het bekende Scrum-procesplaatje geprojecteerd boven op het V-model. Twee geloven op één kussen – ja, daar slaapt inderdaad de duivel tussen.
Van hoog tot laag
De meeste nadelen van Agile die bovengenoemde artikelen opvoeren, vallen opmerkelijk goed samen met de valkuilen die ik als Agile-coach en Scrum-trainer al jarenlang onder de aandacht breng. De aanpak gaat gebukt onder wijdverbreide misverstanden, die niet zelden opgeld doen bij managers die worden geacht een organisatie te leiden op het glibberige pad naar agility. En als het resultaat dan tegenvalt, krijgt de methode de schuld. Terecht?
De afgelopen tien jaar heb ik een breed scala aan bedrijven geholpen Scrum te implementeren of te optimaliseren. Hoewel ik er altijd op hamer dat de rol van het (hogere) management cruciaal is in zo’n verandertraject en dat managers honderd procent betrokken moeten zijn en moeten meedoen met alle voorbereidingen en trainingen, is het vaak hetzelfde liedje: ze zijn op het laatste moment verhinderd voor de kickoff of hebben bij nader inzien toch geen tijd om een rol te vervullen in de nieuwe werkwijze. Bovendien: het team weet toch zelf wel wat er gemaakt moet worden? Scrum wordt dan gezien als een leuke manier van werken voor software-engineers.
Dit staat in schril contrast met mijn eigen ervaringen dat het management een doorslaggevende rol speelt in het succes van de nieuwe aanpak. Als mij één ding duidelijk is geworden de afgelopen jaren, is het dat Scrum een organisatiebrede aangelegenheid is, en dat iedereen, van hoog tot laag, het Agile-gedachtegoed tussen de oren moet hebben zitten, en waar mogelijk moet faciliteren om de werkwijze tot een werkelijk succes te maken. In alle andere gevallen is het hoogstens een suboptimalisatie.
Een paar jaar geleden vroeg een grote hightech-onderneming mij een lezing te geven, om de invoering van Scrum op alle softwareontwikkelafdelingen kracht bij te zetten. Voor een overvol auditorium begon ik met de vraag: ‘Wie van jullie is manager of projectleider?’ Slechts een paar handen gingen aarzelend omhoog. Ik stond dus voor zo’n 250 software-engineers, terwijl ik mijn praatje juist had toegespitst op de rol van het management bij de transitie. Naderhand ging ik verhaal halen bij de organisator van de introductiedag, en tot mijn niet geringe verbazing kreeg ik het antwoord ‘dat er over een jaar een vergelijkbare dag georganiseerd zou worden, maar dan voor het management’.
Zeker als het gaat om een afdeling die een start maakt met Scrum geloof ik niet zo in zelfsturing. Trek er gerust maar een jaartje voor uit voordat een scrumteam is uitgegroeid tot een geoliede, high-performance en zelforganiserende machine. Vooral in de beginfase zijn de dagelijkse bemoeienis en de onvoorwaardelijke support van het (hogere) management en projectleiders onontbeerlijk – en dan heb ik het ook nog eens over agile managers, die de Agile-mindset met hart en ziel omarmen, zich hebben bekwaamd in ‘dienend leiderschap’. Ik zie dat als een randvoorwaarde. Als daar niet aan wordt voldaan, is de kans groot dat Scrum inderdaad een ramp wordt voor opdrachtgevers of gekkenwerk is in een complexe omgeving.
Onbekend terrein
Het fundament van Agile is voortschrijdend inzicht: continu checken of je nog wel op de goede hoogte vliegt. Daarmee samenhangend: het is een empirische aanpak, wat betekent dat je de werkwijze aanpast aan de hand van de praktijk – ofwel: altijd je boerenverstand blijven gebruiken. Als je tot het inzicht komt dat het bouwen van een complex systeem goed uitgewerkte requirements of een gedetailleerd ontwerp vereist, dan is dat zo – en het is onzin om dat overboord te zetten omdat ‘we nu agile werken’.
Ik ben als softwarearchitect betrokken geweest bij de realisatie van de eerste volledig digitale pacemaker. Zoals bij elk nieuw medisch instrument zijn er zeer strenge regels voor toelating. Stel je nu eens voor dat de fabrikant tegen de FDA zou zeggen: ‘Tja, we werken nu agile, dus de specificaties van de nieuwe pacemaker weten we pas vlak voor we hem op de markt brengen.’ En al eerder heb ik gefulmineerd tegen het in hardcore Agile-kringen populaire concept van ‘just-in-time architectuur’: volgens mij de meest effectieve manier om de klok twintig jaar terug te zetten.
Elke implementatie van Agile hangt af van het type organisatie, de mensen en de producten – en zal dus moeten worden aangepast. Maar deze aanpassingen moeten wel gebeuren vanuit een juist begrip van de Agile-principes en de Scrum-practices. Dit neemt niet weg dat als je met Agile begint, je een aantal zaken in place moet hebben, waar iedereen (ook de directie!) met zijn tengels van af moet blijven – pas als je daarmee bent gestart, ga je met z’n allen leren hoe het effectiever en (wie weet) prettiger kan. Een agile organisatie is een lerende organisatie en de Agile-werkwijze heeft dan ook geen expliciet einddoel.
Kortom: de Agile-methode werkt niet (altijd), omdat ontwikkelaars worden losgelaten in onbekend terrein, zonder bezielende leiding van agile managers, die de teams behoeden voor de vele valkuilen en misverstanden. Sterker nog: vaak moeten teamleden knokken om te voorkomen dat managers de poten onder de scrumteams wegzagen. Dat de Scrum Guide niet spreekt over managers, heeft geleid tot de jammerlijke misrekening dat er geen (sturende, faciliterende en motiverende) rol is weggelegd voor managers in een Agile-aanpak.
Schouders eronder
Om op een positieve noot te eindigen: gelukkig zijn er ook succesverhalen, waarbij ik heb meegemaakt dat een organisatie grote stappen heeft gezet naar significant hogere doelmatigheid en groter werkplezier. En ik denk niet toevallig: in honderd procent van die gevallen was de directie volledig betrokken, toegewijd en vastbesloten om de transitie naar Agile tot een succes te maken.
Dus beste lezer: mocht je een manager of projectleider zijn bij wie Agile een negatieve klank heeft en bezorgt Scrum je slapeloze nachten, dan nodig ik je uit om eens na te denken over hoe je je schouders eronder kunt zetten om Scrum toch tot een succes te maken in jouw organisatie, in plaats van je af te vragen wat Scrum kan doen voor jou – om maar eens een bekend staatsman te parafraseren.
Anders dan een van de auteurs vraag ik me niet af of ik misschien een oude man word. Want dat ben ik al, met een kleine veertig jaar ervaring in de hightechindustrie. Ik ga binnen afzienbare tijd met pensioen, en met de voorbereidingen daarvoor ben ik al een tijdje bezig – op een watervalachtige manier, door het pakket van eisen goed uit te werken en de randvoorwaarden expliciet in beeld te brengen. Dat alles om straks op een lekkere agile manier te kunnen genieten van mijn volgende levensfase!