It is said almost everywhere that a Scrum Master should not be part of the developer team. And in my experience, this really should be avoided.
Due to several circumstances it may be that you have a part-time Scrum Master, who has to switch between that role and the one of a team member. But there are several reasons for that a Scrum Master should do his mastering job rather than being occupied with working on Sprint Backlog items:
- The Scrum Master role defines a full-time job if it is taken seriously. Serving all the facets of that role consumes all of the Scrum Master’s available time.
- Having the Scrum Master role alone avoids conflicts of interests. How can a Scrum Master be neutral and propose an appropriate solution if there is a conflict between the Product Owner and the team, and he is a team member the same time?
- A Scrum Master has a better position for moderation if he is not involved in the everyday business of working on the Sprint Backlog items. This makes him have a more abstract and less emotional view on what happens during the Sprint.
- In case the Sprint Goal is in danger: I bet, a part-time Scrum Master will decide to concentrate his work on the Sprint Backlog items, neglecting his alter ego. This definitely results in a weak Scrum Master and means a danger for a proper Scrum process.
For sure, these aspects are even more important when you want to carry Scrum into your enterprise for the first time. At that time, obeying the Scrum rules is crucial for success. And so, the Scrum Master should not be distracted from doing his job. Part of this job is implementing Scrum and comprises – among others – creating an understanding of the underlying concepts in the mind of the people involved. He acts as a change agent!
If you do have a Scrum Master who is a team member also, you should check the option, that he is not the Scrum Master of his own team. This prevents him from at least a few conflicts of interests and puts him in a better position for his moderation jobs.
Fortunately, we recently had a change. We do not have Scrum Masters any more, who are members of the developer teams the same time. A Scrum Master now is responsible for up to four teams and the same number of Product Owners.
Just two more ideas concerning the Scrum Master role, which may lead slightly off topic, but I find them worth mentioning here:
First, when starting to implement Scrum or trying to do Scrum seriously, I advise a Scrum Master not being part of the company originally, i.e., he should not be recruited from the existing staff. This helps him
- to have a better standing towards the management. A prophet has no honour in his own country.
- to have a better standing towards the team as well. For the team members do not know him, they have an open mind to what he tells.
- to be impartial, because he can be more objective. He does not know all the internal things of the company at the time he starts his job.
- to find out the skills and abilities of the team, because he can have an unprejudiced look on it.
Second, I hardly dare to mention, that of course a Scrum Master has to be well versed in Scrum, agility, etc. in general and to be well versed in his role in particular. I.e., when the decision for doing Scrum is made, an experienced Scrum Master should be engaged. Furthermore, the Scrum Master role requires a lot of soft skills – first to mention communication skills. (But the latter is worth another blog post…)