How do I compare individual performance in an agile world?

This is a question I am often asked by organisations in the early stages of the transition to agile processes. The question usually stems from the ingrained command and control mindset, and the real question is How do I know who to blame when it all goes wrong?

Firstly lets assume its not all going to go wrong.

Scrum is all about building high performance teams which are self regulating. Software development is a team activity so this makes perfect sense. One of the things we learn is to do the things that help meet our objective (i.e. deliver working software) and to stop doing the things that don’t contribute to this.

As soon as you introduce the concept of individual performance measurement you introduce conflict within the team. On the one hand we have the interests of the team, and on the other we have personal interests which lead to the following types of question:

• How can I make sure I look good?
• What do I need to do to get a promotion?
• How do I avoid getting fired / disciplined (etc)?
• How do I ensure that I get a good increase / bonus?

This immediately leads to dysfunctional behaviour.

• Developers may consistently inflate time estimates (I’ll look good if I always finish early)
• Everyone will tell everyone else how difficult and time consuming their current activity is (Make sure they recognise how important I am)
• People will spend a lot of time blaming others for failure or predicting failure because of the way that others work (If they are looking for someone to blame; I’d better make sure its not me)
• People will simply do the wrong thing (It’s not the highest priority but feature x is really important to my boss – although he has nothing to do with this project he is performing my appraisal and I’ll get a better score that way)

And the most important question may be completely forgotten:

What does my team need me to do!

We have to trust, and if necessary ensure, that the team is self regulating and continuously strives to inspect and adapt. If anyone in the team is not pulling their weight this will be uncovered and will be uncomfortable for those in question. Hopefully the reasons for the underperformance can be resolved if they are related to things such as lack of training or resources. These are barriers and it is the Scrum Master’s job to remove barriers. Scrum is uncomfortable for genuine slackers because there is nowhere to hide. These people will either change their attitude or move to another organisation where they can hide. Of course you should work with these people to address the problems, but unfortunately this is not always successful and there may be casualties along the way.