Agile 2008: The Wisdom of Crowds and Agile Teams
James Surowiecki, author of the Wisdom of Crowds, gave the keynote speech that opened Agile 2008 on Tuesday, August 5. The thesis behind the wisdom of crowds is simple: given the right circumstances, a group of people can make a decision that is better than the best answer of most (if not all) of the group's members.
To kick the lecture off, Surowiecki presented the results of an experiment conducted with the Agile 2008 participants. As we each signed in, we were asked to guess the number of lines of code in Microsoft's Visual Studio. The group answer was around 47 million lines of code. The actual lines of code in Visual studio is a little over 43 million lines of code! Of the entire group - there are approximately 1600 attendees (although not everyone filled out the survey) - only two people came up with an answer better than the group's answer. Throughout the lecture he presented stories that illustrated the success of this theory.
Then Surowiecki discussed the necessary constraints for a group of people to be smart and they were:
- The group must be able to aggregate the individual's opinion - and not just vote for the best solution.
- The members of the group must act independently to avoid groupthink.
- The group must be diverse.
Many of the attendees left the lecture pondering this new information and how it might possibly help them form smarter teams. One attendee told this reporter how this theory shed light on his particular situation: he has a team of top experts - an all-star development team - and yet they have been making some really bad decisions. In applying the constraints for a smart group - his team fails the diversity constraint.
Finally, noticeably missing from the lecture was Surowiecki's fourth constraint (found in the book): the team size must be large. Does that invalidate the wisdom of crowds for small development teams?
Does that invalidate the wisdom of crowds for small development teams?
If large groups of people can come up with better "guesses", you have to put up with lots of drawbacks and cons that come with such a large group:
- management gets difficult.
- lots of frictions and inefficiency get introduced on the non technical sides.
- the less skilled people tend to slow down the more skilled ones.
I read his book which is a great read and teaches many interesting things, but AFAIR, it has mostly to do with guesses and one-offs, while developments teams work together on the mid- and long-term.
I am not sure I am right about this though. I would just assume that people with different background bring value to the team, but they must all be very skilled, have the will get even more in depths, have the will to achieve something great. Answering a single question doesn't tell a lot about these requirements.