An anti-pattern when you Scale Up the Scrum Team

NOTE: The blog updated follow Scrum guide 2020

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 they are common situation happen nowadays:
 
- Can we have over 10 people in Scrum team? Do I need to separate them to 2 Scrum teams?
 
- When we scale up the number of Scrum team, can we scale up the number of Product Owner as well? Then each of Product Owner 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?
 
Mostly, the answers I got for this question are: “We need to speed up the works, because of the big number of features we need to deliver", "We’re late!"...
 
Firstly, I would like to clarify a wrong assumption is: more people will help to work faster. The Brooks's Law said: "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, the complexity 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 but not sure about the right value user need, have another way to help you to move up your works by doing less works. 

Deliver values

​More Value from less Work
 
The key to make your product success is not how many features you deliver, but about how user find it’s useful or what's the real value you bring to the customer. Look back on your smartphone, how many features you use daily and think they’re useful for you, how many features even you don't know what is it. I believe there’re just a few useful features.
 
It had a story about iPhone OS: the first version was released to the market and it didn’t have “copy & paste” ability. They only released that feature at version 3.0. But we all know about the success of iPhone when it was released to the market from the first time, right?
 
So instead of scaling up your team to increase the delivery big number of features, you can focus on a small team (enough to finish the work). Support them to deliver the goal, test it, if it failed, fail quickly. Then learn and improve to find what is the right value of your product need to deliver, by empowering, keeping and maintaining the self-organization.
 

What if my Business is Scaling Up? 
 
When your business is being scaled up, you need to explore new market, new customer segment. Therefore, you need more team to deliver more value. So you can think about scaling up Scrum team but you should keep each team in small size (number of Scrum team member should not over 10). And if you need more than 2 Scrum teams work in same product, you can think about using Nexus.
 
 
From here we can answer 2 questions above:
 
1. Can we have over 10 people in Scrum team? 
 
Yes, you can. But you need to take into account on complexity, more people doesn't mean the work is faster and it doesn’t support to deliver the right value to your user.
 
Do I need to separate them to 2 Scrum teams?
 
You can separate them to 2 Scrum teams but alignment between them needs to be managed and done integrated increment needs to be delivered at the end of the sprint.
 
2. When we scale up the number of Scrum team, can we scale up number of PO as well? Then each of PO will take responsibility for each part of the same product. 
  
Same with the number of Scrum team member, having more than one PO in one product doesn’t help you much to maximize value. Just increasing complexity, missing responsibility, lacking of alignment and impacting to the transparency of product backlog. 
 
So instead of scaling up the number of PO, you need to support he/ she to do his/ her work, is maximizing the value of the product by respect 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 members in Scrum team, the less work from Product backlog items need to be detailed.