Are you looking for the English version of our website?
Menu
Menu

Wat Is Agile Projectmanagement?

Sinds projectmanagement een wijdverbreide praktijk werd, werden er steeds meer verschillende projectmanagement methoden ontwikkeld. Één van deze specifieke methoden waar je vaak over hoort, is Agile projectmanagement. Maar wat houdt het precies in en hoe wordt het toegepast? We leggen het uit in dit artikel, zodat je voor jezelf kan beslissen of het een geschikte methode is voor jouw projecten.

Wat Is Agile Projectmanagement?

Projectmanagement wordt toegepast om succesvolle resultaten te kunnen boeken. Echter bestaat er geen one-size-fits-all benadering wat projectmanagement betreft, omdat elk project uniek is. Sinds projectmanagement zoveel gebruikt wordt, zijn er in verloop van tijd veel verschillende methoden ontwikkeld om beter aan te sluiten op bepaalde projecten en branches. Agile projectmanagement begon naam en faam te maken aan het begin van het millennium, en natuurlijk wil jij weten waar alle ophef over gaat. In dit artikel, vind je alles wat je wilde weten Agile projectmanagement, plus een aantal van de meest populaire methoden die onder de overkoepelende term vallen.

Inhoudsopgave:

1. Traditioneel projectmanagement vs. Agile projectmanagement
2. De geschiedenis van Agile projectmanagement
3. Voor welke projecten wordt Agile projectmanagement gebruikt?
4. Wat houdt Agile projectmanagement precies in?
5. Welke Agile projectmanagement methoden zijn er?
6. Wat zijn de voordelen van Agile projectmanagement?
7. Conclusie

Traditioneel projectmanagement vs. Agile projectmanagement

Voordat we wat dieper ingaan op wat Agile projectmanagement is, leggen wij je eerst uit hoe het nou verschilt van traditionele projectmanagement.

De structuur van traditioneel projectmanagement 

Doorgaans bestaat een doorsnee project uit een bepaalde reeks activiteiten, verdeeld over verschillende fases. Volgens de meeste projectmanagement opleidingsinstituten, worden deze fases als volgt genoemd:

  • Initiatiefase

  • Definitiefase

  • Ontwerpfase

  • Voorbereidingsfase

  • Realisatiefase

  • Nazorgfase

Dit is een standaard structuur natuurlijk, aangezien elk project uniek is. De activiteiten en fases kunnen er totaal anders uitzien afhankelijk per branche, en de omvang van de werkzaamheden. In het algemeen, zie je dat traditionele projectmanagement methoden deze structuur volgen.

Traditioneel projectmanagement is lineair

Andere kenmerken van traditioneel projectmanagement zijn de stap-voor-stap benadering, en de chronologische volgorde van uitvoering. Meestal wordt deze traditionele benadering als de Waterval methode aangeduid. Elke fase wordt achtereenvolgens voltooid, van initiatie tot aan de nazorgfase. Wanneer een fase als voltooid beschouwd wordt, kunnen er achteraf ook geen aanpassingen meer gemaakt worden. Deze aanpak is dus erg lineair.

Voor heel veel branches, werkt traditioneel projectmanagement heel erg goed. Vooral in de productie- en bouwindustrie, waar een concreet plan gevolgd wordt zonder dat gaandeweg grote aanpassingen vereist zijn.

Agile projectmanagement is non-lineair

Daarentegen, hebben een hoop andere branches ondervonden dat een lineaire benadering niet strookt met sommige projecten die een stuk complexer zijn. Bijvoorbeeld bij softwareontwikkeling.

Terwijl sommige softwareontwikkeling projecten een enkele, duidelijk gedefinieerde deliverable hebben die strak gemonitord wordt, vereisen sommige projecten heel wat meer flexibiliteit.

Agile projectmanagement is ontwikkeld om een veel betere structuur te bieden aan flexibele, wat meer ingewikkelde projecten. In plaats van een chronologische manier van fases doorlopen, hebben dit soort projecten meerdere evaluatie fases nodig zodat aanpassingen gemaakt kunnen worden. Agile projectmanagement volgt dus een non-lineaire, iteratieve benadering.

Hierbij werkt het team aan projecten waarvan het tijdpad verdeeld is in korte iteraties. Na iedere iteratie, vindt er een meeting plaats om de status van deliverables te evalueren en te bepalen welke veranderingen er gemaakt moeten worden.

