Het Agile-manifest uitgelegd en hoe je het toepast

Wat is het Agile-manifest?

Het Agile-manifest is een schriftelijke verklaring met vier waarden en twaalf principes die bedoeld zijn om werkwijzen binnen de softwareontwikkeling te verbeteren.

Het manifest was eerder filosofisch dan voorschrijvend en bedoeld om te kunnen worden aangepast aan verschillende teamgroottes, doelen en omstandigheden.

De 4 waarden van het Agile-manifest

Het officiële Agile-manifest bestaat uit deze 4 waarden:

1. Individuen en interacties boven processen en hulpmiddelen
2. Werkende software boven uitgebreide documentatie
3. Samenwerking met de klant boven contractonderhandelingen
4. Reageren op verandering boven het volgen van een plan

Het is interessant om op te merken dat de auteurs de waarden lieten volgen door deze verduidelijkende verklaring: "Dat wil zeggen: hoewel er waarde zit in de items aan de rechterkant, hechten we meer waarde aan de items aan de linkerkant."

Dit onderstreept het idee dat het Agile-manifest niet draait om het volgen van een bepaald proces of het gebruiken van een specifieke agile hulpmiddel. Het draait om het aannemen van een specifieke denkwijze.

De 12 principes van het Agile-manifest

Naast de vier waarden bevat het Agile-manifest 12 ondersteunende principes die uitleggen hoe de waarden op agile projecten moeten worden geïnterpreteerd en toegepast.

1. Stel de klant voorop

De hoogste prioriteit is het tevredenstellen van de klant door waardevolle software vroegtijdig en voortdurend op te leveren.

2. Verwelkom verandering

Verwelkom veranderende vereisten, zelfs laat in de ontwikkeling. Agile processen benutten verandering voor het concurrentievoordeel van de klant.

3. Lever regelmatig op

Lever regelmatig werkende software op, van een paar weken tot een paar maanden, waarbij de voorkeur uitgaat naar de kortere termijn.

4. Werk samen tussen teams

Zakelijke medewerkers en ontwikkelaars moeten gedurende het hele project dagelijks samenwerken.

5. Ontwikkel talent

Bouw projecten rond gemotiveerde individuen. Geef hun de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.

6. Praat met elkaar

De meest efficiënte en effectieve manier om informatie over te brengen aan en binnen een ontwikkelingsteam is een gesprek van persoon tot persoon.

7. Meet wat ertoe doet

Werkende software is de belangrijkste maatstaf voor vooruitgang.

8. Doseer het werk om burn-out te voorkomen

Agile processen bevorderen duurzame ontwikkeling. Opdrachtgevers, ontwikkelaars en gebruikers moeten in staat zijn om voor onbepaalde tijd een constant tempo aan te houden.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

9. Richt je op kwaliteit en het werk gaat sneller

Voortdurende aandacht voor technische uitmuntendheid en goed ontwerp vergroot het aanpassingsvermogen.

10. Omarm eenvoud

Eenvoud – de kunst om de hoeveelheid werk die niet wordt gedaan te maximaliseren – is essentieel.

11. Doe niet aan micromanagement

De beste architecturen, vereisten en ontwerpen ontstaan uit zelforganiserende teams.

12. Reflecteer en pas aan

Het team reflecteert regelmatig op hoe het effectiever kan worden en stemt vervolgens zijn gedrag daarop af.

Geschiedenis, auteurs en ontstaansgeschiedenis van het Agile Manifesto

Binnen de techwereld wordt het Agile Manifesto besproken met dezelfde eerbied en oneerbiedigheid als elke heilige tekst die in de loop der tijd is overgeleverd.

In februari 2001 kwamen 17 softwareprofessionals die zichzelf “The Agile Alliance” noemden, bijeen in de Amerikaanse staat Utah om te ontwikkelen wat zij een “Manifesto for Agile Software Development” noemden. Het document, dat de nadruk legt op vier waarden en 12 principes, staat nu bekend als het Agile Manifesto.

De auteurs van het Agile Manifesto worden vaak aangeduid als de Agile Alliance en waren afkomstig uit verschillende ontwikkelprocessen, waaronder extreme programming, Scrum en Crystal. 

