Skip to main content

Scrum Master as a coach or as a manager ?

Last post 09:59 am February 9, 2016 by Chee-Hong Hsia
6 replies
05:31 am February 8, 2016


I wonder how the Scrum Master should act in a situation where the Dev Team ( + PO) does not (want to) follow the Scrum Guide.
For instance, if the Dev Team grow up above 9 people and doesn't want to split, how should the Scrum Master react ?
I see 2 options :
#1 : be consistent with the guide, act as a manager accountable of the process and enforce the split.
#2 : use this situation as a learning opportunity, act as a coach and teacher, and try to help the team realize that a split is necessary. If the Dev Team doesn't want to split know, use the next Sprint Retrospectives to hightlight the problems raised by the coordination and complexity of this oversized team.

Re-re-re-reading the Scrum Guide, I wonder if the 3-9 Dev Team size is mandatory.
It's written on page 6 that "OPTIMAL Dev Team size...", but not that the range of 3 to 9 is mandatory.
Should it depend of the context or not ?


06:11 am February 8, 2016

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.


08:07 am February 8, 2016

> 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.

08:16 am February 8, 2016

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.

01:40 pm February 8, 2016

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.

03:12 pm February 8, 2016

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.

09:59 am February 9, 2016

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.