May 8, 2013

Democracy and Agile

It was a dark and stormy night, and a friend was giving me a ride home. I was sitting in the back seat as his wife was telling us that she had joined a political party. "Isn't democracy wonderful", she ended. I hesitated for a brief second, then shot back: "Democracy is shit!"

That was the starting point of a vigorous debate on the pros and cons of democracy. She was getting more and more agitated, miserably failing to deflect my arguments, or making her own arguments stand. After a while my friend started to laugh, and, knowing me, revealed that I was just playing the devil's advocate.

And I was, but democracy* has its limitations, and should be used with caution outside the realm of politics.

In an agile team there is little room for democracy. You decide what is right on your own, and if the decision proves controversial, or if you feel you need input, you come to some kind of consensus after a discussion within the team.

What if the team simply can't agree on the best way forward? Then the team has failed. If it's a rare occasion, accept defeat, have a vote (or not), make a decision, then move on.

A team that often fails to agree on important issues, isn't working very well, and democracy is probably not going to save it.

Planning poker might look like democracy, but it isn't. Planning poker voting is part of a process to get consensus around what a task means, and how difficult a task it is. Time estimation has been shown to be detrimental in its own right, but that has nothing to do with democracy. (And estimation may be necessary, despite the drawbacks.)




* For this post I'll define democracy as the process of voting about something, with the majority deciding the outcome.