Back in the year 2000, we worked on a large project for railway system automation. We had a lot of tasks to solve - starting with train scheduling and ending with ticket office automation. It was one of the most exciting projects that I have ever worked on.

Back then, we were a small group of proud and (perhaps too) self-confident developers eager to put our mathematical and programming skills into action. Our company had more of a scientific than corporate vibe to it, and in our particular group, we had an atmosphere of cheerful and sometimes a bit reckless and exploratory software development.

However, our work was not without struggle. You would probably find our problems back then insignificant and easy to solve - problems stemming from the immaturity of our processes and a lack of essential tools and basic structure. But back then we didn’t know all that and tried our best to organize ourselves so that we understood each other’s code, who is working on what, and how to make things working more reliable.

One day, everything changed. A guy from the team brought Extreme Programming Explained (the first edition, I think) to work.

We were amazed. We tried everything and loved it. Pair programming. Refactoring (we also bought Martin Fowler’s Refactoring: Improving the Design of Existing Code). Automated testing. Small increments. Continuous integration.

This all was like a breath of fresh air to us - and we didn’t want any other way anymore. The joy of looking at green tests! Lunch break conversations about coding best practices we are going to implement! Setting up our own CI system!

When in 2001 we learned about the Agile Manifesto, we were so ready for it. It made so much sense that our only question was - how come nobody came up with this earlier. The key is embracing the change, being always ready for it, and not investing too much resources into planning for something that may change. It’s so easy! It’s so brilliantly true!

Now, many years later, many books later, and many companies later I can confidently say - agile took a wrong turn and became something different. Something it was never supposed to be.

New Religion

I don’t know where to begin, so I’ll start with my general impression, and then I will add some examples.

And no, this is not a post where I will say “corporate” agile bad or “scrum-but” bad or any other truth worn thin. On the contrary, I’m talking about the “good” Agile that the cheerful but barely experienced in software development coaches will share with you in a two-day training session. I’m talking about one of the huge pillars of modern agile - Scrum itself.

My biggest problem with Agile is that it has become a cult, full of fanatics, dogmas, sermons, its own mythology, and of course the holy inquisition that fiercely fights heretics. I’m a heretic now. In this post I will say a few anti-Agile things, so you may think I have completely embraced the Dark Side, where all the Evil Managers in their suits sit, and where the looming shade of the Great and Terrible Waterfall instills fear into the hearts of the bravest developers.

I’m sorry, but it has to be said.

Remark 1: I really don’t think the Agile Founding Parents had anything to do with this wrong turn. Being a big fan of their work, I can’t believe that this is what they had in mind.

Remark 2: To make a distinction, I will call the Agile of 2001 just Agile. And I will call the new one Agile Cult, or AC.

Mythology: The Epic Battle of Agile and Waterfall

Any cult has to have a foundational myth. For the AC this is The Battle of Agile vs. Waterfall.

This is basically a story about the Old Ways to Manage Things that were absolutely wrong and never worked. They never worked so much that you’d be surprised at how the humans managed to fly to the moon, create foundational software for the Internet, develop programming languages, operating systems, productivity tools, and so much more software that’s still being used to this day.

When Agile needs an opponent (or rather a punching bag) to defeat or an uglier sibling to be compared against, it’s Waterfall. The old stupid Waterfall that was designed to fail, and failed every time, or if not every time then just enough times to be absolutely useless, but for the statistics to feel plausible.

I’ve searched the Internet for “agile vs. waterfall”, and I’ve got over a hundred thousand exact matches. I have no idea if the horse is still alive, but it sure has been beaten more than enough times already.

Don’t bother opening these articles (unless you are one of the lucky people who have not been exposed to hundreds of them already). They are all the same article, telling the same story of a heroic struggle between Agile and Waterfall, where flexible, smart, and modern Agile gloriously wins.

Agile does not need this story. Agile has changed the mindset of millions of developers around the world and absolutely transformed the world of software development.

Comparison with “Waterfall” does not add anything valuable - and if anything, it diminishes the success and reduces the value to “it’s better than something we’ve just told you is absolutely bad.”

