Being a ScrumMaster is a Full-Time Endeavor
I oftentimes get asked whether the ScrumMaster is a full-time role or whether it should be combined with other roles such as QA Manager, Developer, Tester, etc. Although I have argued for both sides of this topic in the past, I’m now convinced taking a stand for the ScrumMaster as a full-time role is more beneficial not only for the person in the role, but also for the organization and the teams they serve.
As described by Schwaber and Sutherland in the official Scrum Guide, the ScrumMaster is one of the three roles that constitute every Scrum team (the others being the Product Owner and the development team). While the Product Owner is focused on building the right product and the development team is focused on building the product right, the ScrumMaster is focused on removing impediments to agility and helping everyone embrace the Scrum values, principles, and practices.
The ScrumMaster therefore acts as a coach to both the development team and the Product Owner. A ScrumMaster also provides process leadership, helping the Scrum team and the organization develop their own high-performing, organization-specific Scrum approach.
Together with the Agile Transformation Team (which approaches agility from an end-to-end organizational perspective), the ScrumMaster is one of the key roles shaping an environment that sustains an agile organization at the team, program and organizational levels.
Ok — this sounds fine and dandy — but what does it mean in terms of concrete deliverables? What is the ScrumMaster doing every day? How do they spend their time and what are they working on?
While there is no such thing as a definitive “ScrumMaster Playbook” to easily describe everything a ScrumMaster does (the role is far too complex for that), there is common agreement that a ScrumMaster’s work tends to converge around a few key responsibilities. Kenny Rubin does a nice job of summarizing these in his book “Essential Scrum”. Below are excerpts of his text:
The ScrumMaster is the agile coach for the Scrum team — both the development team and the product owner. By coaching both roles, the ScrumMaster can remove barriers between the roles and enable the product owner to directly drive development.
The ScrumMaster is often described as a servant leader of the Scrum team. Even when acting as the team’s coach, the ScrumMaster is first and foremost a servant to the Scrum team, ensuring that its highest-priority needs are being met. A servant leader would never ask, “So, what are you going to do for me today?” Instead, a servant leader asks, “So, what can I do today to help you and the team be more effective?”
The ScrumMaster is the Scrum team’s process authority. In this capacity, the ScrumMaster is empowered to ensure that the Scrum team enacts and adheres to the Scrum values, principles, and practices along with the Scrum team’s specific approaches. The ScrumMaster continuously helps the Scrum team improve the process, whenever possible, to maximize delivered business value.
The ScrumMaster protects the development team from outside interference so that it can remain focused on delivering business value every sprint. Interference can come from any number of sources, from managers who want to redirect team members in the middle of a sprint, to issues originating from other teams. No matter what the source of the interference, the ScrumMaster acts as an interceptor (fielding inquiries, addressing management, and arbitrating disputes) so that the team can focus on delivering value.
The ScrumMaster must help change more than faulty servers and similar impediments. A good ScrumMaster must help change minds as well. Scrum can be very disruptive to the status quo; the change that is required to be successful with Scrum can be difficult. The ScrumMaster helps others understand the need for change, the impacts of Scrum outside of the Scrum team, and the broad-reaching benefits Scrum can help achieve.
As would be expected, the relative focus and the concrete activities performed by the ScrumMaster will depend on where the team is in a given Sprint. Rubin illustrates as much in the following figure:
In the beginning and end of a Sprint, the ScrumMaster will focus a greater relative portion of their time on traditional Scrum activities (planning, prioritization, estimating, commitments, etc.). As the Sprint progresses, other elements of the role may come more into play.
So given all of this, is the ScrumMaster a full-time role?
Yes, as the teams form and Scrum is relative new to them, it is absolutely a full-time role. As the team matures and becomes more self-sustaining and actively embraces a continuous improvement mindset, the ScrumMaster may find that they have more capacity than when the team was less experienced. What to do then?
Although it might be tempting to have the ScrumMaster combine roles with another existing role (DevManager, QA Manager, Developer, etc.), there are conflicts of interest inherent in this setup — some more obvious than others.
What I have seen be successful at the companies I’ve worked for, is to have the ScrumMaster take on another team instead rather than take on another, distinct role.
As Rubin notes in Essential Scrum,
“becoming a good ScrumMaster requires acquiring a valuable, not-so-common set of skills. I prefer that a person who has those skills share them with multiple teams rather than spend time performing non-ScrumMaster activities”.
This scheme leverages the unique skills, knowledge and abilities of the ScrumMaster without having to confront the many conflicts of interest associated with other ScrumMaster role-combinations.
The implications of this is that agile organizations need to take the ScrumMaster role seriously and create a formal title with a career path, role portrait and all that it entails to appropriately value the ScrumMaster in the organization. Too often, organizations are not ready to take this step and instead places ScrumMasters in other, more traditional job categories (Engineering Lead, QA Manager, etc.) while in reality performing a very different job.
This is at best a temporary solution and at worst a symptom of a company that does not value the critical role ScrumMasters play in the organization. It might also serve as a leading indicator for great ScrumMasters to take their talents elsewhere.