De bijsluiter bij Agile

Agile en risicomanagement

Agile alchemisten presenteren agile als wondermiddel: ze beloven je producten met 100 procent klanttevredenheid, gebouwd door teams die het beste uit zichzelf halen. Risico’s zijn er volgens hen niet. Wel is agile werken, zoals je altijd al dacht en wellicht hebt ervaren, vaak het beste middel. Maar die ronkende beloften zijn niet reëel. Agile werken is niet vrij van risico’s. Ook agile trajecten kunnen verziekt raken en doodlopen. Het is goed de positieve effecten én de bijwerkingen van agile te kennen. In dit artikel geven we een bijsluiter bij dit wondermiddel.

 

Het verkoopverhaal is dat er nauwelijks risico’s kleven aan agile werken. De scrum guide stelde tot eind 2020 dat risico’s zich beperken tot de kosten van één sprint. De grote aandacht die er in klassiek projectmanagement is voor de beheersing van tijd, geld, kwaliteit en voor risico’s, die is er in agile niet. Agile werken reduceert zeker een aantal risico’s onder andere door de grote betrokkenheid van de business en het iteratief en incrementeel werken. Transparantie en inspectie maken snelle aanpassing mogelijk. Maar agile werken neemt niet alle risico’s weg; het introduceert ook nieuwe. En snel leveren van werkende software is niet altijd de beste manier om risico’s te onderkennen en te ondervangen. Om meer inzicht te krijgen in risico’s in agile trajecten, heeft KWD onderzoek uitgevoerd.

Onderzoek naar risico’s in 30 agile trajecten

Uit de literatuur hebben we 50 risico’s gedestilleerd die bij software-ontwikkelprojecten kunnen optreden. Deze risico’s hebben we gegroepeerd in vijf categorieën: 1) Beheersing en Besturing, 2) Tools en Architectuur, 3) Samenwerking met de rest van de organisatie, 4) Samenwerking binnen het team en 5) Eindresultaat.

Vervolgens hebben we 30 agile trajecten bekeken van 30 verschillende agile leaders. Onderzocht is welke risico’s daarin een probleem werden. Aan de agile leaders is gevraagd hoe zij dachten dat agile werken die risico’s heeft vergroot of verkleind. De inzichten die we hebben opgedaan, delen we in dit artikel: Wat zijn de belangrijkste risico’s? En hoe kun je problemen voorkomen?

Tabel 1 geeft een overzicht van de positieve effecten en de bijwerkingen van agile werken, per risico-categorie.

Beheersing en besturing 
Betrokken bestuurdersOnduidelijkheid over rollen
 Onduidelijkheid wanner resultaten worden geleverd
Samenwerking met de rest van de organisatie 
Gecommitteerde businessLate constatering van issues door combinatie van requirements
Beter verwachtingsmanagementStakeholders uit beeld
Heldere requirementsVerschillende werkwijzen tussen verschillende teams
 Gebrek aan samenwerking tussen teams en omgeving (bv QA, Legal)
 Uitstel van ontwikkelingen met hoog risico
 Requirement-conflicten tussen verschillende product owners
Samenwerking binnen team 
Goed teamwerkMinder oog voor vakmanschap
Focus op projectbelangUitstel van vervelende taken
Eindresultaten  
Eindresultaat voldoet beter aan verwachtingen van eindgebruikersEindresultaat niet goed beheerbaar en/of uitbreidbaar
Eindresultaat voldoet beter aan verwachtingen van opdrachtgever / management 
Positieve effectenBijwerkingen 

Tabel 1. Overzicht van de positieve effecten en de bijwerkingen van agile werken, per risico-categorie.

Volgens de ervaring van de respondenten verhoogt agile werken risico’s het meest in de categorie Beheersing en Besturing. Ook in de categorie Tools en Architectuur en de categorie Samenwerking vergroot agile werken risico’s. Opmerkelijk was dat in de categorie Samenwering binnen team evenveel positieve als negatieve effecten werden gerapporteerd. Ten aanzien van het eindresultaat hebben de respondenten juist minder risico’s ervaren; agile trajecten leveren betere eindresultaten op.

Een aantal in het oog springende resultaten lichten we verder toe.

Eindresultaten en verwachtingen

In ruim 80 procent van de onderzochte agile trajecten werd tijd en budget overschreden. Zeker grote en vernieuwende IT-trajecten zijn weerbarstig, agile werken lost dat niet volledig op. Daarbij speelt waarschijnlijk een rol dat de verwachtingen van een agile team en de verwachtingen van bestuurders uiteen lopen. Teams kunnen relatief makkelijk het agile gedachtengoed omarmen en zich richten op de stories bovenaan de backlog, zonder vastomlijnd beeld van het eindresultaat. Voor bestuurders kan die agile mindset lastig zijn. Ze zijn verantwoordelijk voor de realisatie van een businesscase en daarvoor moeten bepaalde resultaten behaald worden. Regelmatig wordt een agile traject verlengd om dichter bij die verwachte resultaten te komen.

Dat neemt niet weg dat in agile trajecten de resultaten beter voldoen aan de verwachtingen van eindgebruikers, en beter voldoen aan de verwachtingen van opdrachtgevers; agile werken levert betere eindresultaten op.

