Vijf valkuilen van Agile ontwikkelen

Open de website van een willekeurig it-bureau en de termen Agile, Scrum en Kanban vliegen je om de oren. Wie anno 2015 nog niet 'scrumt' loopt achter de feiten aan, toch? Waarom is Agile zo ontzettend populair? En is Agile werken echt de ultieme methode om toekomstbestendige software te bouwen? Pas op, het is niet al goud wat blinkt…

Agile ontwikkelen is hot. En dat is niet gek, het zorgt er immers voor dat je snel – met zo min mogelijk middelen – op een lichtvoetige manier je doel bereikt. En het gaat daarbij niet zozeer om de bestemming (het opleveren van de gewenste oplossing) maar vooral om de reis er naartoe.

Je maakt vooraf geen plan van duizenden euro’s om pas na maanden werk iets op te leveren. Je werkt in korte sprints en levert steeds kleine onderdelen op, zodat je kunt inspelen op veranderende omstandigheden. En je vraagt je voortdurend af: welke slimme dingen kunnen we onderweg doen om nog sneller en nog beter op onze bestemming te komen?

Agile ontwikkelaars verdoen – als het goed is – hun tijd niet met oeverloos geklets in vergaderingen of met het maken van paginalange complexe architecturen en functionele ontwerpen die – als we eerlijk zijn – eigenlijk niemand ooit echt leest of bekijkt. Agile ontwikkelaars zijn als zwarte ninja’s; je ziet ze niet, ze bewegen zich snel en soepel en zijn in no time waar ze moeten zijn.

Populariteit van Agile werken

Iedereen doet het, iedereen werkt ‘Agile’. Waarom is de methode nu juist zo trending? Ik kan diverse oorzaken aanwijzen. Wat dacht je van de snelheid waarin technologische ontwikkelingen elkaar vandaag de dag opvolgen? Maar ook de snelheid van de maatschappij als geheel is van grote invloed!

Traditionele ontwikkelmethoden houden dat tempo simpelweg niet bij. Je moet wel supersnel ontwikkelen om mee te kunnen, om snel genoeg te kunnen opleveren en om je concurrenten voor of zelfs maar bij te kunnen blijven. En die concurrenten komen tegenwoordig niet alleen uit je eigen land of werelddeel. Door de globalisatie kun je als it-bureau uit Maarssen zelfs concurrentie krijgen van een bureau uit Tokio.

Het zijn trouwens niet alleen concurrenten die het tempo opvoeren, ook de consumenten, de eindgebruikers. It wordt steeds belangrijker voor mensen, het zit in steeds meer onderdelen van het leven verweven. Niet gek dus dat consumenten er steeds van meer verwachten. Er komt logischerwijs dus ook meer druk vanuit de maatschappij om snel, goede en stabiele oplossingen te leveren die échte problemen oplossen en echt bijdragen aan de kwaliteit van werken en leven.

Het is niet al goud wat blinkt: 5 valkuilen

Is aAgile werken dan het antwoord op al onze vragen en uitdagingen? Ja en nee. Ik geloof 100 procent in deze methode, maar dat wil niet zeggen dat er geen valkuilen zijn waar ontwikkelteams – ook de onze – dagelijks mee worstelen.

1. Te weinig focus en tijd voor goede communicatie
Als je het mij vraagt valt of staat een agile ontwikkeltraject met voortdurende communicatie. Communicatie is natuurlijk altijd al belangrijk geweest, ook toen we nog volgens traditionele methoden ontwikkelden. Maar wat anders is, is dat je in een agile project voortdurend, intensief, maar ook effectief met elkaar moet praten over wensen en resultaten. Als je dat niet doet, werkt het namelijk niet.

Wat ik vaak merk, is dat de opdrachtgever niet voldoende tijd heeft om aan het einde van elke sprint écht te kijken naar wat er opgeleverd is en goede feedback te geven. Agile ontwikkelen werkt alleen als opdrachtgever en -nemer als het ware ‘samen op reis gaan’ en een voortdurende focus hebben op het helpen van de ander. De opdrachtgever moet echt de tijd hebben en prioriteit kunnen geven aan het project. En de leverancier, de opdrachtnemer, moet zijn expertise inzetten om zo snel en goed mogelijk in te spelen op de behoeften van de opdrachtgever en diens verwachtingen waar te maken.

2. Onvoldoende juiste inhoudelijke expertise in huis
Als je samen op reis gaat, moet je wel dezelfde taal spreken. Agile ontwikkelen gaat alleen goed als de opdrachtnemer kennis heeft van de branche waarin de opdrachtgever opereert. Kleine verschillen in terminologie kunnen bijvoorbeeld al problemen opleveren als het gaat om communicatie tussen beide partijen.

Heeft het it-bureau niet de domeinkennis in huis, dan heb je iemand nodig die continu de brug moet slaan tussen de it-ers enerzijds en de branche en opdrachtgever anderzijds. En dat maakt snel en lichtvoetig ontwikkelen erg lastig. Kortom: als je als opdrachtgever kiest voor een bureau dat domeinkennis, technische expertise en ervaring in jouw branche heeft, verhoog je de slagingskansen.

