Many team leaders live with a belief that multiplying the number of people by average utilization (or performance) results in the team’s capacity. The software world is not so simple and with its complexity, this way of thinking rather builds big teams that don’t deliver much value and makes the management harder.

This all leads to thinking that the organization should always improve or increase the utilization or hire more people – which is less effective, increases costs and brings more stress because of extreme focus on wrong metrics.

However, metrics are important, builds predictability, and are somehow the reference for the current situation there is also the business value that the team delivers. All numbers helps to make the decisions better, but what if the team works extremely hard with full of commitment but does deliver value for the company, its clients, or users? This way doesn’t make sense, and the right balance is the key.

What you can do to increase the capacity of software development?

  • Obvious: hire more people  
  • Less obvious: augment a new team 
  • Less obvious: focus on more important tasks 
  • Not obvious: outsource just some tasks  
  • Not obvious: improve deployment process  
  • Less obvious: prepare better staging environment 
  • Not obvious: improve QA processes and data  
  • Less obvious: implement continuous delivery 
  • Less obvious: introduce separated DevOps role 
  • Less obvious: make longer retrospective with team 

Ask yourself where is the real bottleneck and cause of the challenges you have now? Maybe it’s because of the lack of tools and skills within the team or communication between people sucks? Focus on the process and people first, and then go to the numbers to validate and prepare the proper plan.

Reduce the cost of the development team

The typical costs of the development team are related to the recruitment process, payroll, hardware and licenses, of course the office space, sick leaves, holidays and perks.

Define better the requirement

People will spend less time on discussions, meetings and evaluation of tasks when you will define them well. It doesn’t mean you have to dive into the code, functions and methods and describe how to develop something you need. Once you define the user’s needs, describe the expected behavior and flow, discuss and keep in mind your technology limitations and describe the business value and how you will accept the work, this will help a lot!

Involve QA as soon as possible and manage test data  

Why you should focus on QA and why it’s important? Because developers don’t focus 50% of their time on feedback and bug fixing if the code is tested well. They can then develop the new code and solve new tasks.

Define the most important test cases along with the test data (the input that you use to say it works). There is no one the best QA process because there is not just one development process. Find the sweet spot and moment when would be the best to test resolved tasks.

You can create the column on your board as “QA”, and before or after deploying to the staging server provide functional testing. Having the Continuous Integration (e.g. Jenkins) optimized well will allow you to make automated and unit tests quickly after the merge or commit to the branch. Very often we use many staging servers in the office, before deploying to a staging server on the production environment.

Prioritize and plan right features and focus on value  

Lack of proper planning and frequent changes in the roadmap (pivots) makes the development harder because developers works on assumptions you provide. Every architecture and database can be changed, of course, but the question is the amount of work, which rises exponentially with the complexity of your solution.

Even if there is 463 of your product backlog items and all of them are extremely important, you can use MoSCoW method to prioritize the work:

  1. Must have
  2. Should have
  3. Could have
  4. Won’t have (this time)

No matter how self-organized the team can be, they will deliver the work defined and prioritized by the Product Owner (or Project Manager, whatever name we’ll use). Even if you have to cut the budget quickly, think about the overall spending and what business value you will get. Delivering important features that brings money in a short amount of time, might be worth to spend now, or even increase the team to shorten the delivery time in order to build the revenue and benefit from these features quicker.

Outsource the work 

Hire the augmented team to reduce recruitment costs and all office-related spendings. Contracts are very often flexible and allow to change the team composition by the time, and so you can reduce team when there is not much work while having the ability to increase quickly when it’s needed.

Other benefits of team augmentation are that you don’t need to spend days on interviews, but once you find the right development partner and share the expectations you can easily rely on their experience with the team members or even expect more responsibility on the delivery in case you go for project-based approach sometime.

With project-based approach, the idea for outsourcing not the whole development but just part of the work, also is a good idea when you have:


Lack of skills or knowledge on you end. In that case augmented team can bring value to architecture design, tasks where your team is struggling.


Small and simple tasks that someone else can do, while your team focus on what’s the most important for your organization and solution.

Remote work?

It’s popular now to reduce office space even by 100% and let people work from home. There is also an expectation they will be extremely happy to keep or increase productivity.

It might work, but before making such moves reevaluate pros and cons from not having people on a daily basis in the office. It’s not about controlling what they do, rather about communication. The main concerns are of course the connection issues. Imagine 10 people on Teams trying to say something having poor internet connection and issues with remote collaboration tools. Before you start with remote approach even for a small part of the team, set objectives related to communication routines, devices and solve them.

Focus on business growth instead of micro management

Having the operations or technology role very often means that you need to step into the process and take more control. Even if you have the person who is in charge doesn’t help you – in fact, this might the reason why you have to step in periodically.

It’s especially hard when the people are with the company for many years, and does not follow the changing environment and growing scale. Very often does not develop the right skills, doesn’t have tools or simply just feels very comfortable in their position.

How to start?

You might think about augmenting the development team to outsource the work or increase the team’s capacity. The good model is to have the integrated nearshore team facilitated by the person on the vendor’s end. In case you don’t have the product owner or project manager expected to manage the team on a daily basis, it may allow your people to focus more on the product development.

We see that many organizations are on a different level of implementation of an agile way of work. To start well, it is good to implement well-designed onboarding process. All parties should be aligned not only with the expectations but also the right measurements (e.g. team performance, velocity, capacity, etc.), the right process, and communication routines (e.g. daily meetings, planning) from the beginning.