To SCRUM or not to SCRUM?

That’s a question you’re not even supposed to ask in modern corporate world, at least it never occur to me to do so. Agile has become the norm in software development to the point where most people can’t even remember how life was before it. After 15 years in software development and a Masters in Agile Management, I accepted SCRUM as the solution of all solutions and care very little about any alternatives, but is SCRUM really that agile? Many software engineers have been asking themselves this question all over the world, and surveys and researches have frequently shown a quite negative feeling towards the topic. I was only recently introduced to the immense pool of criticism towards the framework and it seems that I have somehow broken free, and now my “algorithm” is allowing me to find articles and Youtube videos that I didn’t know existed. The dividing line was an article named Study finds 268% higher failure rates for Agile software projects, published here. It’s very important to note that this non-scientific study was backed by consultancy firm Engprax, which promotes their own framework as an alternative, so take that with the largest grain of salt you can find.

That article connected to another, where one of the co-signers of the Agile Manifesto, John Kern, call out in an interview, what he calls the “Agile Industrial Complex”, adding “It feels like we stepped back in time,” … “As if the manifesto never existed, and we’re back to heavy processes.” Whole interview here.

That was it. I was slowly understanding that I was in the SCRUM-Matrix and it was time to take the pill.

But before continue analyzing criticisms, let’s first revisit some definitions to fresh things up, shall we?

What is Agile?

The concept is not as new as you might expect. Interactive/incremental software practices have already being used all the way back to 1950s, and adaptive methodologies were replacing the Waterfall method since the 70s. But what is the modern understanding of Agile?

The Agile Manifesto, published in 2001 by a group of 17 software engineers, is a simple set of rules that describe a lightweight development methods. If has some simple axioms like:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

One of the founders of the manifesto, Jim Highsmith, explains:

The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.

For short, Agile is a lightweight software development methodology that is flexible, reacts quickly to scope change and empowers teams to organize their own work. In principle, not bad, right? So why so many people, specially devs, hate it so much? Well maybe they don’t hate “agile” itself, but something else..

What is SCRUM?

Just like the concept of Agile, the term SCRUM is not new, but what we call SCRUM today was born in 2002 when Ken Schwaber and others founded the Scrum Alliance, which is responsible for accreditation and certification of the framework. In 2009 Scrum.org became responsible for the update and publish of The Scrum Guide, which is currently on it’s 6th iteration (as per 2024), and it’s the “bible” that describes all there is to know about the framework. Basic stuff that you all probably know already, but it was good to revise it before we can go forward.

Agile by itself is more of a lose concept, it needs a framework to be implemented, and the most popular one is by far, SCRUM. It lays down rigorous rules, procedures, roles and ceremonies that must be followed by the book.

I know I’m probably preaching to the choir here, because if you’re reading this at all, you’re probably a dev, engineer or project manager with tons of experience in what a SCRUM team is, but just to be pedantic, let’s check this cool diagram of what the framework proposes:

The image above resumes what SCRUM is all about: roles, processes and ceremonies (source wiki). Every sprint has mandatory ceremonies (Planning, Review, Retrospective, Backlog grooming…) and every workday starts with a stand-up meeting. This promise to do twice the work in half the time. Almost magical, don’t you thing? So why so many people dislike it, or dare I say, resent it?

If SCRUM is so good, why the negative feeling?

When I talk about SCRUM not being the best thing since sliced bread, what I usually get from people are gazes of incredulity, but the bubble seems to be bursting. An increasing amount of posts, articles and YouTube videos are being published every week reporting strong and valid criticisms, coming mostly from experience professionals on the field. But if SCRUM is so good, if it promotes team synergy, if it enables such impressive efficiency, why so many in the trade seem to hate it? Let’s check some of the most common criticisms, starting with the Agile Wikipedia page itself, which has this telling disclaimer:

While there is much anecdotal evidence that the agile mindset and agile-based practices improve the software development process, the empirical evidence is limited and less than conclusive.

In the next paragraphs I will show you just a hint of the type of criticism that’s out there. I was shocked about how shielded I was of all this content, but after following the white rabbit a little bit down the hole, here’s what I’ve found:

A tweet (Scrum is cancer) got rival and started a worldwide movement of engagement with the topic. Millions of people have shared it and a lot of blogs, forums and many discussion threads spawned from it. Threads like this were started to discuss articles like Agile and the Long Crisis of Software, and have hundreds of opinions on the matter, some very solid ones, I might add, like:

• “Standups are the new timesheets: a humiliating exercise in micromanagement.”
• “It’s another meeting on my calendar potentially interrupting whatever deep focus I was in.”
• “an assembly line in which no one, at any point, takes full responsibility for what the team has created”.
• In his talk “Agile is Dead”, Dave Thomas (one of the creators of the Agile Manifesto) speaks about how distorted and perverted the manifesto’s intentions have been by the “Agile” industry.

I have found in this other thread more interesting points, like:

• “Anything larger than a developer can do in two weeks is infeasible”
• “Went from being agile to implementing Agile”
• “Its purpose is to identify low performers, but it has an unacceptably high false positive rate.”
• “It has no regard for career coherency.”

In this blog post, michaelochurch says: “Atomized user stories aren’t good for engineers’ careers. By age 30, you’re expected to be able to show that you can work at the whole-project level, and that you’re at least ready to go beyond such a level into infrastructure, architecture, research, or leadership.”

