In the previous post, we talked about how Modern Agile teaches the necessity of safety as we seek to Banish Fear and Be Awesome. In part two of that series, we’ll look specifically at the Scrum Master role and what it takes to be awesome in that role.
Safe to be an Awesome Scrum Master
IMHO, a Scrum Master has the widest set of responsibilities and accountabilities of any Scrum Team role. From the Scrum Guide:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
In the Retrospective section it also states:
The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
Take a minute to read what Gunther Verheyen writes on the subject of courage, accountability and transparency, as it forms the basis of how I will use the terms here.
An SM’s duties include not only service to the Development team and Product Owner but also to the the organization as a whole. These are huge responsibilities which must be fulfilled while staying true to the 5 Scrum Values. The SM must lead through serving while being committed, courageous, focused, open and respectful of others.
I see an SM being awesome while operating with a prerequisite of safety a few ways…
The Accountable, Servant Leader…
…works to unlock the creativity and effectiveness of others.
…must be free to practice self-sacrifice and hone the skill of Agenda-less Scrum Mastering.
…is able to account for the state of Scrum practice and is courageous enough to be transparent about it.
…has the courage to take on the responsibility of organizational change even though she cannot assure the outcome.
…doesn’t give in (often) or lose hope (completely) during the arduous practice of promoting and supporting a Scrum implementation.
The Experienced, Scrum Practitioner…
…understands Scrum and agility thoroughly.
…evangelizes professional Scrum without fanaticism.
…understands the breadth, commitment, and urgency of change and is careful to promote commitment to change, not just change for its own sake.
…leads through empiricism yet understands the validity and power of natural belief in those she leads.
…knows how to identify when a Scrum team has internalized the values of agility and may safely diverge from Scrum.
The Free and Selfless Coach…
…calls forth and evokes change rather than convincing them to be a certain way.
…is not punished for the behavior of those she coaches.
…courageously refuses to betray the trust of those she coaches.
…is disciplined to be neutral yet fully engaged when coaching.
…glories in teams and individuals who grow out of their need of her :).
The Empowered Impediment Remover…
…has access to direct or indirect means of removing impediments.
…tenaciously clears the way for teams to work without waste.
…encourages others to remove their own impediments when possible.
…feels safe to fail until she succeeds.
Organizational change, team and individual coaching, application of Scrum and agility in complex product development — these are hard problems. It requires courage, safety and support for those who seek to be responsible and accountable for them. This is not a job for the weak hearted or those made culpable as a project manager would. It requires the Scrum Master to be a combination of resolute and winsome, one willing to champion the unpopular yet free of judgment for those who disagree vehemently. At the same time she must be both teacher and student, leader and servant. This can be a difficult role for those who do not love it.
What is holding you back from being an awesome Scrum Master? What has to change before it is safe in your organization to be an awesome Scrum Master?
Stay tuned for next time when we’ll ask the same questions of the Development Team.