Identifying Red Flags for Scrum Master Job Postings

Have you ever applied for a job after reading the job description and felt the elation of securing it, only to find out later that you have been set up for failure? Maybe this could have all been avoided if you had seen the red flags in the job description.

In my last post , I shared some tips on the things job interviewers or hirers should look out for to identify potentially excellent Scrum Masters for their organization. Flipping over to the other side of the coin as a Scrum Master (SM) looking for a job, I would like to share 8 tips on spotting the red flags when reading the job description of a Scrum Master position:

1. The job title and description mention “Scrum Master/ Agile Project Manager” or “Scrum Master/ Business Analyst”. If you aren’t a Scrum Master, you will be doing a different job. Maybe you will have to perform two roles so that you won’t be a resource that is less than 100% utilized. Or maybe the organization is looking for a Project Manager or a Business Analyst with Scrum Master experience. Hirers should get a proper Business Analyst if they want SMs to “understand and analyze requirements” and “evaluate newly released functionalities so that they can recommend suitable solutions for implementation”. If you aspire to be a full-time Scrum Master, perhaps it is better to avoid applying to such positions.
2. The job posting mentions being a Scrum Master to Agile projects. Scrum is best used to develop products with stable teams. When projects take on a waterfall-ish nature without long-lived teams, the Scrum implementation would be sub-optimal. The propensity to adapt to changes in the plan is lessened with projects. This is an additional hurdle for the Scrum Master to overcome.
3. You are reporting to the Project Management Office (PMO) instead of the Agile Centre of Excellence or the Transformation Office. This is a signal that the organization is trying to inject change using the old operating system. Similar to fitting a square peg in a round hole, we see the Scrum Master being subjected to the old organizational structure. For real change to happen, the organization will need to view the move to Scrum as a paradigm shift, and putting Agile under the PMO is not a good start.
4. Be wary when the language used in the JD is very “push” instead of “pull”. There are usually elements of project management in the job description (JD), which signals that the hirer may not have a good understanding of Scrum, and they perceive the Scrum Master to be the new Project Manager. There is nothing wrong with projects but Scrum Teams can thrive better when doing product development. Moreover, the organization might have a culture of telling people to do something instead of giving them the autonomy to figure out the solution for themselves. This culture generates many disengaged employees because they are “forced” to do things in a certain way. For example, the JD states that the Scrum Master should “lead project meetings and process activities”, “prioritize and oversee the tasks of the team” as well as “ensure the team follows best practices”. Scrum teams are self-organizing so SMs should use the power of influence and persuasion to have the team come to a conclusion on the practices that work well in their situation. How about “create reliable and practical plans for projects” or “provide regular status reports”? The one I love most of all is “knowledge of project life cycle in Scrum, Waterfall, etc”.
5. The JD mentions other tasks outside the scope of an SM. The SM’s job is quite hands-on especially if there are multiple teams to lead. Resolving lots of impediments at a team and system level will keep the SM busy all week. Throwing in additional responsibilities like “daily submission of reports to Compliance” or “manage IT vendors to provide efficient solutions and timely project delivery” just gets in the way of the SM’s main goal - which is to make the Scrum Team become a high-performing team that consistently and sustainably deliver great products that please the customer. It doesn’t help when the SM has to take on responsibilities of the team or other roles such as “ensuring quality in the development process and providing ongoing maintenance” or “managing estimation and roadmaps”.
6. There is no mention of the SM having to possess leadership or having to lead the team in the JD. Unlike managers, SMs essentially are true leaders who serve. They create the right environment for people to thrive and for Scrum to work rather than see people as resources to be managed. Team members are to self-organize towards the goals that brought them together in the first place and are not directed by anyone (unless permitted) on how to deliver the expected results.
7. The JD is littered frequently with Agile processes, practices, and methodologies. It may signal a view from the hirer that the SM is this person who can magically make things better if they can force teams to do things in a certain way. Things get better when senior leadership and teams adopt new ways of thinking on collaborating, seeking better alignment, and adapting to changes.
8. The responsibilities stated in the JD are very action-oriented and relegate the SM to a servant rather than a true leader. The JD mentions that the SM is to “arrange Scrum ceremonies (Events)”, “create processes to reduce time-to-market” and “take down minutes”. There is no mention of coaching teams or senior leadership. The expectation from coaching is to “mentor individuals on tools and processes so that the team adheres to best practices”.

I hope that these few pointers will be helpful to you in filtering out SM jobs that might seem questionable. Happy job hunting!