Wanneer je beter niet agile levert

De vraag die zelden meer wordt gesteld

"Niet elk project is even geschikt voor een agile aanpak." Die zin komt uit lesmateriaal en is bedoeld als nuchtere vaststelling, maar in een uitvraag kom je hem zelden tegen. Daar staat meestal al dat er agile gewerkt wordt, en gaat het gesprek verder over ritme en rolverdeling.

Het standpunt hier is smaller, en het is geen afkeer van scrum. Bij een IT-project met hoge onzekerheid werkt iteratief bouwen beter, en bij routinewerk is PRINCE2 het betere antwoord. Wat de aanpak bepaalt is de aard van de opgave, en dat oordeel hoort per opgave opnieuw te worden gemaakt. Wij beoordelen dat per opgave en schrijven het oordeel op, zodat je het kunt tegenspreken.

Hoge onzekerheid

Hoge onzekerheid betekent dat je weet wat je wilt bereiken en nog niet weet hoe het eruit komt te zien. De eisen verschuiven doordat je ze gaandeweg beter begrijpt. Een specificatie die vroeg is vastgelegd beschrijft na verloop van tijd iets anders dan wat er nodig is, en dat verschil valt pas op als iemand het gebouwde voor zich heeft.

Klein leveren is in dat geval de manier waarop de opgave zichzelf uitlegt. Je bouwt een stuk en je stelt bij op wat dat stuk je over de rest vertelt, en wie hier vooraf specificeert koopt schijnzekerheid die hij later terugbetaalt in herwerk.

Routinewerk

Routinewerk is het omgekeerde geval. De uitkomst is vooraf te beschrijven, de koppelvlakken liggen vast en het werk lijkt op wat er eerder is gedaan. PRINCE2 heeft daar mechanismen voor die scrum niet kent. De business case wordt bij elke faseovergang opnieuw beoordeeld, zodat stoppen een ingebouwd moment heeft in plaats van een moedige uitzondering. En met toleranties per laag gaat alleen naar boven wat erbuiten valt, waardoor de stuurgroep pas aan tafel komt bij een afwijking.

Dat is het raamwerk dat bij dit soort werk hoort. Wie het inzet valt niet terug op een oudere manier van werken, en de verwachting is dat het bij een opgave waarvan de uitkomst al vastligt minder overleg kost dan een iteratieve aanpak. Nagerekend is dat niet.

Er bestaat ook een harde variant van dit geval. De cursus testen trekt de grens zo: bij een systeem dat aanspraken vastlegt, is "we zien het wel in productie" geen aanvaardbare testaanpak voor de kernberekening. Leren in productie is een verdedigbare strategie zolang de kosten van een fout te dragen zijn. Bij een berekening waar iemands recht aan hangt zijn ze dat niet, en dan is de leveringsvorm ondergeschikt aan de vraag wat er vóór de livegang bewezen moet zijn.

De regel bij de Agilometer

De Agilometer is een diagnose-instrument met zes sliders, elk beoordeeld op een schaal die loopt van ongeschikt naar zeer geschikt. Wie het invult loopt meteen tegen de verleiding aan om er één getal van te maken. De regel uit het materiaal is onvoorwaardelijk: neem nooit het gemiddelde van de zes scores.

Daar zijn twee redenen voor. De eerste staat in het lesmateriaal zelf. Eén lage score wijst op een specifiek risico dat aandacht verdient, en een hoog gemiddelde met daaronder één laagste score verbergt precies het probleem dat het instrument moet blootleggen. Een opgave waarbij alles meezit behalve de acceptatie van agile werken binnen de organisatie is niet "gemiddeld geschikt"; het is een opgave met één probleem dat om gerichte aandacht vraagt voordat je begint.

De tweede reden volgt daaruit. Het materiaal zegt erbij dat de uitkomst een basis is voor gerichte mitigatie en geen simpel go/no-go-oordeel. Zodra er één cijfer staat, zet iemand er een drempel onder, en dan is het instrument geen hulpmiddel meer bij een gesprek maar een norm waar je overheen moet. Op dat moment verandert het gedrag van degene die scoort. Dat mechanisme is het onderwerp van een ander artikel in deze kennisbank, en het treft de Agilometer ook.

Cynefin doet in ditzelfde gesprek het andere werk: het benoemt welk soort probleem er ligt zonder een aanpak voor te schrijven. Dat kan een probleem zijn waarvan de oplossing te analyseren valt door iemand met verstand van zaken, of een probleem waarvan de uitkomst pas achteraf te begrijpen is. Voor het eerste is een expert de kortste weg, voor het tweede een proef die je kunt overleven.

Waar dit standpunt ophoudt

Het onderscheid tussen complex en gecompliceerd is in de praktijk lastig te trekken, en dat is het zwakke punt van alles hierboven. Cynefin levert geen toets die je in een uitvraag invult, en twee ervaren mensen kunnen dezelfde opgave verschillend plaatsen zonder dat een van beiden het kan aantonen.

Wat de plaatsing vaak verraadt is wat iemand eerder heeft gedaan. Wie dit type systeem al vaker heeft gebouwd ziet gecompliceerd werk, wie het voor het eerst ziet ziet complex werk, en over zichzelf hebben ze allebei gelijk. Het oordeel gaat dus mede over de bezetting en niet alleen over de opgave, en dat hoort er dan ook bij te staan.

Daar komt bij dat een opgave zelden in één domein valt. Een vervangingstraject met een bekende doelarchitectuur en een onbekende datamigratie is in het ene deel routinewerk en in het andere niet. De keuze gaat dan over de plek waar je de grens legt, en dat is een ontwerpbeslissing.

Wat het oordeel dan nog waard is, zit in de vorm: welke opgave is beoordeeld, met welk instrument, welke score kwam laag uit en welke aanname draagt het advies. Bewijsbaar wordt het daar niet van. Wie het er niet mee eens is, weet dan welk stuk hij moet aanvallen.

Wie vindt dat het onderscheid tussen complex en gecompliceerd in de praktijk niet te maken is, heeft hier het sterkste aangrijpingspunt. Geen van de argumenten hierboven weerlegt dat bezwaar. Ze zetten er een opschrijfplicht tegenover, en of dat genoeg is valt te bediscussiëren.