How to align HR with Agile?

In my previous post I reviewed Succeeding with Agile by Mike Cohn. In the book Mike talks about if you want agile to stick in a company, it has to go beyond software development. Other departments have to follow, such as the Human Resources department.

At the Belgian Agile Open 2010 last month, the topic came along in an open space, and this week I listened to a podcast on Interviewing software developers by the guys from Herding Code.

To make things clear, I’m not in the HR business, I don’t even know the business, but just want to blog about 4 things I learned on combining Agile with HR. So here we go…

1. Beware off individual performance reviews & incentives

Individual performance reviews are not agile at all. Problem with them is that they don’t support the mindset of teamwork. Why should a senior developer help out a junior developer who slows him down? A far better approach is to reward teams with incentives when they continuously accomplish goals that they have committed to.

2. Pair-programming is a great way of recruiting developers

Probably the best way to hire good and motivated developers for a company is to pair-program with them. Along the way you find out if the candidate is a team player, if he/she likes to work with us, if he/she likes to work in our code, if he/she is willing to work out of their comfort zone, how he/she solves problems,… and you get a grasp of their technical skill level. Another idea that came across is to have someone observing this pair-programming session.

3. Certificates are useless for software developers

Did it ever happen to you that you had a candidate with an MCSD (or whatever certificate), who could explain all things very well and with great technical detail, but when he/she was hired, couldn’t crank out a single line of code? Listen to the podcast, you’ll be amazed :-). I learned that a certificate proves that you have theoretical knowledge, but that it does not mean that you can apply it. So which developer do you want to hire? The one that can write code, or the one who can explain how to write code?

4. Shorter feedback loops than once a year!

Getting feedback once a year is not agile. In software development we make hard work of shortening the feedback loops, and with that feedback we build better products. Why should this not apply to HR to 'build' better employees?