NOTE: The blog was updated to follow the Scrum Guide 2020
Last week, I had a long discussion with my friends about how to scale up the Scrum team for 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 situations that happen nowadays:
– Can we have over 10 people in a Scrum Team? Do I need to separate them into 2 Scrum teams?
– When we scale up the number of Scrum teams, can we scale up the number of Product Owners as well? Then each Product Owner will take responsibility for 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 work because of the large number of features we need to deliver, “We’re late!”…
Firstly, I would like to clarify a wrong assumption: more people will help us work faster. Brooks’ 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 of managing the team increases. And because it’s complex, how do you know the feature you deliver is the one your user needs?
So instead of increasing complexity to deal with complexity, or focusing on delivering more and more features without being sure about the right value the user needs, have another way to help you 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 how users find it useful or what real value you bring to the customer. Look back on your smartphone: how many features do you use daily and think are useful for you, and how many features you don’t even know what they are. 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 the “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 for the first time, right?
So instead of scaling up your team to deliver a large 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 fails, fail quickly. Then learn and improve to find what value your product needs to deliver by empowering, keeping, and maintaining self-organization.
What if my Business is Scaling Up?
When your business is being scaled up, you need to explore new markets and new customer segments. Therefore, you need more teams to deliver more value. So you can consider scaling up the Scrum team, but keep each team small (no more than 10 members). And if you need more than 2 Scrum teams working on the same product, consider using Nexus.
From here we can answer the 2 questions above:
1. Can we have over 10 people in a Scrum team?
Yes, you can. But you need to take complexity into account: more people don’t mean the work is faster, and it doesn’t help deliver the right value to your user.
Do I need to separate them into 2 Scrum teams?
You can split them into 2 Scrum teams, but alignment between them needs to be managed, and the integrated increment must 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 each PO will take responsibility for each part of the same product.
Same with the number of Scrum team members; having more than one PO in one product doesn’t help you much to maximize value. It just increases complexity, misses responsibility, lacks alignment, and impacts the transparency of the product backlog.
So instead of scaling up the number of POs, you need to support him/her in doing his/her work, which maximizes the value of the product by respecting his/her decision. By delivering the assumed value and figuring out what the right value needs to be delivered. By building trust within the Scrum team: The more trust between the members in the Scrum team, the less work from the product backlog items needs to be detailed.