Brian Woolsey, in his blog, discuss the concept of Sprint Towards Mediocrity, with some funny quotes like: “Make up some absurdly high number to ensure they are confident they can complete it within a sprint. This usually triggers the typical 10-15 minute sidebar conversation where everyone on the team reiterates all the things we don’t yet know. Seems like a good use of time.”

This funny post critics the concept of sprints and explores a new form of management as a satire, but the community follow up from this post was huge, with many claiming that, even though the practices shown in the post are supposed to be “not to dos”, many have expressed that their SCRUM lives reflect exactly that.

Another interesting fact I’ve encounter, is that big tech, specially FAANG, don’t use SCRUM. To be fair, they sometimes do. Huge companies like Google and META do have some teams using it, but it’s not encourage or deployed company-wise, as I used to believe. Adam Ruka takes a shot on this in his blog. This one got me scratching my head… Why would the largest and most powerful software companies not use the best framework ever created? Food for thought..

SCRUM is often criticized for being toxic and stress inducing, that’s not news, but what became news to me was how often is it bashed for being particularly toxic to women. I don’t feel confident in discussing this matter since I’m not a woman nor I understand women’s issues, and I would like to respect you, dear reader, by not pretending I do. But the truth is that these criticism are numerous, which makes me believe they most probably have a point.

I particularly enjoyed this article called SCRUM, Failure by design? In it, Maarten Dalmijn calls for some serious reflection about the inability of the community in admitting SCRUM’s shortcomings, adding:

I can tell you one thing for sure: whatever I write will be dismissed by some in the community with “It’s their fault because they are doing Scrum wrong.”

Fierce proponents will tell you that SCRUM isn’t a “project management thing”, and they have a point to say that, once that scrum.org and the SCRUM guide expertly tap dance around the term, using a myriad of synonyms to avoid simply saying: a project. So the idea is that the framework describes and trains a team to “be SCRUM”. The very essence of the team is a SCRUM one. Terms like mindset, values and principles are constantly thrown around. No one is to think outside of the SCRUM box, don’t act out of the scope of your role and, most important of all, don’t questioned the efficacy of the framework. Ever! Just devote your allegiance to the SCRUM Gods and your team will do twice the work in half the time.

Yes, I understand that I sound like a cynical jerk, but the eagerness with which people defend this methodology is borderline frightening to me. It mimics cult level engagement, and I don’t believe that’s a healthy thing, specially at the workplace.

Of course, like in most cults, criticism is mostly dismissed with an allegation of “not understanding the … let’s say… essence of …”. SCRUM is no different. If you criticize it in anyway, you will be accused of not implementing it correctly. This is what some people online call “The communism argument”.

So here you have it, the strongest criticism I could find about SCRUM. Basically, SCRUM works, if it didn’t, you’re the one to blame, never the framework. This is criminal level of gas-lighting and the final nail on the SCRUM coffin, at least for me.

To be fair..

Ok ok, SCRUM can work well, I’m willing to admit that, but in my experience, only for certain cases. SCRUM is just a tool, and like any other tool, it’s good for certain jobs, but obviously not all. So there will be companies, teams, projects, any other random endeavors that will benefit from SCRUM’s rigid roles and ceremonies. It can successfully bring order to chaos and can also help management “see” what’s going on with more clarity.

Personally, I don’t see much problem with the whole Sprint concept. Other agile methodologies use them too, not only SCRUM, but organizing your team’s work in sprints and doing SCRUM, are very different things. In this sense I might actually agree with scrummies when they say “it’s not real SCRUM”.

I don’t agree with the harshest criticisms that generalize the whole concept of Agile as being inherently bad. The manifesto gave the world a kind of compass: it roughly points to the direction of management gold. Frameworks are just attempts to systematize, coorporatize, or even, institutionalized something that is more of an ethereal idea, and perhaps we would be better off leaving it like that.

Waterfall isn’t coming back, I believe we can agree on that. We will mostly work under some form of Agile, and I believe that is generally a good thing.

Alternatives

When I write texts like this, I usually start by placing some key points that later will became the sections and sub-sections of the article. One of those points for this article was called Alternatives, but I’ve gave up the idea of discussing other frameworks and methodologies with you, dear reader. One of the reasons is that, even though I’ve studied Agile management and have been a software engineer for more than 15 years, I simply don’t feel qualified enough to do so. The other is that there’s a plethora of team and project management tools, frameworks, philosophies and methodologies for us to choose from. I don’t think I should uphold any of them as being the best or the worst, or more importantly, being better or worse than SCRUM. Again, methodologies are tools, how can I tell you which hammer to use if I haven’t even seen the size of the nail.

Closing thoughts

If you google literally anything you like, followed by the word “criticism”, you will be exposed to a whole new point of view, one that you might not be expecting, and oh boy! was I surprise with this one. When I started reading about SCRUM’s shortcomings, I was slapped by a reality I was strangely unaware of, and that sort of gave an epiphany: I was in the bubble. It has been a wild ride that had me questioning many things I believed a knew about software development, academic life and even career building.

If I would make a prediction, I would say that SCRUM is not going to disappear any time soon, but its glory days are unquestionably already behind us.

If I’m ought to have an opinion on the matter, I’d say that the Agile Manifesto is supposed to guide us towards a lightweight methodology, in other words: less is more. Making it heavy, stiff and bureaucratic is exactly the opposite of everything it’s supposed to mean.

Thank you very much for reading theprotoblog!