Agile project lijdt onder gebrek aan visie | KPMG | NL

Agile project lijdt onder gebrek aan visie

Agile project lijdt onder gebrek aan visie

“Laten we maar gewoon beginnen. We bekijken onderweg wel wat we precies gaan doen?” Is dat wat wordt bedoeld met het Agile gedachtengoed? Met enige verbazing constateer ik dat veel bedrijven agile projecten zo benaderen. Zelf kijk ik hier een stuk genuanceerder tegenaan en in deze blog leg ik uit hoe de start van een agile project of programma beter kan worden vormgegeven door gebruik te maken van ‘design thinking’ principes.

1000

Gerelateerde content

Agile

De afgelopen weken heb ik meerdere keren dezelfde constatering gedaan bij verschillende bedrijven die bezig zijn met een Agile project of programma. Deze projecten hebben een sterke IT component, waarbij de software wordt ontwikkeld op basis van het Agile gedachtengoed. In deze specifieke gevallen met een aanpak gebaseerd op het SCRUM framework. In welke mate dit vervolgens ook echt ‘agile’ gebeurt laat ik voor nu even buiten beschouwing. Ondanks het idee dat in een volledige Agile omgeving geen projecten meer bestaan, worden in de beschreven situaties projecten/programma’s om de SCRUM teams heen wel gestart en dan ook op basis van een Agile werkwijze. Deze keuze wordt gemaakt met de gedachte dat de activiteiten binnen een project/programma dan beter aansluiten bij de IT afhankelijkheden binnen het project of omdat de IT leidend is.

Volledige vrijheid?

Waar ik in deze blog op in wil gaan, is de constatering dat omdat een project/programma ‘agile’ wordt aangepakt er op de één of andere manier een idee ontstaat dat er een volledige vrijheid geldt. Projecten worden niet meer afgetrapt met een helder doel en plan voor ogen, want ‘we beslissen toch onderweg wat we precies gaan doen?’. En wijzigingen aan doel/visie/eindproduct hoeven ook niet meer langs een ‘change authority’ want de product owner kan gewoon tussentijds beslissingen nemen en bijsturen waar nodig? Dat er dan geen kader is om deze keuzes op te baseren wordt niet vooraf ingezien, evenals de zwaarte van de rol van product owner. De nadruk ligt vooral op de keuze om het agile aan te pakken en te ontdekken hoe dat dan moet, dan op wat we eigenlijk precies gaan doen en vooral ook waarom.

‘Responding to change’ and changing the plan

Wat dit tot gevolg heeft is dat men een agile project vaak gewoon maar begint. Zonder heldere scope, zonder duidelijk beeld van waar naar toe te gaan, zonder definitie van het ‘minimum viable product’ maar puur op basis van ‘een idee’. Oftewel: we weten ongeveer waarom we een project begonnen zijn, maar laten we vooral de eerste sprint aftrappen zodat we kunnen gaan produceren.

Projecten/programma’s verzanden op deze manier in individuen die met de beste bedoelingen bezig zijn als dolende in de woestijn. Hard bezig om te bedenken, uit te werken en te ontwikkelen, maar zonder een kader, een visie en een strategie. Natuurlijk overdrijf ik hier, zijn er vele tussenvormen en leiden lang niet alle projecten/programma’s met een agile aanpak tot een dergelijke situatie. Echter ik merk in de praktijk dat het dit een groot risico is bij het toepassen van deze, voor afdelingen buiten IT, nog redelijk nieuwe manier van werken. Het feit dat je kiest voor een aanpak van project of programma waarin ‘responding to change’ hogere waardering heeft dan ‘following a plan’ betekent niet dat je helemaal geen plan meer nodig hebt. Een agile project/programma heeft een stevige sprint zero nodig waarin doel, visie en scope worden vastgesteld. Ik ga hier zeker niet pleiten voor een vooraf volledig en gedetailleerd scope inclusief een detailplanning zoals beschreven in PrinceII. Echter is het plan wel nodig, met name voor de product owner, en de sprint 0 kan dus zo groot worden als dat nodig wordt geacht. Je project/programma is vervolgens ‘agile’ in de manier waarop het omgaat met het verder uitwerken van details en het maken van aanpassingen ten opzichte van het originele plan. ‘Changing the plan’ wordt dus belangrijker dan ‘following a plan’.
 

Geef je scope vorm met een design aanpak