Soms bepaalt het team op zulke momenten dat ze een totaal andere richting in moeten slaan, en veranderen zodoende herhaaldelijk het projectplan. Dit betekent dat er vooraf vaak geen concrete visie vastgesteld is, met Agile projectmanagement krijgt deze visie tijdens elke iteratie steeds meer vorm.

De geschiedenis van Agile projectmanagement

Voornamelijk ontstaan in de softwareontwikkeling industrie, kunnen de eerste vormen van Agile projectmanagement herleid worden naar de jaren vijftig.

De eerste alternatieve benaderingen

Destijds werkzaam bij IBM en Motorola, ontwikkelden Bernie Brimsdale, Herb Jacobs, John von Neumann en Gerald Weinberg samen incrementele technieken om software te ontwikkelen. Alhoewel de benaming ‘Agile’ nog niet werd gebruikt, was wel al heel duidelijk dat hun aanpak heel anders was dan traditionele lineaire benaderingen.

De ontwikkeling van deze aanpak liep door tot in de jaren negentig, na een gebeurtenis die bekend staat als de “application development crisis”. Tijdens dit decennium, nam de ontwikkeling van nieuwe software technologien gemiddeld drie jaar in beslag.

Vanwege dit tergend lange process, was er op het gebied van technologie al veel meer mogelijk tegen de tijd dat een product eindelijk gelanceerd werd. Dit maakte het eindproduct al erg achterhaald, omdat de behoeftes van klanten en consumenten inmiddels veranderd waren. Dit leidde tot veel mislukte projecten en een berg weggegooid geld.

De introductie van modern Agile projectmanagement

Vooraanstaande leiders in de industrie beseften maar al te goed dat er echt iets aan gedaan moest worden. Er werd gefocust op het cultiveren van nieuwe, flexibele benaderingen om het proces te versnellen en tevens effectiever te maken.

De moderne vorm van Agile projectmanagement zoals we het nu kennen, werd officieel geïntroduceerd in februari 2001. Zeventien software professionals kwamen bijeen om de kwestie grondig te onderzoeken, en brachten uiteindelijk de “Manifest voor Agile Softwareontwikkeling” voort. Hierin werden de principes van deze nieuwe aanpak uitgebreid in kaart gebracht.

De introductie van modern Agile projectmanagement

Voor welke projecten wordt Agile projectmanagement gebruikt?

Inmiddels zal je op basis van alle bovenstaande informatie al een goed idee hebben. Agile projectmanagement werd in het leven geroepen omdat bij traditionele methoden de flexibiliteit en snelheid ontbrak die voor bepaalde projecten nodig was. Dit soort projecten zijn redelijk complex, omdat het vaak om een volledig nieuw soort product gaat.

Om softwareontwikkeling weer als voorbeeld te gebruiken, is een project duidelijk uniek wanneer daar compleet nieuwe technologieën voor ontwikkeld moeten worden. Er is dus geen voorgaande data waar het op gebaseerd kan worden, omdat het iets is dat niemand ooit eerder heeft gedaan. Daarom is het op voorhand moeilijk te bepalen wat er nodig is om het tot stand te brengen, en hoe lang het zal duren. Het zal allemaal gaandeweg nader bepaald moeten worden.

Een andere belangrijke factor is dat deze projecten een redelijk dringende deadline hebben. Zoals eerder genoemd, wil je geen tijd en geld verspillen aan het ontwikkelen van een product dat uiteindelijk niemand wilt omdat technologieën en klantbehoeften tegen die tijd alweer veranderd zijn. Echter zijn sommige projecten zo omvangrijk dat ze tamelijk wat tijd nodig hebben, dit moet dus op een efficiënte manier gemanaged worden.

Grote projecten die in behapbare stukken verdeeld kunnen worden en regelmatig revisie benodigen, zullen heel erg veel baat hebben bij Agile projectmanagement methoden.

De principes van Agile projectmanagement

Agile projectmanagement komt van het Engelse woord “agility”, dat in het Nederlands vertaald wordt naar “wendbaarheid” en “behendigheid”. Van oorsprong is het achter afgeleid van het Latijnse woord “agere” wat voor “doen” of “handelen” staat. In essentie, staat Agile voor het vermogen om vluchtig vooruit te kunnen bewegen, onderhevig aan constante verandering.

