Why Smaller Quality Teams Matter

There is a misconception that the more people you have working on a project, the faster it will move off the ground. However, more isn’t always better and there is a point of no-impact and diminishing returns once a team reaches a certain size.

Why quality matters

When a project’s budget is focused on the quantity of developers rather than quality, the long term value and stability of the software is often impacted in an inverse manner. The project’s final delivery is only as good as the developers behind the code. 

Quantity does not equate to, nor does it guarantee quality as there are different calibers of developers available. An effective developer can often accomplish a coding task in a third of the time and at a higher standard than a sup-par developer who may appear initially cheaper by the hour. Cost effectiveness of your investment often materializes in the form of good and solid software rather than what you originally spent. The stability of the code produced also determines the long term costs, maintenance and price of future extensions and upgrades. 

Smaller teams makes better agile teams

When it comes to software and agile delivery, sprints are most effective when the amount of communication required is reduced. A small core team of developers is much better and easier to coordinate than large teams with varying levels of skill. With smaller teams, quality assurance across the code base becomes a much simpler task. When less people are working on the same code, the amount of potential code conflicts is often significantly reduced. Errors and misunderstanding is minimized as smaller teams are much better at communicating with one another. 

For an efficient and high quality piece of software, everyone working on the project needs to keep in sync. When there are more people on the team, each team member ends up spending more time working on communication rather than actual work, resulting in reduced overall output. If communication is not maintained, delays often occur as code bottlenecks and misinterpretations arises. This is known as the Ringelmann Effect - where the productivity of individual members reduces significantly as the size of the group increases, resulting in less value for the total money spent. 

Bigger isn’t always better

According to a study done by QSM, the difference between projects with approximately 10,000 lines of equivalent source code for large and small teams is barely a week, with large teams averaging 32 developers and small teams being 4 people. Not only that, the defect rate for large teams was five times greater than small teams. Code defects and bugs are unavoidable and it requires time for the discovery process, documentation and fixing. This often results in unnecessary inflated costs financially and the project’s schedule delivery. 

For faster and leaner development, more people in a team often results in the opposite effect. 

When it comes to an agile no-shore or non-inhouse approach, a small team of 8 people is easier to pivot than a large group of 40 developers across multiple time-zones. Smaller teams often result in simpler processes with less cross-team dependencies. While code management tools like Git and methodologies like agile don’t specify team size, smaller teams are most effective for these tools due to its nature to streamline and simplify. 

--

While the idea of increasing manpower to increase output works well in most manufacturing scenarios, your software and infrastructure is much more complex than well defined processes that can be replicated mechanically. Creating software is the process of transforming business requirements into tangible digital products. 

More minds working on the task doesn’t necessarily guarantee that the project’s velocity will increase. Creating a strong team of developers who are able to effectively communicate with each other is a better way of coding software that is able to perform and support your business. 

Co-authored by:

Dave Wesley ~ President, SRG
LinkedIn

Aphinya Dechalert ~ Marketing Communications, SRG
LinkedIn