Stop saying “Scrum Master”

How’s that for a controversial title? In all honesty though, stop it. Enough is enough — I will now refer to you all as Agilists.

As Agilists, we have first hand exposure to the ever changing world of software development. Not only are there new technologies and platforms on the rise, but many organizations are reimagining the way their software teams get work done and support their products. This means that Scrum isn’t always a good fit, and to be honest, neither is a traditional Scrum Master.

Now, I’m not saying that we don’t need someone on a team that upholds the Agile principles, facilitates discussions, and escalates impediments, but what I am saying is that these teams need more than that. Our software engineers continue to evolve, so we should too.

To get this out of the way first, Agilists should be free to run experiments with their teams as a way of fostering continuous improvement and delivery. Perhaps this means abandoning Scrum altogether and switching to Kanban or XP, or maybe even something more extreme like moving to a Squad model as evangelized by Spotify. So long as the team is onboard, anything is possible so long as delivery doesn’t suffer too much. With this in mind, why are we pigeon-holing our Agilists to just Scrum?

…so long as delivery doesn’t suffer too much.

Anytime you introduce something new, there will be a learning curve at first, there’s no such thing as “instant gratification” when dealing with change. Let’s not make it too difficult though.

As I mentioned earlier, a common definition of a Scrum Master is an individual that removes impediments and helps the team deliver quickly. Well, technical overhead and meetings slow the team down and impediments slow the team down. What if Agilists could handle these things for the team from end-to-end?

Excuse me, Sean, but Scrum Masters already handle impediments, you said this yourself.

Right, they do handle impediments, but typically only raise awareness or get the right people engaged. Often times, the engineers are the ones who explain the issue, but Agilists should be capable of handling the full end-to-end resolution: engage, explain, and follow-up.

Should we as Agilists be writing code or preparing architectural documents? No, not necessarily, but I do think that having foundational knowledge of coding and how the products work would be beneficial. At the end of the day, the Agilist is part of a team, and whether you like it or not, they should know exactly what the team is working on. These individuals should be able to hold their own in an architectural review session or postmortem for a production incident so the engineers can focus on what they do best.

I realize that this might be a challenge, but this is where we evolve. Gone are the days of simply attending a Certified Scrum Master class and calling it a day. We need more knowledge, more insights, and more experience. Take a coding class, get a certification, and have a desire to learn one way or another. We shouldn’t let everything change around us and in some ways, we should be the change.

Back to abandoning Scrum as I mentioned earlier, many organizations are doing just that. Not only does this reduce the amount of time we spend planning and increase the amount of time we spend doing, but it just makes sense in a DevOps culture that many organizations have adopted. Software teams are now supporting the products they build rather than throwing them over the wall, and since we cannot always predict production issues, it becomes a hassle to always account for “what-ifs” during Sprint Planning sessions. Gone are the days of strict release cadences or 2-week cycles, as with CICD and Cloud platforms like AWS or GCP, we can deploy to production faster than ever before. Priorities often change, too, and with that our teams may find that other methodologies set them up for greater success when pivoting from one thing to another.

So, since we know that having a job title tied to a specific methodology is weird, what do we call these Agilists? Well, Agilist works, but why not something like Agile Delivery Lead or Technical Program Manager? I’m leaving Agile Coach out for a reason, because at that level, you’re typically coaching a lot of teams, whereas a present-day Scrum Master is usually only “coaching” one or two. Agile Delivery Lead is clear and to the point – sort of like “by leveraging Agile, we’re leading delivery”. Technical Program Manager works too; this role which is popular with Google, Apple, and Amazon (to name a few), intersects technology with Agile in a program management type role to work with teams and set them up for success.

What are your thoughts on the Scrum Master title?

As always, leave a comment below and thanks for reading!