Follow Us on Twitter

Beginnen met evalueren

Gepubliceerd in

Juli 2008 - Veel (software-) projecten sluiten af met een evaluatie om de zogenaamde "Lessons Learned" vast te leggen. Dat gebeurt vaak onder het motto "handig voor het nageslacht". Het zal niet de eerste keer zijn dat zo'n verslag in een bureaula terecht komt om vervolgens nooit meer door iemand gelezen te worden. En dat is jammer, want vaak brengen evaluaties nuttige verbeterpunten aan het licht.

Zou het niet nuttiger zijn om gedurende een project op vaste momenten terug te kijken, zodat eventuele verbeterpunten al gedurende het project doorgevoerd kunnen worden? Als software iteratief ontwikkeld wordt, dan is aan het einde van elke iteratie een uitgelezen moment om terug te kijken naar de werkwijze van de afgelopen iteratie en om eventuele verbeteringen direct in de volgende iteratie te implementeren.

Terugkijken om vooruit te komen

Nieuwe methoden, technieken en marktontwikkelingen volgen elkaar in rap tempo op. De halfwaardetijd van kennis wordt steeds korter. Je kunt je bijna niet meer onderscheiden met kennis die je al hebt; het accent verschuift steeds meer naar het vermogen om nieuwe dingen sneller te leren dan anderen. Dat is een belangrijke essentie van evalueren: terugkijken om vervolgens van die ervaring te leren. Daarbij spelen drie vragen een belangrijke rol:

  1. Wat ging goed?
  2. Wat kon beter?
  3. Wat kan ik concreet veranderen?

Dat is makkelijker gezegd dan gedaan: met zijn allen elke keer deze drie vragen beantwoorden heb je na een aantal iteraties ook wel gezien. Bovendien bieden ze weinig houvast om even wat dieper na te denken over wat er nu werkelijk gebeurd is, wat dat nu werkelijk voor je betekende en welk leerpunt je daar het beste uit kon halen. Om dit patroon te doorbreken hebben Esther Derby en Diana Larsen een handig boek geschreven, "Agile Retrospectives: Making Good Teams Great". In hun boek beschrijven ze een duidelijke structuur en tientallen werkvormen om te zorgen dat (regelmatig) evalueren geen sleur wordt.

Creëer de juiste omgeving

Elke evaluatie begint door een atmosfeer te maken waarin iedereen zich comfortabel genoeg voelt om vrijuit te spreken. Een belangrijke voorwaarde daarvoor, is dat iedereen goed doordrongen is van het feit dat een evaluatie niet bedoeld is om een zondebok aan te wijzen. Kritiek moet opbouwend zijn en zeker niet direct op personen gericht zijn.

Daarnaast moet een evaluatie een doel hebben. Dat kan bijvoorbeeld zijn een hogere productiviteit, kwaliteit, klanttevredenheid, minder productieverstoringen of een combinatie daarvan. De andere activiteiten in de evaluatie worden dan afgebakend om bij te dragen aan dit doel.

Verzamel informatie

Als je gaat evalueren, is het belangrijk om alle relevante informatie voorhanden te hebben. Hiervoor is het goed om gebeurtenissen en ervaringen expliciet te maken. Ook al evalueer je maar een periode van een maand, mensen hebben van nature de neiging om de gebeurtenissen van de laatste paar dagen als representatief voor de gehele periode te nemen. Daarnaast is het heel verhelderend om de visie van anderen op wat er gebeurd is te horen. Zo ontstaat er een gezamenlijk perspectief tijdens de evaluatie.

Een nuttige techniek hierbij is bijvoorbeeld een tijdlijn. Hierbij schrijft iedereen memobriefjes met voor hem of haar belangrijke gebeurtenissen en plakt die ruwweg in chronologische volgorde op de muur. Gebruik optioneel kleurtjes (bv. rood = negatieve gebeurtenis, groen = positieve gebeurtenis). Door het lezen van briefjes van anderen komen mensen soms nog op ideeën. Trek hier rustig een half uur voor uit als je een periode van een maand evalueert.


Figuur 1, Tijdlijn (bron)

Brainstormen

