Dispatches from the Scrum War
Which way, tech worker?
I have recently been drafted, along with many of my peers, into a secret war for the spirit of the tech industry. This conflict, invisible to both the layman outside the industry and to the giants who sit atop it, is waged in the lower-middle levels of the tech hierarchy, among developers, consultants, and managers. It is waged in open-plan offices and conference halls; it is a cold war, an asymmetric war, waged by secret operatives under a decentralized regime of subversion against an entrenched hegemon.
It is called the Scrum War, and it is a holy war.
My recruitment happened slowly, then all at once. Before I graduated college, my knowledge of ‘agile’, ‘scrum’, ‘waterfall’ etc. were negligible. Within a couple months, I had received my first hint that such a war existed. Another followed shortly afterwards. Six months on, it is inescapable; it pursues me, following me into what I had previously thought were sane and peaceful quarters. My eyes have been opened; I cannot unsee.
The anti-Scrum side got to me first, probably irreversibly, through online blogs and comment sections.
Not long afterwards, the pro-Scrum side found me through my professors in my masters’ program, though even some of these turned out to be subversive double agents.
Within the last year, I’ve become wholly radicalized to the anti-Scrum side. This is no small thing: it has dramatically changed my plans for future work; I’ve formed strong bonds with peers who responded to our faction’s coded language and secret handshakes. I even made a fast friend in a classmate who saw me editing this post and could only say ‘true’.
But what is the Scrum War?
Broadly, it is a conflict of vision over how tech work, especially in software development, ought to be managed. I grant that this is a very strange thing to wage a holy war over, but consider two things:
You doubtless belong to some hobby or other niche community of which most people have only the most passing comprehension: competitive fly-fishing, tabletop games, the collection of antique pens, what have you. Consider how, despite having objectively low stakes and a small population, your niche is full of partisans at each other’s throats over the most minute disagreements. I take for granted that you have seen incredible vitriol spat between people with far more in common than in difference, over arguments which an outsider could hardly parse, let alone summon strong feelings about. This does not arise from the material value of the topic, but from the passion which people invest in it.
Second, consider that the tech industry is neither small nor (certain critics aside) unproductive. Software development in the U.S. alone brings in hundreds of billions in revenue every year. The global battlefields of the Scrum War, even by a conservative estimate, influence tens of billions dollars in fully-loaded annual productive labor. The livelihoods and careers of hundreds of thousands of some of the world’s most highly compensated white-collar workers are at stake.
The Scrum War arises from the turbulent nexus of passion and money: passion for creation and craft, and the incredible sums of cash it can conjure under the right circumstances.
On the pro-Scrum side, it is not uncharitable to compare it to a religion. It is a rather new religion, coming about only in the last thirty years and already quite fragmented, but dominant organizations and orthodoxy have solidified. It possesses scripture, apostles, and a vast fleet of professional missionaries: they gain converts with terrifying efficacy, in a way that will be familiar to scholars of 3rd-century Rome, when Christianity collided with the temple-state complex and conversion became very socially and professionally valuable.
As you may expect, these converts often combine outward zeal with little schooling in the finer points of their theology.
On the anti-Scrum side, Scrum is the devil, and the tiers of consultants and recruiters and coaches are the Goetic legions of Hell.
Scrum promises professional salvation: its doctrine is a master key to create business-value on an unforeseen scale, regardless of domain, a “universal accelerator of human effort.”1 To dedicate yourself to Scrum, with all your heart, is to open up new, life-changing possibilities.
“You saved my life.”
The woman had red hair, a red dress, and eyes red from crying. She was holding a copy of what has come to be known as the Red Book. This book.2
It reminds me of nothing so much as the Eleusinian Mysteries, of which Pindar wrote
Happy is he who, having seen these rites, goes below the hollow earth; for he knows the end of life and he knows its god-sent beginning.
The anti-Scrum side, on the other hand, regards this doctrine as an oppressive and unjust imposition that strangles both craft and productivity in order to create a false sense of control to advance the careers of opportunists, creates ticking tech-debt time bombs, and pushes blame for unrelenting failure downward onto the craftsmen.
Because the target audience of agile and scrum is managers - specifically managers who don't trust the people they manage to do what needs doing, and need endless reassurance that they are doing what they are supposed to. You know, managers who are tempermentally (sic) unsuited to manage people. It inflicts misery on developers in exchange for giving you the illusion of control. If you need that illusion that badly, consider the possibility that you're in the wrong business.3
It attributes to Scrum many of tech-work’s miseries, especially burnout, failing projects, and abuse by predatory managers. It breeds a real, burning resentment of management and consultants among engineers, sometimes wrapped in humor.
"You all but admitted it! You all worship the subdaemon Scrum."
The woman slumped in relief. A misunderstanding. They would make it out of this alive.
"Commissar, no! It's a management methodology! Scrum is a framework to help you implement Agile—"
Valera fired five rounds into her.
"Oh. That's much worse."4
It’s this stark contrast in perceptions and experiences of what should be a fairly concrete thing—a management methodology—that drew me to the subject.
![Scrum: The Art of Doing Twice the Work in Half the Time [Book]](https://substackcdn.com/image/fetch/$s_!6QvQ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F17f92836-c85d-4387-9b78-994055b24d7b_1684x2560.jpeg "Scrum: The Art of Doing Twice the Work in Half the Time [Book]")
I was directed first to the foundational text, Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland, the original creator of Scrum. I’m not through it yet, but it’s a fascinating text. In the opening chapters alone, it combines insights into the failures of command-and-control management techniques (which, according to Sutherland’s detractors, his own system went on to replicate), conversion narratives about businesses facing crises until they accept Scrum as the One True Way, and what I can only describe as softcore erotica for MBAs:
“Listen,” he said, “I don’t know if it will work. I don’t know if Scrum is the answer we need. I do know that the way we are working now will fail, and it is the best option I have available to deliver the organization we need to be in 2035.”
He looked at me. He has been a leader of people for more than forty years in some of the most demanding situations people can be put into. Blue eyes. Light brown hair. The demeanor of a leader. “I have no choice. The world is moving too fast. Our competitors are evolving too quickly. If we don’t change now, we will lose. We have to change.” He paused. “Or die. That’s why.”5
I’m only half-joking when I describe this as the holy scripture of Scrum. It bluntly and straightforwardly makes claims about the powers of Scrum—such as that ‘universal accelerator of human effort’ line—which just cannot be true. Half of my effort has been spent figuring out whether Sutherland is a true believer or a cynical salesman, or something in between.
This scripture is split among several books: if you want Scrum’s Leviticus, you’ll want the Scrum Guide, a considerably shorter text that has been repeatedly revised over the years, and if you want to know why Scrum is associated with something called ‘agile’ you’ll need to refer to the Agile Manifesto and the secondary literature recounting its origins.
But I focus on Scrum among the many variants of ‘agile’ methodologies because it is the single most influential and widespread, primus inter pares. I choose to examine Sutherland’s work rather than the Guide itself because this is what sold thousands of people on the guide and built an entire industry of Scrum coaching, consulting, and certification.
It also happens that I quite like reading and analyzing holy books, and though my specialty is in data science, I also have a little background in Biblical analysis. The terrain feels familiar.
I’ve also wound up pairing this reading with Robert Jackall’s Moral Mazes (1988), which catalogued the moral and ethical systems of yesteryear corporate management, the very system which agile methodologies grew up in reaction against. It’s a productive contrast, and a lesson that change is slower than it seems.
Since this topic has proven more interesting and complex than it first appeared when I entered into it, I will use this space to lay the groundwork and register some hypotheses, and make concrete arguments in later articles.
Disclaimer on Agilities
One especially fruitless front of the Scrum War consists of arguments over exactly what ‘agile’ means, how certain methodologies have strayed from the path of agile, whether a given methodology actually counts as ‘agile’, and so on. This results from a popular misunderstanding, often perpetuated by the creators of these methodologies, that they all spring from some common, virtuous root, and that ‘agile’ actually means anything. It arguably did at some point, but this is certainly no longer the case. Others have written comprehensive histories on the subject, and I will only summarize the main points here:
Agile originated as a catch-all for lightweight project management methodologies originating in ‘90s software development
Contrary to popular misunderstanding, the specific methodologies like Scrum, Extreme Programming (XP), Crystal, DSDM, etc. preceded the Agile Manifesto and the term ‘agile’ itself
They did not have a common ancestor and were not varying applications of the Agile Manifesto’s principles
They all arose in reaction to a common enemy, Waterfall and the tyrannical Gantt chart, an especially heavy methodology which was dominant at the time
They have no particular connection to one another except this opposition, which is why ‘agile’ is a very nebulous term
Since this history isn’t material to the modern failings of Agile methodologies in practice, it is not especially useful to describe Agile per se. At the same time, to speak of Scrum alone would trap us in too narrow a frame. To weave a path between them, I will henceforth use the term Scrum-Agile, which I have coined just now, to head off these objections and refer to the morass that mixes principles, methodologies, concrete applications, and so on. The subject matter is confused and intentionally ambiguous, so the term shall be as well.
What’s The Deal With…?
I lay out the following theses, which I will discuss in greater depth in coming articles. Lightning round!
How Scrum Came to Dominate
The initial popularity of the Agile Manifesto, foremost among developers, posed a threat to established systems of management. In particular, demands for increased developer autonomy and the principle that the people doing the work should decide how the work is done threatened to disintermediate managers and reduce their control over developers.
Scrum-Agile, as one of the heavier, management-central, and process-based of the methodologies represented among the Manifesto’s signatories, came to prominence in order to defend an entrenched managerial class by allowing them to implement shiny new ‘agile’ methodologies while still maintaining control.
How Scrum Came to be Despised
In the following years, as developers came to loathe ‘agile’ instead of loving it, as managers came to be its primary champions in the workplace, Scrum-Agile has remained dominant because it imposes a semblance of order and linearity onto software development, and especially because it generates quantities (velocity, story points) which lend themselves to being monitored as key performance indicators (KPIs).
The fact that, according to the Scrum Guide itself, such quantities are meant for internal team use only and not as managerial tools, is an example of how the processes of Scrum-Agile are mainly honored in the breach.
Scrum and Agile: What’s the Difference?
Distinctions between Agile and Scrum, though real and worthy of note, are not especially important to this discussion. Switching to Kanban is probably good for you, but it doesn’t solve the underlying, systemic problems of Scrum-Agile.
Likewise, misapplication of Scrum-Agile is real, but also not especially relevant. To criticize the finer points of a Scrum-Agile implementation diverts attention from the choice to apply this methodology to begin with, a choice which is often ill-conceived from the start and subject to intense principal-agent problems.
Was it Ever Useful?
The Scrum-Agile literature should be read backward in order to recognize what innovations it actually brought to the table (a focus on close client feedback and fast iteration cycles), which have likely dispersed throughout the industry such that implementing brand-name Scrum-Agile no longer has distinct advantages compared to less-structured ‘folk management’ methods.
Its advantages, following James C. Scott, have passed from explicit episteme into communal metis.
But is it Scrum/Agile?
Aside from a handful of particularities (daily standups, giving Scrum Master roles to non-technical staff, giving the Product Owner control over concrete features), there is little in Scrum-Agile which, in the abstract, couldn’t work with a suitable team and environment that worked to actually implement them. Rather, the poverty of Scrum-Agile arises from how easily it lends itself to misapplication.
Certain misuses, such as
using internal team metrics as shaming and tracking tools,
imposing agile methodologies on teams,
refusing to allocate maintenance or testing during sprints in preference to features,
treating non-linear story points as fungible
are so widespread that they effectively are Scrum-Agile, not a deviation from it. These misuses are, predictably, those which disempower developers and impoverish craft in order to give managers a sense of control.
If it’s So Bad, Why Hasn’t it Been Fixed?
It is not in the interests of the Scrum-Agile industry to fix these problems, not only because admitting Scrum is Not the One True Way could lead to a loss of customers, but because the distance between the ideal dream of Scrum-Agile and the disappointing reality is what sustains the economy of Scrum coaches, certifications, and consultants.
Scrum’s period of fast market share growth ended long ago, and it is dependent on a recurrent spending model. There must always be productivity anxiety, there must always be another workshop on the horizon, another certification on the office wall.
But What About the Success Stories?
The spectacular successes Sutherlands reports in Scrum: The Art of Doing Twice the Work in Half the Time (and they really are spectacular), assuming he is reporting them accurately, are due not to the special virtues of Scrum as a process. Instead, they are due to selection (only a company with a lot to fix would give such wide latitude to an outside consultant implementing his homebrew methods) and to Sutherland’s personal talent as a manger (unlike other consulting influencers I’ve scrutinized, Sutherland does seem to be a genuinely intelligent and talented organizer of human effort, rather than a vaporware salesman).
This dovetails with the recognition that a great deal of corporate malfunction arises from Moral Mazes-style perversions, which an outside consultant with a mandate like Sutherland is free to cut through using his method of choice, even as those same forces will dig their claws into and subvert any new structure introduced to the firm. The specific process or methodology matters less than the situation, because it will not be permitted to make systemic change, though a company in dire straits will submit to temporary, rejuvenating reorganization.
What’s the Deal with Sutherland?
Despite his genuine talent (his record as a soldier and a scientist is solid) Sutherland’s experience of modern software development seems to be from the top, as the guy with unusual leeway to create systems and lead teams, and not as one of the functionaries or code-monkeys.
He is insulated from that level of analysis and fawned over by the managerial and executive class, and so the system he has created is one which serves the needs of the people at the top and not the developers.
To paraphrase an anonymous professor with very strong opinions on Scrum anti-patterns.
You are asked three questions in a Scrum stand-up:
- What did you do yesterday?
- What do you plan to do today?
- What are your blockers?In a job interview, you will be asked what these are by an idiot.
It protects incompetents in their ivory towers. Microsoft, Google, Amazon, Databricks, etc don't allow stuffed shirt managers on their teams, you have to be able to code. ‘Manager’ is a dirty word.
Scrum has become entrenched not as the preferred tool of developers, but the preferred tool of managers. Its creator did once create software, but that was a long, long time ago, before his own ideas ate the industry and became something else entirely.
Also, it’s very hard to take Sutherland seriously when he starts pulling numbers out of his ass.
Light Reading
In the course of my research, I’ve read a great many people criticizing Scrum-Agile, from the lowly engineer ranting on HackerNews to other co-signatories of the Agile Manifesto.
One of the most interesting of these is Ron Jeffries, creator of eXtreme Programming (XP), signatory of the Agile Manifesto, and longtime member of the Scrum Alliance. Sutherland quotes him approvingly as late as the 2024 version of Scrum: The Art of Doing Twice the Work in Half the Time.
So I find it interesting that Jeffries has been a consistent and vocal critic of Scrum for a decade now, on the exact premises I explore above. I leave excerpts from several of his blog posts for your perusal.
There has never been any consistent assessment of the impact of Scrum training on the success of Scrum adoptions. We mostly do not know whether Scrum really transforms the world of work. We do know, or at least I know and my friends know, that Scrum (as done if not as taught) makes the lives of dev team members worse rather than better.
We do not know–no one knows–how well Scrum installations deliver higher productivity, how often they make the lives of their teams better.
I think it’s because Scrum very commonly does not deliver much productivity; because corporate managers don’t know how to use Scrum, much less measure it; and because their approach to using Scrum in fact makes people’s lives worse rather than better.
I will say that if the fall of Scrum could lead to the rise of the real values of the Agile Manifesto, holding people and working together over processes and tools, focusing on working software and collaboration, responding to change rather than comparing estimate to actuals … if the fall of Scrum could lead to those things, it can’t come soon enough for me.
What I am telling us–all of us–is that we’re going to measure our product teams based on their ability to literally deliver value every couple of weeks. To the extent that a team can do that, they’ll look good, and to the extent that they can’t, they’ll not look so good. And we’re going to invest whatever it takes to make it possible for every team to look good by that measure. With some teams, it may take some time. As they get better at doing it, they’ll look better. Once a quarter is better than twice a year. Once a month is better still, and it’s nearly every couple of weeks. I have reason to believe we can do this and I’m committed to providing what we need to make it happen.
A Satirical Website Raises Hackles
That’s what I have been trying to get across to them, and what I have so far failed at, to the point where I’ve pretty much given up. (That won’t make me be quiet, it just keeps me away that I’m shaking my fist at a cloud, not changing the weather.)
As I put it in another article:
Scrum, seen as the whole system, is very much anti-maker and anti-making, despite the good will of everyone I know inside that system.
Developers Should Abandon Agile
My thinking is taken from something Kent Beck said over a decade ago. I would like the world to be safe for developers. At my core, I am a developer, despite years of management, consulting, and writing. I worked with code earlier today, and do so every week if not daily. So it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better. It also saddens me that the enterprise isn’t getting what it could out of the deal, but my main concern is for the people doing the work.
Over a period of years, I’ve heard from many developers who say that “Agile” sucks. (Usually they say that “Scrum” sucks, because most people in organizations trying to do “Agile” are in organizations trying to do Scrum.) I’ve tried to help those people understand that their organization is doing “Agile” wrong: they’re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend.
Too commonly, the “Agile” approach a team uses has been imposed. Larger-scale “Agile” methods appear actually to recommend imposition of process. I include here the so-called “SAFe” method, Scaled Scrum, and LeSS among others. These are pitched to the enterprise, and the enterprise is expected to “install” them, or “roll them out”.
As a developer, you can be sure that this roll-out will not go smoothly nor in a truly Agile fashion. You’ll not likely be trained, much less educated, much less given the real help you need to do your job. Your leadership will perhaps have been trained, perhaps for as much as an entire week(!), to prepare them to bring about this sweeping change in the organization’s approach to product and software development. The road is likely to be a bit bumpy.
I might be tolerant if a team used Jira internally. I could imagine coaching them to use it well, or talking them down off the Jira ledge over time. But when Jira becomes available to management and other stakeholders, it’s almost impossible to use it well.
Let me quote the Jira blurb itself: From agile boards, backlogs, roadmaps, reports, to integrations and add-ons you can plan, track, and manage all your agile software development projects from a single tool.
As we wrote in the Agile Manifesto decades ago, Working software is the primary measure of progress. Not boards, backlogs, roadmaps, and reports. Jira in the hands of management and other stakeholders essentially forces them to manage by proxy information. They look at how well we meet our predictions, how many defects we fix. They look at how Suzy is doing compared to Sal.
They should be looking at the product. They should be demanding to see a real product increment every week or two, and assessing that. That’s what they’re paying for, and that’s what they should be assessing.
Jira interferes with effective management while claiming that it helps.
Bottom line, I’d avoid Jira if I possibly could. In my arguably expert opinion, its existence, its features, its entire purpose is strongly counter to the essence of Agile Software Development.
Jira delenda est.
The Scrum War rages on. Await the next dispatch.
Sutherland, Jeff; Sutherland, J.J.. Scrum: The Art of Doing Twice the Work in Half the Time (p. xiv)
Ibid. (p. xiii).
Tim Boudreau, Quora, via AgileInTheirOwnWords
Nikhil Suresh, Praise the Machine Spirit
Sutherland, Jeff; Sutherland, J.J.. Scrum: The Art of Doing Twice the Work in Half the Time (pp. xvi-xvii)