3

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 something like this or this applied to scrum masters/agile coaches as a guidance.

  • 1
    The training and certification of scrum masters is such that all they bring to the table is process knowledge, unless they acquired coaching skills by a different path. Unfortunately, as a result of the training's focus on processes, many scrum masters remain stuck. Only the ones with an agile mindset of their own will seek to improve their coaching skills. It is those coaching skills, that separates the juniors from the mediors and seniors. So maybe you could look for "career levels" for coaches to help you out. Especially as even the scrum guide doesn't distinguish levels of scrum mastery. – Marjan Venema Nov 8 '16 at 11:34
  • That is an interesting insight. So far, in my mind I never distinguished between scrum masters' process knowledge and coaching functions, but I will definitely look into it and keep it in mind. – CMW Nov 8 '16 at 11:51
  • Personally, I think it is one of the main reasons for so many agile transitions not delivering what Agile promises. There are more reasons of course, but the total lack of attention for coaching skills in the training of people expected to coach the development team and the organization in their Scrum adoption (see scrum guide's scrum master description), certainly doesn't help. Recently published an article on it. – Marjan Venema Nov 8 '16 at 11:57
  • Second the coaching aspect. I would also add that it can have to do with business involvement. I junior scrum master is only focusing on his team. A more senior scrum master also coaches the business as a whole. – Majaii Nov 8 '16 at 15:38
7

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

enter image description here

Entry level: Can implement the tools and processes, but doesnt have a good understanding why the processes, practises, principles and value's 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 value's, but might not yet be the best to teach other Scrum Masters. But should coach teams on Agile practises like technical excellence.

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

Guru's: Leads (larger) succesful Agile transformations, writes books, etc..

  • +1 This is what I was alluding to with "It is those coaching skills, that separates the juniors from the mediors and seniors." in my comment to the question. Like how you gave the various (coaching) levels explicit skills and scope. – Marjan Venema Nov 9 '16 at 8:51
  • Lysa Adkins describes a growth path for Agile coaches in her book coachingagileteams.com , but I am not sure that a Senior Agile coach and a Senior Scrum Master are the same. – Niels van Reijmersdal Nov 9 '16 at 9:00
  • Personally, I think that the way you describe senior scrum masters may effectively be a junior agile coach level? (Haven't read the growth path yet). Maybe the levels you describe here have more to do with Agile Coaches? Scrum master being the entry level job, with intermediate level the start of the Agile Coach levels? From all the job postings I have seen, scrum master does seem the way in to Agile Coaching. Also think that Agile Coaching distinguishes itself from process change management (business redesign) mainly in coaching/people skills level of experience with "higher" management? – Marjan Venema Nov 9 '16 at 9:18
  • I think you are right it could be a junior agile coach. After reading this post: agile-ux.com/2010/03/30/the-scrummaster-is-not-an-agile-coach I guess not everyone agrees with the fact that Scrum states: "Leading and coaching the organization in its Scrum adoption;" or it does not include anything other then what the Scrum guide describes. – Niels van Reijmersdal Nov 9 '16 at 12:18
  • Interesting. Will go through it in more detail later. Mind you, there are also many interpretations of the word 'coach'. A coach in the sense of the training I am in at the moment (personal or team coach focused on what s/he/they want to accomplish) is entirely different from a coach hired for there subject matter expertise, where it becomes more of a 'consultancy' approach - sort of like sports coaches? Agile coaches seem expected to combine the two. – Marjan Venema Nov 9 '16 at 15:58
3

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.

  • Are they technical or not? I do a lot of what a mid level SM does, but don't actually write code. – bobo2000 Jan 13 '17 at 17:40
  • @bobo2000 None of our SMs write code. I am pretty sure that the classical agile-scrum methodology does NOT have SMs write code. They are facilitators who keep things on track and "remove roadblocks". – JBiggs Jan 13 '17 at 19:30
  • that's good to know, I was confused about whether they needed to code or not. Read some answers on here, where they say that SMs need to be extremely technical. – bobo2000 Jan 13 '17 at 20:42
2

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.

  • 1
    Scrum Master should not manage backlogs, that is something Product owners do. Daily Scrums (standups) should be mandatory on Junior level, not just on Senior level. But the worst is that your saying the Scrum Master should speak for the team, the SM should teach the team to self-organize and speak for them selves, not the other way around. In that aspect I also do not understand why SM masters should work with BA's and Stakeholders to work on requirements. The SM should facilitate that the developers and the PO do this in a productive way. You have some stuff right, but so much wrong. – Niels van Reijmersdal Nov 8 '16 at 18:20
  • "but so much wrong" - Indeed, find me an organization that does everything right. Every company is going to do things differently. I was relating what my experience is in my company. This is the path we have actually taken, right or not. Feel free to answer it yourself. – Tim Nov 8 '16 at 18:31
  • 1
    By "speak for the team" I meant be able to stand up in organizational PI meetings and explain what the team is working on in detail. I didn't necessarily mean make decisions. Manage backlog is the same thing. They should be able to work with BA's and provide input and help take care of roadblocks, do a lot of the grunt work of making cards and filling out details provided by the BA or PO, not so much making the decisions or setting priorities. – Tim Nov 8 '16 at 18:51
  • 1
    I expect a Scrum Master to teach self-organisation and not do the work for them. The Scrum team should create the cards and the Product Owner should update the organisation on which value the team is currently working. Ofcourse no organisation does every thing right, but we can aim high and continuously improve to get there. My team does not need me anymore to facilitate Scrum, they can perfectly execute a Sprint without me, but they do need me to help them to grow even further and become even more high-productive. – Niels van Reijmersdal Nov 8 '16 at 19:57
  • Ok that makes sense. More of a work yourself out of a job mindset. I don't think we have that as our goal. One difference is my org is struggling with resources. My team has no BA right now and our product owner is way too busy to provide updates, so it ends up being the scrum master who does that stuff. Good info for the future. Looks like we have a ways to go yet as a company in our agile maturity. – Tim Nov 8 '16 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.