Je bent niet agile … met een agile waterval

Veel organisaties noemen zichzelf agile. Wie zou er niet agile willen zijn? Als je niet agile bent, ben je dan niet per definitie log, traag en stroperig?

Slechts weinig organisaties zouden zichzelf zo omschrijven; toch betekent Agile in de wereld van softwareontwikkeling, -verbetering en -onderhoud meer dan alleen snel en flexibel kunnen handelen. Agile betekent dat een team of organisatie bepaalde principes omarmt die gedrag vormgeven en leiden tot het verinnerlijken van bepaalde methoden.

Wanneer er niet gehandeld wordt zoals beweerd, staat het management vaak de principes in de weg en de practitioners de methoden. De werkwijzen in organisaties zijn vaak zeer vastgeroest en vereisen een aanzienlijke veranderingsinspanning. Sommige organisaties beweren een gemengde aanpak te gebruiken en over te stappen van een meer klassieke aanpak naar een combinatie van Scrum, Kanban en Extreme Programming. Dit wordt gezien als een veilige en conservatieve aanpak die een organisatie in staat stelt organisch te veranderen. Het probleem is echter dat deze tactiek zelden werkt en organisaties al snel vastlopen. Als je niet genoeg tijd en moeite investeert in verandermanagement, leidt dat al snel tot hybride frameworks die geen vis noch vlees zijn – en die zijn slechts zelden echt agile.

Kenmerken van vastgelopen (of potentieel vastgelopen) organisaties

De iteratieve waterval:

De klassieke iteratieve waterval heeft zijn wortels in het spiraalmodel van Barry W. Boehm. In deze pseudoversie van iteratieve ontwikkeling worden korte, tijdgebonden iteraties ingezet voor elk van de klassieke watervalfasen. Op een requirements-sprint volgt een design-sprint, dan een ontwikkelsprint enzovoort. Zowel het klassieke spiraalmodel als de pseudoversie van Agile zijn desondanks aanzienlijk beter dan het klassieke watervalmodel als het gaat om het genereren van feedback en het sneller leveren van waarde; maar organisaties stoppen daardoor met zich verder in de richting van Agile te ontwikkelen en plukken dus slechts een deel van de vruchten.

Requirements vooraf vastleggen:

Bij deze hybride aanpak van Agile verzamelen teams of organisaties alle requirements (soms features genoemd) aan het begin van het project en leggen ze vast voordat het daadwerkelijke werk begint. Agile is gebaseerd op bepaalde aannames met betrekking tot requirements. Twee van de belangrijkste aannames zijn dat requirements steeds opnieuw opduiken en dat ze – zodra ze bekend zijn – na verloop van tijd weer verdwijnen. Het vooraf vastleggen van Product Backlogs is in tegenspraak met deze beide aannames. Bovendien werpt het teams en organisaties terug naar een tijd waarin oplossingen werden ontwikkeld die uiteindelijk niet aan de actuele bedrijfsbehoeften voldoen. Deze aanpak komt meestal voor wanneer de introductie van Agile wordt uitgevoerd met een gefaseerde aanpak, waarbij je begint met de ontwikkelaars en later de Business Analysts enzovoort erbij betrekt. Tussen de groepen die Agile geïnternaliseerd hebben en de groepen waarbij dat niet het geval is, kan vaak extra wrijving ontstaan, wat veelal de agile methoden in de schoenen wordt geschoven en zo verdere veranderingen bemoeilijkt.

Testen nadat de ontwikkeling "done" is:

Een van de gevaarlijkste agile mengvormen is het testen na afgeronde ontwikkeling. Ik heb deze hybride vorm leren kennen onder de naam "Ontwikkeling + 1 Sprint". In dit scenario ontwikkelt een team een oplossing (werkende code bij een softwareprobleem), demonstreert het aan de klanten, beweert dat het "done" is en geeft het DAN door aan de testers. Testers vinden ALTIJD iets. Daarom wordt de software teruggegeven, zodat er ofwel direct aan gewerkt kan worden (wat de huidige Sprint verstoort) of het geheel naar de Backlog wordt verplaatst om er later naar te kijken. De agile principes ondersteunen het opleveren van uitleverbare (of op zijn minst potentieel uitleverbare) software aan het einde van elke Sprint. Uitleverbaar betekent GETEST. Twee iets minder dramatische varianten van dit probleem zijn het gebruik van Hardening Sprints en het testen helemaal aan het einde van een project. In die gevallen wordt tenminste niet beweerd dat men agile werkt.

Conclusie over agile en waterval

De manier waarop mensen werken, is de enige betrouwbare indicator om te bepalen of een organisatie agile is of niet. Soms weerspiegelt de werkwijze van deze mensen een overstap naar Agile – maar ik ga ervan uit dat men daar al snel zal vastlopen als deze overstap niet met grote gedrevenheid wordt uitgevoerd. Wanneer een team of een organisatie Agile wil overnemen, kies je een project uit en laat je iedereen die bij dit project betrokken is, tegelijkertijd en gedurende het gehele werkproces met Agile werken. Als dat betekent dat je een heel project of een heel team moet coachen, dan is dat maar zo. Je kunt deze aanpak goed vergelijken met een ui die je in plakken snijdt, waarbij je bij elke snede elke afzonderlijke laag van de ui bereikt, in plaats van laag voor laag af te pellen.

Een laatste opmerking: ook al loop je met deze hybride aanpakken uiteindelijk tegen je grenzen aan, ze zijn waarschijnlijk nog steeds beter dan de methode(n) die je eerder gebruikte. Dit is geen aanklacht tegen de mensen die moeite hebben met de overstap naar Agile. Het is veeleer een aanmoediging om door te gaan.

Deze tekst is afkomstig uit de blog van SPamCAST en is door ons naar het Nederlands vertaald.