What’s more is that in my 20+ year career, I have never seen “waterfall” implemented as it’s described in these articles. Even in most retrograde organizations, I’ve seen people realizing the value or shorter iterations and thoughtful experiments.

But every cult needs a myth. For AC it’s The Epic Battle of Agile and Waterfall.

Rewards for the Faithful…

This is something I see a lot in different teams and organizations. A perception that Agile practices are mainly aimed at developer comfort.

Many Agile practices indeed add to the comfort of team members - in the same way as any sensible practices do. Yes, focusing on what makes sense and reducing useless activities will naturally reduce stress. However, the main focus of Agile is delivering more value through embracing change.

Here’s a good example. Why is there a WIP limit in Kanban? This article (which popped up on page 1 of my search engine) suggests the reason is overload prevention. I quote:

(Adding a clarification after getting a review comment - the quoted article is obviously wrong, some more comments here).

Many other practices (or the absence thereof) are also interpreted from the developers’ comfort standpoint. For example, estimations and time constraints (I don’t like the word deadline, too much dead for my taste) are evil because they are stressful.

What’s the difference? Does it matter whether we don’t do estimations because they are not a wise investment of time and effort, or because they are stressful and uncomfortable? For me there’s a huge difference - and that is a difference between wisdom and cult.

Let’s take a look at estimations and constraints

Starting with axioms. There are real constraints and artificial constraints. Setting artificial constraints is dumb. Ignoring real constraints is dumb.

Now that we’re past stating the obvious, let’s take a further look.

The story about constraints (“deadlines”) that’s regularly told in the Agile vs. Waterfall articles usually goes like this:

• Manager: How long would it take you to complete a reporting feature?
• Developer: I don’t know, too much is unclear yet.
• Manager: Well, what’s your best guess?
• Developer: Maybe like two months?
• Manager: Excellent, this placed us in June. ….
• Manager: Commits to June in front of their boss.
• June: Comes.
• Manager: Where reporting?
• Developer: It’s not yet ready, many things changed since my first crude estimation.
• Manager: Starts repressive actions.

This is a perfect example of artificial constraints. There was no real-world necessity to deliver reporting by June. Even more so, without the manager’s question, the “June deadline” would not even exist.

Now if this tendency continues, the developers will be forced to either push back (good choice, but not always possible in real life) or pad the estimations until they end up in the safe range.

This story has been discussed million times, so I’m not going to write a lot about it. Of course, the whole interaction is completely meaningless and is just a waste of resources.

One absolutely wrong conclusion you can make from this is “estimations bad, deadlines bad.” It’s tempting to draw this conclusion, and it looks right, and what makes it especially attractive is that it brings comfort. No estimations, no time constraints = stress-free life, and what’s the goal of working for a company other than not having stress - not adding value to customers, that’s for sure!

Okay, jokes aside. Let’s consider a few different situations.

Don’t be late to your flight

First, let’s look at the most ridiculous myth, which is “you can’t predict the future, so you can’t plan.”

How many times in your life have you missed a flight because you were late? What’s your miss-vs-not-miss ratio? For me that’s 0/100, I have never missed a flight in my life - although I was close maybe once.

But how does it happen? When you depart from home, you don’t know the future. You don’t know what the traffic is going to be, you don’t know if trains and buses are going to be on schedule (I live in Europe, so I use public transport :), you don’t know if you are not going to fall and break your ankle. How on earth can you be there on time every time?

Can you actually… PREDICT THE FUTURE?!

There’s a big difference between not planning at all, departing at a random time with random things packed in your suitcase, and:

• Using a list for your baggage
• Packing things in advance
• Having a Plan A (train), and a plan B (taxi)
• Departing in advance to allow for both Plan A and Plan B
• Knowing the critical time when you are going to switch from A to B

“Agile Cultists hate this simple trick.”

I am not trying to claim that getting to the airport has the same level of complexity as implementing a software feature. Not at all. I’m trying to establish that planning makes sense - even if you (obviously) can’t predict the future.

Christmas sale

