Projecten in een Agile omgeving, hoe werkt dat?

Veel mensen binnen het vakgebied informatievoorzieningsmanagement zijn stellig: projecten en Agile gaan niet samen. Vanuit de theorie is dit goed te begrijpen, want het toevoegen van projectrollen, het doorlopen van projectfases én het bijhouden van projectdocumentatie lijkt inderdaad niet samen te gaan met de principes van Agile. Toch is de kwestie niet zo zwart-wit als we soms denken.  

Het is een hoge eis om als organisatie, op alle niveaus, volledig Agile te werken. Hoe groter de organisatie, hoe moeilijker dit in praktijk blijkt te zijn. De organisatie kan dan kiezen uit drie opties: 

1. Stoppen met projecten en zorgen dat iedereen binnen de organisatie Agile gaat werken
2. Accepteren dat Agile-teams een andere werkwijze hanteren en doorgaan met organisatie brede projecten 
3. Projecten laten aansluiten op de Agile-teams zonder de Agile manier van werken te verstoren 

Omdat de eerste optie in praktijk vaak onhaalbaar is zullen organisaties een voorkeur hebben voor de derde optie. In de derde optie worden de krachten van projectmanagement en Agile namelijk gebundeld. De tweede optie zal over het algemeen nooit de voorkeur hebben, omdat dit leidt tot twee aparte werkwijzen waarbij weinig met elkaar gecommuniceerd wordt. Bij de tweede optie moet ook vaak achteraf bijgestuurd worden, waardoor het behalen van organisatiedoelstellingen moeilijk is.  

Helaas zien we in praktijk de tweede optie het meest voorkomen, ondanks goede intenties om voor de derde optie te gaan. Dat komt omdat onvoldoende begrepen wordt hoe projectmanagement goed kan aansluiten bij Agile werken op de werkvloer. Het heeft namelijk geen zin om projecten op een statische manier te doorlopen en daarin een constructieve bijdrage van Agile teams te verwachten. Een projectmanager die taken delegeert naar het Agile team, en vervolgens wacht tot de deadline voor oplevering, komt vaak bedrogen uit. Dit komt omdat de meerwaarde en de noodzaak van het project dan onvoldoende duidelijk zijn. In dit geval is de projectmanager maar één van de zoveel stakeholders die iets van het Agile team verwacht.  

Vooral aan de kant van projectmanagement moeten Agile werkwijzen geïmplementeerd worden om de aansluiting te vinden. In het Prince2 Agile framework wordt de volledige structuur van Prince2 doorgelicht en toegepast op Agile productoplevering. In deze blog wordt een suggestie gedaan om de drie meest gevoelde pijnpunten voor aansluiting op te lossen, namelijk:  

1. de afstandelijke projectmanager;
2. de statische projectfases; en
3. de overvloedige projectdocumentatie.  

Binnen projectmanagement is de positie van de projectmanager essentieel. De projectmanager is verantwoordelijk voor het dagelijks managen van het project om de afgesproken producten op te leveren. Deze producten worden opgeleverd door het Agile team, soms in samenwerking met een leverancier. De projectmanager is daarmee afhankelijk van het Agile team, maar het Agile team is ook afhankelijk van de projectmanager om de juiste producten te kunnen leveren.  

Het is dus belangrijk dat de projectmanager en het Agile team elkaar goed begrijpen. Dit kan door als projectmanager zelf plaats te nemen in het Agile team als het gaat een project waar één team aan werkt. Bij grotere projecten met meer teams is het aan te raden om per team een teammanager aan te wijzen, in plaats van als projectmanager zelf bij elk team plaats te nemen. De teammanager ziet erop toe dat de afgesproken producten met de juiste kwaliteit en doorlooptijd worden opgeleverd. De teammanager kan gezien worden als de belangrijkste schakel tussen de projectmanager en het Agile team. De rol van teammanager kan verdeeld worden onder de Scrum Master, Product Owner en ontwikkelaars. Een andere optie is om een teammanager als functie toe te voegen aan het Agile team.  

Voor welke vorm gekozen moet worden is per organisatie verschillend. Het is vooral belangrijk dat de afstand tussen het Agile team en de projectmanager wordt weggenomen. Het staat namelijk vast dat de projectmanager invloed gaat uitoefenen op het Agile team, omdat vanuit het management een opdracht is gekomen. In dat geval kan de projectmanager beter je vriend zijn (en kan je al projectmanager ook beter vrienden met het team zijn). 

