De ict-branche heeft een slechte naam als het gaat over het op tijd opleveren van projecten en dat daarbij het budget geen geweld is aangedaan. Regelmatig worden we opgeschrikt door mislukte ict-projecten die bergen geld hebben gekost. Agile projectmanagement zou echter het ei van Columbus zijn. De gebruiker krijgt niet wat hij wil, maar wat hij nodig heeft. Anthony Louws is overtuigd van de kracht van Agile projectmanagement, maar er komt wel veel bij kijken.
Agile development betekent grofweg leveren wat de klant nodig heeft in plaats van wat deze wil hebben. Het is een vaak geciteerde kreet waar velen blij van worden. De klant is blij omdat hij toch niet precies weet wat hij wil en er nu langer over kan nadenken. De projectmanager is blij omdat hij denkt van eindeloze discussies over verkeerd geïnterpreteerde specificaties en scopecreep af te zijn. De tester is blij omdat hij er vroeg bij betrokken wordt en het verschil kan maken. Tot slot is ook de ontwikkelaar blij, omdat er eindelijk naar hem geluisterd wordt. Dat is mooi, zou je zeggen en het is bijna gênant dat we daar niet dertig jaar geleden achter gekomen zijn. Want eerlijk is eerlijk, de ict-branche heeft geen beste naam als het gaat om ‘on-time, on-budget delivery'.
Het team
In het Agile gedachtegoed staat de rol van het team vaak centraal. Dat is begrijpelijk want zij zijn degenen die de werkende software moeten realiseren en daar gaat het uiteindelijk om. De rol van de projectmanager wordt minder vaak belicht. Toch ondergaat ook de rol van de projectmanager belangrijke wijzigingen. Alleen al het feit dat sommige stromingen beweren geen projectmanager nodig te hebben geeft aan dat de Agile wereld worstelt met deze rol.
Agile betekent ook: meer zelfsturing, teamverantwoordelijkheid, empowerment van de projectmedewerkers. Als projectmanager in een Agile omgeving richt je je op coachend en stimulerend leiderschap. Klassiek PMBOK of Prince2 geschoolde projectmanagers zullen zich moeten realiseren dat een directieve manier van leidinggeven moeilijk te verenigen is met het Agile gedachtegoed. Er is weinig ruimte voor instrueren als je tegelijkertijd zelfsturing en empowerment van de medewerkers predikt.
Senior of junior
Hier zit ook gelijk een valkuil voor de projectmanager. Vanuit het situationeel leiderschap weten we dat een coachende of delegerende leiderschapsstijl alleen effectief is bij competente senior medewerkers. Medewerkers die er nog niet aan toe zijn of niet gewend zijn om deze manier van leiding te ontvangen voelen zich onbegrepen of reddeloos verloren. Wellicht gaan ze teveel hun eigen weg. In ieder geval wordt er niet het beste uit hen gehaald. Kort gezegd: projectmedewerkers met onvoldoende persoonlijke senioriteit of verantwoordelijkheidsgevoel die deze vrijheid niet aan kunnen, kun je niet gebruiken in een Agile-omgeving.
Dat betekent dat je bij de samenstelling van het team en de selectie van de medewerkers voor je project scherper zult moeten selecteren op de eigenschappen verantwoordelijkheidsgevoel en consciëntieus gedrag.
Is er dan helemaal geen plaats voor junior medewerkers? Toch wel. Het gaat meer om gedrag en aanpassingsvermogen dan om de vraag of een ontwikkelaar tien jaar Java ervaring heeft. Juniors in een Agile-team kan, maar niet in het begin en niet teveel tegelijk. Mocht je als projectmanager echter overwegen om junior medewerkers in het Agile team op te nemen dan alleen als aanvulling op een inmiddels goed lopend team waarin de Agile werkwijze ‘business as usual' geworden is. Dat schept de voorwaarden om juniors snel te kunnen laten inwerken zonder dat het proces verstoord raakt.
Controlekramp
De Agile werkwijze brengt nog iets anders met zich mee waar je je als projectmanager goed op moet instellen. Van oudsher hebben directies, senior management en opdrachtgevers sterk de neiging om te denken in risico, deadlines en budgetten. Daar is op zich niks mis mee, maar dat leidt er wel vaak toe dat zij van hun projectmanagers eisen dat ze ‘in control' zijn.
Als ik Prince2 in één woord zou moeten samenvatten zou dat het woord projectbeheersing zijn. Alles staat in het teken om projecten gecontroleerd te laten verlopen. De Agile werkwijze met zijn teamverantwoordelijkheid, empowermentlaag in de organisatie en een grote rol voor gebruikers is slecht voor de zenuwen van controlefreaks.
Vanuit het adagium ‘vertrouwen is goed, controle is beter' kan de vrijheid van werken, die tot op zekere hoogte aan het team gegeven wordt, bij een dergelijke houding de roep om controle juist aanwakkeren. Met name bij overheden en bureaucratische organisaties waar risicobeheersing het primaire paradigma lijkt te zijn, leidt dit nogal eens tot een controlekramp. Projectmanagers die geneigd zijn hierin mee te gaan zullen er snel achter komen dat dit in een Agile-project contraproductief werkt.
Architectuur
Een derde valkuil van Agile projecten waar een projectmanager een prominente rol in moet spelen, gaat over het fenomeen applicatiearchitectuur. Iedereen die wel eens onderhoud heeft moeten plegen aan een grote, enigszins gedateerde applicatie weet dat het werken met een bord spaghetti een drama wordt. Zelfs met uitgebreide documentatie is het zo goed als onvoorspelbaar wat er allemaal gaat bewegen als je aan een draadje trekt. Grote applicaties kosten veel geld en die moeten dus een tijdje mee kunnen. De ict-branche kent een hoge doorstroomsnelheid van medewerkers en de kans dat de lead-developers van destijds nog steeds beschikbaar zijn voor het onderhoud is dan klein.
Grote applicaties met een veelheid aan functies, datastromen en interfaces met de buitenwereld vereisen een logische en kristalheldere architectuur. Het uitwerken van een goede applicatiearchitectuur is specialistisch werk dat je niet aan de eerste de beste programmeur moet overlaten. Het ontwikkelen van een applicatie onder architectuur kost veel tijd, energie en discipline. Dat kan echter wel botsen met een aantal Agile principes.
Iedereen die regelmatig over de A2 tussen Utrecht en Amsterdam rijdt, ondervindt het aan den lijve. Al jaren lang torenen de zandhopen boven ons uit en zijn de bouwputten, wegomleggingen en wegversmallingen orde van de dag. Dat alles omdat er (hopelijk) een gedegen architectuur gemaakt is, zodat we met zijn allen in 2012 weer fileloos kunnen zoeven. Dat mag dan ook wel want voorlopig worden de files door de bouwwerkzaamheden alleen maar erger en trekt de gebruiker aan het kortste eind.
In de weg staan
Nu ga ik niet beweren dat projecten in de weg- en waterbouw op een Agile manier moeten worden opgepakt of maatgevend zijn voor hoe we projecten in de ict moeten doen, maar feit is wel dat een snelle oplossing volgende week een toekomstvaste oplossing in de weg kan staan. Uiteindelijk zal dan die toekomstvaste oplossing (als de klant daar nog budget voor heeft en er het nut van inziet) hoogstwaarschijnlijk meer gaan kosten dan zonder die tijdelijke tussenoplossingen.
De rol die de projectmanager hier moet spelen is anticiperen. Als een opdrachtgever te snel bruikbare tussenresultaten wil, zal de kans op noodzakelijke ingrijpende refactoring in latere iteraties aanzienlijk toenemen. De projectmanager zal dit risico nadrukkelijk op de agenda moeten zetten, de consequenties duidelijk moeten maken en hiervoor voldoende ruimte moeten claimen om dit op te vangen.
Tot slot
Zonder pretentie compleet te zijn en zonder de voordelen die Agile development absoluut heeft te marginaliseren, zijn dit wel zaken waar een minder ervaren projectmanager een gemakkelijke valkuil heeft. Niet iedere projectmanager is hiervoor geschikt en niet iedere projectmanager krijgt het vertrouwen van zijn opdrachtgever om het op deze manier aan te pakken, maar als de projectmanager de noodzakelijke senioriteit van zijn teamleden niet onderschat, de controlekramp van zijn opdrachtgever weet te pareren en het bouwen onder architectuur op de juiste manier kan borgen geeft het hoop.
Agile development is niet alleen een teamaangelegenheid. Een projectmanager en zijn opdrachtgever die het spel kunnen meespelen en kunnen uitleggen zijn kritische succesfactoren om te doen wat we beloofd hebben: leveren wat de klant nodig heeft in plaats van wat hij/zij wil hebben.
Anthony Louws,
Projectadviseur bij Microbais Automatisering
Goed stuk, maar wel erg gedacht vanuit de rol van een projectleider/projectmanager.
Maar misschien dat dat juist de kracht is omdat de functie van de auteur (projectadviseur) goed in het voorstellingsvermogen past van het management (dat moet men mee zien te krijgen!)
Waar hij de plank misslaat is op het eind wanneer hij over ‘refactoring’ spreekt i.c.m. applicatiearchitectuur.
Het een heeft niets met het ander te maken. De uitdrukking in eXtreme Programming heet niet voor niets ‘refactor mercilessly’. Dit is een bezigheid die je altijd moet doen, het hele project door, vanaf het begin tot het eind en zelfs daarna. Bouw eerst de meest simpele oplossing die werkt en refactor daarna.
Natuurlijk is een goede applicatiestructuur belangrijk maar die bedenk je al voor dat je begint met bouwen.