I’m not a fan of Scrum Masters, not as a responsibility passed around inside of a team, but the kind of Certified Scrum Masters that generally have it as their job title. I’ve worked with a few of them in varying capacities over the years, but I’ve noticed the same reoccurring problems. To be clear though, I take issue with them as colleagues, but not necessarily as people – because many of them are great people who I like outside of work.
The Scrum Masters I’ve worked with have come in two flavors – one where they act as a coach for teams to help them enact Scrum and one where they’ve acted as pseudo project managers and directly lead teams. Though I find the former less problematic than the latter, I’ve found the issues between them largely the same and only a matter of degree than kind. Therefore, I will be using the term CSM to describe the specific Certified Scrum Masters for both of these cases.
Certified Scrum Masters are not Developers
Software Development is not special from many other industries, but in software development, as in the rest of STEM, the process is not easily understood by non-practitioners. There are many other jobs, such as house painter or mechanic that require just as much ingenuity and creativity, but where the process is much more easily understood by the average person. To many people, programming is magic. Generally, this isn’t a problem – I don’t need to know exactly how my car works to be able to drive it, nor should the average person need to know the inner workings of their computer, but where it becomes an issue is when these non-developers become responsible for coaching or even become in charge of developers.
Because CSMs do not understand the process of software development, their ability to communicate with and understand developers is typically very little. This leads them to being narrowly focused on processes and tools over people and interactions. As coaches, they become obsessed with doing things the “right way” whether or not it actually suits the needs of the team and when the team fails to see results from their effort, the team is told the solution is more Scrum or that they aren’t doing it the right way. As project managers, they lack the ability to actually lead the team, only being capable of moving tasks across a JIRA board and pestering the team members about when they will complete their tasks. In both cases, I’ve found their contributions to be net-zero or even net-negative.
In contrast, I’ve experienced having both an Agile Coach (note Agile and not Scrum) and managers who are/were developers themselves, including my current one. The difference is astounding. The Agile Coach I had at a previous company pushed me into a completely new paradigm and helped me find the track to push my skills to the next level. I believe they were paramount to many of my future successes. And my current manager is able to understand the services we own, provide code reviews and feedback, and help provide solutions that make our team effective.
Being a developer does not automatically make a good manager, but not being one guarantees ineffectiveness and I find the same is true of CSMs in both capacities.
The Process Isn’t the Problem
Team processes can be annoying and frustrating, but rarely have I found them to be the true blockers of a team’s progress. Often, they’re merely the symptoms at the most, if they’re even a problem to begin with. CSMs come in to make teams work faster and more efficiently by trying to optimize the process. Adding more swim lanes to the JIRA board to make ticket status more granular or staring at the burndown chart every morning has no impact on the output on the team and is more likely to hinder than help, but these are where CSMs focus their efforts.
This is not a problem unique to CSMs. It’s why the saying, “if all you have is a hammer, everything looks like a nail” exists, and I criticize developers for the same thing as well – that being too narrowly focused without taking the bigger picture into account is a path to ineffectiveness and failure.
Actually solving the issue requires digging into the root cause and understanding that bigger picture. Sometimes there are no blockers. Sometimes, the team is juggling too many projects and the constant context switching is taking away their ability to gain the necessary knowledge to build their systems.
And sometimes, you just need to hire more people.
Adam Lif 