Life Is Too Short To Be a Scrum Master

Inside, I feel at peace with my decision, but strangely, when I try explaining it to others, feelings of frustration and failure bubble up. I suppose I am still processing it, even though I have made up my mind to no longer work as a Scrum Master, Agile Coach, or any other similar role.

A Failure of Sorts

The first feeling I have regarding this change in professional course is one of failure. I have taken a few unrelated paths in my professional life, but the last years have been relatively coherent. I transitioned from Computational Linguist to Software Developer to Scrum Master, and then to the more method-agnostic variant of it, called Agile Coach. However, I ultimately came to prefer the title Agile Practitioner. I fell in love with the practice of Agile, Lean, and all the new approaches that had emerged as a response to the needs of the modern world of work. I was fascinated with the field and felt like a kid in an amusement park who wanted to try and learn everything. I felt rejuvenated and on a mission. I had a pretty steep development curve too, and felt like I had finally found my calling. Now, after roughly 7 years, I see that phase has come to an end. Do not mistake me. This is not a requiem. I feel as alive as I have ever felt. The path ahead is just as exciting, if not more. This essay is my personal reflection on how I arrived at this point, in addition to being a follow-up to my essay from April 2024. I hope other fellow practitioners find something useful in this one as well.

A Curious Case

In all industries and fields of work that I am aware of, the more competent you become, the more sought after you will be. Well, not in our industry. This was the first red flag I noticed about two years ago. In my own experience and from what I have heard from peers, most employers look for less experienced SMs and ACs so that they can put them in a box, hand them a checklist, and kindly ask them to do what they are told. I have heard and read all the fairytales about the modern workplaces that want true agility and put people first, blah blah blah. All the evidence that I have shows me that at least 90% of these claims are nothing but marketing and empty hypes. The other rare situations are also only temporary and limited to a small part of the organization. Just imagine a Civil Engineer, a Mechanical Engineer, a Medical Doctor, a teacher, or any other professional who does something that relies on their knowledge, experience, and expertise. How on earth would they become less desired as a workforce when they develop, learn, and grow more? I have an idea how.

Battle on All Fronts

For a good while, I had the illusion that the old-school approach to management was the problem and that I was the champion of the poor Developers and powerless teams. Imagine a knight in full armor on a horse defending the weak, the oppressed. My knowledge, skills, experience, and expertise were my weapons, armor, and ride. I had one goal: to enlighten the misled, to show them a better way to treat the commoners and gain even more profit while doing so. I could not be more wrong. It was quite a bitter reckoning that I was in battle on all fronts. Managers, Middle Managers, Engineering Managers, Product Owners, and even my most beloved Developers. Every once in a blue moon, someone would express appreciation for how I was helping them or how a particular method I had applied blew their mind. But, truth be told, I was misunderstood and excluded by and from most circles. I was an outsider to all parties, and I have heard the exact same observation from virtually all fellow SMs and ACs.

Management by Numbers

Where should I start? Let’s start with the most obvious one: the old-school, Tayloristic, deterministic-minded management. I have lost count of how often I have come across this one personally or in others’ descriptions of their circumstances. Of course, none of these managers would admit that about themselves. I have had firsthand experience with ones who even called whatever they were doing Agile. Ron Jeffries beautifully called this Dark Agile. The truth is that what they were doing was, in Deming’s words, management by numbers, which is really, if you peel it until you reach its core, management by deflection of responsibility. These managers want evidence, basically some numbers, to justify any effort. The first impression is that “if you can’t measure it, you can’t manage it,” but when you look at its heart, the evidence, the numbers they are asking for are not for themselves. They are for their superiors. This way, if the overall results are not appealing to the big bosses, these managers can show them the numbers and say, “Here, see for yourself. I have reduced costs this much. The failure can’t be mine. I’ve done everything I could, and the ‘evidence’ confirms that.” Most, if not all, of the big decisions that I have seen in my career were made by extremely oversimplified first-order arguments that did not go beyond a simple cost-benefit analysis, where all higher-order costs were neglected and much of the perceived benefits were mere wishes. Why did they hire Agile Practitioners, you might ask? These managers hire Agile Practitioners because they see it as a trendy, cute way to get things organized and monitored, measure productivity, and claim the “we are Agile” badge. That is a direct consequence of Agile becoming synonymous with Good and the opposite of Evil. No one wants to be Not Agile, and everyone goes to ridiculous lengths to fake having earned it.

Beware of Their Turfs

Then come our own Engineering Managers and Product Owners. These can be the best allies of an Agile Practitioner to drive real change and make significant improvements within the boundaries of teams, across teams, and even the larger organization. But of course, that would happen if you are not conquering their territories and reducing their political power. Let’s face it, if a PO is already owning the product, and assigning and monitoring the work like a good old Project Manager, why would he welcome your presence and your efforts in making the team self-organizing and empowered? For the benefit of the organization and business? He would, of course, if that was his priority. But evidently, it is not. Staying relevant, needed, and depended on are much stronger drivers of our professional behavior than the collective win.

