This article is dedicated to providing a detailed explanation of Misunderstood Stances of a Scrum Master mentioned in the Scrum Master. This Is The Way article. Like its original version proposed by Barry Overeem in The 8 Stances of a Scrum Master whitepaper, it should serve as a guide for a Scrum Master to understand the most common behavioral patterns that hinder a Scrum Master from staying on The Way of a Scrum Master.
Apart from some changes and clarifications, the model provided in this article extends the original one. So, it should help Scrum Masters keep on The Way in most work situations. Moreover, you can always find the comparison with the original model in Scrum Master. Evolution of Stances article.
While reading this article, you will see such references as “proper” Stances — they are described in the Scrum Master. This Is The Way article.
Unlike the latter one, Misunderstood Stances model cannot be complete because the number of ways to misuse a Scrum Master accountability is countless. Nevertheless, we will attempt to cover the most common cases here. Hence, it is deemed an Advanced Model.
2. Why Misunderstood?
The Way of a Scrum Master can be identified as follows:
Out of all ways available for a Scrum Master, the most valuable are those that enable the Scrum Team to continuously improve its capability to effectively self-manage in addressing complex problems through empiricism to maximize the generated business value.
All cases listed in this article will be described very briefly. The stances described here will implicitly mean that by taking them a Scrum Master does not help the team’s growth in self-management.
Moreover, a Scrum Master that acts in these stances might cause significant negative consequences for self-management culture.
Accountabilities are crucial in Scrum. Effective self-management is impossible without clear accountabilities. By acting in Misunderstood Stances, Scrum Masters sometimes take over Developer’s or Product Owner’s responsibilities, thus undermining their sense of accountability.
You cannot help people permanently by doing for them what they could and should do for themselves.
(associated with Abraham Lincoln)
In addition to what we mentioned above, such Misunderstood Stances as Policeman and Team Boss create a somewhat similar accountability ambiguity type. When a Scrum Master takes these stances, people start perceiving such a Scrum Master as someone with a superior position in the organization.
This makes it extremely hard for a Scrum Master to create a trustful atmosphere and culture of openness within the team, critical for improving self-management.
In some cases, Misunderstood Stances are taken just due to a misunderstanding of The Way of Scrum Masters. However, sometimes, the need to take these stances is caused by some organizational problems preventing people from fulfilling their accountabilities.
To provide you with some examples, see a shortlist of such problems:
- Lack of motivation of team members to do whatever needed to achieve product goals and therefore properly fulfill their accountabilities;
- Misunderstanding of accountabilities by management and/or team members that puts pressure on a Scrum Master or other team members to behave against their true role purposes;
- Pressure from outside the team (e.g., to “accelerate” or “show better organization results”) that stimulates people to shift their focus from fulfilling their accountabilities to doing whatever it takes to reduce such pressure;
- Numerous types of organizational dysfunctions: such as traditional Individual Performance Evaluation, lack of focus on multi-competent professional growth, etc.;
- Lack of skills or knowledge of team members about how to do something to fulfill their accountabilities effectively;
- and the list can go on.
In such cases, taking Misunderstood Stances is usually needed as a workaround. Thanks to them, a Scrum Master gets things done as those “things” are left untouched or done poorly by others. In reality, this is a short-term solution that removes only a symptom. The real underlying problem gets hidden behind the workaround and grows further.
Acting this way, a Scrum Master does not serve the purpose of the role as the team does not advance its capability to effectively self-manage. Such problems will surely come out again, and the story will repeat itself.
In fact, (s)he is doing the contrary and impedes the team’s growth into a self-managing organism. By hiding or ignoring the real problem, a Scrum Master actually abandons one of the primary responsibilities: “Causing the removal of impediments to the Scrum Team’s progress,” considering a longer-term “progress.”
And you should mind that unless you discover and treat the real causes of the problem, it might lead to severe consequences that would be way harder to solve.
You can compare this with an attempt to fix a headache, while a deeper analysis including other symptoms could reveal that it is actually cancer. By regularly fixing the headache, one can just hide the existence of cancer. But the latter will finally bring much more severe consequences than the benefits one gains by fixing the symptoms. Should one had done a proper analysis and undertaken a timely treatment, they would have had at least a chance.
From the perspective of achieving the Goal of a Scrum Master, acting in Misunderstood Stances causes waste of effort or even causes harm.
3. Eight Misunderstood Stances
Does something for others that do not require special knowledge and in general, anyone can do this:
- Sets up meetings which (s)he is not going to facilitate
- Takes meetings’ minutes that he/she do not facilitate
- Gathers people to a meeting (in case they are late)
- Reminds people about their planned activities
- Updates team vacation schedules
- Updates team meeting schedules
- Updates descriptions of Developers’ agreements about their processes
- Requests admins to change a workflow in a task tracker
- Updates Product Backlog (e.g., writes/updates PBIs)
- Updates Sprint Backlog (e.g., updates tasks and statuses)
This list can go on endlessly since we speak about everything that a Product Owner or Developers can do perfectly well themselves
3.2. Tool Manager
Ensures that tools used by other people work well. This encompasses both software tools (such as Jira, Trello, Confluence, Slack, etc.) and physical ones (such as burndown charts on a whiteboard).
In general, this may concern the tools:
- for Sprint progress tracking
- for the progress tracking of long-term goals
- for Sprint Backlog management
- for Product Backlog management
- for Release management
- for other activities, e.g., collaboration, communications, development, testing, etc.
Decision making on the tools to use
Suppose the organization does not prescribe that someone from outside the team is the one who makes decisions concerning the tools. In this case, those who need these tools to fulfill their responsibilities should decide the tools themselves.
Technical administration of software tools
The difference between this case and the misunderstood Secretary Stance is that the latter does not require particular expertise while administering software tools usually requires some knowledge and coordination.
Suppose an organization does not have a particular department or a 3rd party dedicated to providing a software tool-administration service. In this case, this responsibility lies on those who need these tools to fulfill their accountabilities.
This stance is about anyone who has ever received information and just passed it to someone else. To make it even more straightforward, let’s dive into some real-life examples:
- Serves as a messenger between Developers;
- Collects information from outside the team and passes it to team members and vice versa (e.g., informs developers about management decisions or reports to managers about team’s progress);
- Passes the information from Developers of one team to Developers of another team (e.g., acts as a representative of developers in cross-team syncs);
- Passes information from team to PO and vice versa (e.g., gets PBI clarification from PO for developers or collects status updates from developers for PO);
- Informs management/stakeholders about team problems (except for a Scrum Master acting as Impediment Remover);
- Not just holds the team accountable for ensuring its transparency, but reports to management/stakeholders on team progress in general or concerning specific team’s metrics.
In most cases, this Stance represents not only a set of behavioral anti-patterns but additionally a symptom of dysfunctional communication channels within an organization. Taking this misunderstood Stance, a Scrum Master hides the real problem.
For instance, sometimes managers do not have a reliable communication channel for teams, and people do not get important organizational updates. Instead of addressing this issue, managers may prefer to communicate these updates via Scrum Masters.
Sometimes, this is just easier to talk to 10 Scrum Masters (who will pass it to their teams) rather than 200 developers. However, additional harm comes from the fact that the information hand-over creates additional queues and leads to wasteful work, delays, miscommunication, and frustration. More about queuing theory can be found here.
Coordinates / organize people and processes. This may apply to work:
- between Developers of one Scrum Team
- between Developers of different Scrum Teams
- between Developers and Product Owner
- between a Scrum Team and stakeholders (e.g., managers)
In these cases, coordination is necessary to organize some people’s collaboration. Developers and a Product Owner, as part of a Scrum Team, are expected to self-manage. It simply means that coordination of their own work and collaboration with others is part of their accountabilities.
Two teams are expected to make some initial research necessary for PBR. A Scrum Master observes that teams are not planning to discuss it together and instead will do this without any coordination between them. This will most probably lead to double work or to not achieving goals. The Scrum Master gathers them in a meeting, drives them through the discussion, and finally arranges how the teams will coordinate from now on.
Same teams from the previous example. Several days after the meeting.
A Scrum Master checks the results of one team and the results of the other team. It looks like they worked in isolation and did not collaborate at all. The SM decides and declares that to each team that they are now going to sync with each other on a daily basis.
3.5. Team Extension
Does something that is Developer’s or Product Owner’s accountability. As a result, such a Scrum Master adds capacity to those roles by means of taking that capacity from the Scrum Master role.
Such activities may include:
- Tracking Sprint Progress, e.g., using a Sprint burn-down chart (as Developers’ extension);
- Tracking progress towards mid or long — term goals, e.g., using release burn-up chart (as PO’s extension);
- Deciding on PBIs estimates (as Developers’ extension);
- Deciding on PBIssplitting (as PO’s extension);
- Deciding on a Sprint Plan (as Developers’ extension);
- Deciding on a Release Plan (as PO’s extension);
- Participating in product increment creation, e.g., gathering requirements, writing code, testing, etc. (as Developers’ extension).
Sometimes, a Product Owner is overloaded, and Scrum Masters try to add their own capacity to help. Precisely because the combination of these two roles almost always leads to negative consequences, this is most likely a bad idea.
The demand for taking Team Extension Stance may come from the fact that Developers have a lack of capacity. In this case, a Scrum Master may combine these two roles or even switch to a Developer role completely.
In any case, if several roles are combined or there is a shift from one role to another, it should be entirely transparent for everyone.
And such decisions should be thoroughly considered taking into account all the pros and cons.
As a downside, there will be the value of the lost opportunity to spend this time and effort on activities that could help a team and organization make better progress towards the Optimizing Goal.
It should be clear that the quality of work as a Scrum Master may significantly decrease because (s)he additionally takes a Developer role:
- A combined Developer/Scrum Master usually becomes biased concerning what happens inside a team and team’s collaboration with a Product Owner;
- A combined Developer/Scrum Master lacks a full-picture view and runs higher risks of local optimization;
- A combined Developer/Scrum Master usually performs the Developers’ responsibility instead of making sure that Developers learn how to improve their capability to self-manage. In this case, the Misunderstood Stances such as Secretary, Tool Manager, Intermediary, Coordinator, Super Hero, Policeman become a new norm since the associated behavior is acceptable for a Developer;
- A combined Developer/Scrum Master has a constant conflict of interests, e.g., whether to focus on finishing an item by the end of a Sprint or spending some time observing a cross-team collaboration which has room for improvement;
- While switching between different tasks in one role leads to some loss of time/effort to switch the context. It gets way worse when the role is constantly switched;
- The quality of a Scrum Master’s work as Facilitator suffers first since this stance requires to keep a neutral position while the combined Developer/Scrum Master usually has to be a part of the discussion;
- The quality of a Scrum Master’s work as Professional Coach also suffers since the combined Developer/Scrum Master usually knows too much about the problem, and it is too hard to refrain from teaching.
3.6. Super Hero
Solves issues that people could resolve themselves. Here we consider only the cases, when:
- The concerned people could solve the issue if they had more time, motivation, etc.
- The issue is not really going to lead to critical implications for the organization if a Scrum Master does not start fixing it immediately.
This stance is one of the most common and hard-to-resist traps for Scrum Masters. First of all, it is tough to say “No” when someone asks you to help with some issue. This is even harder when you value relationships with the person in need of help.
Moreover, it is even much harder to stop doing this. First of all, because people get used to this stance of yours. Apart from this, you get addicted very quickly to the appreciation from teams and management for helping them fix things quickly. Fixing issues for others means doing something of apparent importance for them.
Consider that if the people concerned cannot fix their issues themselves, there are some hidden root causes. And by sorting out these issues for them, Scrum Masters hide real problems such as lack of time or people’s motivation to fix these issues themselves.
This Misunderstood Stance is most often mixed with Impediments Remover Stance. The difference lies in the conditions we listed as bullet points at the beginning of this chapter.
Holds team members to account for not following rules instead of allowing them to self-manage and hold each other accountable. This may happen in regards to:
- Scrum rules, without due empathy to people in their particular situation, not trying to ensure a clear understanding of why certain rules are essential and how to follow them considering the team’s context;
- Some metrics with targets either agreed within a team or imposed from outside;
- Working agreements that were agreed upon by team members themselves;
- Policies, standards, or processes within an organization;
- Official external regulations and mandatory industry standards.
When this is not about Scrum rules or the team’s working agreements, some organizations create special roles outside teams to detect violation cases and hold employees accountable for not following mandatory rules. This should not be the responsibility of a Scrum Master. Otherwise, this role is perceived as having a managing position, and we discussed this at the beginning of this article.
Members of a self-managing team are responsible for holding each other accountable for not following the rules themselves. This is a foundation of their self-management.
What could be done instead
Whenever Scrum Masters suspect some rules violation by team members, in most cases, their appropriate behavior would be to start with Observer Stance to understand the situation first.
Then, when it is the right time, Scrum Master can take Mirror Holder Stance to show the whole team the reflection of their actions. And the most important point here is that these reflections should focus on the fact that team members do not hold each other accountable for the rules violation rather than on the rule violation itself.
Mirror Holder Stance is most often misused when a Scrum Master takes Policeman Stance. As described above, the critical difference is in whom the Scrum Master holds accountable and for what. Read a full explanation of Mirror Holder Stance in the Scrum Master. This Is The Way article.
If the Team does not see benefits in having some rules they decided upon previously, they can change their decision but make it transparent.
If the Team does not see benefits in some Scrum elements, then instead of forcing people to follow those tools, a Scrum Master should ensure that people clearly understand why those elements exist in Scrum and why Scrum can be beneficial at all. Only when this understanding exists, but people still do not want that element, it makes sense to analyze why it happens.
Sometimes, Scrum might is not a wise choice. But sometimes, it might be a good choice, yet people are not motivated to achieve common goals through maximizing value.
Whatever are the root causes of people's unwillingness to follow Scrum rules, a Scrum Master should identify and address those root causes instead of forcing people.
Anyway, whatever is the situation, a Scrum Master can find proper stances in Scrum Master. This Is The Way article.
3.8. Team Boss
Makes decisions or has a significantly higher impact than other team members on:
- Hiring/firing team members;
- Team members’ motivation, e.g., through their individual performance assessment, financial compensation, bonuses distribution, etc.
Obviously, such a role would be perceived by team members as someone with a superior position. Hence, it could not be considered as a peer role.
What could be done instead
If this is the case, a Scrum Master should consider taking Change Agent Focusing Stance to change their role responsibilities.
4. Let’s Improve It Together
If you know some very common anti-pattern of a Scrum Master’s behavior that cannot be associated with any of the Misunderstood Stances described above, please leave a respective comment to this article.