Agile, Watervalmethode en PRINCE2, het beste van drie werelden
Agile is een veelgehoorde term, agile is overal! Agile stemt mensen tevreden. Je project gaat beter en je levert het eerder op. Niets mis mee toch? Of toch wel? Is het een hype? Werkt het altijd goed? Spreker en schrijver Dion Kotteman is een ervaren adviseur op het gebied van IT, organisatiestrategie en organisatie-inrichting. Hij legt aan je uit dat projectmatig werken meer dan alleen agile zou moeten zijn.
Omvang van de projecten
Vaak worden projecten die gebruik maken van agile afgezet tegen projecten die volgens een watervalmethode werken. Het algemene beeld hierbij is dat agile projecten veel succesvoller zijn. Dat valt nog te bezien. Recent onderzoek van de Standish Group laat zien dat dat wel 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 wat was afgesproken? Dan blijken overall agile projecten beter te scoren. Maar als je de omvang van de projecten meeneemt in de overweging, ziet het landschap er anders uit. En waarom zou je de omvang niet meenemen? Wat je ziet als je de omvang van een project mee in beschouwing neemt, als je het project dus normaliseert naar grootte, is dat de agile projecten toch iets minder succesvol blijken te zijn.
Misschien dacht je dat al wel; agile projecten werken op kleine schaal niet gek, maar hoe is dat als het project veel groter is? Niet voor niets zie je de 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 zit, moet het resultaat wel voldoen aan de bestaande architectuurafspraken. Tenminste, dat is wel prettig!
Training
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 twee dagen wordt veel gezien. 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 haar dagelijkse stand-ups en het product increment te beschrijven. Binnen een sprint is hij ook in staat om de start-of-sprint workshop, de sprint planning workshop en de end-of-sprint en retrospective te beschrijven.”
Dit is natuurlijk onvoldoende om met succes agile/Scrum, toe te passen. Begrip van Scrum is mooi, maar dan ben je het nog niet Meester. 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 teveel bij de Scrum Master alleen.
“Het kunnen werken in een Scrum-omgeving vraagt om gedragsverandering van iedereen.”
De Product Owner
De rol van Product Owner is de moeilijkste rol en die 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. 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 gedragsverandering van iedereen. Denk hierbij aan samenwerken, vrijheid in communicatie en zelfsturend (nu ook wel zelforganiserend genoemd) kunnen optreden. Om als Scrum-team zelfsturend te werken moeten de opdrachtgever en de Product Owner het Scrum-team deze ruimte ook geven.
Belangrijk hierbij is om het team zoveel mogelijk intact te houden, geen grote tussentijdse wisselingen te hebben. Verder is het belangrijk om alle betrokkenen zoveel mogelijk fulltime op hun taak te laten zitten. 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. En daar komt de link met traditionele methoden om de hoek: combineer het!
Compliancy is een onmisbaar onderwerp geworden. Maar hoe betrek je dat nu bij het agile werken? Niet door achteraf te vragen of het zo goed is. Een succesvolle aanpak bestaat hierbij uit de volgende vier stappen: De compliance officer neemt een actieve positie in en levert specs. Die gaan in de definition of done. De product owner neemt dit in de back log op. Als de sprint geweest is waar deze eisen in zijn opgenomen, beoordeelt de compliance officer of het opgeleverde aan de eisen voldoet.
Van de compliance officer wordt 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 wel eens 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.
Bij architectuur geldt iets vergelijkbaars: teams moeten bij de start verkennen welke architectuur geldt. Zijn er standaards, 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. Je zult al snel zien dat de PRINCE2 principes goed toepasbaar zijn in een agile omgeving. Er is al zoiets als PRINCE2- agile (de synthese van de beide methoden); daar wordt gezocht naar het beste uit beide werelden. 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 gedachtengoed toegepast worden. Dat werkt.
Conclusie
De conclusie van het voorgaande : zorg 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. En vergeet dat het óf óf is: agile kan gesteund worden door PRINCE2 en andersom.
Over Dion Kotteman
Dion Kotteman is een ervaren adviseur op het gebied van IT, organisatie strategie en organisatie inrichting. Hij heeft een achtergrond bij diverse banken (ABN AMRO, RABO, ING) en bij de overheid. Zo was hij Programmadirecteur bij de ING, Algemeen Directeur van de Auditdienst Rijk, Rijks CIO en Raadsadviseur. Dion publiceert regelmatig boeken en is gastdocent aan Nyenrode Universiteit (digital leadership) en TU Delft (projectmanagement). Hij was lid van de Raad van Commissarissen van een verzekeraar en adviseert bedrijven en organisaties.
Kom in contact met de Brunel Informatie Management Community
In de Brunel Community Informatie Management dagen we onszelf en onze specialisten uit om open te blijven staan voor de trends en ontwikkelingen binnen het vakgebied informatiemanagement. Kennisdeling, ontwikkeling en verbinding, daar gaat het om. Tussen experts, specialisten en opdrachtgevers om met elkaar de digitale ambities te realiseren.