Een snelle blik op de officiële website van het manifesto toont de auteurs in een omgeving die kan doen denken aan een geheim genootschap of een bijeenkomst van grondleggers. Het was duidelijk dat het hun bedoeling was iets te creëren dat een blijvende impact op de sector zou hebben. Dat is zeker gelukt.

Hoewel de personen die in Utah bijeenkwamen niet de pioniers waren van agile principes in het algemeen, brachten zij wel de waarden samen die al enige tijd op de achtergrond aan het ontstaan waren in de wereld van softwareontwikkeling.

Tegenwoordig heeft de agile-methodologie vrijwel elke sector doordrongen.

De auteurs waren:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

Waarom het Agile Manifesto (nog steeds) belangrijk is

Het Agile Manifesto is nog steeds relevant vanwege de focus op mensgerichte manieren van werken en de ruimte voor flexibiliteit.

Snelle technologische veranderingen gaan vaak gepaard met veranderende projectvereisten. Het Agile Manifesto stelt projectmanagers in staat om aanpassingsvermogen en samenwerking prioriteit te geven door een responsieve en veerkrachtige projectomgeving te creëren die tegelijkertijd werk kan opleveren, kan innoveren en kan bijsturen wanneer dat nodig is.

Het bevordert ook een klantgerichte mentaliteit door werkende oplossingen hoger te waarderen dan uitgebreide documentatie. Hierdoor kunnen projectmanagers vroegtijdig feedback verzamelen en hun werk voortdurend verfijnen, zodat het project nauw aansluit bij de behoeften van gebruikers. Deze iteratieve en klantgerichte aanpak verhoogt het succespercentage en de tevredenheid van projecten.

Hoe pas je het Agile Manifesto toe?

Laten we elk van de vier waarden van het agile manifesto wat nader bekijken. Door de kernwaarden te bespreken, verkennen we ook de 12 principes die bij elk ervan horen.

Waarde 1: Individuen en interacties boven processen en tools

De kern van agile draait om mensen. Agile benadrukt dat een team samenwerkt, nauw samenwerkt en zelfstandig beslissingen neemt. Agile gaat er niet om een team te vertellen wat het moet doen of bouwen. 

Bij agile projecten moet communicatie vrij en voortdurend verlopen, niet vastomlijnd en ingepland zijn. Werken in afgesloten silo’s is niet waar agile om draait.

Beoordeel de teamcommunicatie

Vraag jezelf af: voeren jij en je team gesprekken van persoon tot persoon? Of vertrouwen jullie op e-mails, documenten en bepaalde geliefde berichtentools (zonder namen te noemen)? 

Zelfs als je op afstand werkt, kan een gesprek van persoon tot persoon ervoor zorgen dat dingen sneller gebeuren. Vooral wanneer een team net wordt gevormd, stimuleert synchrone communicatie vertrouwen en openheid en helpt deze bij het opbouwen van relaties.

Wees minder controlerend

We hebben ons hier allemaal weleens schuldig aan gemaakt. Maar vertrouwen is essentieel voor agile. Op zoek naar iets wat je direct kunt toepassen? BEHEER NIET OP DETAILNIVEAU (ja, ik bedoel dat als een bevel).

Het is verleidelijk om de taken tot in detail uit te werken, ze aan het team toe te wijzen en ze vervolgens te volgen totdat ze de opgelegde deadline halen (of niet), zodat je overal controle over hebt. Maar om je team echt in staat te stellen zelfstandig te werken, moet je een stapje terug doen en hen eigenaar laten zijn van hun werk!

Stimuleer een zelforganiserend team

Het gaat niet om managen, maar om leidinggeven en faciliteren. Een zelforganiserend team houdt in dat een team zelf kiest hoe het zijn werk het beste kan uitvoeren. Het team moet beslissen hoe het de achterstand aan werk omzet in code die kan worden uitgebracht. Maar sla niet door naar het andere uiterste door helemaal geen hulp of begeleiding te bieden: het team heeft nog steeds een visie, motivatie en hulp nodig om blokkades op te lossen.

Hoe zorg je er dan voor dat je stopt met het uitdelen van taken en in plaats daarvan bepaalt hoe je het werk kunt faciliteren?

Maak je niet druk om het proces of de tool

Ik weet het, ik weet het: in de wereld van agile projectmanagement is er voortdurend sprake van tools voor projectmanagement en agile projectmanagementsoftware.