In projectmanagement, wordt Agile uitgedrukt met vijf principes:

  • Focus op de klant

  • Transparantie

  • Aanpassingsvermogen

  • Verantwoordelijkheid

  • Constante verbetering

Focus op de klant

Zoals we weten, kunnen de behoeften en wensen van de klant drastisch veranderd zijn tegen de tijd dat een software projecten voltooid is. Exact om deze reden richten Agile benaderingen zich vooral op de klant.

Soms verkondigen klanten wat ze willen, zonder echt te weten hoe dat in realiteit zou moeten uitpakken. De iteratieve aanpak van Agile projectmanagement biedt de perfecte oplossing voor dit probleem, omdat de klant bij de evaluatie van iedere iteratie kan worden betrokken.

Deze evaluatie “feedback loops” dienen eigenlijk als project cyclus checkpoints, om stap voor stap de richting van het project te bepalen. 

Transparantie

Om een open dialoog te behouden over wat de beste manier is om dingen te doen, is complete transparantie cruciaal. Het gehele team plus alle stakeholders worden aangemoedigd hun ideeën en meningen te blijven delen.

Dit betekent ook dat alle taken en werkprocessen van teamleden openlijk besproken worden. Bij voorkeur, wordt alles ook gevisualiseerd met een tool of systeem die voor iedereen toegankelijk is.

Aanpassingsvermogen

Door snel en frequent feedback te ontvangen na iedere iteratie, kunnen teams ook sneller reageren en aanpassingen uitvoeren. Om dit aanpassingsvermogen te kunnen handhaven, wordt er geen concreet plan gemaakt waar aan één stuk door aan wordt gewerkt. Al het werk wordt in plaats daarvan in kleine stukken verdeeld, en na elk klein stukje geëvalueerd. 

Als de wensen van de klant veranderd zijn, kan het team aan de hand daarvan aanpassingen doorvoeren tijdens de volgende iteratie. 

Verantwoordelijkheid

Bij traditioneel projectmanagement worden de meeste beslissingen door de projectmanager genomen. Bij Agile projectmanagement worden alle teamleden en stakeholders meer betrokken bij het beslissingsproces. Dit verhoogt het verantwoordelijkheidsgevoel, en zorgt tevens voor effectieve leiderschap.

Constante verbetering

Dit behoort echt tot de regelrechte kern van Agile projectmanagement. Er bestaan veel uiteenlopende Agile methoden die een klein beetje van elkaar verschillen. Echter volgen ze allemaal hetzelfde iteratieve proces dat constante verbetering mogelijk maakt.

Het doel is om constant het product of de service te blijven verbeteren totdat de klant helemaal tevreden is. Daarnaast, krijgen teamleden zo ook de kans om continu hun vaardigheden en kennis te blijven ontwikkelen terwijl ze actief aan een project werken.

Normaal gesproken, kan men pas achteraf uitleggen wat ze geleerd hebben wanneer het eindresultaat gemeten wordt tegenover de verwachtingen. Nu loopt het leerproces door terwijl het project actief is.

Constante verbetering

Welke Agile methoden zijn er?

Nu je de karakteristieken en principes van Agile projectmanagement begrijpt, zullen we verschillende populaire Agile projectmanagement methoden onder de loep nemen.

Hybride

Zoals eerder genoemd, is de Watervalmethode een traditionele aanpak waarbij een duidelijk gedefinieerd plan stap-voor-stap gevolgd wordt. Bij een Hybride aanpak worden eigenschappen van traditionele en Agile projectmanagement stijlen met elkaar gecombineerd.

Een hoop bedrijven hebben gemerkt dat een combinatie van beide methoden beter werkt dan wanneer ze er slechts één van kiezen. 

Dit betekent bijvoorbeeld dat er een duidelijk plan wordt gemaakt voor het budget, offertes en schema’s, terwijl er een Agile benadering wordt gekozen voor het iteratieve werk- en evaluatieproces. De principes van traditionele- en Agile methoden kunnen op heel veel verschillende manieren gecombineerd worden, afhankelijk van het type project.

In het algemeen, wordt de hybride aanpak vooral gebruikt voor projecten waarbij tegelijkertijd aan hardware- en software ontwikkeling wordt gewerkt.