Na het verzamelen van informatie komt de vraag: "Waarom?". Deze vraag nodigt uit tot brainstormen op basis van alle verzamelde informatie. Waarom ging iets goed? Waarom ging iets finaal mis? Waar zaten de risico's? Wat zijn onze sterke punten? In deze fase worden patronen duidelijk. Patronen die leiden tot succes, of juist tot een mislukking. Zonder dit inzicht in onderliggende problemen, tussen oorzaak en gevolg, is het niet mogelijk om effectief oplossingen te verzinnen en door te voeren.

Een werkvorm om dit te doen is door bij een bepaald probleem je 5 keer af te vragen waarom iets optreedt. De redenatie daarachter is dat als je jezelf 5 keer "waarom?" afgevraagd hebt, je de kern van het probleem (en niet alleen een symptoom) te pakken hebt waarvoor je een oplossing zoekt.

Bijvoorbeeld:
V: Waarom was er vorige week een productieverstoring?
A: Omdat we een bug over het hoofd gezien hebben.
V: Waarom hebben we die bug over het hoofd gezien?
A: Omdat we niet uitgebreid genoeg getest hebben.
V: Waarom hebben we dan niet uitgebreid genoeg getest?
A: Omdat we daar geen tijd voor hebben.
V: Waarom hebben we daar niet genoeg tijd voor?
A: Omdat een volledige regressietest teveel tijd in beslag neemt.
V: Waarom neemt een volledige regressietest zoveel tijd in beslag?
A: Omdat we die handmatig doen en we niet een oneindig aantal testers hebben.

In dit voorbeeld kan het een oplossing zijn om te gaan investeren in testautomatisering, zodat regressietesten niet zo'n groot beslag leggen op kostbare test-uren.

Acties uitzetten en afsluiten

Veel evaluaties stranden op dit punt: er is een lange lijst met (goede) oplossingen en dan wordt de evaluatie afgesloten. Daarmee wordt een belangrijke stap overgeslagen: welke acties zijn nodig om een oplossing te realiseren? Als de lijst met oplossingen te lang is, kies dan 1 of enkele oplossingen waarvan iedereen vindt dat die de belangrijkste problemen oplossen.

Maak die oplossing concreet: wat kunnen we in de komende iteratie doen, zodat we na de volgende iteratie kunnen bepalen of we (een deel van) het probleem getackeld hebben? Om te voorkomen dat grote, tijdrovende oplossingen onoverkomelijk lijken kan het nuttig zijn om deze te splitsen in een korte termijn verbetering (bv. "doe een onderzoek naar welke tools we in kunnen zetten voor testautomatisering") en een lange termijn verbetering (bv. "alle regressietests automatiseren").

Als de acties bepaald zijn is de tijd gekomen om de evaluatie af te sluiten. Zorg ervoor dat het team alles wat ze geleerd hebben meenemen: tenslotte zijn het hun eigen ervaringen en verbeteringen. En vergeet vooral niet iedereen voor zijn tijd en harde werk te bedanken!

Valkuilen

Het is verleidelijk om een evaluatie over te slaan op het moment dat er druk op je project staat. Veel gehoorde redenen zijn dan "geen tijd", "we lopen al achter" en "volgende keer beter!". Bekijk het eens van de andere kant: juist door op dat moment even de rust te nemen om je problemen te analyseren, boek je potentieel een veel grotere winst als je effectief in oplossingen kunt investeren. Een investering van een paar uur tot een halve dag in een evaluatie is dan snel genoeg terugverdiend.

Een andere valkuil is om niet meer terug te komen op afgesproken acties. Vergeet niet om in de volgende evaluatie kort terug te kijken naar de vorige evaluatie, welke acties daar afgesproken zijn en wat daar in de afgelopen iteratie mee gedaan is. Als er niets mee gedaan is, waarom is dat dan? Dat kan tot interessante conclusies leiden - en daar wordt weer van geleerd.

Tot slot

Voor iedereen die geïnteresseerd is om evaluaties te organiseren en faciliteren is het boek van Derby en Larsen een aanrader. Zeker als je regelmatig (bv. maandelijks) met hetzelfde team evalueert, is het een verademing om elke keer afwisselende werkvormen uit deze "gereedschapskist" te gebruiken.

Referenties

Over de auteur
Martin Schapendonk is (agile) projectmanager voor Whitehorses en heeft bijna 10 jaar ervaring in vrijwel alle rollen in software development projecten. Naast Certified ScrumMaster is hij ook Prince2 Practitioner.

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.