Agile werken: de flexibele aanpak

Agile is geen methode. Het is een manier van kijken naar werk waarvan de uitkomst nog niet vastligt. Zeventien softwareontwikkelaars legden die manier vast in het Agile Manifesto. Ze schreven het van 11 tot en met 13 februari 2001 in skidorp Snowbird in de Amerikaanse staat Utah. Dat manifest telt vier waarden en twaalf principes en past op één pagina. Scrum, Kanban en SAFe zijn methodes die op dat denken zijn gebouwd. Wie de denkwijze en de methode door elkaar haalt, koopt een methode zonder te weten waarvoor.

Wat betekent agile werken in de praktijk

Agile werken betekent dat je een groot plan opknipt in korte rondes en na elke ronde iets bruikbaars oplevert. Zo’n ronde heet een iteratie. Dat is een afgebakende periode waarin het team een klein stuk van het geheel af maakt en laat zien. In de praktijk duurt een iteratie twee tot vier weken.

Het verschil met de klassieke aanpak zit in het moment waarop je fouten ontdekt. Werk je in één lange rechte lijn, dan hoor je pas na negen maanden dat de klant iets anders bedoelde. Werk je in rondes van drie weken, dan hoor je het na drie weken. Je gooit dan drie weken werk weg in plaats van negen maanden.

Neem een kaaswinkel die een bestelsysteem laat bouwen. De eigenaar vraagt om een klantenaccount met een spaarpunt, en na de eerste ronde van twee weken ziet ze het inlogscherm. Meteen blijkt dat haar vaste klanten helemaal niet willen inloggen; ze bellen liever. Die ontdekking kostte twee weken bouwen. In een traditioneel project was hij pas bij de oplevering gekomen.

De vier waarden uit het Agile Manifesto

Het zijn vier keuzes tussen twee dingen die allebei goed zijn. De officiële Nederlandse vertaling op agilemanifesto.org luidt:

• Mensen en hun onderlinge interactie boven processen en hulpmiddelen
• Werkende software boven allesomvattende documentatie
• Samenwerking met de klant boven contractonderhandelingen
• Inspelen op verandering boven het volgen van een plan

Let op het woord boven. De opstellers schreven er zelf een zin onder: ze waarderen alles wat rechts staat, maar hechten meer waarde aan wat links staat. Rechts is dus niet waardeloos.

Precies daar gaat het in veel Nederlandse teksten over agile mis. Je leest dan dat agile teams geen documentatie maken, geen contract nodig hebben of niet plannen. Dat staat er niet. Er staat dat werkende software zwaarder telt dan een dik rapport, niet dat het rapport overbodig is. Een team dat zijn ontwerpkeuzes nergens vastlegt, is niet agile maar slordig.

Wat de twaalf principes concreet van je vragen

De twaalf principes maken de vier waarden pas bruikbaar, want ze noemen gedrag in plaats van houding. Vier ervan bepalen hoe je week eruitziet.

• “Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.” Je zet dus een vaste opleverdatum in de agenda, ook als er weinig af is.
• “Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces.” Een wijziging in week 20 is dus geen scheldwoord maar informatie.
• “Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.” Dat vraagt dat iemand van de opdrachtgever tijd vrijmaakt, elke dag.
• “Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.” Zonder die terugblik verandert er niets en herhaal je dezelfde fout twintig rondes lang.

Het manifest gaat over software. Dat woord staat er letterlijk in. Teams buiten de ICT vertalen het naar “werkend product” of “bruikbaar resultaat”, en dat werkt prima, maar het is een vertaling en geen citaat. Wie beweert dat het manifest over marketing of zorg gaat, leest iets wat er niet staat.

Agile, Scrum, Kanban en SAFe: wat is het verschil

Agile is de denkwijze, de rest zijn manieren om die denkwijze in te richten. Je kunt agile werken zonder Scrum, en je kunt Scrum invoeren zonder ook maar iets agile te doen. De tabel zet de vier naast elkaar op wat ze zijn en op hun vaste ritme.

Scrum is het bekendste raamwerk binnen agile. Ken Schwaber en Jeff Sutherland noemen het in de Scrum Guide van november 2020 met opzet onvolledig: het legt alleen rollen, bijeenkomsten en werkstukken vast en laat de rest aan jou. Hoe de rollen precies heten en wat een sprint inhoudt, lees je in het artikel over Scrum en zijn rollen, events en artefacten. Zoek je de bredere vergelijking met de klassieke fasenaanpak, dan helpt het overzicht over projectmanagement, methoden en fasen verder.

