With this in mind Paul Whiteside from the BCS Internet Specialist Group, examines what organisations need to do in order to successfully scale their software development teams.
When teams become larger it is often difficult to ensure that the right people are in the right roles and doing the right things. Large teams can be very inefficient, if poorly organised. The bigger the team gets the worse the efficiency becomes until the team struggles to deliver anything at all.
There are two different, but related problems in scaling teams. The first problem relates to scaling an existing development team that needs to grow. The second relates to an existing team that is already large and needs to increase its performance. Whether scaling a small team or driving efficiency in a larger team the following should be considered...
Carefully decide how much scaling is necessary
A critical aspect to scaling an existing team or bringing efficiency to a larger team is deciding on how beneficial it is to have a large team.
The Mythical Man Month by Fred Brooks, states that adding people onto a late project makes it later. Although it’s a simplification of the actual complexity that exists on IT projects, it’s very true. The book was written many years ago yet the same mistakes and assumptions are still prevalent. Even if your project is not running late, the implications for team size remain the same.
Identify the real problems before deciding to scale the team
Pure resourcing is rarely a problem and is simply a function of overall project expenditure. Deploying extra people should be avoided if a resource problem does not actually exist. It pays to investigate whether efficiencies can be found elsewhere before loading people onto a development project.
Without the proper organisation and working practices in place, adding more people will fail, or at best waste money as the extra people cannot be effectively applied.
The rational approach to getting more through-put is to increase effort. Depending on the task, this can only work to a degree before people start to get in each others’ way and communication becomes almost impossible.
A large project that lends itself to highly parallel activity, can be easily scaled in this way, but IT projects are rarely that simple…
- Multiple disciplines are involved at different stages. At times work involves several disciplines working together to solve difficult, hard to define problems. This can become a bottleneck.
- It’s impossible to predict exactly which specialities will be involved, when and for how long.
- Dependencies with other projects with changing plans can be difficult to co-ordinate.
- Things change as you progress through the project so it’s realistic to do detailed planning a few weeks in advance at best. Iterative planning within an evolving programme plan is a reliable approach.
- Environment management and processes can cause bottlenecks.
- Complex ‘merge and integration’ operations cannot be planned for accurately.
So how can we ensure we are getting performance out of large teams?
Design the team to solve the problem you have
When extra throughput is required, simply adding more people is not enough. Scaling a team involves people, processes, architecture and an environment, hence resourcing is just one part of the problem.
Other dimensions that must be considered are:
Technology and architecture
The architecture of the system can be an enabler or a constraint to scaling the team. If architectural constraints exist, it is unwise to scale the team until these constraints are addressed.
It’s important to consider whether the architecture breaks down into components that can be developed in isolation. If there are a lot of dependencies in the architecture, this will reflect in the dependencies between development teams.
The architecture or technology solution should allow several people to work on a change at the same time. If every change requires merging a large and complex configuration, this will also impact development. Consider the maximum amount of developers that can work on a code base at any time before considering scaling up the team.
People and organisation
Small focused teams can bring a lot of value. When a large projects run into trouble, a small team is often formed to do some turnaround work, or deliver a very simple version of the solution, in the hope that this success can be replicated.
Often it’s not possible to replicate the success the small teams have had. This is because the small team was charged with a small but important problem, whilst the larger team still has responsibility to deliver the entire scope of the project.
Also the small team tends to be the ‘A’ team, selected from within the organisation for their skill. Realistically on a large team not everyone will be an ‘A team’ player, so it’s important to consider that a developer is not a standard unit of productivity.
The answer is to ensure that the entire project consists of small teams with specific areas of expertise. These teams come together to deliver streams or themes of delivery. This is not a new concept, and there are three main approaches to structuring a large team.
The first approach, common on large teams, is to organise by discipline. Teams of specialists provide a shared service to other teams. Typically a project manager will book time from the disciplines to get a piece of work done. This approach can lead to silos of knowledge and problems with utilisation and availability. Many activities can end up competing for a limited pool of resource, leading to unpredictability in schedules.
The second approach is to organise by architectural component. This works well if the architecture is such that a component can be isolated from others and changes to it will not impact other component development. This is, however, very difficult to achieve for most architectures and end-to-end delivery of value can take a long time as many components must be developed and orchestrated before any business value can be realised.
The third approach is to organise by function. This works well as the functions can organise for end-to-end delivery, validating all elements of the architecture as development progresses. This model ensures separation of concerns and leads naturally to organising by ‘streams’ with each stream targeting a specific area of the application and demonstrating value by delivering a particular function in its entirety.
Processes
An inefficient process can cause long periods of waiting. For a large team this is disastrous in terms of productivity. Before scaling teams ensure that processes are lightweight and allow fast turnaround of important issues.
When teams become large it is important to rationalise and reduce the process overhead. This can be accomplished by automating activities such as sign-offs and integrations using continuous development and deployment approaches.
Whilst too much process can slow down a development effort, the opposite is also true. A robust governance model is essential when teams become large. This allows senior management who are responsible for delivery to have an accurate view of how well the teams are performing and delivering value. Before scaling up teams ensure that a proper governance structure has been well thought out to support the objectives of the programme.
Environments
All development work relies on the quality and robustness of underlying development environments. Various types of environment from developer sand-boxes, through integration, to pre-production, must be well maintained and deployment of software to these environments must be fast and accurate.
If deployment to shared environments is difficult, error prone and time consuming, ways to fix these problems must be devised before simply deciding that scaling the development teams will yield the required results.
Other concerns
As a team grows other problems besides structure, organisation and processes come into play.
Team dynamics change as more people are added. Individuals must take on new roles or responsibilities and learn new ways of working. This can lead to a conflict as people learn how to work in the new environment and adjust to new processes and working practices.
Building trust across all new teams and, in the case of outsourced development, between customer and supplier is critical. An important consideration is getting the right kind of people with the right skills and then ensuring the support in is in place to facilitate successful deliveries and reduce attrition.
Part of building trust is instilling a culture of openness and accountability across all the teams. This means that team members feel a sense of commitment to each other as well as to their management and the programme.
Scaling is an expensive solution to increasing throughput and achieving earlier delivery. Don’t consider scaling without thinking about architecture, process, culture, and team dynamics. Managing large teams and ensuring productivity is difficult therefore it is essential to understand the problem at hand before creating a strategy for structuring and governing the team effectively.