Projecten duren soms maanden terwijl sprints enkele weken duren. Daarnaast heeft een project vaak een harde deadline en een chronologische volgorde van opstarten tot afsluiten. Daarmee lijkt het een lastige opgave om Agile werken en projectmatig werken in dezelfde flow te krijgen. Toch is dit mogelijk door met werkpakketten te werken.  

Een werkpakket

Een werkpakket bevat alle informatie die relevant is voor het maken van één of meerdere producten, zoals een productbeschrijving, en kan gezien worden als een overeenkomst tussen de projectmanager en het Agile team. Werkpakketten die te groot, te gedetailleerd of simpelweg onrealistisch zijn kunnen met goede onderbouwing door de teammanager worden afgewezen. Bijvoorbeeld een groot werkpakket, met verschillende onderdelen waarbij veel afstemming nodig is, past vaak niet binnen één sprint. Het is dan handiger om het werkpakket in kleinere delen op te knippen. Een afwijzing van een werkpakket zal in traditioneel projectmanagement leiden tot vertraging en een teleurgestelde business. Andersom zal het accepteren van te grote werkpakketten ook tot teleurstelling leiden, omdat niet aan de verwachtingen kan worden voldaan.  

De 6 toleranties

Vaak lijkt alles binnen een project prioriteit te hebben én is de oplossing al volledig uitgedacht, nog voordat het Agile team aan de slag gaat. Daarom moet anders gekeken worden naar toleranties op zes aspecten: tijd, kosten, benefits, risico, kwaliteit en scope. Om projecten in de juiste flow te krijgen moeten tijd en kosten van een project vast staan. Het verschuiven van de deadline of het ophogen van capaciteit is niet de juiste Agile oplossing. Daarentegen verschuift de variabiliteit juist naar benefits, risico, kwaliteit en scope.  

Minimum Valuable Product (MVP)

Regelmatig bevat de businesscase één totaaloplossing met een specifieke scope, maar om projecten te laten werken in een Agile omgeving is een businesscase met een minimum valuable product (MVP) meer geschikt. Door te beschrijven waaraan het product minimaal moet voldoen om tijd en kosten te rechtvaardigen, laat dit het Agile team ruimte om hun werk op de andere vier aspecten op maat te maken. Belangrijk hierin is verwachtingsmanagement: door aan het begin de business geen gouden bergen te beloven krijgt het Agile team ruimte om samen met de business een passende oplossing te vinden. 

Projecten brengen vaak documentatie met zich mee. Heel veel documentatie. In het Agile manifest spreekt men de voorkeur uit voor werkende software boven allesomvattende documentatie. De 26 (!) soorten projectbeschrijvingen bij projectmanagement lijken daarmee onmogelijk te passen bij een Agile omgeving. Ook hiervoor zijn aan de projectmanagementzijde aanpassingen nodig. 

Ten eerste hoeft niet elke projectbeschrijving, zoals de businesscase, allesomvattend te zijn. Het gaat erom dat elk document een specifiek doel beschrijft, ongeacht de vorm. Documentatie mag dus ook in de vorm van een PowerPoint, een Excel-bestand of een gefotografeerde flipover. Lijvige documenten van meerdere pagina’s zijn niet Agile en worden vaak ook minder goed begrepen. Daarentegen helpt minimale documentatie juist bij de toetsing door het Agile team, bijvoorbeeld of opgeleverde producten voldoen aan de Definition of Done. Door in documentatie alleen te benoemen wat écht belangrijk is, voorkom je dat tijd verloren gaat aan het achterhalen van hoofd- en bijzaken.  
 
Ten tweede hoeft het Agile team niet alle documentatie te schrijven en volledig te doorgronden. Het is alleen belangrijk dat de juiste informatie vindbaar is, zodat zij hun werk goed kunnen doen. Uiteindelijk kan een Agile team zelf voldoende hebben aan een Kanban en het uitwerken van user stories. Het gaat er namelijk vooral om dat projectmanagement en Agile elkaar beter weten te vinden, zonder dat ze elkaars werk overnemen. Om de aansluiting te vinden moet je weten waar ieders grenzen liggen. Daarmee kunnen projecten prima naast een Agile team bestaan, mits projectmanagement zelf óók aanpassingen wil doen om Agile te werken.