Comfortable in Fear

And to my biggest surprise, even many developers, I would say most developers, are not interested in self-driving collaborative work. And when they do show some interest, it only goes so far to get some slightly better results, to get out of the hole they are stuck in. All efforts stop there. The worst cases are when teams insist that Agile approaches to work are yet another trick from the oppressive management, fooling them into working harder and monitoring their every step. In their defense, they do have a point. There is such a thing as Dark Agile. However, that also closes the door to any well-intended effort to create a healthier, more collaborative, self-leading, team-oriented work.

Transformation Theater

This one should blow anyone’s mind. It did mine. Even Transformation efforts are run by managers who, at the end of the day, want to show some clean and happy statistics to the big bosses, so every attempt at actually transforming anything is killed at inception by the very agents of change. So much of what is called Agile Transformation is nothing but a theater, a game of make-belief; a very lucrative one, nonetheless. It is simple math. There is a budget for the Transformation, and it is much easier not to truly change anything but show superficial improvements that keep the money coming. A few years and thousands of Euros later, the Transformation is killed and replaced by another fad offered by other charlatans, and in the meantime, everyone wins. The agents of change create make-belief evidence of their achievements. Managers brag about bringing the enterprise to modern ways of working and bringing home that sweet “we are Agile” badge. Marketing milks this cow like any other. Everyone gets something out of this theater, and by the time it is over, there will be another theater to set up.

At the Heart of the Matter

The sad truth that no one dares verbalize is that everyone is insecure. Everyone’s first and strongest driver is fear; fear of becoming redundant, fear of losing influence, fear of losing the sweet income, fear of leaving one’s comfort zone and stepping into the unknown, fear of greatness and trading it for the comfort of mediocrity. Agile, Lean, and all the newer approaches are not fighting against any institution. They are fighting against our very own nature, not our best angels, nevertheless the very human nature. For this reason and this reason alone, all such approaches are doomed to fail to deliver repeatable, sustainable results.

Too Little, Too Short

These battles on all fronts may sound like I am demonizing everyone and claiming that no one ever understood, appreciated, or supported my work. Not at all. I have had the absolute pleasure of working with brilliant managers, product people, and software people who not only understood and supported my work and the work of others in my position but even became mentor figures to me. But there is a caveat. All of these fair winds were very limited in their domain of influence and the time they lasted. At best, we could do some good work in a little bubble until it burst. Sometimes the domain was larger, but someone with a heftier title would come along and break everything we had built. I wish these were exceptions, but my years in the trade and everything I hear from my peers tell me that these are the norm.

To Each His Own

Regardless of how this essay is perceived, I do not intend to make a point that no one should stay in the role of Scrum Master or Agile Coach, that no one should shift to Agile Delivery Manager or Agile Project Manager, or that no one should try showing their worth. On the contrary, I root for all those who are still trying to make a difference, who are trying to show their value, or to redefine their role so it fits the demands of the existing organizations. This essay reflects my journey, my development, and my path. It is a very personal view, a very personal experience, and a very personal decision. However, having talked to a few fellow practitioners, I know that my experiences and reflections are not unique, and my guess is that many find themselves in similar situations, yet not many speak out. My sanity was restored when I found out that so many others around me are having similar experiences. I hope these words help others figure out that they are not alone and that it is not they who need fixing.

If Only

To dig deep in my soul and take these thoughts out was not easy or comfortable, but I felt I owed it to myself and to others who are on the same path or are considering it. Even though I have talked with several experienced practitioners and I know that their thoughts and feelings are very similar to mine, I can not claim that this is how everyone feels. So, I encourage everyone who has worked in similar fields to share their thoughts in their own words. I believe the result will be shocking and enlightening. This has been in the shadows for too long and deserves to be brought to light.

Making Enemies Happy

There is an expression in my mother tongue, Farsi, that literally translates to making enemies happy. It means you have said or done something that has made your enemies happy in the eyes of your kind, your allies. I know much of what I have expressed in this article makes many who are not fond of Scrum happy. They might even take this as a testimony of Scrum’s failure. They could not be more wrong. First of all, I do not consider myself belonging to any tribe, be it Scrum or Agile. I have expressed my views on that in another article. Hence, I see no allies or enemies. But still, the saying makes a point. Some of these happy people are those who consider themselves agilists but of different flavors than Scrum. All my points hold true for them as well. The fault is not in the method but in the raw nature of humans and organizations. Some of the happy people may consider themselves of entirely different tribes, such as Lean, Product Management, or Leadership. I have more than sufficient evidence that the practitioners and coaches in their tribes have virtually identical problems. Once again, human nature and the nature of organizations are the same for them. The point is, if you are reading this article and you are still smiling, you have not understood it.