Growing Pains: Scaling Development by Splitting Teams
Squads is growing, and this has caused the need for scaling up our development capacity. Because the Squads model is appealing to developers, recruiting hasn’t been much of a problem, but we did find an interesting challenge in scaling up our teams. Research has shown that the productivity of a team doesn’t scale linearly with the number of members in the team, but clients rightfully expect that our productivity increases linearly with the budget.
To tackle this challenge we’ve decided to split into multiple teams. I expect that this is something many development organizations struggle with, so I’ll share the lessons learned and a strategy that I’ve found allows this scaling to happen without undermining the self-managing nature of a good Agile team.
Create a development team from an existing one
When splitting teams, it is tempting to create a matrix of skill sets and divide them as evenly as you can over the new teams by assigning members to each team. The problem with this approach is that it disrupts the established routine and the implicit behavior that made the old team collaborate well. Essentially you start from scratch building two teams.
Another problem is that by assigning members to a team, you rob them of free choice and organizational malfunctions will not be felt by team members as caused by them, but they will (correctly) be blamed on the managerial decisions. This breeds apathy and needs time to be fixed by the team. We don’t have the luxury of that time, so this is not an option.
With StarterSquad we’ve decided that creating a new team can only happen from an existing, matured team. One of the senior members of the team leaves the team to start a new one. Then the members that chose to do so can follow and join the new team, new team members are recruited and added to the new team afterward. Important to ensure that the decision to join a team is made by the member, not by a team lead or manager.
Risks I saw upfront
Leaving teams to self govern who joins which team is scary. What if:
- all members stay in the existing team?
- all members want to join the new team?
- what if the old team gets weakened too much?
- the new team isn’t strong enough?
StarterSquad is built on the conviction that creating intrinsic motivation is key to growing self-governance. The rules of StarterSquad ensure that there is a direct coupling between team success and team member rewards. In other words, being in very effective and well-functioning team results in higher rewards for the members.
This, and responsibility felt for the team and its clients results in members taking decisions that are beneficial to the clients of the team. Being in a large team is not as rewarding as being in a small focused team. Jumping out of a team is risky, but the benefits can be very compelling. Joining a small team and making it perform better by adding just the right skills is beneficial to you and the other team members, so such a decision is appreciated by the team you join.
How it worked out
I left my team. I announced that I would start a new team and discussed what projects my new (one man) team should be responsible for. Some projects were tightly coupled to me, so the other team was very willing to let me take them off their plate. This caused some problems in the old team because the amount of work there wasn’t enough to fill their capacity. I had the opposite problem, so I started to ask for help. Quite quickly two members joined my team and continued work on the projects that I’d taken from their old team. Things started to balance out a bit. The new team I had was heavy on back-end skills, and light on front-end skills. I know my way around Angular and I can work with Sass, and HTML5 but I know the experts that can code circles around me in that area. I needed my old teammates on those projects.
I tried to recruit a front-ender out of the old team, but they were reluctant to leave the hardcore that they felt comfortable in. I solved this by becoming a client of the old team, and ‘buying’ some of their capacity.
After making this move in a few days two things happened:
- I spent 40% less time in calls
- Most clients noticed a slight increase in productivity
Two weeks later, it’s business as usual and I’m increasing the size of my team by hiring new members. The old team is more focused and running smoothly. I expect that they will run into a capacity shortage soon too. Growth has happened with virtually no negative effects on clients. In fact, it has solved the problems I associated with the team getting too big. I should have done this earlier.
The not so good
It seems that by splitting the team, more focus is directed to clients. Why is this bad you say? Well, it’s good for the clients, but not for the long term of StarterSquad. This increased client focus seems to result in less focus on our open source efforts, our pet projects, and less focus on maintaining the website. I’m still analyzing that situation trying to find another way to have my cake and eat it too. That, in the end, is what StarterSquad is all about.
How does this apply to you?
If you’re reading this, chances are you’re trying to scale development too. Of course, you could hire StarterSquad to do it for you, but if you want to do it inside your own organization, you can stick to the basic plan that worked for us:
- start team around a small core
- let the team members decide what team they go in
- couple team member rewards to team success
- couple team success to project successes
- assign resources to projects
- create new teams by breaking up an existing team
- assign members to teams
I’d love to hear how you did it. If you need some free advice.