Skip to content

The big Scrum Master misunderstanding

This morning I received a Scrum Master job spec.  About 5 years ago these were really bad – essentially Project Manager jobs with a different name. They have gotten better and I’m even noticing words like collaboration and facilitation. The one I read this morning caught my attention as the opening paragraph was great and then it got weird. Anyway. I decided it was worth debunking each Key Responsibility and highlighting whose responsibility that is in Scrum and why.

(NOTE: there are some good job specs – I’ve included one at the bottom of this post)

Key responsibilities

– Run daily, weekly and monthly agile rituals efficiently and strictly

I agree the Scrum Master (SM) should ensure these are happening, however it is not their responsibility to run them. If they are not happening the SM should figure out why and help solve the underlying impediment.

– Tracks work progress to identify blockages and developer divergence from allocated tasks

The team tracks their own progress during the sprint and also allocates tasks themselves. The Product Owner (PO) tracks work progress against the release or product. The SM should note blockages and divergence and help the team and PO to solve these impediments.

– Blocks Business, Operational Staff and Product owners from interference with Development Structure

Uh no. Just no. An SM needs to encourage communication with Business, Ops and PO’s not block it. Find a way to allow effective communication to happen with all parties and encourage that it keeps happening. If there is ‘interference’ then the SM should dig deeper to solve the underlying problem of why interference is needed.

– Polices channels for submission of development work requests

What? No. The PO is responsible for all work that the team receives, thus if there are multiple channels to monitor it should be the POs responsibility. What the SM could do here is help resolve the multiple channels, into something simpler and easy for the PO to manage.

– Implements structure changes and strategy that are generated by agile retrospectives

Actions from the retrospective are for the team to own, action and do. The SM might note larger impediments and start working on those.

– High velocity communicator – making sure that all information regarding changes in scope, delays & other detrimental events are communicated to those involved with the piece of work as soon as they arise

Yes the SM should be a great communicator, but detrimental events should be communicated by the team and the PO. Changes in Scope should be a discussion with the PO and the team. If these detrimental events occur often, then the SM should be looking at solving the causes of this. Likewise if scope is changing mid sprint often, the SM might focus on having more grooming sessions and look into some techniques to use in grooming to prevent this happening mid-sprint.

– Blocks stories that do not contain the right level of detail from entering the Dev Structure

Uh no. If the team doesn’t have enough detail then they should explain that during grooming and not commit to taking in the story during sprint planning 1. If the SM notices that the story seems vague they can ask questions to help the team surface these assumptions and questions.

– Blocks changes to work once in development without following the proper re-evaluation process

Uh no. Change is encouraged as is feedback in Scrum. Should something change mid-sprint, if the team feels they can accommodate the change without it affecting their sprint commitment – excellent  it is in. If the team feels they can’t take on the change and make their commitment – the PO decides what is more important and drops stories from the sprint.

– Removes blockers with extreme prejudice when raised by development team

To be fair, I’m not sure what “with extreme prejudice” means in this context. Anything preventing the team from going as fast as possible is an impediment. The SM’s job is to ensure these are removed, but not necessarily by removing impediments themselves, they can help the team and PO to remove these themselves if possible.

Essential Skills and competencies

– Certified Scrum Master

There are many other certification schemes than just a CSM. So if you’re screening based on these 3 letters you’re making a mistake. Plus all this means is I sat in a class for 2 days. Seriously HOW is that essential to being a good SM?

– Tertiary Degree in Commerce, IT or Engineering

Why do you need a degree to be an SM? You require communication and people skills in buckets. Commerce, IT and Engineering may help you understand jargon but it also means you make assumptions when working with tech teams. By the way – Scrum is not just for Tech teams. Some of the best SM’s I know have no techie background. So making this an essential requirement is odd and short sighted.

– 3-5 years as Scrum Master or Agile Project Manager

Experience as an SM is great to have. As for Agile Project Manager – I don’t know what that is but I can tell you the skills to be a Project Manager and the skills to be a great SM are VERY different. If you have a PM becoming an SM they need to unlearn many things – it’s not impossible, just very difficult.

– 5 years in Agile Development Environment

As above any experience is important. Even if its experience in doing this agile thing badly – it all helps.

– Strong communicator

More importantly an effective communicator. SM need to be able to communicate in many different forms and with many different people.

– Experience running Scrum with Jira

