Splitting Software Delivery Teams

If you have noticed that your team's performance has plateaued despite more people being added to the team, it might be time to split your team. Debate and collaboration are fundamental to good team performance but too much of it can burn too much time and take time away from getting the job done.

Before we look at reasons to split your team, here are a few reasons not to #imo:

• Personality differences of team members. Different personalities have different strengths and should be kept together to have stronger teams. The team and the individuals need to learn to accept and even embrace these differences.
• Disagreements in ways of working. People need to learn to compromise and work together. Some give and take is required by all members of the team to create a way of working for the team as a whole.
• Projects teams. This creating teams around projects create headaches with ownership when the teams disband.
• Avoid support teams. If you have one, you need to be very careful of the personality types you have in these teams to make sure you get people who enjoy support and have decent communication skills. A common mistake #imo, is to put graduates/junior developers in support teams to get them to "up-skill". Junior team members need to learn dev practices which generally is not as strict in support teams as they are in product delivery teams.
• Capabilities or Disciplines. For example, don't have a test team and a dev team. Software development includes Business Analysis, Coding, DevOps and QA, you can't build successful, reliable, scalable software and still keep your sanity without all 4 and separating them creates bottlenecks and availability issues that cause friction...

Why should I break up my agile delivery team?

The team has grown too much.

The larger a team the more process is needed to manage work which results in process loss known as the Ringelmann Effect. Amazon famously has a 2 pizzas team approach, which keeps team sizes between 8 and 12.

As with all rules of thumb, be careful with this rule, as I don't believe having 8 to 12 developers in a team is healthy. It needs a good balance of all your capabilities (i.e. QA, BA, DevOps and Developers). You should also be careful with your distribution of seniority in a team, for example having too many senior developers (in my opinion more than 2) in a team can cause too much debate which also slows down delivery.

Incompatible working practices for all work items in your pipeline

Different teams require different ways of working depending on what their work pipelines look like. A simple example is that an integration team and a web development team will have different ways of working to be effective. This is because with integration development the feedback loop is instant and requirements evolve a lot faster than when you need to get feedback from people.

If you have a mix of work that is causing your team to be slowed down by work not compatible with the team's ways of working it might be useful to split into 2 teams to deal with the different types of work.

Two ways of working for cross skilled teams that facilitate all the "good stuff" like small increments, collaboration and cross-skilling are Scrum and Kanban. Product development where it is easier to predict priorities over a short period (at most a month) works better in Scrum whereas Integration teams might work better as Kanban since their work items could change quickly and waiting 2 weeks for the next sprint might be wasteful.

Approaches to splitting teams

I've seen and been part of different team splits that worked and ones that did not. I've also spoken to various other leaders of multiple teams and even asked some recruiters what they've seen and these are some of the options I've come across excluding the ones I've already discounted above:

Long-lived "cross skilled teams"

The good old forming-storming-norming-performing teams; are teams that stay together for a long time and refine their way of working to work well for the team. These teams are generally thrown together as a mix of capabilities required to achieve deliverables independently. For example 2-4 developers, a tester or 2 and a BA.

While I think this is a good place to start, I am not convinced it is the most productive method for having multiple teams long term. "Performing" teams have a way of working that is too embedded for them to change in order to deal with different environments. For example, if you hire a team to build a website and now you need to support it. Does supporting an existing app require the same way of working as building a new one?

Another risk of long-lived teams is that teams can stagnate. You can avoid this by limiting the time the team stays together, for example disbanding teams after around 18 months. In the real world, you'd usually have a bit of churn which might take care of enough deviation in the team to make disbanding unnecessary.

"Focus teams" (my own name as I have no idea what to call them)

I was talking to an investor who dealt with software companies and it actually took me a while to grasp what he was trying to explain to me. We finally agreed that he preferred was a team structure where the members are select based on the specific skills required for the work or project they are working on. This might sound obvious, but it means a cookie-cutter delivery team approach like the above won't give the best results.

Some examples of focus teams are:

• App building team needs. These teams need a lot of DevOps skills, they need a good technical architect in the team and senior developers to pave the way so the app can scale.
• Web design teams are similar to the above but have slightly different technology skills.
• Integration teams. Again similar but possibly also needs some consulting skills.
• Feature development teams. These teams need people who can pump out code, i.e. it needs to be Developer heavy. They usually need account management or BA skills to figure out how to grow the app and keep meeting the customers/clients changing requirements. They also have regression concerns so a good tester or automated testing engineer would be vital.
• Support teams. These teams need subject matter experts, developers and testers. I think a good support team needs to be able to fix most issues by themselves. They also need people with good people skills and at times, thick skin.
• Operations teams. These teams are almost pure DevOps. You require people with security training and training/certifications in whatever environment (cloud/other) you are running in. It is completely possible to have DevOps as part of product delivery teams but for larger companies having someone to own (owning and doing is not the same), the wider operational tasks could be handy.

Team Scaffolding

I said above to not make Project teams. Team scaffolding has similarities but instead of focusing on projects, you focus on pipeline. The idea of scaffolding is to re-evaluate your pipeline each quarter and restructure teams to meet the needs of the company in the next quarter.

I believe this model will work best using "focus teams" rather than "cross skilled" teams simply because you don't always need all the skills in every team.

The obvious challenges here are project ownership and hand-offs at the end of a scaffolding period. You also need to deal with people that don't "fit" into any team during a particular period.

I've come to realise while trying to implement this strategy that it is really hard to not create a situation where all team members are 100% happy with the team they are placed in. The way I've managed this is to not put "hard labels" on the teams. While a team is structured to be able to do a certain kind of work, giving them other types of projects at times to keep things engaging really helps team morale.

Scaffolded teams can become Long-lived teams. I don't think this is a bad thing (if it ain't broke...) I think however you need to make sure the team understands that while the current format works and makes sense they will be kept together but there is always a possibility that they might be broken up.

Product Teams

Your product needs to be large enough to keep a team busy before you can consider dedicating a team to it, but it can create a sense of ownership and pride which in return can result in the team uplifting the product.

The main pitfall for a product team is that the team members can get into a rut. So it is important to rotate people out of these teams to make sure they are developing in areas that the product doesn't touch much.

In Conclusion

I think it is important to not split your teams too soon, but if you see that your performance is plateauing despite more people being added, you need to either split your teams or change your way of working.

As with all things you need to figure out what works for your teams and your company. The solution you come up with will probably end up being a hybrid of the above, but hopefully, I gave you something to think about.