Tegenwoordig is Agile helemaal ‘hot’. Als je ergens vertelt dat je een project volgens de watervalmethode doet, dan word je vaak met vreemde ogen aangekeken: dat is immers zó 2014… Maar het “agile” aanvliegen van projecten wil nog niet zeggen dat het een gegarandeerd succes is. Ook die projecten kunnen falen. Hier dan ook een aantal risico’s bij Agile projecten.
Risico’s bij Agile projecten
1. Inleertijd
De spelregels bij Agile lijken to eenvoudig te zijn. Het aantal rollen is beperkt en iedereen die een boek gelezen heeft over Agile kan al snel aan de slag. Daar ligt echter wel een risico, want hoewel de regels makkelijk lijken, vergt het goed Agile kunnen werken een andere cultuur binnen een bedrijf. Dit verander je niet van de één op de andere dag en vergt dus tijd. In plaats van het initieel maken van een plan, worden nu de eisen/wensen continu geprioriteerd en wordt gebouwd wat op dat moment het belangrijkst is. Dat vraagt om een andere manier van het spel spelen door zowel de klant als de leverancier. In de praktijk wordt deze omslag vaak onderschat.
2. Beschikbaarheid van de klant
De klant zit niet alleen aan de voorkant bij het doen van het vooronderzoek en het opstellen van de requirements en als potentiële ‘senior user’ in de Stuurgroep. Nee, de klant is volcontinu aanwezig om af te stemmen met het projectteam over de prioriteiten, de eisen, de wensen, of wat gebouwd is/wordt matcht met de wensen en de “definition of done”, enzovoorts. Dat betekent dat die klant daadwerkelijk ook beschikbaar moet zijn voor dat soort vraagstukken. Zeker als de klant het Agile werken nog niet goed in de vingers heeft, is de kans dat deze beschikbaarheid niet zal voldoen en er toch zaken worden gemaakt die niet helemaal aansluiten bij de ideeën. Dat kan rework inhouden en kostbare tijd doen verspillen.
3. Te weinig documenteren
Het idee van Agile is dat alleen gedocumenteerd wordt, wat daadwerkelijk nodig is en waarde toevoegt. Helaas zien veel projectteams dit als “we hoeven niets te documenteren” – met als gevolg dat er zo weinig op papier staat dat later in het project niet meer precies bekend is hoe iets is ingericht of waarom bepaalde keuzes zijn gemaakt. Ook bij de oplevering naar de lijnorganisatie kan dit voor forse problemen zorgen. Het is dus van groot belang dat er goed wordt gekeken wat de feitelijke minimale set aan documentatie is en dat deze er dus ook komt.
4. Onvoldoende vooruit denken
Het Agile werken nodigt uit tot snel beginnen. We weten wat nu belangrijk is, de backlog is gevuld, de springplanning is klaar – we gaan beginnen – go go go! Totdat bij sprint 10 bedacht wordt dat de dan te realiseren eisen/wensen niet meer mogelijk zijn met de opzet die er dan is: er is bij de architectuur onvoldoende rekening gehouden met het geheel en er is een forse hoeveelheid werk nodig om de architectuur te herzien en zaken opnieuw te bouwen. Ook bij Agile projecten is het aan het begin belangrijk om vooruit te kijken naar wat de klant op dat moment voor ogen heeft. Natuurlijk kan de wereld nog veranderen en de precieze invulling van de sprints ook, maar sluit niet je ogen voor dat wat waarschijnlijk toch komen gaat.
5. Te weinig afstemming met andere teams
Veel projecten zijn dermate groot dat men niet uit komt met één projectteam. Er zijn meerdere teams nodig om de benodigde functionaliteiten te bouwen. Dat is natuurlijk niet iets nieuws, want ook bij traditionele projecten heb je vaak meerdere teams die werkpakketten opleveren. De snelheid waarmee echter zaken kunnen wijzigen, is bij Agile wel een ander verhaal. Dat betekent dat er een goede afstemming moet zijn tussen de teams (via de ‘scrum of scrums’). Waar echter afstemming nodig is, is een potentieel risico aanwezig – en zeker met de dynamiek bij Agile projecten is deze niet te onderschatten.
