Over Cowboy coding (‘agile’) en Grijpbaarheid – Mechatronica en Machinebouw.

Het doel van een column is om een extreme opinie weer te geven die tot nadenken aanzit. Dacht ik. Nu, ik hebt het geweten. Meerdere, bijna emotionele reacties heb ik mogen ontvangen (zie pag 10). Boos was men. Oeps. Agile en Scrum zijn blijkbaar gevoelige onderwerpen. Wat raakt hen nu zo? Laat ik wat toelichting geven – en misschien wat extra olie op het vuur gooien.

De Nederlandse traditie van ontwerpen en bouwen is er eentje van doelen definiëren en bespreken met stakeholders, vooruitplannen, ontwerpen, beoogde resultaten beoordelen en uiteindelijk realiseren volgens het plan. Zo bouwden we polders, steden en complexe projecten zoals de deltawerken. De bijbehorende projectmanagementaanpak wordt ook wel de Delftse Methode (DM) genoemd. Deze hebben niet-techneuten in de loop der tijd vertaald in bijvoorbeeld Prince2. In de praktijk inmiddels vaak gehanteerd in een managementmethode waarbij het ‘proces’ leidend wordt en poogt de inhoud te faciliteren, in de hoop dat het daarmee goed komt. In de ict – vooral bij overheden – heeft dat geleid tot een geschiedenis aan mislukkingen waarbij honderden miljoenen over de balk zijn gegooid. Ik snap daarom de Scrum- en Agile-tegenbeweging heus wel.

De meest gehoorde excuses bij ict-mislukkingen zijn: slecht projectmanagement, slechte opdrachtgevers, slecht programma van eisen, onrealistische deadlines en veranderende doelen tijdens het project. Het zal best. Bij grote dure en complexe processen heb je vooral behoefte aan een zeer strakke leider (architect), veel communicatietijd en doelen die vooraf op schrift worden vastgelegd.

Managementonderzoekers zoals Teun van Aken hebben hierover boeken vol geschreven. Van Aken heeft veel (mislukte) projecten geanalyseerd en uit zijn koker komt het woord ‘grijpbaarheid’ en de bijpassende aanvliegroutes. De grijpbaarheid van een project wordt bepaald door hoe tastbaar het eindresultaat vooraf is beschreven, hoeveel belanghebbenden er zijn, en hoeveel disciplines inhoudelijk zijn betrokken.

Om een lang verhaal kort te maken, zeer grijpbare projecten hoef je niet kapot te organiseren. Dat is de categorie ‘doen en loslaten’. Bij grijpbare (deel)projecten zet je een inhoudelijk sterk en klein team aan het werk met een heel duidelijke eindopdracht. In de scrumpraktijk wordt daar bijvoorbeeld een maand doorlooptijd voor gekozen. Prima. Blijkbaar is de it-praktijkervaring dat de spanningsboog van een groep ontwikkelaars niet groter dan een maand is. Dat zegt vooral wat over de kennis en kunde van een gemiddeld scrumteam is mijn indruk. Als opdrachtgever zou ik daarom ook nooit grotere complexe opdrachten willen verstrekken aan een scrumteam. Te risicovol en te duur, zeker als ze per uur worden uitbetaald en niet op basis van concrete van tevoren gedefinieerde eindresultaten een project willen aannemen.

Aan de andere kant van het spectrum bevinden zich de zeer complexe, ongrijpbare projecten. Voor deze projecten is na jaren van management- en sociaal onderzoek maar één advies te geven: zorg voor een strakke organisatie en knip de grote einddoelen in hapklare brokken. Klassiek opdelen, definiëren, begroten en plannen dus. Niks Agile-erigs of Scrummerigs bij deze categorie alsjeblieft. De individuele grijpbare deelprojecten mogen overigens wel worden uitgevoerd door gepassioneerde ontwikkelexperts, heel graag met een minimum aan overhead. Als je daar het label Scrum of Agile opplakt, kan ik daarmee leven.

Grote ongrijpbare projecten hebben in de praktijk vooral een zeer ervaren systeemarchitect nodig, net als bij het ontwerpen van een brug of complexe fabriek. Daar wordt een hoofdarchitect of hoofdconstructeur integraal eindverantwoordelijk gemaakt. Iemand die er strak bovenop zit, het geheel kan overzien en zich laat omringen met goede secondanten. Mijn grootste klacht bij de Agile- en Scrum-praktijk is het ontbreken van zo’n ervaren systeemarchitect. Dat leidt uiteindelijk tot ellende.

In de praktijk van Agile zie ik ook te vaak cowboy coding. Enkele eenlingen – niet altijd de beste communicators – die achter hun computer ‘gewoon’ aan de gang gaan. Ook de architectuur van een (Scrum?) deelproject dient daarom eerst klassiek op schrift te worden gezet, is mijn ervaring. Voordenken en niet nadenken, schreef ik de vorige keer niet voor niks.

Mijn reageerders hebben met hun emotie vooral laten zien weinig (project)managementkennis te hebben over complexe omgevingen en projecten. Het verbaast me dan ook niks dat veel ict-projecten zo vreselijk uit de klauwen blijven lopen. Agile ontwikkelen is steeds weer een stukje erbij en zien waar het schip strandt. Het leidt niet tot mooie polders, werkende Maaslandkeringen, efficiënte en grote melkfabrieken of vliegtuigen. Mijn tip van de dag: voordat we over Scrum of Agile praten, definiëren we eerst de grijpbaarheid van een project. Pas daarna kiezen we de projectvorm.

STREAMER – Definieer eerst de grijpbaarheid van een project

dit stuk is eerder gepubliceerd in Mechatronica en Machinebouw