Over SAFe hoor je zelden een eerlijk woord. Het is eigendom van een bedrijf dat trainingen en certificaten verkoopt. Dat maakt het niet slecht, maar het betekent wel dat de bron die SAFe aanprijst, er zelf aan verdient.

Werkt agile werken echt beter

Er is minder hard bewijs dan de verkooppraatjes suggereren. Het cijfer dat je overal tegenkomt, komt uit de CHAOS-rapporten van de Standish Group, een Amerikaans adviesbureau. Twee informatici van de Vrije Universiteit Amsterdam, Laurenz Eveleens en Chris Verhoef, vergeleken die cijfers in IEEE Software van januari 2010 met 5.457 echte projectvoorspellingen. Hun oordeel is hard: de maatstaf meet alleen of een schatting klopte, niet of het project iets opleverde.

Ze lieten ook zien hoe rekbaar dat is. Bij één bedrijf uit hun onderzoek liep het geslaagd-percentage van 94 naar 6 procent, puur door dezelfde gegevens anders te tellen. Een cijfer dat zo kan schuiven, kun je niet gebruiken om een aanpak te verkopen.

Serieuzer materiaal is er wel. Kim Dikert, Maria Paasivaara en Casper Lassenius van de Finse Aalto-universiteit onderzochten de invoering van agile in grote organisaties. Hun studie verscheen in 2016 in het Journal of Systems and Software. Zij zeefden 1.875 publicaties tot 52 bruikbare studies over 42 bedrijven en vonden 35 knelpunten en 29 succesfactoren. De vier factoren die er bovenuit staken: steun van de leiding, het model aanpassen aan je eigen situatie, training en begeleiding, en een gedeelde houding. Zelf tekenen ze erbij aan dat bijna 90 procent van die studies ervaringsverslagen zijn, dus geen gecontroleerd onderzoek.

De jaarlijkse State of Agile-rapporten worden veel geciteerd, maar die komen van Digital.ai, een leverancier van software voor agile teams. Een leverancier die onderzoek doet naar de populariteit van zijn eigen markt is geen neutrale bron. Gebruik die cijfers hooguit als indruk van wat bedrijven zeggen te doen, niet als bewijs dat het werkt.

Voor welk werk is agile geschikt en voor welk niet

Agile loont als de uitkomst onzeker is en bijsturen goedkoop is. Dat is de kern, en alles wat je verder leest volgt daaruit. Software, een nieuwe dienst, een website, een campagne: daar weet je vooraf niet wat werkt, en een verkeerde keuze corrigeer je in dagen.

Op drie soorten werk past het slecht. Ten eerste werk met een uitkomst die vastligt in de wet of in een vergunning; daar valt niets bij te sturen. Ten tweede werk waarin corrigeren duur is, zoals gestorte fundering of een gedrukte oplage van 20.000 folders. En werk met één harde datum en een vaste inhoud, zoals een subsidieaanvraag die op 1 november compleet binnen moet zijn.

Ook de overheid heeft die les geleerd, maar dan andersom. De Tijdelijke commissie ICT-projecten bij de overheid heet in de wandelgangen de commissie-Elias. Zij concludeerde op 15 oktober 2014 dat de rijksoverheid de beheersing van ICT-projecten niet op orde had. Een van haar regels voor nieuwe projecten luidt dat je de ontwikkeling faseert en per fase direct bruikbare producten oplevert. Dat is de kerngedachte van agile, opgeschreven door een parlementaire onderzoekscommissie.

Mijn oordeel: agile is geen verbetering voor elk team, maar voor werk met een onzekere uitkomst is het de beste van de beschikbare aanpakken. Voor werk met een vaste uitkomst is het duurder dan het waard is, omdat je overleg en opleverrondes betaalt voor veranderingen die niet komen.

Zo begin je zonder je organisatie om te gooien

Begin bij het ritme, niet bij de rollen. Kies één team en één project, spreek een ronde van twee weken af en zet twee afspraken in de agenda: een oplevermoment en een terugblik van een half uur. Meer heb je de eerste drie maanden niet nodig. Certificaten, borden en een scrummaster kun je altijd nog toevoegen.

Die terugblik is het deel dat teams als eerste schrappen en dat ze het hardst nodig hebben. Loopt die bijeenkomst vast in gemopper, dan helpt de aanpak uit het artikel over effectief vergaderen met een concreet resultaat. Wil je het werk van je team zichtbaar maken zonder meteen een duur pakket te kopen, kijk dan naar Asana en de kosten en alternatieven daarvan. Meer over samenwerken en werkmethodes vind je in de rubriek Organiseren.

Veelgestelde vragen over agile werken