De Agile Organisatie

agile (bijvoeglijk naamwoord) - beweeglijk
able to move quickly and easily:
“The antelope is very agile.”

Als software ontwikkelaar gebruik ik de beste methoden en technieken om een product te maken met een zo hoog mogelijke kwaliteit. Mijn werk is vaak een intensief balanceren tussen deadlines, budget en wensen. Maar vrijwel altijd lukt het om het evenwicht te bewaren en is de klant tevreden. Echter, soms lukt dit onvoldoende en ben ik ontevreden. Het resultaat valt tegen. Er had zoveel meer ingezeten. Waar ligt dat aan? Wat geeft het ene project de flow waardoor het succesvol is, en waarom lukt dat bij andere projecten niet? Ik zal u een geheim verklappen. Al mijn succesvolle projecten van de afgelopen 25 jaar volgden een aanpak die al een tijd als Agile Software Development in de belangstelling staat.

Het Agile Manifesto vat de aanpak kort en bondig samen in een viertal uitgangspunten:

1. Individuen en interactie zijn belangrijker dan processen en gereedschappen.
2. Werkende software is belangrijker dan uitvoerige documentatie.
3. Samenwerking met de klant is belangrijker dan onderhandelen over een contract.
4. Reageren op verandering is belangrijker dan een plan volgen.

Inderdaad, in mijn succesvolle projecten maakten we onze eigen regels en afspraken, en kozen we de gereedschappen die de beste bijdrage leverden aan het gewenste resultaat. We brachten onze inzichten zo snel mogelijk als testbare software in praktijk, en konden daardoor tijdig corrigeren en nieuwe inzichten oppakken. We kregen allemaal de kans om creatief te zijn, en konden open, eerlijk en op gelijke voet met elkaar oplossingen uitwerken. Er was geen tegenstelling tussen opdrachtgever en opdrachtnemer. We werkten zij aan zij samen onder het motto “getting the job done”. En, niet het onbelangrijkste, we hadden allemaal veel plezier in ons werk.

Helaas, in mijn minder succesvolle projecten werden we beperkt door conventionele (ambtelijke) organisaties die qua software ontwikkeling nog steeds leunden op de waterval methode. In een typisch waterval project zoekt een gestage stroom van documenten haar laagste punt van Informatie Analist, via Functioneel- en Technisch Ontwerper, naar de Programmeur, die de software mag bouwen. Fouten in het ontwerp die de programmeur ontdekt moeten in een moeizame weg omhoog bij de functionaris met de juiste autorisatie (dat klinkt alweer heel ambtelijk) terecht komen, waarna de oplossing weer naar beneden sijpelt. U voelt het al: dit is een tijdrovend en zeer foutgevoelig proces, dat niet zelden leidt tot forse overschrijdingen van budget, deadlines en frustratie-tolerantie.

Waarom bestaan er nog steeds organisaties die projecten zo dwingend de waterval insturen? Gebrek aan kennis kan nauwelijks een verklaring zijn. Ook in de meest ambtelijke organisaties laten mensen zich op congressen en seminars informeren over de best practices van Agile en vergelijkbare methoden van Software Development.

Kennelijk is men onmachtig om het geleerde in praktijk te brengen, omdat het idee niet past op het fundament waarop hun organisatie is ingericht. Maar ondersteunt dit fundament de organisatie wel optimaal? De wereld verandert continue, en organisaties worden continue uitgedaagd om snel en adequaat te reageren. Misschien zijn zij daarom juist wel meer gebaat bij een flexibel skelet dan bij een rigide fundament. Een skelet dat hen in staat stelt om van hun plaats te komen en soepel en doelgericht te bewegen. Inderdaad, Agile dus.

-- Rijk Ravestein