Wordt agile geïmplementeerd vanuit kans of vanuit mitigatie?

De VUCA wereld is grof gezegd vanuit twee percepties te benaderen: als kans / opportunity of als bedreiging die gemitigeerd moet worden. Voorbeelden van organisaties die VUCA zien als kans zijn start-ups met hun disruptieve initiatieven. Denk aan de “platformen” als Thuisbezorgd, Booking en aan Spotify, Amazon, etc. Die organisaties gebruiken agile om disruptief in te spelen op de mogelijkheden die de VUCA wereld biedt. Maar er zijn ook organisaties die overgaan op de agile-aanpak uit angst om door concurrenten te worden voorbijgestreefd, ook op het IT vlak. Of ze zetten agile in vanuit andere defensieve overwegingen. Voorbeelden zijn hier te over en te zien bij verzekeraars, banken, overheidsorganisatie die zich gedwongen voelen mee te gaan met de veranderingen in hun omgeving die elkaar steeds sneller opvolgen.

Hoe kan de projectmanager met VUCA omgaan?

Projectmanagers (PM) zijn vooral bezig met:

• Wat moet ik leveren en aan welke kwaliteitscriteria moet dat voldoen?
• Wanneer moet ik dat leveren?
• Hoe kan ik dat voor elkaar krijgen gegeven de organisatie, het proces, de mensen en de middelen?

De Waarom-vraag komt vaak pas om de hoek kijken als er problemen ontstaan. Dan moet worden geanalyseerd wat de oorzaak daarvan is en waar interventies nodig zijn. De praktijk laat zien dat in het geval er agile wordt gewerkt, de projectmanager zich veel eerder met de Waarom-vraag moet bezighouden. Dan maakt het een groot verschil uit vanuit welke van de twee bovengenoemde percepties agile is geïmplementeerd. Om de Waarom-vraag goed te kunnen beantwoorden moet de projectmanager een goed inzicht hebben in wat de visie is van de organisatie en wat de cultuur is waarbinnen deze visie vorm moet krijgen.

Nu is elke situatie in de praktijk uniek en kent zijn eigen nuances. Behalve de twee agile-percepties zijn er binnen organisaties die agile werken twee rollen te onderscheiden: die van de Entrepreneur en die van de Mitigateur.

Entrepeneur-agility

De entrepeneur (een persoon maar het kan ook een organisatie zijn met een entrepeneural management) is offensief, heeft een visie, soms nog niet heel concreet, maar heeft wel de richting scherp op het netvlies staan. Kenmerken van de Entrepreneur zijn gedrevenheid, focus, besluitvaardigheid, daadkracht, doelgerichtheid, actie. Dat werkt door in de agile aanpak en in de teams. Hier is wendbaarheid een echt een issue, de backlog reageert echt op het succes van het product in de markt. De focus ligt op het ontwikkelen van nieuwe functionaliteit en pas in tweede instantie op architectuur en non-functionele requirements. Agile kan hier agile zijn zoals het bedoeld is.

Mitigatie-agility

De Mitigateur is defensief, scant wat er gebeurd in zijn omgeving en reageert. De Mitigateur is veel meer gebonden aan een bestaande situatie van waaruit hij acteert en die hij probeert in stand te houden en eventueel, als dat kan, uit te breiden.
Kenmerken van de Mitigateur zijn: continuerend, behoudend, risicomijdend, controle, reactie. Met als gevolg dat ook de agile implementatie anders verloopt. Vaak is in dit soort situaties een hybride implementatie te zien: agile met een Prince 2 governance/rapportage structuur. De wendbaarheid is uit nood geboren en reactief gedreven, de backlog is veel minder en marginaal aan verandering onderhevig. De focus ligt hier vaak op de bestaande architectuur en non-functionele requirements waarbinnen de nieuwe functionaliteit moet worden ontwikkeld. Agile wordt hier vaak – gechargeerd – “voor de vorm” gedaan en is niet noodzakelijk.

Consequenties voor de projectmanager

Agile zegt dat de projectmanager niet meer nodig is, maar in de praktijk blijkt dat niet waar te zijn, zeker niet als er geschaald moet worden (meerdere scrumteams), meer projecten tegelijk draaien (portfolio), enzovoort. Dan is coördinatie nodig.
De projectmanager vindt zichzelf dan ook vaak terug in de agile omgeving, al is het onder een andere titel zoals bijvoorbeeld value stream engineer, release train engineer, scrummaster, maar ook gewoon als projectmanager. Projectmanagers hebben met de hierboven genoemde verschillen te maken en het helpt daarvan bewust te zijn.

