Agile: een hype?

Agile is een veelgehoorde term, agile is overal! Agile stemt mensen tevreden: je project gaat beter en je levert eerder op. Niets mis mee toch? Of toch wel? Soms is er een zendingsdrang bij de aanhangers van agile werken te bespeuren waar een gemiddelde missionaris jaloers op zou zijn. Daarom de vraag: gaat werken met agile altijd goed?

Vaak worden projecten die gebruikmaken van agile afgezet tegen projecten die volgens een watervalmethode werken. Het algemene beeld dat hierbij wordt gecreëerd is dat agile-projecten veel succesvoller zijn. Maar dat valt nog te bezien. Recent onderzoek van de Standish Group laat zien dat dat meevalt als je naar de omvang van de projecten kijkt. De Standish Group heeft de succesrate van watervalprojecten afgezet tegen die van agile-projecten.

De succesrate is als volgt gedefinieerd: wordt er binnen budget en op tijd geleverd, zoals afgesproken? Dan blijken overall agile-projecten beter te scoren. Maar neem je de omvang van de projecten mee in de overweging, dan ziet het landschap er anders uit. En waarom zou je de omvang niet meenemen? Een groot watervalproject is een project en een klein agile-project ook, al zijn er natuurlijk wel grote verschillen. Wat je ziet als je de omvang van een project meeneemt in de beschouwing – het project dus normaliseert naar grootte – is dat de agile-projecten toch iets minder succesvol blijken te zijn.

Scaling agile

Misschien dacht je dat al wel, dat agile-projecten op kleine schaal niet gek werken, maar hoe is dat als het project veel groter is? Niet voor niets zie je behoefte aan samenhang als er meer kleinere teams zijn. Dan ontstaan er ‘tribes’ die voor afstemming zorgen. Daar komt nog bij dat er ook afstemming nodig is om delen in het geheel te passen: prima als je een klein projectje op een agile-manier doet, maar als je in een grote organisatie werkt, moet het resultaat wel voldoen aan de bestaande architectuurafspraken. Sommige auteurs, zoals Henny Portman, propageren in dit licht ‘scaling agile’ alsook het ontwikkelen van een hybride aanpak. Niet enkel
agile dus. Portman betoogt op dit punt het volgende: ‘Traditionele of hybride projecten zullen blijven bestaan, waarbinnen gebruikgemaakt wordt van zowel agile als meer traditionele aanpakken. Blijft er dus behoefte aan een projectmanagerrol, maar dan wel een die zich binnen de lijnorganisatie zal gaan ontwikkelen in de richting van portfoliomanager, agile-coach of product owner?’

Trainingen en de kwaliteit ervan

Training is natuurlijk belangrijk als je een nieuw concept introduceert. Er is geen gebrek aan agile-trainingen, de markt speelt er goed op in. Maar hoe is het met de kwaliteit? Een training voor scrum master van slechts twee dagen wordt veel gezien. Wat staat er in 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 scrumprocesmodel met daarbinnen de product backlog, sprint backlog, de sprint met haar 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.’

Wat je ziet als je de omvang van een project meeneemt in de beschouwing – het project dus normaliseert naar grootte – is dat agile-projecten toch iets minder succesvol blijken te zijn

Dit is natuurlijk onvoldoende om met succes agile/scrum, toe te passen. Begrip van scrum is mooi, maar dat maakt je nog geen scrum master. Wil je met succes agile werken invoeren, dan vraagt dat veel begeleiding. De scrum master moet stevig in zijn schoenen staan, het gaat ook om een verandertraject. Een scrum-coach is soms een goede optie: die begeleidt de scrum master zodat hij het team effectiever en efficiënter kan maken. Naast de scrum master moet het hele scrum-team een training krijgen en begeleid worden bij het toepassen van scrum. Anders blijft de actie te veel bij de scrum master alleen.

De product owner

De rol van product owner is de moeilijkste rol en wordt bovendien 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. Hij moet de verbinding met de business zijn.

Het kunnen werken in een scrum-omgeving vraagt om een 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.

Belangrijk hierbij is om het team zoveel mogelijk intact te houden, geen grote tussentijdse wisselingen te hebben. En verder ook om alle betrokkenen zoveel als mogelijk fulltime hun taak te laten uitvoeren. Ook het in dezelfde ruimte werken bevordert de communicatie en de samenwerking binnen het team. Blijkt dit niet mogelijk, maak dan gebruik van moderne communicatiemiddelen, elektronische teamborden en dergelijke.

Waar kan het misgaan?

Agile-projecten kunnen op een aantal elementen de mist in gaan. De belangrijkste zijn compliancy en architectuur. Compliancy is een onmisbaar onderwerp geworden. Het krijgt steeds meer aandacht en steeds vaker is er een compliance officer die het onderwerp in de gaten houdt. Maar hoe betrek je die nu bij het agile werken? Niet door achteraf te vragen of het zo goed is. Een succesvolle aanpak bestaat uit de vier stappen:

1. De compliance officer neemt een actieve positie in en levert specs.
2. Die gaan in de definition of done.
3. De product owner neemt dit in de backlog op.
4. Als de sprint geweest is waar deze eisen in zijn opgenomen, beoordeelt de compliance officer of het opgeleverde aan de eisen voldoet (zie figuur 1).

Van de compliance officer wordt dus een proactieve houding verwacht. Hij vult de definition of done in met concrete eisen. Zo wordt dat tijdig in het proces ingebracht. Aan het eind checkt hij of het goed is uitgevoerd. De praktijk is nog weleens dat de compliance officer alleen aan het eind optreedt en dan zijn de rapen gaar. In het ergste geval kun je dan niet live met je mooi met agile ontwikkelde applicatie.

De verzameling compliancerichtlijnen groeide de afgelopen jaren enorm. Er moet steeds opnieuw aangetoond worden dat voldaan is aan alle in- en externe regels. Het gevaar bij agile werken is dat deze noodzakelijke regels te makkelijk naar de achtergrond verschuiven.

Bij architectuur geldt iets vergelijkbaars: teams moeten bij de start verkennen welke architectuur geldt. Zijn er standaarden, en welke? Is er een chief architect die checkt en regels geeft? Consulteer die dan ruim voor de aanvang en niet pas op het eind!

Daarnaast is het de moeite waard ook naar bestaande Prince2-principes, processen en thema’s te kijken, 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 agile-aanpak vind je vooral terug binnen de productoplevering. Afhankelijk van de situatie kan meer of minder van het agile- of Prince2-gedachtegoed toegepast worden.

Conclusie

De conclusie van het voorgaande is: zorg ervoor dat agile meer is dan een hype, bouw bestaande methoden en restricties in, zorg voor de benodigde aandacht voor compliance, pas op de architectuur en leid (en begeleid!) de mensen echt op in agile werken. Dan is het prima denkbaar dat agile-
projecten overall nog eens succesvoller worden dan de traditionelere methoden!