It’s widely recognised that adding people to a team often doesn’t result in increases in velocity and can even reduce the velocity of the team due to the extra communication overhead. Instead, teams look to increasing levels of automation and tools to improve their productivity without adding extra people.

Where many teams struggle however is in finding the right balance of building out the product versus “sharpening the saw” by improving their tools and automating processes. With the same people attempting to do both jobs that contention is unavoidable.

The solution then is to build a second team who’s job is entirely focussed on building, maintaining, configuring and improving the tools that the product team uses. Since the majority of tools used by a project are fairly orthogonal to the project itself – and often shared with other product teams – the tool team can be much more independent, reducing the communication overhead. Not only do the product team now have more time to devote to improving the product, they are continuously made more productive because of the work done by the tools team.

The most common argument against having a separate team devoted to tools is that the people building the actual product are in the best position to know what tools will make them work better and exactly how those tools should work. While this is certainly true, agile development methods are explicitly designed to help one team efficiently deliver solutions to other people’s problems. The customer for the tools team is the product team – and they already have a common understanding of software development and speak roughly the same language.

This certainly isn’t a new idea – Fred Brooks suggests it in The Mythical Man Month – and it’s used in many large companies but many small teams have a hard time switching over to this level of thinking, unable to really believe that adding people to the product team may make it go slower and that the same number of people could do significantly more if they had better tools. The time to create a dedicated tools team is significantly earlier in a team’s growth than most people initially think.