Maar hoe weet je welke vragen je van tevoren al beantwoord moet hebben en welke beter op een later moment verder uitgewerkt kunnen worden? Hoe weet je tot op welk detail je een planning moet maken en wanneer ga je te ver en verzand je in een waterval? Een goede aanpak om hier helderheid in te krijgen is naar een ‘design approach’. In de ontwerpwereld worden vraagstukken eerst breed aangepakt, en vervolgens worden steeds meer details van een product of dienst verder ingevuld tijdens de verdere ontwikkeling. Hierbij doorloop je meerdere convergerende en divergerende fases, en maak je continue keuzes die impact hebben op de uiteindelijke invulling. Op basis van een initiële probleemstelling of een idee, onderzoek je de context (convergerend) en ontwikkel je een visie die als leidraad dient in de oplossingsrichtingen (divergerend). Op basis hiervan genereer je ideeën in de vorm van concepten (convergerend), en werk je uiteindelijk één of meerdere concepten uit tot een finale oplossing (divergerend). De oorspronkelijke visie is leidend in de keuzes die je in de divergerende fases maakt en biedt je houvast voor doel en scope.

Even een voorbeeld: als je een product gaat ontwikkelen om blinde mensen de weg te laten vinden weet je vooraf al dat zintuigen anders dan zicht een belangrijke rol gaan spelen. Je weet echter aan het begin nog niet welk materiaal je nodig zal hebben voor het product. Je startpunt is een idee dat je blinden de weg wil laten vinden, en je onderzoekt welke zintuigen, of een combinatie van zintuigen, leidend zal zijn voor het ontwerp (‘discover’ in de afbeelding hieronder). Vervolgens maak je een overwogen keuze voor de toepassing van een bepaalt zintuig, dit vormt je visie. Daarnaast ontwikkel je mogelijke oplossingen op basis van bijvoorbeeld tast (‘develop’ fase). Na de keuze voor het meest passende concept (op basis van de visie) werk je de details van het uiteindelijke product (bijvoorbeeld stoeptegels met ribbels) pas uit en weet je dat je tegels nodig hebt. Met deze denkwijze kun je een agile project/programma ook vormgeven; je start met een algemeen idee/doel, je ontwikkelt vervolgens een scope aan de hand van een visie, waarna je per deel van het programma punten verder uitwerkt en vormgeeft. Steeds in een cyclus van convergeren en divergeren waarbij de visie de leidraad vormt voor de keuzes die maakt.
 

Visie bepaalt scope

Startpunt in deze aanpak is dus het ontwikkelen van een visie op basis van het probleem of idee: wat beoog je met het project/programma te bereiken? Ofwel het waarom van het project/programma. Het vormt de basis voor het resultaat van je project/programma, en biedt een kader voor de keuzes die je onderweg maakt. Een belangrijk aspect bij het leveren van waarde (IT of niet) en een visie bepalen is de ‘wie’. Wie gaat er gebruik van maken, wie heeft er baat bij of wiens leven wordt er door beïnvloed? Is dit een klant, of zijn het juist vooral interne medewerkers? Door eerst een beeld te vormen van wie en waarom, is de stap naar wat eenvoudiger te maken. Wat zijn dan de behoeftes of problemen die deze mensen hebben, wat willen zij graag bereiken? En wat zullen we dus als project/programma moeten doen en opleveren (features) om dit te bereiken? Je legt hiermee al bijna de basis voor high-level epics/features/user stories die op project/programma niveau beschrijven wat je output wordt. Een tool om visie en scope te definiëren bij de start van een project/programma is het ‘Product Vision Canvas’ van Roman Pichler. Met dit template wordt de relatie tussen gebruikers, behoeften, features en de waarde die het levert snel duidelijk en het biedt houvast om latere keuzes op te baseren tijdens de invulling onderweg, zowel strategisch als op detailniveau. Uiteraard is het invullen van een dergelijk canvas niet iets wat je alleen in sprint zero doet, maar ook eens de zoveel sprints weer bekijkt en aanpast waar nodig. Ook hiervoor geldt dat ‘responding to change’ belangrijker is dan ‘following a plan’, al herijk je een visie minder vaak dan bijvoorbeeld de volgorde van items op een product backlog.

Net als bij productontwikkeling binnen de ontwerpwereld is het formuleren van een heldere visie één van de pijlers van succes binnen agile projecten en programma’s. Met deze visie heeft een product owner een kader om beslissingen tijdens een project/programma op te baseren. Vrijheid in invulling betekent dus niet algehele vrijheid vanaf het begin, maar een gedegen strategische aanpak om efficiënt tot resultaat te komen.

Auteur

Karin Smorenburg
Karin is consultant bij KPMG IT Advisory, heeft een achtergrond in Strategic Product Design en ervaring met Agile projecten en programma’s.
 

Neem contact met ons op

 

Offerteaanvraag (RFP)

 

Bevestig