Maar dit is de kern: je klant geeft niets om je interne agile workflowproces. Dat zouden ze ook niet moeten doen.

Agile draait om een klantgerichte aanpak en om je team in staat te stellen beter en waardevoller werk op te leveren. Later meer over de klantgerichte aanpak!

Silo's verwijderen

Silo's belemmeren de samenwerking en doen daardoor afbreuk aan agile waarden. 

Overweeg de volgende tips om silo's te doorbreken:

• Plaats het team bij elkaar: Ja, deze tip opnieuw. Het is geweldig als je ontwerpers bij elkaar kunnen zitten en over ontwerp kunnen praten, maar is het niet beter als ze met de ontwikkelaars praten over het bouwen van dit geweldige product? Ik weet dat dit lastig kan zijn in een grotere organisatie of in omgevingen waarin op afstand wordt gewerkt, maar zelfs samenkomen in een gedeeld Slack-kanaal of geplande sessies voor gezamenlijk werken houden, waarin mensen gelijktijdig en op afstand diepgaand kunnen werken, kan ervoor zorgen dat je team meer verbonden blijft.
• Ontmoedig overdrachten tussen afdelingen: De meer afgeschermde, watervalachtige aanpak waarbij elke afdeling in fasen werkt (UX, daarna ontwerp, daarna ontwikkeling en vervolgens QA) kan vaak leiden tot communicatiestoornissen en meer verspilling binnen een project. Overweeg je team samen aan functies te laten werken in plaats van werk langs een keten door te geven. Zelfs als je in sprints werkt, maar met voorafgaand een ontwerpsprint, moet je je ontwikkelaars bij de ontwerpsprint betrekken: zij gaan dit uiteindelijk bouwen!

Waarde #2: Werkende software boven uitgebreide documentatie

Houd er rekening mee dat het manifest niet zegt dat documentatie moet verdwijnen; het waardeert de onderdelen aan de linkerkant simpelweg hoger dan die aan de rechterkant. Dat betekent dat documentatie nog steeds bestaat. Scrum bevat bijvoorbeeld user stories om een ontwikkelaar te informeren over hoe hij met de bouw kan beginnen.

Maar wat kun je doen om afstand te nemen van de zware, tijdrovende documentatie en snel tot iets tastbaars te komen?

Stroomlijn de documentatie die je gebruikt

Identificeer eventuele knelpunten of blokkades in je proces. Gebruik je te veel documentatie? Doe je er eindeloos over om het perfecte eisenoverzicht op te stellen, besteed je veel tijd aan een functionele scope en heb je daarna geen tijd meer om het product te bouwen? Beperk onnodige documentatie door:

• Je te richten op ontwerp- en ontwikkelingstaken die rechtstreeks bijdragen aan het product zelf, in plaats van aan een geschreven document dat uiteindelijk niet zal worden gebruikt
• Vooraf workshops te houden om eisen en vervolgstappen vast te leggen, in plaats van lange documenten te schrijven. Leg de resultaten vast en deel ze met foto's en korte notities.

Begin snel met bouwen

Het schrijven van pagina's vol eisen-documentatie is een manier om de behoeften van het bedrijf, de klant en de eindgebruiker in kaart te brengen. Maar uiteindelijk is het veel nuttiger om iets te zien dat werkt, zich gedraagt en reageert.

Overweeg enkele van de volgende manieren om je project snel vooruit te helpen:

• Beperk de voorafgaande verkenning of definiëring tot een kortere periode: Door de tijd die je besteedt aan definiëren en uitzoeken te beperken, kun je sneller iets opleveren waar ontwerpers en ontwikkelaars mee aan de slag kunnen. Je kunt het proces versnellen met deze vragen voor verkennende sessies.
• Houd workshops: Door teamworkshops te organiseren, breng je belanghebbenden samen zodat ze sneller beslissingen kunnen nemen.
• Wijzig je projectplan: Heb je de definiëring, het ontwerp en de ontwikkeling na elkaar gepland? Overweeg dan om de ontwikkeling naar voren te halen en ontwerpers en ontwikkelaars eerder samen iets te laten maken.

Gebruik prototypingmethoden in plaats van statische ontwerpen

Beschouw voortgang niet als een definitiedocument of een statisch ontwerp dat slechts een vinkje is voor goedkeuring door je klant, maar laat hem iets zien dat onderdeel wordt van het eindproduct.

