When dividing 100 people into scrum teams, who should take responsibility for putting individual people into teams, should it be Scrum Master, Product Owner, or should people be allowed to emerge teams on their own?
So many answers to this. It is going to depend on your organization. Someplace like Zappos or Valve is totally self-organized and even self-directed. That said, lets go with your average software development company as your "average" answer.
Then you still have two answers, "now" and "future".
With a 100 developers you're talking a large organization. Even if you run very lean on staffing, you probably have over 200 people in the company total. Keep 150 in mind for now as that's important. After 150 you go beyond the human mind's "tribe" limit. If your company is over 150 then not everyone can remain connected.
Focusing on the 100 developers, you're talking about 11 to 15 scrum teams. Not 10. That's important as team size is based on real size. After eight it becomes increasingly harder to manage communication and collaboration. There is a reason phone numbers in the US are seven base digits.
"Now"- Scrum Masters, Product Owners and the team should all absolutely have input into the process. However, in your average software organization, management will need to have the final decision. At this point in an agile transformation you're still sorting out a lot and dealing with legacy models. You also need to address the product needs. If all the UI guys self-organize into a team, they won't have skills they need to form a good team (not to mention the lack of QA).
Start by understanding what you need to do. You may have some specific requirements, like an API, that drive make-up of certain teams.
Then understand the people. It can be very helpful to have everyone in the organization take some kind of communication profile. Personally I recommend DISC. You don't want to staff a team with all one communication type, it will fail, regardless of the communication type.
Finally, understand what's working now. You likely have people that work well together already. Try and leverage that to shorten the team forming cycle (forming, storming, norming, performing).
"Future" - The first step to a future model is to make it so teams have a mechanism to request and be granted that someone be moved from their team. The team is going to be measured as a team. If they have someone that doesn't fit or isn't doing their share of the work, the team needs to know they can ask for that person to be moved.
Later down the road you can move to a more flexible model, that allows teams to propose new formations. That though is it's own level of transformation and beyond what I believe you want right now.
I encountered the same question, while taking the Scrum.org PSM exam. The short answer is:
- You provide the people with the vision - what should the teams be composed for? What are the projects they will to work on? What are the delivery expectations etc
- Let the people divide into the teams on their own.
This is a good article (by Craig Larman and Ahmad Fahmy) which describe this problem in real-life situation.
According this article:
Teams should be self-designed (It means people should be allowed to emerge teams on their own).
This process should have facilitator, who will help people to organize themselves in well balanced cross-functional teams.
Craig Larman took as a basis following approach (which was used by another manager in China):
Instead of deciding on the new teams, the Chinese department manager, Lv Yi (along with Bas Vodde, a Scrum expert who worked in the group), invited everyone into a large room, explained the goal of new Scrum teams, and simply asked the group members to decide among themselves. The group agreed it needed four hours for this, and Lv Yi said, "I'll come back in four hours, and if some people have not decided by then, I will decide." Four hours later and after much talk and activity, the group had self-designed their new teams. Then volunteer ScrumMasters were brought to the center of the room, and the teams picked the ScrumMasters that they wanted.
Then he improved this approach and facilitated it (for making self-designed teams more balanced and cross-functional).
You can read all other details of this dividing process in the article above.
This is how you can do
Current Scrum master has to break the team with the help of Product owner and based on the modules/features.
So you will get feature wise team and then scrum master can delegate his responsibility to eligible member of each team and that member will act as scrum master for that particular team.