Knowledge Base / Scrum Team / Scrum Master / How is the Scrum Master?
The Scrum Master is present
A Scrum Master who is present is immediately aware of obstacles that are holding up the Developers’ work and can quickly take action to remove them before they threaten the Sprint Goal. A Scrum Master who perceives any deviations in Scrum practices can act to correct them, teaching and enabling the Developers and Product Owner to use Scrum correctly.
A Scrum Master who monitors the work of the Scrum Team is able to detect dysfunctional behaviors, conflicts or relationship issues among the Developers or between the Developers and the Product Owner and act as quickly as possible to help resolve these questions. In being present, he can protect the Developers from external interferences that threaten the Sprint Goal, which can occur at any time. In addition, he acts as a facilitator at Scrum events whenever necessary, and there is no way to do that without being present at them.
In short, the Scrum Master is ideally present whenever the Scrum Team needs him, which can mean a full-time job. Unfortunately, it is common for Scrum Masters to work part-time or with more than one team at the same time. In these cases, the Scrum Master may be needed at times when he will not be present. In this way, instead of saving money, the organization will waste the opportunity to fully have someone specialized in leveraging the work of the Scrum Team.
But remember, we do not expect a Scrum Master to continually prove their necessity for the Developers or the Product Owner to perform well. In fact, it’s quite the opposite! A good Scrum Master works to enable the Scrum Team to become more and more autonomous.
In general, a full-time Scrum Master is important for teams that have been working together for a short time, for teams that are beginning to use Scrum, for young teams, for teams inserted into hierarchical and bureaucratic organizations and for dysfunctional teams – that is, those facing serious problems in the way they operate.
Discussion: Can the Scrum Master also be…?
I have seen a lot of Scrum adoptions where the person who is the Scrum Master also works part time as a Developer. While this division of labor is not prohibited, exercising those two accountabilities can sacrifice the Scrum Master’s neutrality and thus hamper his work as a facilitator.
It is not uncommon for the Scrum Master’s suggestions or decisions to have, in the eyes of the other Developers, greater weight than their own opinions and for this reason they invariably feel they need to accept them. This type of situation can become more evident in times of crisis.
When such a scenario occurs, the Scrum Master ends up doing the opposite of what his work really should be: enabling the Developers to jointly increase their autonomy. Furthermore, mainly due to a lack of time and differences in the type of work, the activities of removing impediments, facilitation and acting as an agent of organizational change can be hampered when the Scrum Master also exercises a technical role.
Nevertheless, this can often be the most viable beginning point in an organization. By not understanding well what a Scrum Master is, management might not accept hiring someone full-time for this function and may end up transferring these responsibilities to a Developer.
If you find yourself in such a situation, the solution is not to refuse the adoption of Scrum. Seek to understand your responsibilities well, identify the limitations that the “double shift” is producing and, as a change agent, work within the organization to gradually make your work and that of other Scrum Masters viable full-time.
However, that said, we strongly recommend that the Scrum Master not accumulate the accountabilities of the Product Owner in the same Scrum Team. This recommendation was a rule in the first two versions of the official Scrum guide (SCHWABER, 2009, 2010), but was later withdrawn (SCHWABER; SUTHERLAND, 2011) to make the framework less prescriptive.
Should the accountabilities of the Scrum Master and Product Owner be concentrated in a single individual, the conflict of interest is exacerbated. There is no one to facilitate the relationship between the Product Owner and the Developers. There is no one to defend the Developers and educate the Product Owner if, dysfunctionally, the Product Owner seeks to interfere with the work during a Sprint. In these cases, the concentration of power can leave this individual with characteristics close to those of a traditional project manager, exercising command and control over the Developers.