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 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, 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 work, because of the big number of features we need to deliver", "We’re late!"...
Firstly, I would like to clarify a wrong assumption: more people will help to work faster. 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 you are not sure about the right value users need, having another way to help you to move up your work by doing less works.
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 or finding out what the real value is that 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 do you not know about. I believe there are 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 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, 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 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 Scrum team but you should keep each team in small size (number of development team member should not over 9). 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 2 questions above:
1. Can we have over 9 people in the Development Team?
Yes, you can. But you need to take into account complexity, more people doesn't mean the work is faster and it doesn’t mean it will 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 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, 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; it is 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.