Home > Agile > stupidity of the team

stupidity of the team

I’ve just completed reading Wisdom of the crowd. It was not what I had expected, since the context within which I was given this book lead me to believe that it would cover something completely different. But this is not a bad thing – the area which the book covered is much more interesting than the area which I thought it would cover.

If you’ve read the book, my posts on the content will be old news but here goes. The book is about how the minds of many can produce better answers to questions than single expert brains. The average solution of a diverse and heterogeneous group can in many cases be closer to reality than one expert. Of course this is not always the case and single experts can of course outsmart the crowd, but this is absolutely not always the case.

But before I tap into those stories, I will first cover the stupidity of the team. Working with agile values and team work, this was a very interesting chapter.

Surowiecki sees great risks in team intelligence. What his research shows that a team often tend becoming more stupid than the individuals. Not 1+1=3 but rather 1+1+1+1=2

So, which teams are in the risk zone for building team stupidy?

According to Surowiecki, the small, closely knit homogeneous team tend to build team stupidy. 

But why?

In small, homogeneous groups, like minded ideas are welcomed and appreciated. The reward for agreeing with the others is high. You build team spirit and a sense of security about a solution. The person who oppose the idea is a trouble maker and is wrong since everyone else seem to agree. The opposer easily become an outcast and can select between leaving the group, staying an outcast or applying group ideas.

So what happens with that scrum team, where all the developers are of the roughly the same age, have worked together for many years, have the same education, read the same blog posts and have built a system together? They tend to create inside the box ideas.

But of course this does not apply to just software developers. We have committees, steering group and management teams. I've earlier explained that when I'm evaluating a supplier, I look at the Hiring section to learn more about the company. I will from now on also look at the Board of Directors listing. If the members seem to have been casted in the same form, I guess diversity is not a high priority and conformity is valued higher than collective intelligence.

So, how will this affect me? I will actively seek steering groups which are diverse. Of course they should all have the qualifications but I've added a new qualification and that is to be as unsimilar to the others as possible. I will work with the developers to make them not only discuss ideas in their normal comfort groups but also discuss ideas with other developers. This is one of the great things about working with a big development department. There are lots of guys (and some gals too…) so you're not always stuck with the same setup all the time.

I will also try to read blog posts, books and articles by people who have the opposite viewpoint of my own. Why should I read something that I already think? Why not read something that opposes my ideas instead? I might change my mind.

And that is perhaps too many turn to group stupidity instead of the collective intelligence. The risk for changing your mind is too great.

Posted via email from forss’s posterous

Categories: Agile
  1. 2012/06/30 at 5:53 pm

    I like your writeup. I see many parallels between your description of “team stupidity” and what was exposed by both the Climategate 1.0 email leak and the Climategate 2.0 email leak. Ready the leaked emails, it rapidly becomes obvious that the man-made global warming catastrophe alarmists were demonstrably suffering from “team stupidity”. The parallels are remarkable.

    • Anna Forss
      2012/09/14 at 12:39 pm

      Hi!
      I’m glad to hear that.

  1. No trackbacks yet.

Leave a comment