Gebruik snelle prototyping om iets werkends en bruikbaars te maken—en, nog belangrijker, iets dat je met klanten kunt testen. Feedback verzamelen over een prototype wordt een nuttige manier om de voortgang bij te houden, in plaats van te vertrouwen op een oplevering die niet het voordeel heeft dat deze onderdeel is van het eindproduct.

Je kunt prototypes met verschillende niveaus van getrouwheid maken:

• Lage getrouwheid: klikbare ontwerpen. Dit is wanneer je snel iets moet uitwerken om het met klanten te testen; het gaat dan meer om het testen van uitstraling en gevoel en eenvoudige interacties.
• Gemiddelde getrouwheid: met enige beweging of animatie.
• Hoge getrouwheid: werkende HTML. Gebruikt voor complexe interacties, maar je kunt dit verder ontwikkelen tot code die kan worden uitgebracht.

Prototypes met een hoge getrouwheid komen dichter bij “werkende software” dan de andere typen, maar kunnen meer tijd kosten om te maken. Prototypes met een lage of gemiddelde getrouwheid bieden ontwikkelaars betere richtlijnen dan statische ontwerpen.

Lever snel iets aan de eindgebruiker of klant

Dit is een belangrijke.

Bij frequente releases van werkende software kan de klant gebruikmaken van nieuwe functies die zijn uitgebracht. In plaats van te wachten tot het einde van het project op een grote lancering, is het cruciaal om je klant eerder waarde te leveren om een beter product te krijgen.

Hoe kun je in je organisatie vaker opleveren?

• Bekijk je projectplan of je projectroutekaart: Heb je gepland om de ontwikkeling af te ronden en vervolgens aan het einde van je project te lanceren? Werk in plaats daarvan met je team samen om het werk op te splitsen in functies of werkonderdelen die tussentijds onafhankelijk kunnen worden uitgebracht.
• Richt je op blokkades: Een belangrijk onderdeel van je rol is het helpen wegnemen van blokkades voor het team wanneer zich problemen voordoen. Hoe kun je hen helpen efficiënter te leveren? Zijn er werkwijzen die releases vertragen? Door met je team een sprintretrospectief te houden, kun je kansen voor procesverbetering ontdekken.
• Automatiseer: Als je organisatie veel moeite steekt in releases, automatiseer dan waar mogelijk processen. Geautomatiseerd testen en implementeren kan bijvoorbeeld handmatig werk besparen en de benodigde inspanning voor een release verminderen. Bespreek met je wendbare ontwikkelingsteam welke processen zij gebruiken en welke mogelijkheden er zijn voor automatisering.

Waarde #3: samenwerking met de klant boven contractonderhandelingen

In plaats van aan het begin van een project een zeer specifiek contract op te stellen met precieze opleveringen, scope, budgetten en planningen, houd je je wendbare contract zo globaal mogelijk. Neem gedurende je project beslissingen door nauw samen te werken met je klanten en belanghebbenden.

Wendbaar werken draait niet om het besteden van enorm veel tijd aan het vooraf definiëren van vereisten. Het gaat erom aan een project te beginnen en gaandeweg te leren op basis van klanttests en feedback die je uit werkende software haalt.

Kies voor een klantgerichte aanpak

Ik ben dol op dit citaat uit een artikel van Neil Killick:

“Een wendbare denker vraagt zich voortdurend af: ‘Wat is de eenvoudigste/snelste manier om waarde bij de klant te krijgen?’ Stel je jezelf die vraag dagelijks? Zo niet, dan is dat je eerste stap.”

Het zijn niet alleen ontwerpers en ontwikkelaars die hierover moeten nadenken—projectmanagers zouden dat ook moeten doen. Ook wij zijn verantwoordelijk voor het leveren van het best mogelijke product of de best mogelijke dienst aan een klant. Je klant, de gebruiker van je product of dienst, moet centraal staan in alles wat je doet.

Stel de eindklant centraal in het plan

Plan niet rond opleveringen en schattingen, maar rond waardevolle resultaten voor de klant. Wat willen we dat de klant doet, en waarom? Hoe meten we of dit werkt?

Stuur het gesprek in de richting van de waarde die we voor de klant hebben geleverd, in plaats van het aantal werkonderdelen dat we hebben opgeleverd.

