Imagine you are a Scrum Master in a small Organization that tries to adopt Scrum. There are 10 developers and the Product Owner. Can they be divided into teams? If yes, how?
What would be the need to have them split?
What would be the pitfalls if they didn't?
What do they think themselves?
Have they tried being a single team and what was the experience?
Imagine you are a Scrum Master in a small Organization that tries to adopt Scrum. There are 10 developers and the Product Owner. Can they be divided into teams? If yes, how?
Yes, they can be divided into teams. How they do that would depend upon whether or not they should.
The Scrum Master's role would be to teach the benefits of Scrum, the design of the "Development Team", and the responsibilities thereof. The teams could then be formed collaboratively for the goal of it/them being cross-functional and self-organizing.
It's not really a decision the Scrum Master should make, regardless the size of the organization, but should be involved to help everyone understand the goal/purpose of the team design in order to apply the Scrum Values and them be able to effectively function together as a Scrum Team(s).
Perhaps the Scrum Master should facilitate a workshop to help teach them how to do this?
Can they be divided into 2 teams? Yes. But, why? The usual answer is "so that they can get more done." But it is also a fallacy in many cases. Don't divide them just to have 2 teams.
As for how to divide them should there be a need? Ask the Developers how they feel a division would allow them to do the work needed to address the items in the Product Backlog(s). So you see that before you decide to divide the teams, the Product Owner first needs to determine what needs are to be addressed for the products.
The comments and questions asked by others are all good, but I'd propose one more question:
How many products do you have?
Just because you have one Product Owner doesn't mean that you only have one product. I'd want to understand how many products you have and how to best organize the people around those products. Then, you can figure out how to organize multiple teams, if you need to, around each product - and others have given good insight into that aspect of the problem.
I am just talking about 1 product. As per the scrum guideline the number of people in a Development Team should be between 3 and 9 and in my case there are 10 developers.
How many products do you have?
A vital question.
If the answer is one, then it's most likely unhelpful to divide that in some arbitrary way, so you should maintain having one Product Owner, and one Product Backlog.
A Product Owner who can convey a vision for the product, and who is focused on the maximization of value should be able to set expectations for the developers.
Self-organizing developers should then be able to form a team or teams that enable effective product development.
If it's one large team, with 10 developers, communication may become unmanageable, and the team might struggle to focus on a single Sprint Goal, and it may explicitly or implicitly lead to the team forming temporary or persistent sub-teams. This can be an incredibly unhealthy state for a group which considers itself a team, to be in; but it could be useful evidence of a need to split.
Two or more teams would lead to other complications, such as alignment between the teams, having to deal with dependencies, having the highest priority Product Backlog Items not picked up because one team lacks the skills to work in that area, having to decide whether to delay Sprint Retrospectives and Sprint Plannings for at least one team, so that the Product Owner can be present in all of them, or have some of them take place without the Product Owner.
Or to approach this problem from a different angle:
What evidence is there that 10 is the right number of developers to work on this product?
Having discussed expectations and opportunities, what if the Product Owner, Scrum Master and Development Team all agree that a smaller number of developers is required?
Are the team members brave enough to have that conversation? What would happen to the developers who don't work on this product… can they still work on a different product, or in a different role within the organization?
It's often best to avoid scaling.
This question appears in PSM-1 in third party website (Lapshin et. al).
However, this question most appropriately should belong to Nexus and Not Scrum assessment.
@rajesh, this is not a part of any Scrum.org assessment or it would not be permitted on the site or anywhere as that would be a copyright violation. That said, this is a core Scrum question as to how you as a Scrum Master would handle such a situation. Nexus or other scaling frameworks may help guide you, however this is true to any Scrum Master role with or without the use of a scaling framework.