This is probably important to this company. More important is that the SM knows various tools and how to simplify them and use them for what they are good for. Sadly most Jira implementations try and enforce a process and thus end up becoming hugely over complicated things. The SM should try and remove this impediment – there are many ways to do this. Also the SM should not be using Jira. This tool is for the team and the PO to visualise work and then act on the info.

A great Scrum Master job spec:

I got this job spec for an SM here and have pasted it in, as the ad will probably be removed at some point. The same people have written a blog post on on what makes a good SM job spec, a very good read.

Your tasks

  • Guide and coach the team and organisation to follow Agile/Scrum practices
  • Guide and coach the team to become self-organized
  • Help the team assess their ‘Scrum Maturity’ and higher levels of maturity
  • Improve transparency within the team
  • Remove impediments
  • Guide the team to find the right person within the organisation that can help them
  • Build a safe and trusting environment where conflicts can be managed in a healthy way without fear of blame
  • Be responsible for supporting and coaching the Product Owner on Agile/Scrum practices

Your profile

  • Experienced in a Scrum Master role for at least two years for a software development team
  • Good skills and knowledge of facilitation, continuous improvement, empowerment, transparency and servant leadership
  • Knowledge of Agile approaches – Kanban, Scrum, XP, etc.
  • Knowledge and experience with Agile techniques – Automated Testing, User Stories, TDD, Continuous Integration, Testing, Pairing, Agile Games, etc.

You will notice this job spec has much more emphasis on the coaching aspect of the SM, and on responsibility of growing the team. The experience also mentions various agile approaches and techniques. Much more important than a certification or degree.

9 thoughts on “The big Scrum Master misunderstanding”

  1. I agree with your summary wholeheartedly, especially the CSM requirement – if, for example, I already have 5+ years of experience as a successful SM and feel that negates the need for a piece of paper saying I’m a qualified SM, that doesn’t make me any worse at the job!

    I’m interested to hear your thoughts on:
    1. Do you believe a Scrum Master for software delivery projects needs to have at least a partially technical background or would a broad understanding of key concepts suffice? I ask this based on the great SM job spec you cite here, specifically the bit about knowledge of agile techniques such as automated testing, TDD and Continuous Integration and the depth of understanding required.

    2. Is a Scrum Master always a full time job or should they be spread across multiple teams where teams are experienced? The scenario I’m imagining is an experienced PO and group of devs, well versed in agile. In theory they need less coaching and if things are going well, will likely experience less blockers.

    1. Hi Nick,
      I believe that if the team is a technical team the Scrum Master will pick up enough domain language over time. I personally don’t think that much knowledge is required. You can facilitate a great session just by watching body language and asking clarifying questions. I have seen non-technical SMs struggle to understand lingo and then after a few months realise that the lingo is not the important part. I think if you are confident in your ability as a SM then this is not a problem. Introducing new techniques that you have never tried and don’t fully understand is kind of the idea 🙂 If I happen to read about #noestimates – I don’t need to attend a course to understand it, I just need to go – wow interesting and forward it along to the team who will try it if they find it interesting.

      The full time job is an interesting one. I believe all SMs should be trying to work themselves out of a job always. If a team has been together for a while they should be used to trying new things and growing as a team. Perhaps a coach looking in every now and then can inject new ideas. That said, most teams I know of don’t stay together for that long. There is churn and over a 2 year period, 80 % of the team has changed. In this case the SM has a fairly constant job in building trust and helping that team grow and navigate new members.

      For me the sign of a team not needing a SM is when the continuously inspect and adapt. If I can see them stop, pause and fix something in their process then they are doing great.

      Hope that helps!

  2. Great article Sam, totally agree with your points. Do you think the problem of writing bad specs lies with the business that is trying to find a good ScrumMaster or with the agency they have hired not knowing the role?
    I found it interesting that one recruitment agency attended a lean coffee a couple of months ago to try to work out what a ScrumMaster actually does, I found that a breath of fresh air!

    1. Sadly I’ve heard of great Scrum Masters not making it to interviews because recruitment agencies block them for not being qualified. This might be a misunderstanding from the recruitment agency but its probably a company specification that insists on some or other important qualification. Its so sad. And it makes me mad.

  3. Excellent article. I still see several ‘Scrum Master/Project Manager’ or ‘Scrum Master/Technical lead’ job postings. I read through the job description and use that as a gauge to determine if that company is being or doing Agile. Hopefully such postings will change as HR or hiring managers get a clearer understanding of the SM role and it’s responsibility.

  4. Pingback: ScrumMaster Job Description

Comments are closed.