Betrek je klant nauw bij het project

In plaats van elke week een statusvergadering te houden en vervolgens aan het einde van een bepaalde periode aan je klant en belanghebbenden op te leveren, kun je je klant dagelijks bij het project betrekken.

Als je meer volgens een Scrumproces werkt, maak je de klant de producteigenaar. De producteigenaar is verantwoordelijk voor het samenbrengen van de bedrijfs-, technische en klantvereisten. Het is essentieel om al vroeg en regelmatig draagvlak en samenwerking van de klant te verkrijgen om vertragingen te voorkomen. Uiteindelijk levert dit een beter product of een betere dienst op voor de eindklant.

Betrek een klant die op afstand staat

Als je klant geen tijd heeft om aan het project bij te dragen of anderszins niet betrokken is, zorg er dan voor dat iemand in het team de klant vertegenwoordigt. Het is essentieel dat iemand rekening houdt met de behoeften van de klant en het bedrijf.

Zelfs als de klant niet dagelijks betrokken is, moet je ervoor zorgen dat je regelmatig met hem of haar communiceert en hem of haar op zijn minst betrekt bij gesprekken over agile planning en prioritering. Werk met de klant samen om de voordelen van diens betrokkenheid te laten zien.

Maak een productroutekaart

Overweeg een productroutekaart te gebruiken om het traject van je product in kaart te brengen. Een productroutekaart communiceert het plan voor het product en visualiseert de functies die gepland zijn voor oplevering. Een routekaart ligt aan het begin van een project niet vast; in plaats daarvan ontwikkelt deze zich in de loop der tijd om veranderingen in prioriteiten weer te geven.

Zorg ervoor dat je met je eindgebruikers of klanten praat

Ik kan dit niet genoeg benadrukken—je moet proberen je product vroegtijdig en regelmatig met eindgebruikers en klanten te testen. 

Testen levert zoveel voordelen op:

• Je kunt ervoor zorgen dat je product aan de behoeften van klanten voldoet. Is het product waardevol voor de klant en dus voor het bedrijf? Dit helpt je om de product-marktfit te beoordelen.
• Je kunt feedback van klanten verwerken in je ontwerp- en ontwikkelproces, wat resulteert in een beter eindproduct.
• Je kunt inzichten verkrijgen die je kunt gebruiken voor toekomstig werk.

• Het vaak genoemde probleem met testen bij klanten is het budget—het kan duur zijn. Hier zijn enkele manieren om te testen, ongeacht het budget van je project:

Guerrillatesten: Ik vind deze methode geweldig omdat ze goedkoop en eenvoudig is. Bied mensen aan om een echte (of virtuele) koffie voor hen te kopen als ze enkele vragen over je ontwerpen of prototype willen beantwoorden. Het is moeilijker om te bepalen wie je vragen beantwoordt, maar snelle feedback kan nuttig zijn bij het testen van het uiterlijk en gevoel of eenvoudige interacties.

Enquêtes: Om kwantitatieve gegevens van een bredere groep mensen te verzamelen, kun je een enquête maken om een ontwerp te evalueren of dieper in te gaan op klantgedrag.

Websites zoals usertesting.com: Je kunt je ontwerpen naar een van deze websites uploaden en via die websites mensen werven (eventueel met behulp van criteria). Zij klikken vervolgens door je ontwerpen, leggen hun gedachten vast en beantwoorden vragen.

Face-to-facetesten: Ja, dit kan een duurdere optie zijn, omdat je waarschijnlijk mensen moet werven en vergoedingen moet betalen; toch kan dit van onschatbare waarde zijn als je complexe interacties of functies met een hoog risico test.

Waarde #4: Reageren op verandering in plaats van een plan volgen

Agile- en watervalprojecten kunnen op dit gebied niet meer van elkaar verschillen. Bij traditionele softwareontwikkelingsprojecten leg je de vereisten, kosten en planning vooraf vast, terwijl agile ruimte laat voor verandering en deze omarmt.

Verandering is goed! Het is niet slecht! Hoeveel projectplannen zijn precies uitgekomen zoals je ze aan het begin hebt opgesteld? Niet veel, vermoed ik (ik heb aan projecten gewerkt met tientallen versies van het projectplan).

