Authority and Trust: Finding the Scrum Master Balance
Look up the definition of Scrum Master and you will often read they have “process authority.” Now imagine working with a new team that has become familiar with that term and immediately sensing unease and even a touch of hostility as team members ask: “Is the Scrum Master my boss,” “Do we have to listen to her,” and “What authority does he have, anyway?” Whether you agree with “process authority” or not, the term is out there, and it can often create a lot of angst and leave team members thinking they have to do what the Scrum Master says.
I worked on a new Scrum project where the project teams were concerned about the process authority definition. As a result, they were slightly hostile to the Scrum Master role, untrusting of the Scrum Master’s responsibility, and concerned Scrum Masters had authority to tell the teams what to do. I was the project’s agile coach and needed to diffuse the confusion and better the working environment as quickly as possible. Of course, this did not happen overnight, but my journey started with this interactive presentation and discussion many found helpful.
This presentation explores topics to help ease the tension and confusion surrounding the Scrum Master role that teams unfamiliar with Scrum may create. These topics include…
- How the "deliverable" of a Scrum Master is different than the "deliverable" of a team member
- How different leadership styles play a role into servant leadership
- What it means (and does not mean) when the Scrum Master has “process authority”
- The importance of trust in a Scrum Master/team relationship
The presentation uses real-time audience feedback to further explore these topics. Audience members will provide answers to questions provided throughout the presentation, so we can explore members’ thoughts, opinions, and experiences they have had with Scrum Masters.
Outline/Structure of the Talk
The session is divided into four overarching sections:
- Scrum Master Expectations. The expectations from the Scrum Master should be viewed differently than that of the development team (I call these expectations the “deliverables”). This section takes an interesting and perhaps surprising view of how we should think about these expectations.
- Leadership Styles. Servant leadership is, of course, important. But Scrum Masters can come from many leadership styles. As we keep servant leadership in mind, which leadership style should an Scrum Master consider?
- Process Authority. Many debates swirl around the idea of the Scrum Master as the “process authority.” What does authority mean anyway? This section examines the notion of “process authority” and provides a perspective to help put this in a better light.
- Trust. Perhaps more than anything else, trust is a must between the Scrum Master and everyone else. How is it gained?
This presentation is interactive and uses real-time polling to engage audience members to participate in the presentation discussion. Particularly, audience members will provide feedback concerning experiences they have had with leadership styles and the ideas around process authority. This feedback will be incorporated into the presentation and used to enhance the ideas discussed.
You will walk away from this presentation having learned…
- How to describe the concept of process authority to diffuse concerns – especially helpful to those teams who are unsure and untrusting of the Scrum Master role.
- How different leadership styles play an important part toward servant leadership and team dynamics.
- Helpful examples, metaphors, and illustrations to better explain the role of the Scrum Master, the importance of the role, and the expectations a team should have of the Scrum Master.
- The importance of Trust in a Scrum Master / team relationship.
- Helpful characteristics and traits a Scrum Master possesses.
- Other participants’ experiences of the topics above (using real time interactive polling).
Anyone who wants to learn more about the role of the Scrum Master
Prerequisites for Attendees
There are no prerequisites.