For higher productivity should we go even smaller?
"If a project team can eat more than two pizzas, it's too large." This is a quote from Werner Vogels, the Chief Technology Officer and Vice-President at Amazon discussing his approach to running Amazon's software development operation.
There is something to be said about breaking up a big problem into smaller ones and then having small and focused teams resolve one small problem at a time. Agile has embraced this aspect and time and time again we have experienced how small teams are dramatically more efficient than large teams.
The oft cited "truism" is that Agile teams should have 7 people plus or minus 2. Perhaps it is time to review this. The more time we spend looking into team size and productivity at our current companies as well as evaluating the best practices from other large companies such as Google, NOKIA or Amazon the more we see a definite pattern of smaller teams (max 4-5 people) being the more productive.
Like the normal sized Agile teams (7 +/- 2), these smaller teams of 4-5 are responsible for designing, building, implementing and eventually fixing the software they build.
There are some particular characteristics that we have noticed that are distinct from the normal sized Agile team such as:
- No one on these small teams is designated as a Scrum Master, developer, or tester. I guess if you want to be lean and maximize productivity you should perform all responsibilities.
- The teams usually don’t religiously follow standard Scrum events and they perform them only as needed. For example, we observed that over 70% of these teams don’t have daily standups because they don’t have a need for one.
- They are much faster to embrace new XP practice and code ownership than a team of 7.
- Jorgen Hesselberg
- Saji Rajasekharan
- Agile Development Editorial
- Matthew House
- Matthew House