Cheating isn’t bad, targets are bad!
You are probably cheating, somewhere in your life you are cheating. Some of this cheating is the good kind, and some isn’t. What’s interesting is it’s mostly driven by one thing. Targets.
Bear with me, this does have relevance to Agile, eventually.
Throughout all walks of life we’re beset with targets, and it never stops. What are examples of targets?
- Pass marks in school and university exams. (Don’t start me off on the evils of batching children by age instead of ability).
- Commission targets for sales people.
- Quarterly financial targets for companies.
- Rigid deadlines for IT projects
All these are targets, and all these are subject to cheating. Chances are you know someone that has tried to cheat an exam? Sales people frequently close a sale knowing it’ll get cancelled to hit commission targets, because it’s the ‘sale’ that gets counted. Creative accounting to report not entirely accurate financial statuses of companies. IT projects that release poor quality software that doesn’t really provide the service the users need.
Why? We cheat because of the target. You could argue that this is because of a cognitive bias towards self deception, and you’d be partly right. We have that bias, because of the target.
Self deception bias is defined a process of denying or rationalizing away the relevance, significance, or importance of opposing evidence and logical argument (thank you Wikipedia). In our examples this might be “Everyone cheats on their exams, so it’s OK”, or “We are not counting the expenditure on xyz this quarter because…” or “Our project was a complete success, our users are happy and got what they asked for, we delivered on time”. This bias is only there because there is a target. Often they can be perceived as (or actually are) arbitrary and therefore not really ‘relevant, important or significant’.
As a culture we’re obsessed with targets and measuring. NHS waiting lists, speed limits, service level agreements, you name it there is probably a target.
In Agile software development, the most often debated target is ‘velocity’. I was contact by a friend last week that had been urged the get the team from 24 story points to 25. There was no real rationale for it, just the desire to beat the drum a little harder, whip the slaves and get up to ramming speed.
I won’t divulge his answer, suffice to say he gave the right one. Velocity isn’t something that should be used as a target. If someone in your project or company is using velocity as a target then the team will develop the cognitive bias for self deception. They’ll subvert the working practices to achieve the target and make the individual happy. This could take the form of simply inflating the estimations to satisfy the target, much worse would be a less diligent approach to the quality of the product. You get more software, faster, but at much reduced quality. Systems thinking tells us that poor quality causes rework and production costs increase. Still that guy that wanted to go faster is happy right?