Bimodal

This combination of traditional Waterfall and Agile methods was introduced by Gartner in 2014. It involves two separate teams that work on projects while having two different goals. 

Deze specifieke combinatie van de traditionele Watervalmethode met Agile werd geïntroduceerd door Gartner in 2014. Hierbij werken twee verschillende teams aan projecten met beiden een ander doel voor ogen.

Het Agile team focust zich vooral op het onvoorspelbare aspect van het project waarvoor ze innovatieve oplossingen moeten bedenken. Daarentegen focust het Waterval team zich juist op de voorspelbare factoren, en zorgen ze dat het project stabiel blijft wanneer aanpassingen gemaakt worden.

Beide teams volgen andere methoden en een eigen manier van rapporteren, maar ze houden elkaar wel van alles op de hoogte.

De Bimodal methode is vooral geschikt voor bedrijven die aan een mix van korte- en langetermijn projecten werken waarvoor verschillende ontwikkelingsprocessen nodig zijn.

Kanban

De Kanban methode verdeelt alle project taken in drie categorieën:

  • To do

  • In progress

  • Done

De categorieën worden gevisualiseerd door drie kolommen op een zogenoemde Kanban board. Deze hangt meestal aan de muur van de werkplek maar wordt ook wel digitaal  gegenereerd. 

Taken en activiteiten worden vermeld op kaarten, die door de drie kolommen heen bewegen. Als eerste worden ze in de “to do” kolom geplaatst, en naar “In progress” doorgeschoven wanneer een teamlid de taak oppakt. Uiteindelijk belandt de kaart in de “done” kolom wanneer de taak af is.

Ten allen tijde wordt ervoor gewaakt dat er niet teveel kaarten in de middelste kolom staan. Weergegeven met een Kanban board, kunnen teamleden precies zien of ze beter kunnen wachten voordat ze meer taken oppakken. Het maximum aantal kaarten dat “In progress” mag staan wordt bepaald door de zogeheten WIP limit (work-in-progress limit).

De Kanban methode is geschikt voor uiteenlopende branches, van marketing tot IT. Vrij complexe projecten die redelijk wat flexibiliteit vereisen zullen baat hebben bij deze aanpak. Het laat vooral zien welke taken prioriteit hebben terwijl het project langzaam evolueert na elke verandering. Dit zijn echter kleine evolutionaire veranderingen en geen grote, revolutionaire veranderingen.

De Kanban methode verdeelt alle project taken in drie categorieën

Lean

De Lean projectmanagement methode werd alsmaar populairder sinds Toyota er indrukwekkende resultaten mee behaalde. Het productiesysteem maakte gebruik van deze methode om voertuigen zo snel en efficiënt mogelijk te produceren, om ze zo snel mogelijk te kunnen afleveren bij de klant.

De Lean aanpak wordt dus vooral toegepast in de productie industrie, al wordt het ook steeds meer gebruikt voor softwareontwikkeling.

Het principe van Lean projectmanagement bestaat uit het identificeren van alle soorten verspilling. Er wordt getracht de gewenste waarde te creëren, met een minimum aan materialen, arbeid en ruimte. De drie soorten verspilling worden aangeduid als de 3M’s:

  • Muda: niet-waardetoevoegende activiteiten die middelen verbruiken

  • Muri: overmatige inzet van materialen of medewerkers

  • Mura: alle vormen van ongelijkheid of overbelasting die het proces afremmen

Het constant onderzoeken en elimineren van verspilling in deze drie categorieën helpt het productieproces sneller en efficiënter te maken. Deze aanpak is bijzonder geschikt voor organisaties die hun processen willen herstructureren om kosten te besparen.

Scrum

In de jaren tachtig ontwikkeld door Hirotaka Takeuchi en Ikujiro Nonaka, is de Scrum aanpak inmiddels verreweg de meest populaire Agile methode voor software bedrijven geworden. Tegen de jaren 90 werd een heel solide framework voor Scrum gehanteerd, waar specifieke rollen en meetings.

Een Scrum team werkt aan projecten tijdens meerdere korte iteraties, zogeheten sprints. Deze sprints kunnen 1 tot 4 weken duren. Als dit langer zou duren, zou het team de voortgang niet snel genoeg kunnen evalueren, wat niet genoeg flexibiliteit biedt. Na iedere sprint, wordt de voortgang geëvalueerd om te bepalen welke aanpassingen nodig zijn.

