The Forces of Destruction

This post came to my mind while reading this post in Sarah‘s blog .It is not my intention to discuss pair programming (or flying a plane) here, but one thing that got my attention was the mention that there is a culture bias towards single programming, more specifically:

…Gladwell has lead me to start believing that there is a cultural bias towards single programming. Take universities for example – you can be expelled for working collaboratively; individual results count, team work in assignments is often discouraged.

And I definitely agree with it. Actually, that is exactly what Deming says in one of his books. According to him, everyone is born with a power of intrinsic motivation, dignity, cooperation, curiosity and joy in learning, but all these characteristics are consumed by the “forces of destruction” that our present style of rewards brings with it, like grades in school, competition between people and payment for individual performance.

And if we analyze it, that is kind of the funny part (not to say sad…): We teach everyone since primary school how not to collaborate with anyone. Students cannot share their knowledge in exams, are always competing for better grades, and when these same persons start they work life, one of the most requested skills is what? working with teams…

But like this isn’t enough, the same companies that hire employees “who can work in teams” still have individual performance reviews, blame cultures, give individual bonuses and promote managers because of the good performances of his subordinates. And when cooperation is not easy, everyone still wonders why is so difficult for people to work collaboratively.

And coming back to the world of agile software development, this doesn’t stop being a reality. It is not unusual to see teams where only the most experienced people are valued, where project managers have an authority position against the rest of the team and less experienced developers don’t have a say when discussing with more experience ones (and here comes pair programming….)

So, if you really want your team to work collaboratively, think about all the times where you are measuring and rewarding them individually, and stop doing it!

  1. Anonymous said:

    Well, I’ll work collaboratively and join the communist love-fest when everyone on the team gets an equal share of the profits. I don’t see why everyone is so enamered with conscription at the hands of industrialists when, in reality, they’re effectively wage slaves.

    In addition to the dreadful proletarian aspect of pairing, XP has its technical downside too. Effectively, XP is engineering-specific Lysenkoism. It works well for transferring skills, but it’s definitely not productive to do it more than half-of-the-time. This is especially true when no one on the team knows how to write the software.

  2. Not entering in the communist love-fest discussion (even because I wouldn’t join it), I definitely disagree with the XP non-productive part.

    I’m not saying that people should pair all the time, but work collaboratively brings huge benefits, in my opinion.

    And when no one on the team knows how to write software, well, than you have much bigger problems that trying to define your methodology.

  3. Nice point, Frank. For me the benefits of Pair Programming are so clear. I try to stimulate people here in Locaweb to do it, but the cultural barrier is huge! It’s been two years I talk about pair programming and still now I see a one-person-per-computer environment. What do you suggest me to do? How can I convince people that collaborating and pairing is better than do it alone? Do you think there’s will be a big change, or things will happen slowly, as long as people change their own beliefs?

%d bloggers like this: