What's expected from different career levels for a Scrum Master?

Question

Every career has juniors, intermediates, seniors, gurus, and whatnot. I'm looking for what separates the different levels so I know how to structure a career path within a company.

Ideally I'd like to have definitions that distinguishes between different levels applied to Scrum Master and Agile Coach roles as guidance. This short answer to a currently-closed question "What's the difference between Entry Level/Jr/Sr developers?" explains the differences as:

Entry Level - must give them explicit instructions, check everything they do, little or no design responsibility, no analysis responsibility

Junior - less explicit instructions, less checking, some minor design and analysis responsibility; helps the entry-level people find the compiler and use the repository

Senior - major design and analysis responsibility, is expected to correct oversights on his/her own, little/no checking, little/no instructions; helps the junior-level people learn/improve analysis and design skills

The currently-accepted answer on Software Engineering Stack Exchange is much longer, but makes similar distinctions.

Answer 1

I think the different levels can relate to the Agile Onion as described by Simon Powers.

Entry level: Can implement the tools and processes, but doesn't have a good understanding why the processes, practises, principles and values exist. Could lead to cargo-cult Agile.

Intermediate: Can work on a team level, but does not yet have the experience to change organizations. Understands principles and values, but might not yet be the best to teach other Scrum Masters. But should coach teams on Agile practices like technical excellence.

Senior: Assists management to create structural and cultural changes in the organisation to become more Agile. Leads the path through Agile Fluency.

Guru: Leads (larger) successful Agile transformations, writes books, etc..

Answer 2

In our organization, junior SMs facilitate the cadence of the project. They make sure the meetings happen, make sure the right people are there, help the team members self organize, and also track things like story point burndown, etc. They provide summaries of team work at internal sprint reviews, and bring up issues the team has to management. As with the classic definition of agile scrum, they are always looking out for impediments and seeking to remove them.

Mid level SMs are generally obvious because of their people skills. Mid level SMs are leaders (not in a traditional manager sense, but they are someone the team tends to look to and rely on). Mid level SMs are great at generating team cohesion and team morale tends to be high. At this level, the Sm tends to become much more comfortable using their experience to look at past sprints and be able to make projections about future work that make them very useful to PMO types. A SM at mid level can not only help facilitate a planning meeting, but has experience with the team and can contribute estimates of what might or might not be too big of an item to take on based on past performance. This tends to help the tech leads and BAs a lot.

Senior SMs tend to get sucked up into the management functions that are (in my opinion) the weak area of agile scrum. Senior SMs are often involved in organizing project-wide initiatives, keeping SQA efforts on track (organizationally), making sure that teams are covering needed areas when it comes to release issues, defect prioritization, etc. For a larger project, they tend to fill the void left where "self organize" basically fails (anything larger than 40 people or so) and step into a lot of roles traditionally covered by a PM or PMO staff. Unfortunately this means that senior SMs are often spread too thin between way too many responsibilities.

Answer 3

Junior

A junior scrum master should understand and be able to explain the fundamental principles and founding ideas behind agile. They should be able to explain to the more reluctant members of a team why they are doing Agile.

JSM's (if I can shorten it that way) should be able to facilitate and mediate all of the basic Agile ceremonies at a very informal, casual level. This would include daily standups, sprint planning, backlog refinement, sprint review, and retrospective meetings. They should understand the basic purpose of each meeting and provide the team some level of direction, as well as steer the meeting without meddling. Allow the right conversations to happen naturally, but also steer them away from going off on a tangent.

Intermediate

At this level, the scrum master needs to get better at understanding the team's work, and explain it or provide updates on things if required. ISM's should start helping with work intake. They should be able to have basic discussions with the team's business analyst and other stakeholders to help define and break down requirements and document work, and to make sure the requirements and the work intake capacity are in agreement with team goals and previous sprint capacities. They should be able to work with the product owner to understand priorities and should then ensure the team's sprint plans agree with those priorities, and help the team communicate to the PO any delays, roadblocks, or unexpected work coming in.

The scrum master should also act as a roadblock-mover. They should be able to help get things escalated and resolved so that the team can work more efficiently, and they should start to look at inter-team dynamics. For example, during retrospectives, they should begin to see if certain team members are causing trouble for others, and look at ways to remedy that. They should feel more comfortable having difficult discussions when necessary ("your behavior is hurting your team, what ideas do you have to fix that?"). Not taking on the role of manager, but they do have to manage certain things day to day and make sure the team is meeting their commitments. The scrum master should feel like an integral part of the team and should celebrate their team's successes and feel badly about things that slow their team down.

ISM's should help the team manage their backlog in terms of the grunt work of making cards and filling requirement details in and prioritizing work from discussions with stakeholders; they should be able to take a few notes as to what needs done and go do it later, without taking valuable time during the Agile meetings that could be used for team collaboration and discussion.

Meetings should become more structured and formalized. The team backlog should be well documented, either digitally or physically, and some effort should be made to ensure that cards are moved at each standup, and team members should be held accountable for providing an update. If they are not able to be physically present at the meeting, they should provide an update through email or some other means, having someone else fill in for them. The team should feel like they are in sync. There should be a working agreements document posted somewhere and the entire team should be aware of it and have voted it into practice.

ISM's should begin helping their team to become more self-organizing and to rely on the scrum master less and less. The greater their skill, the less they should be required, sort of shrinking into the background and being less of an active participant and more of an enabler and an observer.

Senior

At the senior level, scrum masters should build up a refined sense of their team's weaknesses and strengths and should develop a plan to specifically address those findings. They should feel comfortable addressing the team as a whole and with a certain amount of authority, only to motivate and enable them to do their best work. They should be able to address infractions and encourage the team to further adopt Agile practices. At this level the shift from "doing Agile" to "being Agile" should be complete. They should understand when their team feels uncomfortable with or resistant to being Agile, even when those concerns are not voiced out loud.

They should be able to get ahead of the game and help the team react to disruptors, getting resolution quickly or at least helping the team communicate the roadblocks effectively and work out what to do with the appropriate stakeholders. They should be experts at getting feedback and improving, not just the team but also themselves and how they facilitate the Agile ceremonies. They should use each meeting well, digging into the depths of the team's workload, publishing each triumph, and when issues occur, getting to the crux of what went wrong, and how to fix it going forward.

They should hold their team accountable to their working agreements and not be afraid to challenge team members and get tough when required. This should still be done in an Agile frame of mind, being willing to adapt if the team decides as a whole that things should change. Getting a feel for where the team is at and what they are thinking should be easy at this point. The working agreement document should be further refined and capture team policies for Agile meetings and learnings from past mistakes. The senior scrum master should be able to mediate and resolve conflicts between team members and to keep team meetings focused and productive.

At this stage they should ensure that all work is broken down into sprint size tasks prior to the beginning of a sprint, and that during the sprint the work is broken down further into day-size work or smaller, so that cards can be moved during the daily standup. Standups should be mandatory at this point, though the schedule would be somewhat flexible.

The retrospective in particular should be quite detailed and should really get the team thinking. Senior scrum masters know how to finesse every last detail from their team without having to beg for it, and how to help each person participate and enjoy doing so.

The SSM should become the "man behind the curtain" - helping the team along in their Agile maturity without interfering and teaching the team to run the scrum processes on their own more and more.

Guru

Scrum master gurus should be able to teach what they know and mentor new scrum masters. They should know Agile inside and out and be able to explain and defend its core tenets easily. They should be able to tailor their approach to an individual team and should be experts at reading people and understanding the team's interactions.

They should have a great enthusiasm for Agile and be able to relate any situation to its corresponding Agile principle. They should be able to perform the scrum ceremonies admirably for any team, whether brand new to Agile or quite mature. They should have multiple plans and ideas for every aspect of being Agile, and be able to quickly select the best one that applies to each scenario or to each team or even individual. They should be able to quickly build a deep technical knowledge of their team's workload that enables their team to be far more productive and efficient. They should be able to explain the work the team does in detail, and make minor decisions related to work intake, and should push back on attempts to overfill the team backlog or to hold the team to a previous velocity.

They should be able to teach the team to self-organize and manage their own backlog, and handle the Agile meetings and ceremonies smoothly and without intervention or moderation. They should exemplify Agile practices and be able to take criticism from the team, even requesting it, and use it to improve themselves. They should be able to help the team improve but to do so while being basically invisible.

Answer 4

TL;DR

You are trying to apply a legacy hierarchy to a framework that explicitly rejects the notion of a team hierarchy. This makes the question itself an anti-pattern within Scrum.

