De mythe van agile: valkuilen en kansen bij iteratieve software ontwikkeling

Agile is al een tijdje het toverwoord binnen software ontwikkeling. Bij het ontwikkelen van software applicaties is agile tegenwoordig de standaard aanpak. Maar is agile altijd de meest voor de hand liggende en passende aanpak?

Wat is agile?

Agile staat voor lenig of wendbaar. Binnen deze methode gebeurt het ontwikkelen van software in korte overzichtelijke periodes die iteraties of sprints worden genoemd. Een iteratie is als het ware een klein project op zich en iedere iteratie levert bruikbare software op. Een aantal van die iteraties of sprints achter elkaar leveren passende software oplossingen op voor de beoogde business case.

Wat is er mis met de ‘good old’ watervalmethode?

Haaks op agile staat software ontwikkeling volgens de zogenaamde watervalmethode. Hierbij doorloopt de ontwikkeling van software een aantal opeenvolgende fasen: analyse, ontwerp, bouw, testen en implementatie.

Op basis van een uitgebreide informatieanalyse en een functioneel ontwerp wordt een ontwerpdocument geschreven. Na goedkeuring van het ontwerp door de opdrachtgever trekken de software ontwikkelaars zich als het ware terug om na een langere of kortere tijd weer ‘naar buiten’ te komen met de ontwikkelde software die is afgeleid van het functioneel ontwerp.

Onderstaand plaatje laat een paar valkuilen zien die bij het omzetten van de wensen van de klant of de business naar systemen of producten in zijn algemeenheid kunnen optreden. Of te wel: de ‘running gag’ voor consultants.

Behalve misverstanden in communicatie en interpretatie bleek in de praktijk de omgeving van de opdrachtgever veranderd of was er sprake van voortschrijdend inzicht waar geen rekening mee gehouden werd tijdens de ontwikkeling. Het resultaat? Software die niet voldoet aan de wensen en eisen van de klant.

Iteratieve software ontwikkeling maakt bijsturen mogelijk

Het ontwikkelen van software op een iteratieve manier maakt, in tegenstelling tot de watervalmethode, bijsturen mogelijk. Omdat je op geregelde momenten tijdens het ontwikkelproces communiceert en frequent datgene wat is ontwikkeld toetst aan de verwachtingen. Dit levert over het algemeen software op die goed past bij de wensen van de klant en van de business waar de software zijn toegevoegde waarde moet bewijzen.

Bij agile methoden ligt de nadruk op directe communicatie. De opdrachtgever is onderdeel van het agile team en fungeert als product owner. Daarmee kan een heel direct sturing worden gegeven aan het uiteindelijke resultaat. Maar dat brengt ook verantwoordelijkheid met zich mee.

Is agile altijd de oplossing?

Agile werken vergt namelijk niet alleen iets van de uitvoerder, maar ook van de opdrachtgever. Werk je volgens scrum, een van de agile frameworks, dan pakt een multidisciplinair en zelfsturend team het project als team op. Iedereen is betrokken bij het plannen, het benoemen van blokkades en het verdelen van de taken.

Scrum gaat er van uit dat de benodigde kennis in het team zelf aanwezig is. De product owner, bij voorkeur een vertegenwoordiger van de opdrachtgever, maakt een lijst van de eisen en taken, ook wel user stories genoemd. Dat kost tijd en het betekent dat een product owner uit zijn of haar normale werkproces gehaald moet worden. Dit is niet voor alle opdrachtgevers te regelen. Of men komt er tijdens het proces achter dat het niet werkt.

Ook al is scrum niet in alle situaties werkbaar, op een iteratieve manier software ontwikkelen met regelmatige toetsing van resultaten door de opdrachtgever is aan te bevelen. De kort-cyclische aanpak maakt snelle feedback mogelijk. Een agile aanpak benadrukt daarbij behalve teamverantwoordelijkheid ook de individuele verantwoordelijkheid van ontwikkelaars en borgt directe betrokkenheid en medeverantwoordelijkheid van de opdrachtgever. Een aantal valkuilen uit de watervalmethode zijn door iteratieve software ontwikkeling daardoor goed te omzeilen.

Agile software ontwikkeling is een mythe als niet aan alle randvoorwaarden wordt voldaan

Agile is een mooie aanpak, maar het blijft een mythe als aan een aantal randvoorwaarden niet is voldaan. Agile lost niet alle ‘problemen’ vanzelf op en het levert niet per definitie een productiever team of een beter eindproduct op. Een heleboel aspecten en best practices uit de ‘normale’ software ontwikkeling blijven overeind. De belangrijkste randvoorwaarden hebben we op een rij gezet:

Goed plannen en structureren
Agile wordt soms toegepast om lukraak te gaan programmeren. Maar juist bij agile zijn het gedegen plannen en structureren van gewenste functionaliteit in blokken van groot belang. Je kunt niet zomaar lukraak functionaliteit gaan bouwen. Een goede volgorde en taakverdeling over sprints heen en binnen sprints is cruciaal om chaos te voorkomen.

Ontwerp en documentatie blijven belangrijk
Bij agile werken wordt vaak gedacht dat er minder ontworpen en gedocumenteerd hoeft te worden. Het klopt dat er geen ellenlange documenten als een blueprint of functioneel ontwerp worden geschreven. Maar ontwerpen en documenteren blijven natuurlijk belangrijk. Een degelijke functionele en technische opzet van de applicatie en de architectuur zijn nog steeds randvoorwaarden voor succes.

Communicatie en verwachtingsmanagement is cruciaal
Natuurlijk is ook bij agile communicatie belangrijk. Bij een scrum aanpak horen zogenaamde — het liefst dagelijkse — stand ups. Dit zijn korte meetings van het team waar iedereen vertelt wat hij heeft gedaan sinds de vorige meeting, gaat doen tot de volgende meeting en welke issues er spelen. Frequente afstemming met het team is bij iteratieve software ontwikkeling cruciaal. In de praktijk zit de opdrachtgever in de rol van product owner nu eenmaal niet altijd ‘naast’ het team. Het organiseren van de betrokkenheid en het benadrukken van de medeverantwoordelijkheid in het proces is in dat geval des te belangrijker.

Gebruik een collaboration tool als communicatiemiddel
Gebruik een collaboration tool, zoals bijvoorbeeld Jira van Atlassian, om de issues en de iteratieve stappen te managen. Dit is nodig om als team het overzicht te houden en de doelstellingen van de sprints te behalen. Jira issues gelden tegelijkertijd als documentatie. Alle project en product requirements kunnen zodanig vastgelegd worden dat iedereen erbij kan en inzicht in heeft.

Gebruik de acceptatieomgeving als toetsing van de software
Bij ontwikkelen van software doorlopen we een OTAP-ontwikkelstraat, van Ontwikkeling en Test naar Acceptatie en Productie. De acceptatieomgeving is de omgeving waar de opdrachtgever kan toetsen of de geleverde software voldoet aan de wensen en verwachtingen.

Zorg dat de product owner het mandaat heeft
De product owner moet het mandaat van zijn organisatie hebben om besluiten te nemen. Het werkt averechts als er later op besluiten moet worden teruggekomen, omdat bijvoorbeeld het management het toch liever anders wil. Dit mandaat moet goed verankerd zijn. In de watervalmethode is dit het goedgekeurde functioneel ontwerp waarop wordt teruggegrepen. Bij agile werken is het de product owner die de knopen doorhakt en de besluiten neemt.

Wil je meer weten over agile software ontwikkeling en hoe je deze methode binnen jouw organisatie toepast? Neem dan vrijblijvend contact op met één van onze specialisten. Zij helpen je graag verder.