It-organisaties kiezen voor agile om wendbaarder te worden en sneller in te kunnen spelen op veranderingen. Het is dan ook niet verwonderlijk dat snelheid in de agile-methode centraal staat. De keerzijde is dat snelheid te bepalend is, alsof het in veel projecten een doel an sich is.
Organisaties denken vaak onvoldoende na over fundamentele kwaliteitskeuzes. Snel willen opleveren betekent dat de meeste aandacht uitgaat naar de functionaliteit, terwijl essentiële stappen op lange termijn worden overgeslagen, zoals aandacht voor het onderhouden, aanpassen of uitbreiden van de gekozen software. Het gevolg is dat er ongemerkt problemen worden gecreëerd die in een latere fase niet eenvoudig zijn op te lossen, zoals technical debt. Dit houdt in dat de bestaande functionaliteit niet meer wordt aangepast naar nieuwe technieken, omdat dit meer tijd kost en niet direct waarde oplevert. Het softwaresysteem wordt zo beetje bij beetje complexer en soms zelfs onhoudbaar, terwijl storingen vaker voorkomen en opschalen onmogelijk is. Het repareren ervan kost veel tijd en geld.
Deadline
Daarnaast zorgt de focus op snelheid, vaak in combinatie met een deadline, ervoor dat er niet genoeg stil wordt gestaan bij de behoefte van de opdrachtgever. In de meeste gevallen ligt oorzaak ervan bij de business die een concrete oplossing vraagt, terwijl het probleem nog niet nauwkeurig in kaart is gebracht. Het ontwikkelteam bouwt dan precies de gevraagde oplossing zonder zelf een kritische analyse te doen van het probleem.
Rol van kwaliteit
Het probleem ontstaat dus vaak al in het begintraject waarbij er onvoldoende stil wordt gestaan bij de beste werkwijze voor het type project. Door een slechte voorbereiding komt het vaak voor dat er weinig tijd overblijft voor de daadwerkelijke ontwikkeling van het product. Het wordt dan een race tegen de klok en dat gaat meestal ten koste van de kwaliteit.
Agile werken is nog steeds een zeer beproefde methode met veel voordelen, zoals een continue feedback loop en het realiseren van een kortere marktintroductietijd. Maar er moet geen gevoel van structurele haast overheersen tijdens het project. Met name in het begin van een project is het belangrijk om voldoende tijd te nemen om het probleem te analyseren, zodat je zeker weet dat je de juiste oplossing gaat bouwen. Daarnaast moet er meer tijd gereserveerd worden aan het einde van het project, zodat er voldoende mogelijkheden zijn om de restanten van een te snelle eindspint door een deadline weg te werken, zoals bijvoorbeeld tech debt. Het halen van een deadline is belangrijk, maar niet zo belangrijk als het realiseren van een kwalitatief eindproduct.
Auteur: Marc Jousma, business analist en product owner bij Info Support
