I have a team of 11 developers and 3 Product Owners. Their ideas about how to organize the team are all over the place. Some want to do 1 week sprints. Others want one month sprints. And we pull inModifying a complex technique before you have mastered it is a failure pattern. So when you are just getting started, try to get as close to Scrum by the book as you can, without obsessing over it... much. I call this Pretty Good Scrum(tm). ;-)
resourcespeople so we can get the right velocity to meet our deadlines. This seems like a mess. How much should I let my beginning team self-organize? -- recently asked on a Scrum Discussion Forum.
Yes the team self-organizes... and the Scrum Master is charged with teaching the team and helping them improve. When the team is just getting started, it should follow the lead the of Scrum Master, and the Scrum Master should stay close to the book. As they get better, they'll be better able to inspect and adapt themselves.
Successful teams learn quickly. How do you learn quickly? Short answer: Do short sprints. More in a moment.
Remember, never hit anyone with the book! The rules of Scrum are there to help you, not to threaten or punish people. Be sure you can answer why the rule of Scrum is a good answer. Treat everything as an experiment or learning exercise, so they have the security of knowing they can change things later. That's what retrospectives are for.
It will probably take you three or four sprints to get to Pretty Good Scrum. That's why I recommend one week sprints to start. Why learn in four months what you can learn in 4 weeks?
If I were confronted with the situation above, I would ask five questions and help the team(s) and PO(s) find answers that stay within the constraints defined by Scrum.
1. How big is a Scrum team? 7+/-2. To stay in those bounds, you need two teams. Ask your teams how they want divide themselves, respecting that constraint. By giving them the problem, they become responsible for the solution, so they won't come to you anymore with "yes, but..."! If they talk about limited specialists, ask them how to resolve the problem.
2. How many Product Owners does a Scrum Team have? One, though you might also have a Chief Product Owner role in the case of multiple teams. Ask your product owners how they want to split up their work. And yes, the PO is responsible for the Vision. Do they have one, can they communicate it? Is it shared and supported by the Team and other stakeholders?
3. How long is the Sprint? Normally this is negotiated between PO and Team. And... as Scrum Master you are responsible for the process, which gives you the right to intervene to improve the team. Shorter sprints accelerate learning. So I would suggest starting with a couple of one week sprints. Be sure to get your team to agree to this. I have also had great experiences doing 2 or 3 sprints at 59 minutes each (ask me more about this if you're interested).
4. Who estimates and decides how much work can be accomplished in a sprint? The team. Not the math, not the PO, not the stakeholders and not management. Have them estimate the work, and don't let them take on more than they can chew. Think of highways at rush hour if you want to know why this is a good idea.
5. Whose job is it to make sure that wish and reality are in harmony with each other? The Product Owner. If the desired scope does not match up with the team's reasonable forecast of what they can accomplish by the desired release date (aka deadline), whose job is it to fix the problem? The PO. Given your context, conversations about reducing scope and the impact of product-level multitasking on ROI might be quite fruitful!
Back to the original question: "How much do you let a new team self organize?" The answer is "quite a lot!" The trick is setting constraints that cause people to come up with right answers.