My colleague Josh Anderson and I were chatting on the Meta-Cast the other day about agile team sizes. While there are no prescriptive limits or guidelines to agile team size, there are general guidelines.
From Scrum, the size has always been recommended to b 7 +/- 2 (or 3..9 in the latest Scrum Guide) as the preferred size for teams. But as in all things agile, direct experience is always valuable. So what was ours?
Too Big
The answer seems to be somewhere around 10+ people.
Josh and I talked about 13 being a magic number at Teradata. That aligns with my experience too.
Josh had team ~ 13 team members. One of the primary reasons he shared for that was cross-team dependencies.
Too Small
Josh didn’t really have a lot of experience with extremely small teams. I have had some. I’ve encountered teams of 3-4 and always found them to be somewhat unbalanced from a pure mass perspective. There usually aren’t enough team members to effectively pair, collaborate, or review each other’s work.
2-3-4 seems odd to me. I think 4 is the smallest “team” that works in my experience. And I’m not including the PO and SM in this…
Just Right
Josh feels ~7 people, I feel ~6 people are the right size for an agile team. I think we both base this on direct experience, where teams of this size simply seem to work best together.
I always get asked; does this include the Product Owner and ScrumMaster? At least in my case, the answer is no. These are the equivalent numbers for what the Scrum Guide refers to at the “development team”.
Here’s a related snippet from one of my recent Blog posts –
http://rgalen.com/agile-training-news/2015/5/24/the-newest-craze-in-agile-simplicity-and-un-scaling
This comes from my own personal experience. During 2007 – 2009 I worked as an agile coach and leader at a company called ChannelAdvisor here in Raleigh, North Carolina. As with iContact, ChannelAdvisor was an agile shop (Scrum) and they built a SaaS application suite for eCommerce customers.
We had a large Scrum team that was focused on developing web search application extensions for our platform. The company was growing and we were of the habit to grow our Scrum teams rather large before we would split them into two smaller teams. Our search team was approximately 12 in size.
A business priority change happened that caused us to split the search team in two – essentially making two Scrum teams of six members each. One continued to develop the search application and the other was redirected to another component area.
What’s interesting about the story is that the search teams’ velocity didn’t change after we split them. They were averaging 25 points per sprint before the split and 24 points per sprint after the split.
I know what you’re thinking…that’s impossible. Well, no, this really happened. So what was going on here?
Simply put, the smaller team was more efficient in delivering software. There were fewer communications channels, less hand-offs, more collaboration, and a better focus on their goals. To the point that they were
The Lesson: Try to solve your problems with as small a team as possible. Let them form and mature and achieve a steady velocity. Then “feed them” a prioritized backlog. You may just be surprised at how much they can get done IF you get out of their way.
Wrapping up
I think the key point I’m trying to make is that there is usually a “sweet spot” when it comes to the size of your agile teams. But to some degree, you need to discover this on your own.
In general, I believe smaller is better than bigger.
So here’s to you discovering your own “Just Right”.
Stay agile my friends,
Bob.