We admit it: we are not Scrum Masters.

The Scrum Master role has been living a golden age for some years now, with hundreds of job offers and big demand, it being considered one of the emerging jobs in Spain. Spanish companies were in the midst of the Agile revolution and believed that in order to “be Agile” they had to have as many certified professionals in their ranks as possible.

This growth has been changing latelly. Although demand is still high, the trend is going down. What’s happening? Are things no longer done in an agile manner in our country?

One of the problems we’ve seen along the way has been that an entire way of doing things has been reduced to a mere working method, that Agile has been conflated with Scrum (when it encompasses much more than that) and that the idea has been further simplified by thinking that if we don’t have a Scrum Master we’re not doing things in an agile manner.

Let’s make it clear that agilism isn’t only the Scrum framework out there (although it’s by far the most widespread) but that there are many other valuable agile practices and methods such as XP, Kanban, etc that don’t require a Scrum Master. In short, there is a lot of Agile beyond Scrum.

Back to the Future

To understand what’s going on, let’s take a look at its history. Agile (and Scrum along with it) was born more than 20 years ago as a response to a very specific idea: to make better software. Thus, it began to spread among many development teams as a new way of working.

You’d meet a developer who’d read about it or a manager who’d been to a conference and who’d started to change the way they worked based on the very scant knowledge they had, which maybe they didn’t even fully understand.

Somehow, in better or worse ways, they managed to get good results, which impressed the companies, making agile methods increasingly popular in the industry.

And as with so many things, with popularisation came perversion. Loads of people saw the opportunity to improve their professional situation or get a better salary or even to change careers thanks to a fairly affordable certification (let’s not forget that the Scrum Guide is less than 20 pages long; it’s not exactly like getting ready to sit an examination for judge).

The market then became overcrowded with people claiming to be experts, some of whom might not even have worked in software development projects before.

Based on this, it’s easy to imagine the rest: Agile has been a big disappointment for both companies, which have invested in these processes, and development teams, which find themselves stuck with a role for which they have some repulsion.

How has this state of affairs affected projects?

Well, companies that hired a Scrum Master in the hopes of maximising the productivity of their development team and making it self-organised many times got something they didn’t expect.

In many cases, efforts were focused on implementing strictly an already lax framework, thus losing sight of the original goal of Agile. On this journey we’ve come across real fanatics who’ve put down any other practice (despite the fact that the Scrum Guide accepts them) arguing that it wasn’t Agile or people with no knowledge of technology leading a team in the methodological implementation of Agile and having delivery and their client’s interests take a back seat.

Thus, the client found out that it had hired a person who was supposed to increase the value of its investment but who in fact didn’t let it talk directly to the team “because it would be distracting,” didn’t let it make changes after planning, didn’t perform management tasks “because the guide doesn’t say that this should be done by the Scrum Master” or took the team’s self-organisation to the extreme, even if this meant failing to meet the commitments made.

These situations in which the Scrum Master had misunderstood the most basic principles of communication and collaboration with the client and of adaptability to change put the team at odds with increasing value, instead posing risks to the achievement of the objective.

Teams have experienced this role differently. In many cases, they had a person in their ranks who they didn’t see as being part of the team, someone who, with the team’s self-organisation as their governing principle, always looked at them at a remove and who they didn’t feel was truly involved in the project.

Teams that had worked according to more classic methods went from having a project manager who organised the tasks to a project manager who didn’t know the product’s functionality and didn’t understand the tasks or the problems they faced every day. They felt that they spent all their time stuck in meetings that didn’t allow them to concentrate on development and that sometimes had lost sight of the goal and were held only because the method said so.

Or a lot of times the Scrum Master was seen as a kind of enlightened despot who worked under the premise of “everything for the team, but without the team,” who organised dynamic meetings, regular meetings and processes for the good of the team but without first understanding what it actually needed for its day-to-day work.

As far as we’re concerned, given that the Scrum Guide – although apparently flexible – says that “although implementing only parts of Scrum is possible, the result is not Scrum,” let’s say it loud and clear: at Paradigma we don’t do Scrum. Because when we don’t have a Product Owner – something which the guide says (in a real client-provider environment, it’s usually a person from the business side of things with very little actual dedication), the team has to take on some of the Product Owner’s duties for the sake of the project; because when we can do so, we supplement the method with practices to improve it (something the guide prescribes), but when this is pointless, we adapt the method.

So... is Agile dead?

Agile still has a lot of mileage left – not only in software projects (as has been seen in other sectors). On the other hand, it’s worth noting that Agile’s big expansion has only been possible thanks to Scrum.

Scrum has brought agilism to many companies that would’ve never tried it otherwise and has helped teams understand that there are other ways of doing things. It has allowed companies to understand that it isn’t necessary to think so much in the long term, that it’s necessary to adapt, to divide and conquer, but we’re already at an evolutionary point where we need to know other methods in order to know which alternative works better in each context and be able to have the tools to apply the best ways of working to each project.

But let’s go back to the initial question: is the Scrum Master on the verge of extinction? Well, as in nature, when a species is endangered, it has two options: to adapt or to die. Paradoxically, adaptation is the premise behind agilism.

There’re people who haven’t had to adapt, people who understood from the very beginning that agilism is a means, not an end. Agilists who’ve been able to contribute to each team at the level that was necessary and who’ve adapted their management style to the maturity level of the teams, knowing when to lead and when to take a step back.

Professionals who’ve focused on metrics to help their clients make business decisions and their team think about how to improve and who’ve understood the needs of the project, of the client and of their colleagues. This is what being a true agile leader is all about.

At Paradigma we’ve gone back to the essence of agilism – its principles and values – and we know what works and what doesn’t in our context of developing projects with clients who trust us as a partner to evolve their business. We know that Scrum isn’t always applicable in all environments – it’s too general. This is why we’ve removed the “Scrum Master” label from the agilists in our Agile Circle. We want to go further by always building based on the agile principles we trust and focusing on delivering solutions.

The fact is that, in the Agile world, the figure of the Scrum Master isn’t that of a leader who guarantees delivery, who loses sleep thinking about how to make the project run better, a leader in which to see oneself reflected and who the team follows in times of difficulty.

This is why “Scrum Master” isn’t what defines our work; we prefer to call them Agile Delivery Leaders. First of all, because at Paradigma we don’t just apply Scrum – we work with other agile methods too, but much more importantly, because we also want our role to be not just one person who’s responsible for ensuring the working framework is observed: we’re committed to the project, to the team and to our client’s objectives.

We want to go back to the essence of what Agile was created for: making better software