An Anti-Pattern Emerges When You Scale Up The Scrum Team

Last week, I had a long discussion with my friends about how to scale up the Scrum Team from the startup product. That was an interesting topic and we had many things to discuss. Some of my friends raised some interesting questions. I think these are common situations happen nowadays:

• Can we have over 9 people in the Development Team? Do I need to separate them to 2 Scrum teams?

• When we scale up the number of Scrum Team members, can we scale up the number of Product Owners as well? Then each of Product Owners will take responsibility on each part of the same product.

To answer those questions, I would like to bring back the root cause or the original need: Why do you need to scale up the team?

Why Do You Need to Scale Up The Scrum Team?

The answers I got for this question are: “We need to speed up the work, because of the big number of features we need to deliver", "We’re late!" and more of the kind/

Firstly, I would like to clarify the incorrect assumption that more people will help to work faster. In fact, Brooks's Law says, "Adding manpower to a late software project makes it later."

Secondly, software development is complex because of the market, technology, and people. So if you choose a solution to add more people to the Scrum Team, you need to take into account that the complexity that needs to be managed is increased. And because it's complex, how do you know the feature you deliver is the one your user needs?

So instead of increasing the complexity to deal with complexity or focusing on delivering more and more features without an idea about the value users need, find another way to help you to move up your work by doing less.

More Value From Less Work

The key to making your product successful is not how many features you deliver, but about how useful the user finds it and finding out what the real value is that you bring to the customer. Look back on your smartphone and reflect on how many features you use daily and think are useful versus the number of features do you not know about. I believe there are just a few useful features.

The first version of iOS was released to the market and it didn’t have a copy and paste function. They only released that feature at version 3.0. But we all know about the success of the iPhone when it was released to the market from the first time, right?

So instead of scaling up your team to increase the delivery of a big number of features, you can focus on a small team (enough to finish the work). Support them to deliver the goal, test it, and if it failed, fail quickly. Then learn and improve to find the right value of your product need to deliver by empowering, keeping and maintaining the self-organization within the team.

What if My Business Is Scaling Up?

When your business is being scaled up, you need to explore a new market, a new customer segment. Therefore, you need more team to deliver more value. So you can think about scaling up the Scrum team but you should keep each team to a small size, with no more than 9 members. And if you need more than 2 Scrum teams to work in the same product, you can think about using Nexus.

From here we can answer two questions.

1. Can we have over nine people in the Development Team? Do I need to separate them to two Scrum teams?

Yes, you can. But you need to take into account complexity, as more people doesn't mean the work is faster and it doesn’t mean it will deliver the right value to your user.

You can separate them to two Scrum Teams but the alignment between them needs to be managed and a Done Integrated Increment needs to be delivered at the end of the Sprint.

2. When we scale up the number of Scrum Teams, can we scale up the number of POs as well? Then, will each PO will take responsibility for each part of the same product?

It is the same with the number of Development Team Members: having more than one PO in one product doesn’t help you much to maximize value. It's just increasing complexity, missing responsibility, lacking alignment, and impacting to the transparency of Product Backlog.

So instead of scaling up the number of POs, you need to support he/she to do his/her work by maximizing the value of the product by respect to his/her decision; by delivering the assumed value and figuring out what is the right value need to be delivered; by building the trust within the Scrum team. The more trust between the Development Team and PO built, the less the work from the product backlog items need to be detailed.