Ik noem hier een aantal – niet uitputtend – praktijkvoorbeelden waaraan te herkennen is of een projectmanager te maken heeft met Entrepreneur-agility of met een Mitigatie-agility, als persoon of als organisatie.

1. Agile teams hebben het zwaar in Mitigatie-agility. Zij proberen te werken volgens de agile principes, maar krijgen te maken met opgelegde deadlines, controles, administraties, rapportages en bestaande kaders uit de organisatie van vóór de agile implementatie die in stand zijn gebleven en die in strijd zijn met de pure agile principes. Dat schuurt en leidt soms zelfs tot demotivatie en frustratie van teamleden. In Entrepeneur- agility wordt het team toegestaan zelf-organiserend te werken. Het commitment en de motivatie van deze teams is hoog.
2. De product owner is niet degene die de backlog beheert in de Mitigatie-agility. Hij wordt vaak overruled in de prioriteitstelling van de backlog door senior management. Het senior management wordt gedreven door optredende crisissen, veranderende inzichten of soms botweg door persoonlijke belang. Wat ook opvalt is dat de product owner in deze situaties nogal eens is ingehuurd, wat raar is gezien het belang van de rol. In Entrepeneur-agility heeft de product owner het volledige mandaat om de backlog te beheren. Hij is in dienst van de organisatie en zit dicht op de Entrepeneur.
3. De scrummaster is niet slechts faciliterend in Mitigatie-agility. hij is degene die eisen stelt aan de deadline, de kwaliteit en daarop het team strak controleert en erover rapporteert. Dit is dus meer de klassieke projectleider rol. In Entrepeneur-agility is de scrummaster er slechts om het team optimaal te laten functioneren.
4. Agile coaches zijn druk in Mitigatie-agility met het aangeven hoe agile eigenlijk bedoeld is en wat er ten opzichte van de theorie fout gaat. Het aantal agile coaches actief is bijna een graadmeter voor de mate van Mitigatie-agility. Agile coaches verdwijnen uit Entrepeneur-agility na de implementatie van agile. De overige rollen weten dan wat er van ze wordt verwacht.

Ik ben projectmanager in Entrepeneur – agility, wat nu?

Zeer waarschijnlijk heb je een andere titel: value stream engineer, release train engineer, scrummaster. Welke titel dan ook, stel je vooral faciliterend en coördinerend op. Je rol is alle belemmeringen wegnemen voor de teams. Natuurlijk blijf je bewaken dat alles op rolletjes loopt en adviseer je vanuit je kennis en kunde. Maar sturen is – als het goed is – niet nodig.

Ik ben projectmanager in Mitigatie – agility, hoe zit dat voor mij?

Je rol is eigenlijk de bekende projectmanagementrol en je voornaamste taak is sturen, coördineren, motiveren en rapporteren. Sturen gebeurt zoals in de klassieke projectmanagement op de aspecten tijd, geld, kwaliteit, risico’s. Je coördineert de afstemmingen tussen de teams, van de backlog met de product owners en het management van de organisatie. Je bent vooral veel tijd kwijt aan het motiveren van de teams die in de veronderstelling zijn dat er agile wordt gewerkt. Je wordt daarin gesteund door de agile coaches en die teleurgesteld zijn omdat de realiteit anders is. En natuurlijk rapporteer je aan de stakeholders en stuurgroepen.

Is dit agile? Niet helemaal en daarom horen we termen als “hybride”. Als je als projectmanager probeert te acteren naar de letter van agile heb je een onmogelijke job. Deze situatie vraagt aanpassingsvermogen, situationeel projectmanagement.

Conclusie

Als projectmanager is het wenselijk te weten in welk soort van agile omgeving er gewerkt moet worden. Afhankelijk daarvan worden verschillende eisen aan de projectmanager gesteld dan wel andere activiteiten van hem gevraagd.
Vóórdat een projectmanager met een project start dient hij/zij zichzelf af te vragen: Vanuit welke perceptie is agile hier geïmplementeerd en waarom? Dan kan daar in de fase van het maken van plannen al rekening mee worden gehouden. En niet tijdens het project, wanneer het niet zo lekker loopt als was gehoopt en daarom alsnog de Waarom-vraag moet worden gesteld om een analyse te kunnen maken. Hieruit zal dan waarschijnlijk blijken dat een groot deel van de problemen voortkomen uit het gegeven dat niet vroegtijdig is onderkend hoe de organisatie in elkaar steekt. Inzicht kan helpen om tot een beter projectresultaat te komen.