This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
The Team That Said No to KPIs
If you’ve been following the work of behavioral economists and authors such as Dan Pink, or you’ve read my article What Your HR Department Doesn’t Know About Scrum, you already know that truely Agile organizations have abandoned last-century’s habit of treating employees as rats in a B.F. Skinner box with conditional punishments and conditional rewards, particularly tied to “Key Performance Indicators” (KPIs). Scrum requires self organizing teams to expose organizational impediments. The toughest part of a Scrum Master‘s job is resolving these organizational impediments, or at least mitigating their impact on the team.
Today I read an example of that happening with no resistance from the outer organization:
Thanks very much for your message.
I did not blog about this, because my blog is still under construction.
We are a software company employing about 50 people.
A few years ago, our CEO introduced a company wide bonus system, based on 5 KPI’s. The KPI’s were different for every department, to be determined by the manager of the departments, like Direct Sales, Helpdesk, Development.
I told the CEO that, as a Scrum Master (and manager of the Development department), I could not decide on these KPI’s myself (nor did I want to), so I “took it to the team”, to coin a popular (and rightly so!) Agile phrase.
We discussed it in multiple sessions (I did not “lead” these sessions, nor did I put my view across, I just asked questions), but the team kept coming to the same conclusion: Any KPI we could come up with, either infringed on the Scrum principles, or deferred the team from the continuous improvement principle.
And believe me, we brainstormed about a lot of possibilities: Number of story points gotten credit for per sprint, number of iterations per story or task, newly reported bugs per sprint, even lines (and characters) of code.
Our bottom line was, that it just doesn’t sound right, quantifying performance on any other criteria than working software. And, adult and intelligent as we obviously are (I mean, we’re Development, right?), there will still always be this “hidden agenda” in the back of one’s mind, that makes one, for example, report two defects in one bug, or write a routine differently, to make it larger, in order to positively influence the KPI’s. It’s all unwanted distractions, in the end.
So ultimately, we unanimously decided to kindly refuse the offer. Much to the surprise of the rest of the company, including management. Priceless to see the look on their faces. Funnily enough, no-one asked us to explain why. I reported it to the CEO, and he understood. He’s into Agile. Thank God.
Up to this day, we still don’t participate in the bonus system.
I’ve used this example on a few occasions myself, because it’s very illustrative.
You’re absolutely welcome to share it with other people, if it contributes to spreading the word.
[name omitted pending permission to identify]
I hope the example helps illustrate that teams do not need to tolerate counterproductive management practices. We do these things out of habit and fear, but people who love their work are driven by something else — and why would you hire the other sort? Esther Derby recently tweeted she’d never heard of anyone being fired for declining to participate in performance appraisals. I haven’t either.