3. Slecht verwachtingsmanagement
Als je als bureau wordt ingehuurd om een project te doen, komt er nog extra spanning bij: de opdrachtgever wil immers zo min mogelijk uitgeven en zo snel mogelijk klaar zijn. Daarnaast heeft hij zekerheid nodig en wil hij antwoord op prangende vragen. Hoe lang gaat het project duren? Hoeveel gaat het kosten? Wat gaan we precies maken?

Maar de opdrachtnemer kan alleen agile, goedkoop en snel, werken en echt goede oplossingen leveren als hij niet van tevoren heel veel tijd hoeft te nemen om de opdrachtgever zekerheid te geven, zoals in de vorm van plannen en architectuur. Bovendien komt dat het agile ontwikkelproces niet ten goede; er is een zekere vrijheid nodig om lichtvoetig te kunnen ontwikkelen. Daar komt verwachtingsmanagement om de hoek kijken.

De opdrachtgever moet bij een agile project om kunnen gaan met het feit dat hij van tevoren niet goed weet wat hij gaat krijgen, dat merkt hij tijdens het proces pas. De opdrachtnemer moet zich op zijn beurt niet laten verleiden om vooraf teveel concrete beloftes te doen. Wat ik vaak zeg, is: “we gaan dit doel in zes of zeven sprints samen bereiken, en hoe we dat doen, dat gaan we samen onderweg uitzoeken.” Wat ook belangrijk is, is tussentijds zaken opleveren waar de opdrachtgever blij mee is. Dat wekt vertrouwen, en vertrouwen leidt tot de broodnodige vrijheid.

4. Teveel het manifesto volgen
Agile wordt gelukkig veel meer ingezet vanwege de kracht van de methode, dan omdat het zo hip & happening is. Wat je wel nog te vaak ziet, is dat teams te strak de regels volgen en denken: ‘als we het volgens het boekje doen, dan gaat het vanzelf goed’. Dat is natuurlijk niet zo. Zo gebeurt het bijvoorbeeld dat ontwikkelaars geen documenten maken, in het manifesto staat immers dat ‘software altijd voor documentatie gaat’. Terwijl het soms hartstikke nodig is! Wij hanteren vaak de tien-personen-regel. Als minder dan tien personen het document gaan lezen, dan kun je het beter niet schrijven en de details in een meeting bespreken. Zijn het er meer? Dan heeft het schrijven van de documentatie wel degelijk waarde.

5. Teveel verspilling
Je wil snel en goedkoop op je bestemming aankomen, dus alles waar je tijd en geld in steekt en wat uiteindelijk niet relevant is voor het bereiken van je doel, is zonde. Neem nou al die documentatie die ik net noemde. Soms is het hartstikke nodig, maar veel vaker is het pure verspilling. Datzelfde geldt voor eindeloos overleggen en ‘dure’ mensen voor onnodige zaken inzetten. Het is daarom erg belangrijk om na te denken over welke zaken echt nodig zijn om je doel te bereiken, en welke zaken je alleen doet om bijvoorbeeld jezelf of anderen gerust te stellen.

De uitdaging daarbij is dat de opdrachtgever lastig kan vertellen wat hij wil, zonder dat vast te leggen in een document. Er zijn financiële kaders, want de opdrachtgever wil zekerheid. Daarom wordt er vaak een informatie-analist ingeschakeld om een functioneel ontwerp te maken. Maar het stomme is dat de ontwikkelaars uiteindelijk vaak amper kijken naar dat ontwerp.

Ontwerpen maken hoort ook niet bij agile ontwikkelen. Al is het alleen maar omdat mensen vaak van tevoren niet goed weten wat ze willen en agile nou juist gaat om het tussentijds kunnen inspelen op veranderingen.

Wat er wel bij hoort, is voortdurend kort, maar wel goed en inhoudelijk, bespreken wat de wensen en verwachtingen zijn. En tussentijds voortdurend toetsen of je goed bezig bent. In feite komt het hier op neer: je kunt als opdrachtgever je budget van tienduizend euro maar één keer uitgeven. Waar geef je het dan liever aan uit; aan het laten opschrijven van wat je wilt? Of aan het daadwerkelijk krijgen van wat je wilt?

Blije klanten door gelukkige ontwikkelaars

Agile ontwikkelen past kortom bij de snelheid van de maatschappij waarin we leven. Maar om deze methode te laten slagen zijn goede communicatie, de juiste expertise, slim verwachtingsmanagement en het durven ‘loslaten’ van die veiligheid, zekerheid en duidelijkheid vooraf zeer essentieel.

Doe je het goed, dan levert agile werken niet alleen goedkoper en sneller betere oplossingen op, maar ook blije, gelukkige ontwikkelaars. Niemand vindt het immers leuk om een papieren tijger te schrijven, een dik pak papier dat in de virtuele kast verdwijnt. Ontwikkelaars zijn veel liever bezig met waar ze goed in zijn: ontwikkelen. En gelukkige ontwikkelaars leveren ook nog eens betere resultaten en dus blije klanten op. Ik zeg: win-win!