Agile is meer dan een hype

Overal, in it-land en daarbuiten, hoor je 'Agile, Agile!’. Deze methode heeft stad en land veroverd. En dat is verklaarbaar: met Agile gaat je project beter en je levert eerder op wat wordt gevraagd. Niets mis mee toch? Of toch? Er zijn ook geluiden dat die methode soms niet goed werkt, dat er dingen vergeten lijken te worden. Zitten er ook grenzen aan het Agile werken? Waar moet je dan op letten?

Vaak worden projecten die gebruik maken van Agile afgezet tegen projecten die volgens een waterval methode werken. Het algemene beeld dat hierbij wordt gecreëerd is dat Agile-projecten veel succesvoller zijn.

In de figuur zien we dat bij het gebruik van Agile 42 procent van de projecten succesvol wordt opgeleverd en slechts 14 procent in het geval van een waterval aanpak. Hierbij staat succesvol voor het binnen tijd, geld en conform de specificaties opleveren van een project.

Bij deze cijfers wordt echter geen rekening gehouden met het verschil in omvang van de verschillende projecten. Een klein Agile-project vergelijken met een groot waterval-project is maar beperkt zinvol. Als deze cijfers genormaliseerd worden naar grootte en je vergelijkt projecten van gelijke omvang dan krijg je een heel ander beeld. Dan is het percentage succesvolle Agile-projecten zelfs iets kleiner dan het percentage succesvolle waterval-projecten.

Training

Organisaties die besloten hebben om met Agile te beginnen, vragen projectleiders om zich te bekwamen door een training voor Scrum Master van twee dagen te volgen. Wat zegt de folder van een dergelijke training? ‘Aan het eind van de training is de Scrum Master in staat om de Scrum-principes te benoemen, en het Scrum-procesmodel met daarbinnen de product backlog, sprint backlog, de sprint met de dagelijkse stand-ups en het product increment te beschrijven. Binnen een sprint is hij ook in staat om start-of-sprint workshop, de sprint planning workshop en de end-of-sprint en retrospective te beschrijven.’

Dit is onvoldoende om met succes Agile/Scrum, toe te passen. Begrip van Scrum is mooi, maar dat maakt je nog geen Srum Master. Wil je met succes de rol van Scrum Master kunnen uitoefenen dan vraagt dat veel begeleiding. Een Scrum-coach is een goede optie: die begeleidt de Scrum Master zodat hij/zij het team effectiever en efficiënter kan maken. Naast de Scrum Master moet het gehele Scrum-team een training krijgen en begeleid worden bij het toepassen van Scrum.

De rol van Product Owner is de moeilijkste rol en wordt vaak onderschat. De Product Owner heeft eigen verantwoordelijkheden en ook hij heeft hiervoor ondersteuning nodig in de vorm van training en coaching. Het producteigenaarschap is geen taak die je er even bij doet. De Product Owner zal substantieel tijd vrij moeten maken om deze rol succesvol te kunnen uitvoeren. Je zou kunnen zeggen dat de Product Owner alle taken heeft die bij een slecht watervalproject tot problemen kunnen leiden.

Het kunnen werken in een Scrum-omgeving vraagt om gedragsverandering van alle betrokkenen. Denk hierbij aan samenwerken, vrijheid in communicatie en zelfsturend kunnen optreden. Om als Scrum-team zelfsturend te kunnen functioneren moeten de opdrachtgever en de Product Owner het Scrum-team deze ruimte ook geven. Overigens: de voorkeur groeit om zelfsturende teams ‘zelforganiserend’ te noemen.

Houd het team zoveel mogelijk intact en laat alle betrokkenen zoveel als mogelijk fulltime op hun taak zitten. Ook het in dezelfde ruimte zitten bevordert de communicatie en samenwerking binnen het team. Is dit niet mogelijk maak dan gebruik van moderne communicatiemiddelen, elektronische teamborden et cetera.

Prince2

Compliancy is een onmisbaar onderwerp geworden. Het doorvoeren van wijzigingen is alleen toege-staan als voldaan wordt aan vooraf gestelde richtlijnen, gesteld door zowel de eigen organisatie als de externe toezichthouders. De verzameling compliancy richtlijnen is de afgelopen jaren enorm gegroeid. Er moet steeds opnieuw aangetoond worden dat voldaan is aan alle compliancy regels. Het gevaar bij Agile werken is dat deze noodzakelijke regels naar de achtergrond verschuiven.

Daarnaast is het de moeite waard ook naar bestaande Prince2 principes, processen en thema’s te kijken, en die kunnen op basis van de Agile uitgangspunten per project op maat worden gemaakt. Binnen Prince2 Agile (de synthese van de beide methoden) wordt gezocht naar het beste uit beide werelden waarbij het accent van het Prince2 gebruik ligt op de projectbesturing en het projectmanagement. De Agil- aanpak vind je vooral terug binnen de productoplevering. Afhankelijk van de situatie kan meer of minder van het Agile of Prince2 gedachtengoed toegepast worden.

Conclusie

Er is dus niets mis met Agile, maar het is wel de moeite met onder andere de bovenstaande punten rekening te houden. Wil je dat uitgebreider lezen? Kijk dan in het door mij in samenwerking met Bert Hedeman en Henny Portman geschreven en onlangs verschenen boek: ‘Agile with a smile‘.