Er worden drie belangrijke rollen vervuld:

  • Scrum Master: De Scrum Master zorgt ervoor dat iedereen volgens Scrum principes werkt, en dat obstakels worden aangepakt die dit in de weg staan.

  • Product Owner: Soms kan dit ook de klant of een andere stakeholder zijn. Meestal is het echter een medewerker die de klant/stakeholders vertegenwoordigt. Na iedere sprint vergelijkt een Product Owner de resultaten met de visie voor het eindproduct, en verzorgt waardevolle feedback.

  • Scrum Team: Het team dat verantwoordelijk is voor het afleveren van het eindproduct. Meestal is dit een team van 7-10 leden max, die op een cross-functionele manier met elkaar samenwerken. 

Specifieke Scrum elementen:

  • Product Backlog: Aangezien er na iedere sprint veranderingen nodig zijn, moeten alle items en benodigdheden hiervoor ergens worden genoteerd. De Product Backlog is de lijst waarop bijgehouden wordt wat er allemaal nodig is om het project te voltooien.

  • Sprint Backlog: Dit is een overzicht van alle taken die voltooid moeten worden tijdens een sprint. Het is een bevestigde planning waaraan gewerkt wordt tijdens de sprint.

  • Sprint Burndown Chart: Deze chart geeft de dagelijkse voortgang van resterende taken weer. Het team en de Scrum Master weten zo precies wat er nog moet gebeuren om de print goal te halen.

Scrum meetings:

  • Daily Scrum: Elke dag vindt er een meeting van 15 minuten plaats om het plan voor de dag te bespreken. Deze meeting wordt dagelijks gehouden door het productieteam op hetzelfde tijdstip en dezelfde locatie.

  • Sprint Planning: Bij deze meeting die plaatsvindt vóór de volgende sprint, zijn het team, de Scrum Master en de Product Owner betrokken. Ze bespreken wat er allemaal moet gebeuren om de sprint goal te behalen, en hoe dit gepland wordt. 

  • Sprint Review: Na elke sprint, evalueert de Product Owner de resultaten met het team. Tijdens deze meeting worden eventuele aanpassingen voorgesteld en wordt besproken hoe meer waarde aan het product kan worden toegevoegd tijdens de volgende sprint.

  • Retrospectieve Meetings: Na de Sprint Review met de Product Owner, komt het team samen tijdens een retrospectieve meeting om de resultaten van de vorige sprint te bespreken. Wat goed ging, wat beter kan, en hoe het nu verder moet. Dit moet allemaal geëvalueerd worden vóór de volgende Sprint Planning meeting plaatsvindt.

Scrum is heel geschikt voor hele complexe, lange-termijn projecten die veel flexibiliteit vereisen. Vaak kunnen de gewenste deliverables niet van tevoren vastgesteld worden. Dit wordt echter met de tijd duidelijker na iedere sprint.

Scrumban

De naam zegt het al; Scrumban is een combinatie van Scrum en Kanban. Het handige aan deze combi is dat er met een Kanban board een visualisatie van het Scrum process gemaakt wordt. Het bord wordt alleen wat breder gemaakt zodat alle kolommen voor de sprints erop passen. 

De meeste principes blijven hetzelfde: de hoeveelheid taken “in progress” mogen niet voorbij de WIP limit gaan, en de kaarten schuiven steeds verder op naarmate taken voortbewegen. Alleen zijn zaken zoals het inschatten en plannen van goals overbodig in deze setting, en worden dus redelijk wat Scrum regels opzij geschoven. 

Een Sprint Planning wordt alleen incidenteel georganiseerd indien het team dat nodig acht. Ze zien vanzelf aan een half leeg Kanban board wel of er meer ruimte is voor nieuwe taken uit de Backlog.

XP

De methode genaamd XP, staat voor Extreme Programming. Het is een veelgebruikte Agile methode voor software ontwikkeling, waarbij rekening wordt gehouden met de constant veranderende behoeften van de klant. Het probleem waarbij veel geavanceerdere technologieën al bestaan tegen de tijd dat een product klaar is, wordt hiermee opgelost.