Suppose your team is making an app for a Christmas sale. The sale is one day - 24th of December. It’s a perfect example of a real constraint. Christmas comes on 25th of December, and you can’t ask it to wait, you can’t reason with your manager to postpone the Christmas. The Agile gods are (at least currently) less powerful than Christian.

You started in mid-November and you had around one month to get the app done. Now it’s three days before the sale, and it becomes evident that the app is only halfway done. The first version of the app released after the first sprint is functioning (because you always finish your sprint with a potentially shippable product!), but is not good enough for the customer to put it out there. There’s no way to get the app off the ground on time, so all effort spent on app development is wasted.

You could argue that the Agile practices were not followed well enough (let’s not go too deep into that territory for now). But here’s the thing - in the retrospective, the lead developer says it was pretty evident from the start that it’s impossible to implement the app in one month. It’s not clear if two, or three, or even four months are required, but it was evident that one month is not enough.

Wasn’t that an estimation? Wouldn’t that estimation be useful to make to avoid scrapping work?

I think it certainly would. And there are many other examples where estimations are very useful.

For example, you could assess the order of magnitude of the work required (days? weeks? months?) to quickly judge whether it makes sense to even continue discussion on a project, or it’s better to focus on other things.

(side note: I’m writing more about this in the cost of delay prioritization article.)

Time constraints and budget constraints objectively exist. Christmas comes on 25th of December. If you are launching a space mission, planets would end up in a certain favorable position on a certain date. A factory would be ready to manufacture a new model of sneakers by a certain date, etc.

Meeting these constraints is hard and sometimes stressful 🤷

…and Anathema for Heretics

One thing that I particularly enjoy about Agile is that it encourages experimentation, exploration, and continuous improvement. Well, not in the Agile Cult world.

Let’s take ScrumBut for example. What is ScrumBut you ask? According to Scrum.org it’s a situation where Scrum is modified to conceal a larger-scale dysfunction and is, obviously, not a practice to encourage.

But that’s just Scrum.org opinion. Let’s see how it’s interpreted in th industry. This article is the top page in my search results for “ScrumBut”. And it says, I quote:

and it further reads:

Wow. I didn’t know using “only parts of [Scrum]” is a sin. But it certainly looks like it.

Let’s take a look at another article, the third result of my search (after Scrum.org). The article is called “Why you must avoid ScrumBut at all costs” (at all costs?!). I quote:

Really? Is that the biggest problem?

Oh my Agile god, I thought my goal is to deliver working software and that the biggest problem is hindering that capability of me and my team. But no. Turns out my biggest problem is insufficient purity.

More articles and videos demonstrate further impurity-shaming.

I asked ChatGPT about process tailoring in Agile (to which it gave a completely sensible answer), but as soon as I started to ask about Scrum, the fun started.

Really? Isn’t tailoring done to enhance the team’s ability to deliver value? No, the ultimate virtue of Agile is being Agile.

Good practices are good because they are Agile. Bad practices are bad because they aren’t. This is the perfect world where result is not required anymore - being Agile is both necessary and sufficient.

Final words

From a philosophy behind good software development, Agile turns into its enemy. It becomes rigid, unfocused, full of itself.

We say that the biggest sin of Agile is that it’s spoiled by “corporate.” Bad managers, bad customers who don’t understand how to be Agile. I don’t think so. They certainly have impact, but the biggest harm comes not from Agile heretics, it comes from Agile zealots. For example, I was once present at a large company meeting where participants discussed how they should demand all customers to be agile and follow agile practices, so that the processes of that company work well.

Do we forget the fundamentals? It’s Individuals and interactions over processes and tools. And “while there is value in the items on the right, we value the items on the left more.” Why not ask the customer why they have that “deadline”? Why not ask the management what they want to use the estimation for? Have a dialogue, interact as individuals instead of clinging to a dogma and ranting on the Internet about how your Scrum is not scrum enough, and how your managers and customers are all doing the wrong thing. They may have a valid reason, and if it’s important to deliver value, the processes must adapt, not the goals.

Anyway, I wanted to say the final words, and look at me going on a rant again.

Final word. Spirit of Agile over letter of Agile. While there’s value in the letter of Agile on the right, I value the spirit on the left more.