In the majority of cases, a Scrum Master functions as a disruptor of complacency – the focus of their work lies in continuous improvement, finding ways to remove impediments, ultimately becoming someone that would guide the organisation towards agility. Having said that, what an organisation declares they want to achieve does not necessarily mean they are going to take any steps towards achievement of the said goals.

For HR branding reasons, it is not cool to actively hire Project Secretaries or Project Coordinators – someone to do low-effort administrative tasks and help speak on behalf of the people getting things done. Such positions do not require any specific agile framework knowledge, they are barely visible, and won’t be there to transform the organisation or bring any challenges for the leadership a Scrum Master could do. If a Scrum Master is hired for such a position, the frustration caused by a mismatch between what a Scrum Master expects their work to be and what turns out to be the reality in such cases.

After a certain amount of time, a Scrum Master hired for anything but being a Scrum Master starts looking for a new job – the inability to create positive change really goes a long way. In order to avoid a downward spiral, here are a few observations that you probably should give up on fighting in an unwinnable battle:

1. Your initiatives are being deprioritised – the suggestions you are putting forward are not getting enough traction even if this is something the team wants to see happen and is a pure “bottom-up” example.
2. Your meetings are the first ones to be rescheduled, even if the agenda clearly benefits the Stakeholder participants – okay, imagine a situation. You agree to have a one-to-one meeting with someone up there in the food chain, you agree on time, schedule a meeting – only to get it rescheduled by the Stakeholder multiple times. Reschedule it once – feels like something that could happen to anyone, reschedule the same meeting twice – seems like a cascade of unfortunate events. At the third rescheduling it is always better to cancel the meeting altogether, as it doesn’t receive needed traction. Describe (without going into details) the idea in a quick email and carry on with your day.
3. Your responsibilities are becoming blurrier with each day – there is a fine line between “supporting a Product Owner” and “managing the Product Backlog in their stead”. If you have a question in your head that sounds something like “but why is this something I should be doing instead of this position”, and nobody can give you a clear answer to this question – then your inner voice is right, and the leadership just doesn’t know what Scrum Masters should be doing.
4. …or your responsibilities are those of court jesters – yes, Scrum Masters are responsible for having a positive atmosphere in the team. No, this is not their only responsibility – if you feel like the only input you produce is similar to being a comic relief character in some cheap romcom, maybe something has gone terribly wrong, and this very position is not capable of providing you with actual responsibilities.
5. You have to defend yourself all the time – in a faux agile organisation you will never be fully understood, and if there are any disagreements you will have a need to defend your positions against everyone instead of having a sustainable collaborative process of reaching consensus. And, most importantly,
6. Your leadership fails you.

When it comes to implementing Scrum, we should remind ourselves why exactly we are implementing the framework. Is it because it allows us to consistently deliver value to the end users? Sounds lovely, but… it’s not the only framework that does that. You can absolutely do agile without Scrum.

Should Scrum be your first choice? It depends. When it comes to starting with a new team, the background of the team members matters a lot. Some cultures simply don’t allow building a horizontal structure in a workplace – there is a culturally imposed hierarchy, which doesn’t make sense breaking for the sake of doing Scrum. Will your Product Owner be truly empowered to make evidence-driven decisions that challenge the directives coming from the stakeholders? Will the team actually be in charge of the Sprint Backlog? Are there any checks in place that would prevent the so-called seagull management?

Some cultures do not share the same values as Scrum does – and while commitment, courage, focus, openness and respect are ideal to have in any venture, it’s barely possible to imagine a, say, Middle-eastern or Japanese culture exhibiting the value of courage and being able to challenge the higher-ups. Despite that, some agile consultants keep bringing forward the idea that Scrum is the way to go, and when implemented as a directive from the management, it leads to the following issues:

1. Lack of transparency in the decision-making process – the team is not really in charge of the internal processes. The management (allegedly) knows best what the team members need, creating excessive bureaucracy and it is barely possible to drive the change from the bottom up.
2. The inability to confront the existing issues means that the disappointment in the working processes will grow exponentially, thus leading the team members to burn out – leading to a high turnover rate. They have been promised the idea of doing something that doesn’t really match with the reality.
3. Unempowered middle-level decision-makers – a Product Owner will function as a Business Analyst at best, writing down user stories that have already been decided by a Product Manager, who has, in their turn, received them from a Product Director or the end client. This presence of middlemen does not nurture the cooperation between the development team and the end users, making it hard to predict what the end user actually wants.

We are certainly not forgetting the cases when Scrum is not needed, because the product itself is straightforward. The team has implemented, say, three or four products that are exactly the same. They know it like the back of their hand – Scrum will not be of good use there, as it is designed to work in complex environments, prone to change. In such cases, the team will lose their capacity on the Scrum ceremonies instead of actually working on the implementation – and instead of finding a Scrum Master, go with a Project Manager to control the delivery and (although unlikely) support the team.

Long story short – don’t push one framework as if it will magically solve all issues you experience in your organization. Consider the benefits and drawbacks of using each of the options, before settling on something particular.

One great advantage of a Scrum Team is having shared responsibility – the entire team is accountable for the overall delivery of a quality product. Don’t get me wrong – the idea of shared responsibility is great for a variety of reasons – team members feel supported by their peers, they are focused on the goals and the ways to achieve them, and they have a say in the development process.

Of course, it’s not all sunshine and rainbows – some people may use this idea for their personal advantage – mainly, to work less. If they personally make little effort to contribute to Sprint Goal achievement, but the entire team performs well – they still receive all the praise from the Stakeholders, and there is no clear mechanism to single out one person and make adjustments to the team that works great and reaches all the milestones – making replacements might incur more potential problems in the long run, negatively impacting the morale of the team.

I wouldn’t, however, say you should just ignore the free riders – the other team members might take notice of such behaviour and follow a bad example. Luckily, the ability of a team to self-organise might help a Scrum Master a lot. Quarterly peer ratings might be helpful to assess the individual contributions of each team member – this way the team has a process of penalising the worst examples of free riding, and to make the worst offenders to contribute to the team.

One important detail: the individual performance of each team member should be taking within the existing context, e.g. their seniority level, how long have they been working in the team (we certainly should give the newcomers opportunities to familiarise themselves with the existing ways of working), what tasks they are taking – in some cases, it may appear that the person is not contributing much based on the raw data alone; it is a job of a diligent Scrum Master to raise flags if necessary.