Big decision

How I’ve dealt with the team growing from 5 to 12 people

Life was good, I led a mature team of 5 turned 6, 7, 8… The team was somewhere between the norming and performing stages of Tuckman’s stages. The goal of being a self-managing team was closer. But to keep with the ambitious roadmap we needed more workforce. Then we were 12 and things became harder.

From 2 to 12

A team of 2 does not need to invest time organizing

As mentioned earlier, the team started at 2. We were delivering fast at that time, no burdens of extra communication. Each one knew what to do and how to do it.

Scaling from a pair to a team

The team grew, in number and maturity. At 8 we had our best momentum. People knew and understood each other, workload and tasks were well distributed and the team was performing faster than ever.

Further scaling

Competition is strong and to keep at the top, we needed more features, so we needed more releases, so we needed to bring more talent. And we did.

We were now 12. We welcomed 4 new young developers.

Receiving new people

I think we are good at training new members of the team.

Each team member act as an ambassador of our culture. We have bootstrap documentation with hands-on exercises to avoid full days of reading documentation and watching videos.

Also, our aim is that a new team member is rapidly contributing to the team’s work (with its advantages and drawbacks).

With a bigger team, “velocity per person” fell

I try to use a few but meaningful metrics. I use this one, combined with others, to monitor the team’s performance and find any bottleneck in our process.

When a team grows, it’s expected that each individual drops a little his productivity due to extra communication and process overhead.

Processes bottlenecks:

• Code reviews were a bottleneck, again;
• The board was getting complicated to read and discuss;
• Manual Testing was delayed to later phases;
• Personally, I was again being drawn in too many matters;

And last, but not least, the Scrum events were also suffering:

• Planning was either too long or not meaningful;
• Retrospectives had too many different stories to be told and discussed for one single meeting; Some people were not actively participating;
• Dailies were still under the 15m limit but we had to hurry each person intervention;

After 4 years of leading the team, I felt, for the first time, that this problem had no clear solution.

The team had grown organically. Each person had improved along the way but we were performing worse individually. How could we fix this?

Divide and conquer

Allow me to show how I approach a problem:

I try to find a solution first and look for confirmation. This moto can be explaining in this simple list of steps:

• I analyze the problem;
• I try to find a solution;
• I look for theoretical solutions in blogs and/or books;
• I share the problem with team members and people of trust from other teams and listen to their opinions to improve or even change my original solution;
• We experiment on a small scale;

The only solution I could think of was splitting the team into two. I was sure it would at least reduce the communication overhead (more about lines of communication, here).

I shared my idea with some people. I received feedback, alternatives, and reports about past experiences.

The problems were that it had never been done like I wanted to do it and we couldn’t experiment on a small scale.

How to split the team

To split the team I would need to know the answer for some inevitable questions:

• Which person to which team?
• What would be each team’s responsibility?
• How to divide work?
• How to manage 2 teams?
• How to handle the sudden “cut” of relations the split would mean?

After delivering a big release, we had a 2 days retreat. It was the perfect time to present and discuss my plan.

I proposed how the work would be split between the teams and who would be each Scrum Master. After discussion and debate, we came up with a solid plan on how we could maximize each team's health (relations, comfort, performance …), while also minimizing the effects of drastically changing the way we worked until now.

How it is going

Everyone agrees that we took the right decision. Planning is meaningful, retrospectives are focused, code reviews are faster than ever, and testing has also improved.

Metrics are also improving, and we are now at 0,7 story points solved “per individual day”.

Takeaways

When the team scaled to a size way over healthy agile teams’ size, we start to have a deterioration of individual performance. After analysis and reflection together with some key elements, I decided that we needed to split the team in two. This has proven to be the right decision as team members are happier working in smaller teams and the performance has improved. We have also set the path for further scaling.

Next

In the next post, I’ll explain how I deal with a team geographically distributed.

Reviewed by @nunosantos.ms and @hugobraz94;