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
“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. ”
Dit citaat raakt precies de kern van het probleem:
– De business vraagt om een concrete oplossing
– De business legt een dead-line op
– Het team maakt geen kritische analyse
Het probleem is hier (minstens) drievoudig, waarbij het me sterk doet denken aan de onmogelijke driehoek van kosten, tijd en functionaliteit. Hier liggen de parameters net iets anders, maar toch.
De business vraagt om een concrete oplossing, maar is de business ook bereid om de verantwoordelijkheid te nemen over de gevolgen? Door een concrete oplossing af te dwingen red je het als team misschien voor de deadline, maar je krijgt als team niet het luisterende oor van de business als je de nadelen van de oplossing aandraagt. Of je ziet als team dat dit niet de oorzaak wegneemt, maar slechts een symptoom bestrijd. Met als gevolg dat dit zou kunnen leiden tot het beruchte waterbed-syndroom.
Het komt voor, maar het is zelden dat de business volledig op de hoogte is van de (technische) architectuur van de applicatie. Net zo zelden (of eigenlijk vrijwel nooit) komt het voor dat de business echt de verantwoordelijkheid neemt voor de opgelegde concrete oplossing.
De business legt een dead-line op. In deze situatie krijgt het team meer de ruimte om de oorzaak aan te passen, maar kennelijk is er een symptoom dat dusdanig ernstig is dat er ‘bloed vloeit’. Een goed team voelt aan dat dit een snelle oplossing vergt en zal proberen zo snel mogelijk het bloeden te stelpen. Echter, een perfect team zou moeten aangeven dat dit alleen het symptoom bestrijd, dat dit alleen een noodverband is, en in een perfecte wereld zou de business deze uitleg ook moeten aanvaarden en het team de ruimte geven om de daadwerkelijke oorzaak aan te pakken. Met prioriteit. En in de praktijk blijkt dan dat het werken aan de geplande nieuwe functionaliteit dan niet mag schuiven. “Het werkt toch weer? Het probleem is toch weg?” En het team wordt gedwongen om het noodverband te laten zitten. Tot het bloed weer door het noodverband sijpelt en de business het team de schuld in de schoenen schuift omdat het niet opgelost is.
Als het team de kritische analyse van het onderliggende probleem mag doen, is het waargenomen probleem nog steeds urgent aanwezig. Er kan niet gewerkt worden aan nieuwe functionaliteit (of in elk geval met minder capaciteit) en dead-lines komen in gevaar. En dan ontstaat er vaak een politiek probleem. De managers worden afgerekend op niet gehaalde dead-lines (symptoom van excel-sheet management en KPI gedreven organisaties) en deze reageren dit af op de teams. Die worden gedwongen om OF veel minder kritisch te analyseren (wat vaak leidt tot symptoom bestrijding) of het aanleggen van een noodverband (wat symptoombestrijding is), zodat weer aan functionaliteit kan worden gewerkt.
Managers en leiders gaan anders om met deze drie parameters; een echte Agile georienteerde organisatie zou niet moeten vasthouden aan deadlines, maar accepteren dat functionaliteit opgeleverd wordt in delen wanneer ze klaar zijn en teams moeten beseffen dat perfect de vijand is van gereed.
Ik zou willen zeggen dat snelheid en kwaliteit even belangrijk zijn en met elkaar gewogen dienen te worden in de context van het veld waarin de organisatie zich bevindt. Er zijn situaties waarbij kwaliteit de boventoon dient te voeren (bijv. als er levens van af hangen) ten koste van snelheid en functionaliteit. Er zijn situaties waarbij snelheid de boventoon voert (als er geen levens van af hangen en de functionaliteit eenvoudig kan worden uitgebreid en/of verbeterd). Er zijn situaties waarbij de functionaliteit niet eenvoudig kan worden uitgebreid (omdat deze bijv. is ingebakken in de hardware) en de organisatie de verwachtingen beter moet managen (niets verkopen zonder de teams erbij te betrekken).
Dit is weer zo’n mooie driehoek (veiligheid in al zijn aspecten is een vorm van kwaliteit in dezen).
Straks weer artikel over dev-qual-fast-ops, waarna iemand gaat zeuren dat het ook goedkoop moet zijn.