A couple of years ago Amazon Announced Job Descriptions for their Two-Pizza-Teams. Amazon had figured out a simple rule for staffing their teams which limited the task force at Amazon to five-to-seven-people-per-team, depending on their appetites and turned Amazon into a very healthy company. The rule for staffing a team at amazon was simple - "If you can't feed a team with two pizzas, it's too large."
This is one simple rule tons of so-called-huge software development body shops around the world and the so-called-managers who work for these body shops just don’t get it, even today, almost two years after Amazon proved to the world that it works.
I recently interviewed a manager who worked in a huge Indian body shop who claimed during the interview that he had - "managed a project with fifty resources" - directly reporting to him on a day to day basis. Apparently, it seemed like he had managed many other similar projects in the past and as usual was having a hard time taking this thing to production. He specialized in what I call - going round and round the infinite loop of failure - which is why he was looking for a change.
On the other hand, at work, we had a project with many similar and additional complexities which was blossoming it's way to success and was being run by a self managing team of five to seven really smart individuals.
So, why is it that when a team of fifty bodies in a body shop was struggling at a project and failing pathetically, one or two small teams of three to five programmers were executing much bigger and complex projects flawlessly?
For a shorter answer - smaller self-managing teams of shameless developers and one man armies are much better and much more efficient than huge teams of mediocre bodies who are purely interested winning a war against the client and not shipping genuine value.
I’m not an authority in the craft of building software, but, just for the sake of saving your time, based on my past projects, experience and lessons, you can take my word for it. On the other hand, If you have time to kill, and seek a more logical answer based on data and would rather not just take my word on this one, read on.
Years after Frederick Brooks broke out the fact that adding manpower to a late software project makes it later in Mythical Man-Month, huge body shops, and so-called-managers around the world found another silver bullet.
Add More Manpower to a Project right from the very start! (Especially if you have an outsourcing body shop in India and thousands of relatively cheap developers sitting on the bench.)
This rule is perfect. In-genius! But it has just one problem – it does not work.
Nine women getting together cannot speed up the process of creating a baby. Whether they are involved from the very start or towards the end does not matter.
Doug Putnam does an excellent objective analysis on how teams work and which teams sizes work best in most medium scale project development scenarios. His Research (graphs borrowed from his web-site) seems to suggest that smaller teams are better:
After presenting his analysis on over 491 projects Doug sums up his finding:
| The goal of our research was to find optimum team size for building medium sized information systems. From the 491 projects that were analyzed we would conclude that a 3-7 person team has the best performance (3-5 would be the best, but 5-7 people is a very close second). |
He concludes with words of wisdom which almost sound like a warning to the careful listener:
| Next time you are planning a project think hard about the optimum staffing levels because it can clearly have a significant impact on the overall results. This study gives you some insights into an application and size domain where many systems are being built today. |
While concluding the article he also goes ahead to describe why smaller teams work better. Go ahead, click the link and give the article the read that it definitely deserves.
Now pause a while dear reader and think about the virtues of divide and conquer. While Dough talks about 3 to 7 person teams for medium sized projects ask yourself if you can break up your bigger projects into smaller sub-projects. If you think hard enough, much like Google and Amazon does, inevitably the answer would be yes.
Every now and then I meet budding managers who take pride in mentioning the number of people who report to them. Every now and then I meet budding developers who take pride in mentioning how big the team size of their current project is. It seems mostly cultural. So if you are working with a group of fifty other developers you must be building something seriously important, right?
Wrong. Based on my own personal experience, with fifty plus bodies of mediocre developers, you could in fact be building a perfect piece of crap that may never see the light of production or is not even fundamentally usable.
If you are a budding developer take pride in what you and your team innovates and ships not in how many bodies your current project team consists of or how many documents you or these bodies are writing. If you are a budding manager / team lead take pride in working with a small group of smart individuals who can maneuver, communicate and innovate rather than large multitudes of clueless programmers who can't program.
Growth is inevitable, specially if you are successful. Besides growing your team in numbers, grow them in ability to work smarter. Make sure you are growing with the right people who are capable of shipping by breaking the infinite loop of failure rather than going round and round in it.
Divide your projects into sub-projects and your team into individual self sustaining teams who can run those sub-projects without any hand-holding. Remember, every class library or DLL in your project can be a individual project by itself, led by a small self sustaining team if needed.
A fifty or hundred developers reporting directly to you is something to worry about, not something to be proud of! What are you waiting for? Go get two pizzas and if you can’t feed everyone who works directly with you, on those two pizzas, maybe it’s time to divide your teams and conquer your projects!
“Divide and rule” is an age old practice in the world software engineering. Hence the concepts like modularization. As a rule of thumb you have smaller teams or a part of the team dedicated to these sub-projects. But the essence is often misunderstood and misinterpreted. It is not only about soulless break down of the big team into smaller ones but also about creating smaller self-function units. Getting the combination (of these self-functioning units) right and having right people filling in right shoes is of utmost important. You must have people who can complement each other, at the same they must jell well as a unit. This ensures both high productivity and efficiency of these small units and in turn success of the project.
It is often easy said than done, but, if you really wanna see your team striking new heights ... Get the combination right.
Comments are closed.