Stay Connected:

TwitterLinkedin

For higher productivity should we go even smaller?

    
 About
 Contributions   
 Follow
 Send Message

"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.
Perhaps it is time to change the Agile "truism" of the recommended team size to 5 +/-2? It seems to me that as an Agile team matures, they should also pare down the number of people on the team and let them demonstrate just how fast a small team can go!

Comments   

 
lonely developer 2013-01-29
Yes, the place I work from could take a lesson or two from this... For over 5 years I worked for a small company in a small team. Now I'm working for a large multinational company in a very large organizational.
I miss the ownership and coordination we had in the small team. I miss the focus and highly targeted approach to software development even more. While I do admit that the code I’m dealing with now can be considered better in detail, I think we managed to do a better design in the small team, and to respond faster and better to changed requirements.
Reply
 
 
Mike 2013-01-29
I’ll happily accept what’s been said when I can be assured that what the small teams delivered was flexible enough to cover development, testing and deployment.
Reply
 
 
Isack 2013-02-01
That’s interesting. Also in my experience small teams have generally been more flexible.
Reply
 
 
Jeff C 2013-02-01
I believe the perfect size of the team depends on people and goal you plan to achieve. While your points are valid it doesn't automatically mean the best team size is always 5.
Reply
 
 
Stephanie B. 2013-02-06
That's quite true. We also believe in creating a small agile teams where the product owner is an integral member.
Reply
 
 
Rudolf 2013-02-13
You made some decent points there. Tasks than can't be handled by a group of four or five are probably too complex and should be broken down further.
Reply
 
 
Mark 2013-02-13
My personal experience with teams is to go no more than 7 and, if possible, keeping it an odd number — ultimate being 5 or 7.

Keeping it odd, in my experience, makes it impossible to be evenly divided on an issue
Reply
 
© 2024 Agile Development