Der er en indbygget spænding mellem agile principper og traditionelle belønningssystemer. Teamet forventes at tage et fælles ansvar for leverancen, mens bonusmodellen ofte måler den enkelte. De to peger i hver sin retning, og folk retter sig efter det der bliver målt.
Hvad der går galt med individuelle mål
Måler man antal løste opgaver per person, sker der noget forudsigeligt. Store opgaver bliver upopulære. Hjælp til en kollega bliver noget man gør efter sit eget arbejde. Den der bruger en dag på at rydde op i teknisk gæld, ser dårligst ud i statistikken, selvom vedkommende sparede alle andre for en uge.
Velocity er endnu værre som belønningsgrundlag. Tallet er teamets eget estimeringsredskab, og bliver det knyttet til penge, holder det op med at være brugbart som planlægningsværktøj. Estimaterne vokser, og ingen siger det højt.
Hold det på teamniveau, og hold det lille
Det der ser ud til at virke, er anerkendelse der rammer hele teamet, kommer sjældent, og ikke er knyttet til et tal. Efter en svær leverance, efter en produktionsfejl der blev håndteret ordentligt, efter en periode med overarbejde ingen bad om.
Formen betyder mindre end man tror, men den skal være til at vælge selv. En belønning teamet selv vælger rammer bedre end en fælles gave besluttet af en leder, fordi et udviklingsteam sjældent har samme smag i noget som helst.
Tre faldgruber
- Regelmæssighed. Sker det hvert kvartal på samme dato, bliver det til løn og mister effekten.
- Konkurrence mellem teams. Så snart to teams sammenlignes, holder de op med at dele viden.
- Manglende begrundelse. En belønning uden en klar grund efterlader folk i tvivl om hvad der egentlig værdsættes.
Spørg teamet
Det enkleste greb er at tage spørgsmålet med i en retrospektive. Folk er som regel meget præcise om, hvad der føles som anerkendelse, og hvad der føles som en ledelsesøvelse. Svaret koster ingenting at få.