While HR departments and line managers often need to make these sorts of distinctions for organizational or political reasons having nothing to do with the Scrum framework or the values and principles of the agile manifesto—especially in high power-distance cultures or organizations—the only correct answer within the Scrum framework is to not make these distinctions at all. The Scrum Team is collectively responsible for the success or failure of its processes and delivery, and external definitions of seniority are not relevant to that that responsibility.

Analysis and Recommendations

The 2020 Scrum Guide makes no such distinctions. There are only three defined roles/accountabilities within the framework, and there's no provision for time-in-grade or experience levels for role titles.

With that said, there are certainly mature teams and (in the CMMI sense) immature teams. There are also people who are new to the framework or their role within it. However, while this distinction might be helpful in determining how to help the team adopt the framework or successfully adapt to it, it's important to understand that the Scrum framework doesn't recognize such distinctions:

Within a Scrum Team, there are no sub-teams or hierarchies.

Furthermore, seniority is not intrinsically relevant to the Scrum Team's internal processes. While a Scrum Team is ideally cross-functional, meaning the team collectively has all the necessary skills to deliver value each Sprint, the individuals within the team often have different skill sets and levels of experience. That means it's up to the team to determine how to share the collective responsibility of delivery because:

[A Scrum Team is] self-managing, meaning they internally decide who does what, when, and how.

Since there are no formal hierarchies, and all the Developers are simply "Developers," such decisions are generally based on who is best-suited for a given task. In this case, "best suited" is often an assessment the team collectively makes based on everyone's individual skills, the composition of the team, and each person's available capacity to take on work within the current Sprint. This should always be true, regardless of a person's external rank or title outside the Scrum Team. Ultimately, the whole Scrum Team is accountable for delivery of the Sprint Goal and the Product Increment for the Sprint, and the distinctions your trying to make don't change that.

If your organization chooses to make such distinctions outside the Scrum Framework, that's likely to be for financial or cultural reasons. This is within senior leadership's scope of authority. However, I'd consider it the role of the Product Owner, Scrum Master, and (to a lesser extent) the Scrum Team as a whole to help educate the organization on why this works against agility, and to try to help senior leadership come up with a better way to evaluate the effectiveness of its Scrum Teams and to hire/fire/reward people based on individual performance if they choose to do that in spite of the clear industry evidence that this is an agility anti-pattern.

Senior leadership is always ultimately accountable for "tone at the top." If they break the Scrum process, deliberately or not, then they get to keep both halves. Q.E.D.

End Note: Definitions are Relative

It's also worth pointing out that differences in experience—and the monetary or political value of those differences—are often relative. While many IT organizations often develop their own lexicon or time-in-grade for experience levels (e.g. many companies use 5 years as an arbitrary cut-off point, while others use the frequently-debunked 10,000 hours method), the reality is that the distinctions are typically idiosyncratic and company-specific, and are often formulated based on a combination of existing company culture, specific problem domain, and the current experience levels (however defined) of existing staff.

As an example, assume I have over 20 years of experience in certain programming languages. If you have only 10, but are better than me at that language, which one of us is "senior?" If I've been a professional subject matter expert (SME) at something for a decade, but you've got master of the same subject with five years of experience, does that make you a "journeyman SME" or are we peers with perhaps some different career experiences?

Also consider this counter-example. What if I've been working my rear end off for three years to be the best I can be at something, while you've been coasting in a comfortable sinecure for five? Which one of us is likely to be more experienced or better suited for a given project? Which of us is more deserving of a raise or bonus?

I'd argue that these distinctions are both relativistic and largely immaterial to how much value a given person can bring to a role, a team, or a project. This is where outcome-based assessments for the whole Scrum Team are often more valuable than trying to assign intrinsic value to arbitrary titles or to individual time-in-grade. Your organizational values will certainly vary, but the underlying truth of the proposition will not.

Answer 5

As a Scrum Master, you'll find that you have plenty of career options. The more experience you have with Scrum, you will find that you could take on the mantle of an Agile coach, a mentor, and guide, a Product Manager or Product Owner, or much more. A Scrum Master can become an organizational transformation expert by helping not just one team but several teams and departments in the organization. They can coach management teams, customer organizations, other Scrum teams, etc. to eventually play a crucial role in organizational development and transformation.