Scrum Master as a coach or as a manager ?

I don't read Scrum Guide team size guideline as mandatory. It's just a very clear suggestion that it's optimal. Deviations should be cost-justified. Just like with distributed teams.

To answer your question: yes, you should depend on context and go with option #2. Be careful with confirmation bias though ;-) If problems highlighted by you on Sprint Retrospectives will not get traction, enforcing the split might cause more harm than good. Ultimately it's the team that is going to suffer directly from being oversized.

Cheers
Bartek

> Re-re-re-reading the Scrum Guide, I wonder if the 3-9 Dev Team size is mandatory.

No it isn't. The Scrum framework is not prescriptive enough to enforce such limits without regard to context. 3 - 9 is the optimal range in most circumstances. The duty of the Scrum Master is to coach the team to understand the reasoning behind this range and the risks and pathologies of having a sub-optimal team size. The duty of the Development Team is to self-organise an optimal configuration given their own unique circumstances. The SM can help them inspect and adapt accordingly by observing and explaining the consequences of particular decisions.

NB I once had a Development Team with 12 members which was just about sustainable, but the likelihood was that it would grow further to accommodate a greater demand. After pointing out the risks, which were fairly obvious to most of the team anyhow, they agreed to look for ways to effect a split with minimal dependencies. This was hard to do, but they were able to self-organise a remedy. I think they split into teams of 8 and 4 if I recall correctly. As a general observation, it is rare for a split with minimal dependencies to be as balanced as one might like.

I agree with Ian's first answer above.

(His 2nd answer is a good one but is very unique to his context, so I'm not commenting on that one)

I'm also not sure I'd agree that above nine "a split is necessary" in your words, without again knowing more context. Everything else in #2 looks pretty good. #1 looks more like command and control leadership instead of servant leadership.

I would def encourage consideration of, if teams are split, to split into teams that closely model feature teams rather than component teams. Again, more context would be necessary for that topic.

Thank you very much for your interesting response.

The split was just a example, my main question is if the Dev Team or the PO, new to Scrum, doesn't want to play the game, because of their old habits, how should the Scrum Master deal with it.
Your responses are still valid, even in the case of a Dev Team reluctant to participate to the retrospective for instance, or any other blocking behavior.

Usually when people don’t want to “play by the rule” is due to inexperience. Because of old habits, they don’t see the benefits of the scrum. Also some even see scrum as some short of evil entity and therefore tries everything to proof that it doesn’t work.

The Scrum master should teach, coach others in order for them to see “the light”. I always portrait scrum as a set of best practices that is needed to do product development in a continuous changing world.

In order to create awesome product (and take in counter that the world is constantly changing) you need to have 100% focus, no distractions, daily meet up to see if the sprint is still in line with the goal, excepting that the world is constantly changing, accept that new insights isn’t a sign of weakness but that it’s all about having a positive attitude etc. etc. All of these aspects are embedded in Scrum.