Agile Project Management

Agile Project Management, wanneer maak je er gebruik van? Stel je een technologie start-up voor waarvan de oprichters proberen om ​​duurzaam marktleider in een zakelijke niche te worden. De markt verandert snel, en zij moeten snel een product ontwikkelen waarvoor gebruikers bereid zijn te betalen. Dit is niet eenvoudig!

Door middel van marktonderzoek kunnen ze maar weinig over de markt ontdekken, dus ze moeten gaan experimenteren. Dit betekent dat ze allerlei verschillende oplossingen uitproberen. Stap-voor-stap leren ze het product te verbeteren tot ze een de oplossing hebben ontwikkeld die echt werkt.

Je ziet waarschijnlijk dat veel IT projecten – met name die in een complexe, snel veranderende omgeving – lijken op dit scenario. Je kan op de traditionele manier ontwikkelen maar dan moet je telkens je plannen herzien.

Als je een traditionele waterval benadering gebruikt, zullen tussentijdse wijzigingen leiden tot gemiste deadlines, oplopende kosten en een hogere werkdruk. En in het ergste geval vinden er in de loop van het project zoveel veranderingen plaats dat je eindproduct, wanneer het uiteindelijk is opgeleverd, niet meer relevant is.

Agile Project Management is een aanpak die helpt om deze uitdagingen aan te pakken. In dit artikel beschrijven we wat Agile is en we zullen uitleggen waarom het zo nuttig is.

Wat is Agile Project Management?

Agile Project Management is gebaseerd op een flexibele aanpak. Teamleden werken in kleine afgebakende stukken aan kleine functionerende releases van een applicatie. Ze testen vervolgens elke release ten opzichte van  de acceptatiecriteria van de klant, in plaats van te streven naar een eindresultaat dat pas aan het einde van het project wordt vrijgegeven.

Na al die kleine releases kan ket eindproduct van een agile project heel anders zijn dan dat wat in het begin werd bedacht. Door het test- en controleproces zijn de teamleden er echter zeker van dat het product datgene is wat de klant wil.

Dit zorgt ervoor dat Agile Project Management bijzonder geschikt is voor nieuwe of snel ontwikkelende organisaties, voor mensen in een snel veranderende omgeving of voor zeer complexe situaties, waarbij managers hun weg zoeken naar het optimale bedrijfsproces. Agile is ook toepasbaar voor urgente projecten die niet kunnen wachten tot een volledig, traditioneel project wordt opgestart.

De oorsprong van Agile

Verschillende elementen van Agile Project Management bestaan ​​al decennia. Twee belangrijke gebeurtenissen liggen aan de basis voor de aanpak.

In 1986 publiceerde Hirotaka Takeuchi en Ikujiro Nonaka een artikel genaamd “The New New Product Development Game” in het Harvard Business Review. Daarin schetsten de auteurs een nieuwe manier om producten te ontwikkelen die lijkt op een rugbywedstrijd.

Zij stelden zich een ​​projectmanagement aanpak voor, waarbij teamleden, net als op het veld, hun doel zouden bereiken door de situatie voortdurend opnieuw te evalueren en daarop te reageren. Projecten zouden derhalve evolueren, maar ook leiden tot producten die beter aan de behoefte van de klant voldoen.

De tweede gebeurtenis vond plaats in 2001, toen een groep software- en projectdeskundigen elkaar ontmoetten om te bespreken wat hun meest succesvolle projecten gemeen hadden. Zij creëerden het Agile Project Manifesto, waarin de waarden en principes waar Agile Project Management op steunt, uiteengezet werden.

Agile Project Management is gebaseerd op de productontwikkelingsaanpak van Takeuchi en Nonaka, en bevat de waarden en principes die zijn beschreven in het Agile Project Manifesto.

Agile Versus Traditional Project Management

Laten we Agile Project Management vergelijken met traditioneel projectmanagement en de verschillen in benadering uitlichten.

Agile Project Management	Traditioneel Project Management
Teams zijn zelfsturend en zijn vrij om de opleveringen te kiezen, zolang ze de afgesproken regels maar volgen.	Teams worden doorgaans strikt geleid door een projectmanager. Zij werken aan gedetailleerde schema’s die in het begin zijn afgesproken.
De requirements worden tijdens het proces vastgesteld, omdat requirements zich dan pas openbaren. Dit kan betekenen dat het eindresultaat anders is dan men in het begin van het project had voorgesteld.	De requirements worden voordat het project begint vastgesteld. Dit kan soms leiden tot ‘scope creep‘, omdat gebruikers vooraf vaak meer vragen dan ze nodig hebben, ‘gewoon voor het geval dat’.
Gebruikers testen en feedback vinden voortdurend plaats. Zo is het gemakkelijk om te leren van fouten en de feedback op te nemen in de ontwikkeling. Het constante testen is echter arbeidsintensief, en is moeilijk te beheersen als de gebruikers niet betrokken zijn.	De gebruikers acceptatietesten en feedback vinden helemaal aan het einde van het project plaats, als alles geprogrammeerd en geïmplementeerd is. Dit kan betekenen dat er na de release grote problemen ontstaan. Die kunnen soms dure oplossingen vergen en zelfs de krant halen.
Teams beoordelen zelf voortdurend de voortgang en de richting van hun project. Dit betekent dat ze op elk gewenst moment van richting kunnen veranderen om ervoor te zorgen dat hun product aan veranderende behoeften voldoet. Hierdoor is het moeilijk zijn om bij aanvang een businesscase te schrijven, omdat het eindresultaat niet volledig bekend is.	Teams werken aan een eindproduct dat moet worden opgeleverd – vaak maanden of jaren – nadat het project was begonnen. Soms is het eindproduct of project niet meer relevant, omdat de bedrijfs- of gebruikersbehoeften zijn veranderd. Het komt daarom ook regelmatig voor dat voortijdig de stekker uit grote projecten wordt getrokken.

Uiteindelijk werkt traditioneel projectmanagement vaak het best in een stabiele omgeving, waar een bepaald oplevering nodig is voor een vast budget. Agile is vaak het beste als het eindproduct onzeker is, of waar de omgeving snel verandert.

Discussieer mee op LinkedIn.