“The Ringelmann effect is the tendency for individual members of a group to become increasingly less productive as the size of their group increases. This effect, discovered by French agricultural engineer Maximilien Ringelmann (1861–1931), illustrates the inverse relationship that exists between the size of a group and the magnitude of group members’ individual contribution to the completion of a task. While studying the relationship between process loss (i.e., reductions in performance effectiveness or efficiency) and group productivity, Ringelmann (1913) found that having group members work together on a task (e.g., pulling a rope) actually results in significantly less effort than when individual members are acting alone. Furthermore, Ringelmann discovered that as more and more people are added to a group, the group often becomes increasingly inefficient, ultimately violating the notion that group effort and team participation reliably leads to increased effort on behalf of the members.”
Have you ever noticed what amazing things a small, tight-knit OSS implementation or design team can achieve? Conversely have you ever noticed how ineffective large OSS teams can be? Apparently it’s the Ringelmann Effect.
Thinking about it in conjunction with Jason Fried’s 2 week project theory perhaps the best way to tackle large projects is to actually break them into a series (or a parallel?) of tiny projects with small teams contributing?
Given my penchant for breaking down projects using WBS, I can see the merits of the Ringelmann / Fried approach. The one slight problem is that all roads lead back to the database.
The real data in the database provides the necessary context for trainers, testers, developers, business analysts, etc. The team building the initial data set becomes the critical factor for all other sub-projects.
There’s no doubt that a data build is also suited to task breakdowns, but the trick is determining which elements of the data set will allow other teams to proceed.
For example, if the data team is able to build a working model of a customer’s outside plant network with real data (ie objects, naming conventions, topologies, etc), then the testers can perform their testing of outside plant management modules.
In most cases, you don’t want all your other teams to be waiting for the data team to complete their full data load of all objects and data before they can move forward.
The Ringelmann / Fried Effect is a delicate balance.