Plannen zijn op een bepaald moment de beste inschatting die je kunt maken en je kunt ze gaandeweg verder verfijnen—ze laten echter doorgaans geen ruimte voor verandering. Wat gebeurt er als de behoeften van de klant veranderen? Als het bedrijf van koers verandert? Als je klant de prioriteiten verandert? Als de gespecificeerde functie niet zo eenvoudig te bouwen is als je dacht.

Agile werkwijzen omarmen onzekerheid door een adaptieve planningsaanpak te hanteren (zoals planning poker). De waarden van Scrum schrijven bijvoorbeeld voor dat het team het werk per sprint plant. Voordat ze aan een afgebakende werkperiode beginnen, halen agile teams items uit de werkvoorraad en prioriteren ze deze voor ontwikkeling.

Hoewel er vaak druk wordt uitgeoefend om kosten, planning en scope aan het begin van een project vast te leggen, levert een realistischer kijk op de onzekerheden waarmee je te maken hebt vaak een veel beter eindproduct op. Uiteindelijk is dit wat jij, de klant en je belanghebbenden zouden moeten willen. 

Hier zijn enkele manieren om ruimte te gaan bieden aan verandering in je projecten en meer flexibiliteit aan te moedigen:

Maak een ‘licht’ plan om belanghebbenden tevreden te stellen

“Maar we hebben een plan nodig!”, roepen je belanghebbenden. In plaats van hen in paniek te brengen door te zeggen: “Verrassing, er is geen plan!”, maak je een beknopt releaseplan om hen vertrouwen te geven in de iets minder formele aanpak.

Als je agile projectmanagement uitvoert met Scrum-processen, heb je een lijst met geprioriteerde en ingeschatte gebruikersverhalen in je achterstand. Werk samen met de producteigenaar om deze te groeperen in globale releases en koppel deze aan je productroadmap.

Probeer niet alles te plannen, want daarmee doe je de voordelen van de Scrum-methodologie teniet. Laat je stakeholders zien wat je in de eerste twee of drie releases plant en leg vervolgens uit dat herplannen de kern vormt van een agile manier van werken. Je communiceert updates en verdere releases dan gaandeweg. Hopelijk geeft dit hun het benodigde vertrouwen!

Laat het team geleidelijk kennismaken met een aanpak op basis van sprints

Mike Cohn stelt in zijn artikel “Een agile proces introduceren in een organisatie” voor om teams geleidelijk aan Scrum te laten wennen door een aantal sprinttypen te definiëren, bijvoorbeeld:

• Prototyping
• Vastleggen van vereisten
• Analyse en ontwerp
• Implementatie
• Stabilisatie

Hij beschrijft hier hoe dit kan helpen:

“Vervolgens werken we met de teams samen om de artefacten te definiëren die uit elk sprinttype voortkomen. Het gebruik van sprinttypen zorgt voor precies genoeg formaliteit, zodat de teams duidelijker kunnen zien hoe ze het project moeten aanpakken. Naarmate de teams meer vertrouwd raken met het informele karakter van het agile proces, laten ze het concept van sprinttypen geleidelijk los.”

Dit is een andere manier om je releaseplan vorm te geven. Als je aan elke sprint een “type” toewijst, kunnen je stakeholders zien hoe het plan vorm krijgt, terwijl je niet wordt gedwongen om functies te garanderen. Je team krijgt bovendien een beter beeld van waaraan het gaat werken.

Neem afstand van vaste deadlines

Je team een deadline geven of een vaste datum aan je klant communiceren zijn beide strategieën die gedoemd zijn te mislukken of op zijn minst onderweg stress veroorzaken. Vertrouwen opbouwen tussen jou, je team en je klant of stakeholder is essentieel om te bewijzen dat je waarde zult leveren aan de eindklant, en dat ook daadwerkelijk zult doen.

Vergeet niet dat je de behoefte aan meerdere controlepunten en goedkeuringen probeert te verminderen. Deadlines invoeren voor je project helpt je niet om dit doel te bereiken. Het is ook niet goed om je team voortdurend op de huid te zitten en hen op te jagen voor het werk dat ze hadden “beloofd” op te leveren.

Zoals ik hierboven al aangaf, kunnen roadmaps en releaseplannen een goed mechanisme zijn om af te stappen van een aanpak met vaste datums. Stakeholders een beeld geven van wat er in de nabije toekomst wordt uitgebracht, kan hen geruststellen dat er een plan is.

