Many team leaders live with the 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 building big teams that do not deliver much value makes management harder.
This leads to thinking that the organization should continually improve, 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, build predictability, and are somehow the reference for the current situation. There is also the business value that the team delivers. All numbers help to make the decisions better, but what if the team works extremely hard with total commitment but does deliver value for the company, its clients, or its users? This does not 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
- Focus on more critical tasks
- Prepare a better staging environment
- Implement continuous delivery
- Introduce separated DevOps role
- Make longer retrospectives with the team
Not obvious:
- Outsource some tasks
- Improve the deployment process
- Improve QA processes and data
Ask yourself where are the real bottlenecks and the cause of the challenges you have now. Maybe it’s because of the lack of tools and skills within the team or because communication between people is rough. Focus on the process and people, 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, licenses, office space, sick leave, holidays, and benefits.
Define better the requirement
People will spend less time on discussions, meetings, and evaluation of tasks when you will define them well. It does not 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, explain the expected behavior and flow, discuss, and keep in mind your technical limitations and describe the business value, you will have efficient results.
Involve QA as soon as possible and manage test data
Why should you focus on QA, and why it is important? Because developers do not 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 and the test data (the input you use to say it works). You cannot define the best QA process because there is not just one development process. Find the sweet spot and moment when it is best to test resolved tasks.
To provide functional testing, you can create the column on your board as “QA” before or after deploying to the staging server. 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. Often we use many staging servers in the office before deploying to a staging server in the production environment.
Prioritize and plan the right features and focus on the value
Lack of proper planning and frequent changes in the roadmap (pivots) makes the development harder because developers work 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 are 463 of your product backlog items, and all of them are extremely important, you can use the MoSCoW method to prioritize the work:
- Must have
- Should have
- Could have
- Won’t have (this time)
This method helps to decide which product feature should be a priority. It is beneficial for projects with a fixed deadline. The acronym stands for four categories:
Must have are the easiest factor to establish: without them, the product will not work. These are minimum requirements and cannot be negotiated.
Should have are not essential, but add significant value to the project. Without them, products would still be functional.
Could have are features that make the project more exciting but deleting them will not have any real consequences for the project.
Won’t have are also known as “wish” features – low-impact and can be easily removed if the budget is tight or there is no time for additions.
Elements may be hard to categorize, especially when working in a team. It is essential to keep a logical structure and stick to the decision. It may not be easy to prioritize items within the categories. MoSCoW Method is an excellent first step in prioritizing.
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 will use). Even if you must cut the budget quickly, consider the overall spending and the business value you will get. Delivering essential features that bring money in a short amount of time might be worth spending now or even increasing the team to shorten the delivery time to build revenue and benefit from these features quicker.
Outsource the work
Hire the augmented team to reduce recruitment costs and all office-related spending. Contracts are very often flexible and allow you to change the team composition over time, so you can reduce the team when there is not much work while increasing quickly when needed.
Other benefits of team augmentation are that you do not need to spend days on interviews. Still, 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 for the delivery in case you go for a project-based approach sometimes.
With a project-based approach, the idea of outsourcing, not the whole development but just part of the work, also is a good idea when you have the following:
01
Lack of skills or knowledge on your end. In that case, the augmented team can add value to the architecture design and tasks that your team is struggling with.
02
Small and straightforward tasks that someone else can do while your team focuses on what is the most important for your organization and solution.
Remote work?
It is now popular to reduce office space by 100% and let people work from home. There is also an expectation that they will be pleased to keep or increase productivity.
It might work, but before making such moves reevaluate the pros and cons of not having people in daily in the office. It is not about controlling what they do but about communication. The main concerns are, of course, connection issues. Imagine ten people on Teams trying to say something having poor internet connection and problems with remote collaboration tools before you start with the remote approach, even for a small part of the team, setting objectives related to communication routines and devices and solving them.
Focus on business growth instead of micro-management
Having the operations or technology role very often means you must step into the process and take more control. Even if you have the person in charge does not help you – in fact, this might be why you must step in periodically.
It is tough when people are with the company for many years and do not follow the changing environment and growing scale. Very often, they do not develop the right skills, do not have tools, or feel comfortable in their position.
How to start?
You might consider augmenting the development team to outsource the work or increase the team’s capacity. The suitable model is to facilitate the integrated nearshore team by the person on the vendor’s end. If you do not have the product owner or project manager expected to manage the team daily, it may allow your people to focus more on product development.
We see that many organizations are implementing an agile way of work differently. To start well, it is good to implement a well-designed onboarding process. All parties should be aligned not only with the expectations but also with the proper measurements (e.g., team performance, velocity, capacity, etc.), the appropriate process, and communication routines (e.g., daily meetings and planning) from the beginning.
