Quick Summary - Why are Agile software development teams intentionally designed to be small? Would two five-member teams function better than a single ten-member team? What’s the determining factor for team size? Why does it matter and when should you add teams?
We present here some common sense guidelines so your eyes don’t glaze over when staffing your project.
8 mins read
January 5, 2021
SmartBear’s 2019 State of Code Review surveyed 1,100 developers in companies of all sizes. Among other things, it shows that the size of the average software development team is shrinking – while also gravitating to 6-10 members, as reflected in their chart below.
Agile itself recommends team sizes of 3 to 9 members and many software engineering managers believe 7 members is the magical sweet spot. This considers that a team has different roles – a project manager, business analyst, designers, developers, QA specialists, perhaps DevOps, and others.
The actual structure and size of a team can vary due to a variety of factors though:
There’s no magical number for team size as project requirements for each software project can vary quite radically. Seven is often considered “ideal” for a variety of reasons, but quite simply for its relative efficiency in defining the number of combinations.
The formula used is: N (N-1) / 2.
With a team of five, there are only 10 possible interaction combinations, while a team of seven increases it to 21. The number of combinations applies to what may be called “organizational overhead.” This weighs on the amount of time that is spent planning work, time and number of emails between team members, meeting and reporting requirements, etc. This also correlates to the Ringelmann effect which generalizes a “tendency for individual members of a group to become increasingly less productive as the size of their group increases.”
While it may seem that managing a ten-member team should only be twice as complex as a five-member team, the formula indicates that it’s actually 5.5 times as complex. A sort of proof-positive of the formula is how the military has come to divide its most basic unit, a squad (8-10 members) into teams of 4-5 members.
The Ringelmann effect insinuates that the solution for a project that is falling behind is not always a matter of adding more team members. It’s very situational. Project complexity is one of several factors that can play a role. Some software applications are very simple (news feed apps) and others are much more complex. Apps like Uber involve 2-3 apps with several modules – for customers, drivers, and administrators.
In Agile software development, the goal is for each individual software component to be as self-contained as possible. For example, the GPS and mapping components of an App like Uber don’t need to be tied to the user history or payments module – though data may be passed between these components. Two or more feature teams can work on different components in parallel – instead of sequentially to accelerate time to market. Feature teams typically don’t need their own BA, QA, or DevOps roles.
A theoretical example of team-size fluctuation over the lifetime of a software project.
Software development has its own stages often correlating to the available budget, particularly for startups. Small-medium-sized businesses and enterprises may not have such rigid constraints allowing them to ramp up and get their product to market faster.
Startups often start by bootstrapping their way to deliver a proof of concept or Minimum Viable Product to show investors. In these early stages, fully functional full-featured software isn’t required. You only need something for show – to illustrate the concept and prove your idea is viable. You can probably get by with a project manager, a few developers, and a designer – bypassing QA, BA, and DevOps. When you receive funding, you can scale up – as always keeping your funding runway in mind. Established businesses will still likely want to follow the MVP approach, but can ramp up the size of their team earlier if desired.
Most of the software development effort takes place before it is released to the public. Once released, it’s likely that you’ll need to keep most of the team in place to fix bugs. Thereafter, the development effort will diminish to just focus on improving performance. This is likely to continue for several years to keep your software commercially competitive. However, team requirements will taper off as it reaches the ends of its viable lifespan.
This simple diagram is helpful in providing a pathway for the development of your project regardless of any limiting factors. Well, within certain limits anyway. If you can only afford one developer, it will just take a long time to complete. Time to market is important though, so it may not be a competitive product by the time you launch it. Conversely, it’s hard to expect having your software developed by tomorrow morning… and if somehow it is, don’t expect for it to work. Using common-sense though, you can work out an optimal combination of cost-time-scope of work (and subsequent quality) to fit any budget.
If you decided to hire a development team in Ukraine or even open an R&D center, this calculator helps you figure out how much it would cost.
For as useful as it is, the team-size formula is at best a guideline. Agile places a lot of emphasis on developing team cross-functionality. The more cross-functional your team is, generally the fewer team members you’ll need. The more experienced and organizationally-skilled your project owner is, the more team members they can effectively handle. However, the more roles your project owner has to fill, the lower their effective maximum team size is likely to be. That’s especially the case if you expect your project owner to double as a coder. Where this role is usually filled by a software engineering manager – most either don’t code or are only minimally involved in coding.
We’ve compared the cost of developers on a regional basis – frequently benchmarking costs versus the US Bureau of Labor’s national average of $107,510. If you’re keeping your office in Silicon Valley, the average wage jumps to $141k! Many of our clients are based in Israel where base wages are just $80k. Factoring in the fully-loaded cost of in-house developers (employees) including office space, taxes, benefits requires adding a 1.25 to 1.40 multiplier.
Straight out of PeceptionBox you can outsource with 2-4 Ukrainian developers for the same cost as 1 in-house developer elsewhere. If you’re in San Francisco, you can have an entire 4 member feature-team for the same cost as a single employee. At the same time, Ukrainian developers have stronger technical skills than most of their international counterparts (rank #5 globally) and have a lower turnover. Their combination of skill and affordability has earned Ukrainian developers an overall #2 ranking on the 2019 Kearney Services Location Index.
