Waarom evalueren in agile projecten wél lukt
Projecten evalueren blijft vaak achterwege, ondanks de meerwaarde. In agile projecten – met name in softwareontwikkeling – is evaluatie wél een vast onderdeel van de routine. Waarom? Omdat agile methoden zoals Scrum evaluatie structureren als een tussentijds, productgericht en lerend proces.
Wat is projectevaluatie?
Wij definiëren projectevaluatie als het regelmatig, met alle stakeholders, vaststellen van de stand van zaken, met twee centrale vragen:
- Wat hebben we gedaan (en nagelaten) om dit (tussen)resultaat te bereiken?
- Welke acties zijn nodig om in dit en toekomstige projecten effectiever te werken?
Deze benadering combineert product- en procesgerichte evaluatie en zorgt dat leren ook toekomstige projecten ten goede komt.
Leren op twee niveaus
Evaluatie draait om leren, op twee manieren:
- First loop learning: Wat is de beste werkwijze in deze situatie?
- Double loop learning: Waarom is de situatie zoals deze is? Welke patronen herkennen we, en hoe voorkomen we fouten – of behouden we good practices – in de toekomst? (Argyris, 1977)
Leren moet gebeuren op alle niveaus: individuen, teams, organisaties en soms zelfs ketenpartners. Toch is dit niet eenvoudig: mensen vermijden fouten, uit angst voor het stigma van incompetentie (De Winter, 2010).
Agile en evaluatie: waarom het werkt in softwareontwikkeling
In softwareprojecten is de relatie met opdrachtgevers en eindgebruikers complex. Klassieke fasering – waarbij het eindproduct vooraf volledig wordt gedefinieerd – werkt hier vaak niet, omdat:
- Eindgebruikers moeite hebben om zich een beeld te vormen van het resultaat.
- Processen veranderen tijdens het project, waardoor het eindproduct niet meer past bij de nieuwe situatie.
De oplossing: het Agile Manifesto (2001)
Agile methoden omarmen veranderende eisen en vragen om een flexibele projectstructuur. Scrum is de meest bekende methodiek, gekenmerkt door:
- Korte sprints (4-6 weken) met een werkend (deel)product als resultaat.
- Sprint reviews: de opdrachtgever toetst het product aan de afspraken.
- Sprint retrospectives: het team reflecteert (zonder opdrachtgever) op:
Wat moeten we veranderen?
Wat houden we vast?
Waar moeten we mee stoppen?
Hoe Scrum voldoet aan evaluatie-eisen
| Eis | Scrum |
|---|---|
| Tussentijds | Ja: evaluatie is gekoppeld aan elke sprint |
| Productgericht | Ja: evaluatie vindt plaats bij oplevering van een (deel)product |
| Double loop learning | Ja: retrospectives zoeken naar onderliggende patronen |
| Met alle stakeholders | Deels: eindgebruiken zijn niet altijd direct betrokken |
| Van individueel tot ketenniveau | Nee: focus ligt op projectniveau |
Praktische tips voor effectief evalueren
- Gebruik van de Product Breakdown Structure
Plan evaluaties altijd bij oplevermomenten, niet io vaste tijdstippen. Zo blijft de focus op het product - Geef inhoud aan opleveringen
Zorg dat alle feiten (Tijd, Geld, Kwaliteit, Informatie, Organisatie, Businesscase) op tafel liggen. Een product dat er ‘goed uitziet’ is niet genoeg: kwaliteit moet aantoonbaar zijn. - Koppel evaluaties aan opleveringen, niet aan afrekenen
Evaluaties moeten leren en verbeteren als doel hebben. Vermijd juridische contexten waar verbeterpunten als schuldbekentenissen kunnen worden gezien. - Betrek écht iedereen
Zorg dat eindgebruikers daadwerkelijk aan tafel zitten. Zo voorkom je dure aanpassingen achteraf. - Maak goede afspraken
Vraag naar persoonlijk commitment en formuleer afspraken SMART (met nadruk op Acceptabel en Realistisch). Professionals leren niet makkelijk – wees hier bewust van.
Toepassing buiten softwareprojecten
Deze principes zijn ook heel goed te gebruiken buiten softwareprojecten. Zie ook onze masterclass Projecten evalueren.
Literatuur & Auteurs
Voor een complete literatuurlijst, illustraties en grafieken en informatie over de auteurs, zie het originele artikel (.pdf, 2,3 Mb).
