Doen we Agile projecten of wordt het FrAgile?

We zijn er maar druk mee, al die projecten. Hebben we de afgelopen jaren veel PRINCE2 projecten in PINO (PRINCE2 In Name Only) projecten zien veranderen, zien we nu dat Agile projecten in veel organisaties lijken op projecten die de technieken gebruiken, maar in de praktijk niet echt Agile worden uitgevoerd. De ziel ontbreekt, waardoor er een kunstmatige vorm van Agile ontstaat.

Wat is het gevaar hiervan en hoe zorg je ervoor dat je Agile project geen FrAgile project wordt? Rolf Teekens legt de hoe en wat uit van dit dilemma.

We zijn er maar druk mee, al die projecten. Hebben we de afgelopen jaren veel PRINCE2 projecten in PINO (PRINCE2 In Name Only) projecten zien veranderen, zien we nu dat Agile projecten in veel organisaties lijken op projecten die de technieken gebruiken, maar in de praktijk niet echt Agile worden uitgevoerd. De ziel ontbreekt, waardoor er een kunstmatige vorm van Agile ontstaat. Het gevaar is dat daarmee de kracht van Agile wordt doorbroken omdat we lijken te geloven dat Agile projecten alles oplossen.

Sneller, goedkoper en beter

Veel mensen, die ik hoor over Agile, hebben het idee dat de methode er voor zorgt dat we sneller, goedkoper en beter opleveren. Maar is dat ook zo? In Agile fixeren we de tijd en het geld, evenals het feit dat we geen compromissen toelaten op kwaliteit. Klinkt goed! Maar wacht, als we met de tijd en het geld niet uitkomen, gaan we onderdelen van het project niet leveren. Het gebruik van de MoSCoW techniek stelt in Agile dat we de eisen en wensen aan het project prioriteren en van te voren overeenkomen dat we het Minimale opleveren (Must have items), Waarschijnlijk aangevuld met de ‘Should have’ en ‘Could have’ items. Dus wat we wél doen is eerder iets opleveren waar we alvast wat aan hebben, zodat we dit kunnen uitbouwen en/of verbeteren. Dus wat hebben we vooral? Snellere klantwaarde!

Het verschil tussen franje en rafels

Hoe staat het loslaten van functies en scope dan in relatie met de opmerking dat we geen compromis accepteren op kwaliteit? Doordat we wat weglaten krijgen we ook dat eisen en wensen minder worden ingevuld. In Agile is het zo dat we eisen en wensen vastleggen en dan gaan prioriteren. Deze ‘User Stories’ of ‘Requirements’ geven aan wat de business nodig heeft. Door de prioriteit te geven is het dus zo dat een functie niet wordt gemaakt, maar dat wat wel wordt gemaakt zeker af zal zijn. Het ‘geen compromissen’ gaat dan vooral over het niveau van de kwaliteit waaraan de oplossing gaat voldoen, in plaats van de individuele criteria per functie. Maar alles opleveren? Dat is niet wat Agile belooft. De kunst is het meenemen van de stakeholders in het bijschaven van deze verwachting. We gaan dus niet opleveren wat men verwacht, maar we gaan de verwachting bijschaven naar wat we opleveren.

Wat maakt Agile bijzonder?

Toch is Agile erg interessant. We krijgen niet alles, maar dat hoeft toch ook niet? Welke huidige systemen worden volledig benut? Toch zijn ze ingericht en uitgerold. Soms met functies die we nooit hebben gebruikt. Dus door het Agile te benaderen kun je de essentie uitlichten en de onzin loslaten. Door de iteratieve benadering kun je veel sneller en specifieker de feedback van een functie beoordelen en inbouwen. Daarmee stuur je meer en meer op wat de organisatie écht nodig heeft. De teams hebben we dan gevormd met de mensen van de afdeling er in, aan tafel bij de ontwikkelaars. Maar dat heeft ook een keerzijde. De organisatie moet in staat zijn om los te laten dat we vooraf alles definiëren en altijd alles opleveren, maar het vertrouwen hebben dat de teams de optimale oplossing kunnen definiëren en maken in het project. Dit vertrouwen en loslaten is het lastige.

In vertrouwen leiden

De faciliterende vorm van leiderschap helpt om de verantwoordelijkheid in de teams te stimuleren en ze optimaal te laten presteren. Door ze te inspireren en te motiveren. Een veilige omgeving te geven waarin fouten maken kan, omdat we hier snel van leren en groeien in het werk en de oplossing. Het punt is dat we vaak geen fouten tolereren. Het moet in één keer goed. Maar Agile leert ons juist dat we zelden de eerste keer ‘spot on’ iets kunnen doen. Daarom hebben we de leercyclus in het ontwikkelproces en kunnen we in beschermde omgeving leren, proberen en ontdekken. Daarna kunnen we de waarde evalueren en de goede dingen uitbouwen en van de fouten leren. Dit vereist leiderschap die zich kan bedwingen om de inhoud in te gaan, of te bepalen hoe het team werkt. Loslaten, leren, groeien, bijstellen, meters maken en met trots waarde creëren voor de organisatie. Lukt dat altijd? Nee, helaas niet. Nog steeds geen wonderen. Dan moet je een tovenaar inhuren met een glazen bol.

Agile tips

1. Gebruik Agile nooit omdat men vindt dat het moet, maar omdat het de beste aanpak is om dit specifieke project aan te pakken!
2. Stel je zeker dat de organisatie bereid is om in vertrouwen los te laten, zodat je deze aanpak optimaal kunt gebruiken.
3. ‘Al draagt een aap een gouden ring, het is en blijft een lelijk ding.’ Zorg dus dat je Agile goed gebruikt in plaats van een gedrocht van een project op te leuken met Agile technieken.
4. Neem de organisatie stap voor stap mee in de voltooiing van resultaten, om verwachtingen bij te schaven en vertrouwen te laten groeien.
5. Maak de omgeving van het project veilig genoeg om met het team te leren, te delen, samen te werken, fouten te maken en te groeien. Veel waardevoller dan geloven in de tovenaar. 😉