Er wordt in hele kleine intervallen aan het product gewerkt, genaamd releases. Deze releases fungeren als het ware als checkpoints waarbij de eisen van de klant steeds opnieuw besproken worden.

Elementen van XP:

  • User Stories: De klant verkondigt in een User Story welke functionaliteiten en features voor de software ontwikkeld moeten worden. Na elke release, komt weer een nieuwe User Story die erg kan verschillen van de vorige.

  • Metaphors: Op basis van de User Stories, kan het team een Metaphor voorstellen. Dit is een voorgesteld idee van hoe de eisen vermeld in de User Story eruit zullen komen te zien. 

  • Spike: Wanneer het team een Metaphor wil implementeren, wordt er een Spike gebouwd om te onderzoeken hoe de nieuwe feature/functionaliteit eruit zou moeten zien. Het fungeert als een prototype.

Deze methode heeft overduidelijk veel overeenkomsten met Scrum, al zijn er wel een heel stuk minder specifieke rollen en elementen. Daarbij is XP speciaal bedoeld voor software ontwikkeling.

Crystal 

In tegenstelling tot Scrum waarbij de nadruk op bepaalde componenten en meetings ligt, hebben Crystal Agile methodes juist een sterke focus op het team en het individu. Teamgrootte, niveau van kriticiteit en de prioriteiten van het project hebben een grote invloed op hoe het team te werk gaat.

Deze methode werd door Alistair Cockburn ontwikkeld toen hij tijdens de jaren negentig bij IBM werkzaam was. Toen hij destijds verschillende succesvolle teams analyseerde, concludeerde hij dat de beste gebruiken erg afhankelijk waren van de eigenschappen van het team en het desbetreffende project.

Een klein team heeft bijvoorbeeld geen regelmatige meetings of formele rapporten nodig omdat ze makkelijk tussendoor kunnen communiceren. Voor grotere teams is het een grotere uitdaging om op één lijn te blijven.

De Crystal methode kent meerdere gradaties, gebaseerd op teamgrootte:

  • Crystal Clear: max 8 teamleden

  • Crystal Yellow: gemiddeld 10-20 teamleden

  • Crystal Orange: gemiddeld 20-50 teamleden

  • Crystal Red: gemiddeld 50-100 teamleden

Van de zeven componenten van Crystal Agile project management, worden alleen de eerste drie toegepast bij alle gradaties. De rest wordt eventueel toegepast indien het aansluit op de eigenschappen van het team en het project.

  1. Frequente levering: Tijdens regelmatige intervallen wordt gewerkt aan het leveren van een product aan de gebruiker. Door snel en vaak genoeg te evalueren, voorkom je dat je iets ontwikkelt wat de gebruiker helemaal niet nodig heeft.

  2. Reflectieve verbetering: Teamleden reflecteren voortdurend terug op wat ze geleverd hebben, hoe ze het voor elkaar kregen, en waarom ze het zo deden. Dit helpt het team inzien hoe hun werk in de toekomst kan worden verbeterd. 

  3. Osmotische communicatie: De Crystal methode vereist dat alle teamleden in dezelfde fysieke locatie aanwezig zijn, zodat informatie verspreid wordt alsof het via osmose gaat.

  4. Persoonlijke veiligheid: Open en eerlijke communicatie wordt aangemoedigd, zodat teamleden nooit bang hoeven te zijn om te spreken of met ideeën te komen. Slechte ideeën en suggesties bestaan niet.

  5. Focus op werk: Taken worden volgens prioriteit gepland zodat er niet gewerkt wordt aan zaken die op dat moment minder aandacht nodig hebben. Alle teamleden weten precies wie aan wat werkt, wat ook het collectieve verantwoordelijkheidsgevoel ten goede komt.

  6. Toegang tot expert gebruikers: Geregelde communicatie met echte gebruikers wordt ondersteund om voor waardevolle feedback te zorgen.

  7. Technische attributen: Sommige specifieke technische tools zijn nodig om problemen te signaleren, zoals automatische tests, configuratie management en frequente integratie.

DSDM

Deze afkorting staat voor Dynamic System Development Method en werd ook ontwikkeld in de jaren negentig. Elke activiteit moet aansluiten op de strategische business goals van het bedrijf, terwijl getracht wordt zo snel mogelijk waarde te creëren.