Gebruik een projectomvang op basis van tijd en materiaal

Als je een projectomvang met een vaste prijs en vaste opleveringen hebt, is het moeilijk om op een meer agile manier te leveren. Je kunt zeker enkele van de technieken toepassen die ik al heb besproken, zoals het mogelijk maken van een meer samenwerkend team. Maar je wordt beperkt in de mate waarin je kunt reageren op en je kunt aanpassen aan veranderingen, het team kunt laten bepalen waaraan het werkt of een meer klantgerichte aanpak kunt gebruiken.

Werk samen met je interne team en de klant om een projectomvang op basis van tijd en materiaal vast te leggen—dat wil zeggen dat de klant betaalt voor een team in plaats van voor vaste opleveringen. In eerste instantie kunnen klanten nerveus worden als ze niet precies weten wat ze krijgen.

Om deze zorg weg te nemen, kun je als onderdeel van de projectomvang een achterstand met activiteiten of taken opnemen die voor de lancering in aanmerking kunnen komen. Leg in het contract vast dat het team de achterstand opnieuw plant en prioriteert met input van de klant naarmate het project vordert (hoewel je mogelijk niet elk item behandelt).

Om veranderende prioriteiten en opleveringen te helpen beheren, kunnen teams vertrouwen op agile beheersoftware om hun achterstand voortdurend opnieuw te prioriteren en op samenwerkingstools voor softwareontwikkeling om samenwerking tussen verschillende functies te coördineren.

Op deze manier leg je je niet vast op een vaste projectomvang, maar heeft de klant minder zorgen over hoe het eindproduct eruitziet.

Blijf de voortgang volgen

Het volgen en visualiseren van de voortgang verdwijnt niet zomaar wanneer er geen formeel projectplan is. Door de voortgang zichtbaar te houden voor het team en de stakeholders, zorg je er niet alleen voor dat mogelijke blokkades en knelpunten niet uit het oog worden verloren, maar houd je stakeholders ook op de hoogte. 

Een WIP-bord in Kanban-stijl of agile dashboards werkt goed voor agile projecten. Zodra je je proces hebt gevisualiseerd, kun je ondersteunende taken en activiteiten in kaart gaan brengen. Zo ontdek je knelpunten die je kunt wegnemen om een snellere levering aan de klant mogelijk te maken.

Kritiek op het Agile Manifest

Zoals elke andere projectmanagementmethodologie is agile niet perfect. Critici wijzen erop dat de auteurs van het Agile Manifesto een homogene groep vormden die mogelijk geen rekening heeft gehouden met alternatieve manieren van werken, zoals de voordelen van werken op afstand of hoe je agile buiten de softwareontwikkelingssector kunt toepassen.

Als je agile te ver doorvoert, kan het besluitvorming door een commissie betekenen, waardoor het werktempo vertraagt. Een gebrek aan documentatie kan de oplevering van projecten uiteindelijk schaden, vooral in een werkomgeving op afstand waarin asynchrone communicatie van cruciaal belang is.

Als je besluit agile te gebruiken voor je projecten, raadpleeg dan zeker de agile waarden en principes. Ze bieden een nuttige leidraad om de slechtste neigingen van agile in toom te houden.

Lees hier meer over het debat over de vraag of agile een methodologie of een mentaliteit is.

Wendbaarheid, geen agile

Een laatste gedachte: vergeet de retrospectieve niet! Zoals het Manifesto stelt:

Het team reflecteert regelmatig op manieren om effectiever te worden en stemt zijn gedrag vervolgens daarop af.

Welk type proces je ook uitvoert, de retrospectieve is een effectieve manier om te onderzoeken hoe je werkt en te optimaliseren voor succes. Zorg ervoor dat je regelmatig projectretrospectieven opneemt in het proces dat je gebruikt—en dat je een mechanisme hebt om je lessen toe te passen! PS: Het is belangrijk om je stille teamleden tijdens retrospectieven aan het praten te krijgen—zo doe je dat.

Wat nu?

Wil je meer leren over het implementeren van agile manieren van werken en leren van de beste projectmanagers in de branche? Bekijk dan onze lidmaatschapsopties van DPM.