Voorspelbare flexibiliteit

We zijn nu een paar decennia bezig met de procesmatige aanpak van informatisering. ITIL, ASL en BiSL blijken daarbij nog altijd nuttige hulpmiddelen te zijn, net als CMM in zijn diverse smaken als het gaat om de verbetering van die processen.

Het is zo gewoon geworden om een Changemanager, een Problem Management proces en een RACI te hebben, dat we soms vergeten waarvoor het allemaal is bedoeld.

ITIL was destijds het antwoord op de ervaring, dat de werking en prestaties van automatisering vaak

volkomen onvoorspelbaar waren. En als er problemen optraden omdat “het systeem” niet of iets anders deed dan wat nodig was, was het onduidelijk hoelang een oplossing voor dat probleem op zich zou laten wachten . Er was behoefte aan voorspelbaarheid en voorspelbaarheid is wat de procesmatige aanpak ons heeft gebracht.

Door vast te leggen hoe een resultaat tot stand komt, bereiken we dat datzelfde resultaat een volgende keer ook bereikt kan worden. Door vast te leggen wie er moet worden betrokken in de besluitvorming voorkomen we onnodige weerstanden. Vastleggen is daarbij niet het doel, maar het middel. Een middel om naar een voorspelbaar resultaat te werken. Zo voorspelbaar mogelijk.

Die voorspelbaarheid schiet soms door. Ze ontaardt dan in starheid of, zo je wilt, bureaucratisme. De paarse krokodil staat voor het grijpen, maar u krijgt haar pas mee als u het formuliertje heeft ingevuld. En daarna gaat dat formuliertje in een archief waar niemand ooit nog naar kijkt.

We zien met name in de kleinere, meer dynamische organisaties dat daardoor een soort “procesmoeheid” ontstaat, de behoefte om zaken vooral NIET vast te leggen en NIET te werken langs een vastgesteld proces.

De Agile aanpak speelt daarop in. Ze is gericht op snelle opleveringen van beperkte omvang. De procesgerichte aanpak zou ouderwets zijn.

Procesgericht wordt geassocieerd met de analytische mindset van het Marshall model. Agile hoort, in diezelfde redenering, bij de derde mindset, die van het effectievere, synergistische denken.

Interessant is dat Agile, op zijn beurt, ook te maken heeft met een imago dat weerstand oproept. Het zou ongestructureerd en chaotisch zijn, te weinig kwaliteitsgaranties bieden en alleen maar gericht zijn op snelheid. Documenteren was altijd al een ondergeschoven kindje van systeemontwikkeling en Agile legitimeert dat, is de veelgehoorde klacht.

En net als bij de kritiek op de procesgerichte aanpak vinden ook deze klachten hun oorsprong in voorbeelden uit de realiteit. Zo sprak ik vorig jaar iemand die vol trots meldde dat zijn team, een afdeling voor softwareontwikkeling, Agile had omarmd. “Maar wel onze eigen versie, om het werkbaar te houden. Dus zonder gebruikers, anders duurt het allemaal veel te lang.”

De procesgerichte aanpak en Agile lijken elkaar uit te sluiten - als je Agile werkt, heb je kennelijk niets aan processen en als je procesmatig werkt heb je niets aan Agile denken. Een aantal studenten die ik sprak over de invloed van Agile op het proces framework BiSL wilden graag in contact komen met organisaties die ervaring hadden met de combinatie van Agile en BiSL. Ik kende een aantal dergelijke organisaties en ik kende ook wel mensen bij die organisaties. Toen ik het verzoek van de studenten echter bij die mensen neerlegde liep ik een aantal keren tegen een soort waterscheiding aan - men was OF betrokken bij Agile ontwikkeling OF bij BiSL. Maar niet bij beide!

De procesmatige aanpak (in essentie resultaten tot stand brengen door het afwerken van een checklijst met activiteiten) kan voor veel mensen blijkbaar niet gecombineerd worden met de snelheid en flexibiliteit die sommige organisaties wensen en nodig hebben. En een Agile aanpak (in korte cycli in multidisciplinaire teams snel inspelen op waar je tijdens de ontwikkeling tegenaan loopt) kan in de ogen van anderen niet leiden tot een voorspelbaar resultaat.

We weten natuurlijk dat het combineren van beide wel degelijk kan. BiSL schrijft niet voor dat “ontwikkelaars” en “beheerders” uit elkaar gehouden moeten worden, ook al vinden de kernactiviteiten van beide groepen in aparte procesclusters plaats. Integendeel, samenwerking is een kritische succesfactor en integrale sturing is een centraal begrip in elke vorm van procesgericht werken. En hoewel het Agile manifesto “werkende software boven allesomvattende documentatie” stelt, wordt daarmee niet bedoeld dat je best zonder documentatie kan. Als niemand wéét hoe de software werkt, zal die software ook al snel niet meer werken. Reken maar dat ze dat bij Netflix en Über heel goed weten.

We dreigen het spreekwoordelijke kind met het badwater weg te gooien. Door doel en middel te verwarren stellen we het proces boven het resultaat en snelheid boven bruikbaarheid. Een recept voor een “chaotische bureaucratie”.

We doen er beter aan om het goede van beide aanpakken actief te combineren. De voorspelbaarheid van de procesaanpak en de wendbaarheid van Agile gaan heel goed samen. Of we daarmee in het Informatieparadijs komen weet ik niet, maar het brengt ons in ieder geval iets waar we dringend behoefte aan hebben in de steeds snellere ontwikkelingen: voorspelbare flexibiliteit.