The ScrumMaster role might be the more difficult to define among the three role involved in Scrum. Starting from a “bad” ScrumMaster job description, Sam Laing discusses errors to avoid when you create such a role specification. As a bonus, she adds at the end a good ScrumMaster job description.
Author : Sam Laing, Growing Agile, http://growingagile.co.za/
This morning I received a ScrumMaster job description. About 5 years ago these were really bad, essentially Project Manager jobs with a different name. They have gotten better and I am 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 descriptions – I’ve included one at the bottom of this post)
– Run daily, weekly and monthly agile rituals efficiently and strictly
I agree the ScrumMaster (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 and 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. 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 am 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 ScrumMaster
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 ScrumMaster 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, then they need to unlearn many things. This is 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 visualize work and then act on the info.
A great ScrumMaster job description
I got this job description 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 what makes a good ScrumMaster job description, a very good read.
* Guide and coach the team and organization 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 organization 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
* Experienced in a ScrumMaster 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 specification 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.
About the author
Samantha Laing is an Agile coach for Growing Agile. She focuses on helping teams improve the way they work using agile techniques. She provides a mix of coaching and training to help organizations find their right path. This article has been originally published on http://www.growingagile.co.za/2016/09/the-big-scrum-master-misunderstanding/ and is reproduced here with permission.