The Scrum Master only has the authority to ensure that the Scrum Team follows the rules of Scrum. If not immediately compliant, then working toward compliance increasingly and consistently (for instance, transparency of the increment surpasses most development teams skills and tooling initially). The Scrum Master has not authority to tell the development team or the product owner what to do their job. The Scrum Master can coach, teach, establish learning situations, enter Socratic dialogue, and parent. However, they weren’t given the authority to manage the other members of the Scrum Team.
Some people on the Scrum Team learn by failing, trying again, and failing. Some are terrified of failing and need some prompting, some more coaching, some guidance. But they have to learn. Otherwise, they will always be dependent on the Scrum Master.
I pose the following question to Scrum Masters: “What is the best way to organize 100 developers into Scrum Teams and ensure that they select the correct Product Backlog items.”
The correct answer is to let the developers organize themselves into Scrum Teams. The Scrum Master may remind them that they have to have all the cross-functional skills on each Scrum Team to build a done increment. The Scrum Master may remind them that all 100 people must be engaged meaningfully and that mentoring is expected. The Scrum Master may have the lead developers lead a discussion about the software and architecture to be worked on, with the underlying dependencies. The Scrum Master may have the Product Owner discuss the intricacies of the Product Backlog. The Scrum Master may remind them that they have to deliver one integrated, integration tested increment at the end of the Sprint. But then it is up to the developers to organize themselves. I would expect that the lead developers would form the seed for the new Scrum Teams, but who knows?
If the Scrum Master organizes the Scrum Teams and parses out the Product Backlog, the developers are constrained by the intelligence and knowledge of the Scrum Master. If the developers organize themselves into Scrum Teams, we are engaging the intelligence of all 100 developers. And, if they organize suboptimally, they can correct and continually adjust team membership as they find out more. A learning organization. Bottom-up intelligence.
I have successfully used the technique of letting developers self-organize into teams with groups of up to 200 people. They were working on complex, mission critical software, included subcontractors, and didn’t necessarily know each other well. As training wheels, I once arbitrarily put them into Scrum Teams and then told them to fix my mistakes by reorganizing.
I’ve never tried more than 200 because I can’t get more than that in a reasonable sized room. I suspect that if I were able to do so, they would soon decompose themselves into smaller groups, then smaller groups, then Scrum Teams.
Imagine the arrogance of a Scrum Master who believes that he/she knows how developers should organize better than the people themselves. This Scrum Master often has the thought in his/her mind that to be sure, he/she must control the situation; after all, they think that they are in charge (they think).
Some food for thought.