InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Agile 2008: The Wisdom of Crowds and Agile Teams

Posted by Amr Elssamadisy on Aug 06, 2008

Sections
Process & Practices
Topics
Teamwork ,
Agile
Tags
agile2008

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:

  1. The group must be able to aggregate the individual's opinion - and not just vote for the best solution.
  2. The members of the group must act independently to avoid groupthink.
  3. 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?

  • This article is part of a featured topic series on Agile
age old wisdom by info quack Posted
Does that invalidate the wisdom of crowds for small development teams? by pejvan beigui Posted
Off by 8% by Deborah Hartmann Posted
  1. Back to top

    age old wisdom

    by info quack

    To many cooks spoil the broth?

  2. Back to top

    Does that invalidate the wisdom of crowds for small development teams?

    by pejvan beigui

    No.
    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.

  3. Back to top

    Off by 8%

    by Deborah Hartmann

    I was surprised that the group was off by so little, when my own guess was off by ... well, let's just say I had the wrong number of digits in my figure.

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.