DSDM kan gecombineerd worden met andere methoden, zoals Scrum. Het doel van deze methode, is het team bij elke stap van het process eraan te herinneren wat de strategische objectieven van het bedrijf zijn. Alles wat ze doen moet daadwerkelijke waarde kunnen toevoegen aan het project, binnen een korte termijn.

De acht basisprincipes van DSDM:

  1. Focus op de strategische behoeften

  2. Tijdige oplevering

  3. Samenwerking

  4. Geen concessies op kwaliteit

  5. Vanuit een stevige basis opbouwen

  6. Iteratieve ontwikkeling

  7. Constante, duidelijke communicatie

  8. Demonstreer controle

ASD

Nog een afkorting. ASD staat voor Adaptive Software Development en werd ontwikkeld door Jim Highsmith and Sam Bayer. Hierbij is het uitgangspunt vergelijkbaar met alle andere Agile methoden; een hoog niveau van flexibiliteit bieden zodat het project zich kan aanpassen op de veranderende wensen van klanten. Echter doet ASD dit met behulp van deze drie fases:

  • Speculatie

  • Samenwerking

  • Leren

Het is belangrijk om te begrijpen hoe deze drie fases elkaar overlappen. Ze komen op een  non-lineaire manier aan bod tijdens verschillende punten in het proces. Misschien verschijnen ze zelfs allemaal op hetzelfde tijdstip! Het team speculeert, werkt samen en leert wanneer dit op bepaalde momenten in het projectproces nodig is.

De basis wordt gevormd door deze principes:

  • Je kan niet samenwerken zonder te leren, of leren zonder samen te werken

  • Je kan niet speculeren zonder te leren, of leren zonder speculatie

  • Je kan niet speculeren zonder samenwerking, of samenwerken zonder speculatie

Deze methode is heel geschikt voor niche softwareontwikkelings bedrijven waar kleinel teams aan eenmalige projecten werken. Het is minder geschikt voor grotere teams die tegelijkertijd aan verschillende soorten projecten werken.

ASD staat voor Adaptive Software Development en werd ontwikkeld door Jim Highsmith and Sam Bayer

Wat zijn de voordelen van Agile projectmanagement?

Hier is een kort overzicht van alle voordelen van Agile projectmanagement:

  • Verbeterde samenwerking in het team

  • Verbeterde collectieve verantwoordelijkheidsgevoel

  • Verhoogde flexibiliteit en adaptabiliteit

  • Het ondersteunt constante verbetering

  • Het verbetert klantrelaties 

  • Verbeterd vermogen om obstakels te signaleren

  • Verbeterde kwaliteit van deliverables

  • Verhoogde kans om doelen te bereiken

  • Snellere aflevering van deliverables

  • Verhoogde success-ratio voor complexe projecten

Conclusie

Er bestaat geen one-size-fits-all benadering voor projectmanagement, omdat het echt afhangt van het type projecten waar jouw organisatie aan werkt. Wat uit dit artikel blijkt, is dat Agile methoden heel geschikt zijn voor grote, complexe projecten die veel aanpassingen en herziening vereisen. Projecten die heel nieuw zijn, zullen er ook veel aan hebben omdat een duidelijk plan en uiteindelijke deliverables niet vooraf vastgesteld kunnen worden.

We hebben een aantal van de meest populaire Agile methoden in detail uitgelegd. De omvang van je projecten maar ook de eigenschappen van je team bepalen welke van deze methoden het meest geschikt zouden zijn.

Naast het implementeren van een bepaalde projectmanagement methode, kun je ook de success-rate van je projecten verhogen door projectmanagement software zoals Rodeo te implementeren. Nogmaals, er bestaat geen one-size-fits-all tool voor alle soorten bedrijven. De goede keuze maken is een grote uitdaging, zoals ook wordt uitgelegd in dit artikel. Alles hangt eigenlijk af van de manier waarop je werkprocessen ingericht zijn.

Gelukkig nemen onze experts de tijd om alles over jouw werkprocessen te leren, zodat ze precies kunnen uitleggen hoe Rodeo ze kan optimaliseren. Plan nu een gratis demo in! 

Plan een demo Probeer Gratis

+31 (0)88 165 14 00
Deze website maakt gebruik van Cookies Accepteren