In het begin van de transitie naar een agile organisatie blijft men vaak hangen in wat men zelf weet. Niet zo vreemd natuurlijk, als je zoveel onbekende en onzekere termen en processen naar je hoofd geslingerd krijgt. Eén van de grote struikelblokken voor managers, is het blijven controleren van individuele medewerkers en het vergelijken van teams en hun voortgang. We moeten immers wel onderscheid kunnen maken tussen goede en minder goede medewerkers. Het meten van de oude manier van werken is een stuk moelijker als de functie van een medewerker veranderd. Een ontwikkelaar zal bijvoorbeeld niet alleen meer ontwikkelen, maar zal ook ontwerp en test gaan doen.
Wat ik vaak zie gebeuren, is dat men probeert het resultaat van een team te meten en dit te vergelijken met eerdere metingen of andere teams.
Goede redenen hiervoor zijn verschillend, bijvoorbeeld:
- Men wil zien of er vooruitgang is geboekt in het team.
- Men wil zien of teams van elkaar kunnen leren.
Is er vooruitgang geboekt?
In zo’n meetmoment wordt vaak gebruik gemaakt van een checklist. Een scrum of agile maturity model is daar een bekende term in. Een dergelijke checklist bevat een aantal vragen die meten in hoeverre een team een agile onderdeel beheerst.
Vraag één is: wie vult het assessment in? De agile coach of een andere ‘buitenstaander’? Of het team zelf?
Vraag twee is: hoe goed zijn de stellingen?
Denk aan een stelling als “Het team staat elke dag tijdens de Daily scrum bij elkaar om de drie vragen te beantwoorden”. Waarbij de drie vragen natuurlijk slaan op: “Wat heb ik gisteren gedaan, wat ga ik vandaag doen en waar loop ik tegen aan?”
Op eerste gezicht is dit een valide stelling, totdat je hem moet beantwoorden:
- Wat is elke dag, als je op vrijdag allemaal thuis werkt?
- Wat als je als team betere versie vragen bedacht hebt dan de bekende drie? Is het dan fout? Zie hier een interessant blog van Emiel Romein hierover.
De interpretatie van goed en fout kan tot verschillende antwoorden voeren. Hierdoor kunnen teams die ver gevorderd zijn in Agile juist lager scoren dan teams recent gestart zijn.
Buiten de interpretatie is er ook het gevaar, dat de teams het assessment bewust zo invullen dat ze beter scoren dan de vorige keer. Ze zijn dus niet bezig om zichzelf te verbeteren, maar meer om hun score te verhogen.
Kunnen teams van elkaar leren?
Het valt mij regelmatig op, dat veel mensen die lang in een hiërarchisch ingestelde organisatie werken, terughoudend zijn met het delen van informatie. Dit is het gevolg van het feit dat ze daar vroeger op afgerekend werden. Lessons learned kunnen terugkomen op je beoordeling als kritiekpunt in plaats van dat het gebruikt wordt om te verbeteren.
Het vergelijken van teams middels een assessment zou in mijn opinie altijd moeten gebeuren tussen die teams. Zodat die teams zelf verbeterpunten kunnen vaststellen voordat iemand anders hiernaar gekeken heeft.
Conclusie
Als we teams echt agile willen laten werken, moeten we ze ook de ruimte geven om de activiteiten te doen die nodig zijn om agile te worden. Mijn suggestie is dan ook: doe assessments, maar gebruik ze om teams te laten groeien en laat dat groeien aan de teams over. Of beter: laat de teams de assessments doen en laat ze zelf aangeven wat ze met de uitkomsten doen.
Alex Roos, Agile coach/DevOps Consultant