Technische risico’s en architectuur

Een belangrijk risico van agile werken is verminderde aandacht voor architectuur en technische issues. De Product Owner is gericht op de realisatie van business value. Het team heeft een korte horizon en de nadruk ligt op snelle oplevering van een werkend product. Regelmatig moet een team de agile aanpak al werkend onder de knie krijgen. Technische risico’s verdwijnen dan al snel uit beeld. Stories die voor de business niet direct waarde opleveren worden uitgesteld, zeker als die technisch complex zijn en daardoor duur. Dit geldt bijvoorbeeld voor de oplossing van technical debt, zoals de upgrade naar een nieuwe versie van een platform of tooling. De gezamenlijke verantwoordelijkheid van teams is hier een valkuil; iedereen is verantwoordelijk, en daardoor niemand. Het is menselijk om even de kat uit de boom te kijken, zeker als een probleem nog niet urgent is, of lastig op te lossen. Om zeker te weten dat iemand in actie komt, is het nodig om vóóraf duidelijke afspraken te maken hoe problemen worden aangepakt. Het is goed een bhv’er te benoemen, die het gele hesje aantrekt zodra er een probleem optreedt en het brandalarm afgaat. De bhv’er zorgt dat het pand wordt ontruimt. Als iedereen luistert naar de bhv’er komt de calamiteit het snelst onder controle.

En ander aandachtspunt is de architectuur van de oplossing. In agile trajecten worden relatief vaak gaandeweg nieuwe inzichten opgedaan die een herziening van de architectuur nodig maken. Dat zijn vaak kostbare veranderingen (veel duurder dan één sprint). Zeker voor grote trajecten is het belangrijk om vooraf een architectuur vast te stellen, in plaats van deze te ‘laten ontstaan’. Dat voorkomt dat het fundament instabiel wordt en dat na een aantal sprints het totale bouwwerk instort.

Vakmanschap

In agile is er veel waardering voor de breed inzetbare medewerker met een T-shaped profiel. Medewerkers zijn in de eerste plaats onderdeel van een agile team en voelen zich minder verbonden met expertise centers of vakgroepen, als die er al zijn. Er is minder aandacht voor verdieping van vakmanschap. Grote en vernieuwende trajecten vragen echter vaak om diepgaande expertise, niet alleen van developers maar ook op het gebied van architectuur, testen, UX-design en security. Het loont daarom om te investeren in vakmanschap. Dat kan door middel van trainingen en bijeenkomsten in vakgroepen. Dat zorgt ervoor dat experts elkaar versterken vanuit het principe: ijzer scherp je met ijzer.

Samenwerking

Verwachtingsmanagement en commitment van de business zijn in het algemeen beter in agile trajecten. Dat is natuurlijk geen verrassing: betrokkenheid van de business is een van de beginselen van agile. Maar er zijn wel een paar aandachtspunten. In de helft van de onderzochte trajecten ontstonden problemen in de samenhang van oplossingen doordat verschillende product owners verschillende prioriteiten stelden. En zeker bij trajecten met veel stakeholders, is het voor een product owner onmogelijk om alle belangen te overzien en alle gebruikerseisen scherp in beeld te krijgen.

Het is belangrijk dat de PO op een gestructureerde manier input krijgt, bijvoorbeeld vaneen klankbordgroep met verschillende gebruikersgroepen. Daarnaast is het belangrijk om support van management voor de PO te organiseren. Dat kan bijvoorbeeld door managers deelgenoot te maken van de ontwikkelingen en ze uit te nodigen voor demo’s. 100 procent mandaat voor de PO is er vaak alleen op papier.

Conclusies

Agile werken en risico-management horen bij elkaar. En in een aantal agile methoden wordt risicomanagement expliciet aan de orde gesteld, bijvoorbeeld in SAFe en in Prince2Agile. Maar in de praktijk wordt het medicijn agile al enthousiast toe gediend terwijl de bijsluiter over risicomanagement nog ongelezen in de la ligt. Hiervoor zijn verschillende oorzaken aan te wijzen. Veel risico-management methoden maken gebruik van strikte processen en formele akkoorden, wat niet lijkt te passen in agile omgevingen waar de nadruk ligt op ‘individuals and interactions over processes and tools’. Het beeld bestaat dat risico management saai en stoffig is, en agile juist snel. Ook worden problemen in agile trajecten soms wat gemakzuchtig weggezet als het gevolg van slechte toepassing van agile. Dat staat een realistische analyse van risico’s in de weg.

Agile werken zorgt voor betere resultaten en grotere klanttevredenheid. Maar het is geen wondermiddel dat, als het goed wordt toegepast, alle problemen doet verdwijnen als sneeuw voor de zon. Voor een gezonde toepassing van agile is het belangrijk om te benoemen welke risico’s spelen in een traject. Beoordeel de positieve effecten van agile én ken de bijwerkingen. En maak duidelijke afspraken over wie acties neemt als risico’s zich voordoen. Lees de bijsluiter.

 

Blogdetails

28-06-2021
vakblad

Wil je meer weten?

We vertellen je graag meer over onze aanpak van het succesvol managen van projecten en programma’s.

Bel ons op 088 266 28 70 Stuur ons een bericht