Trap for Agile Frameworks: Morality that Kills Rationality

TL;DR. Moral superiority sells well. And this is why we see it a lot. It gives easy wins today. But it steals the future. If you don’t manage it, or better, avoid it, it replaces thinking with righteousness. Engineers, including CTOs, cannot afford that. We are paid to care about outcomes, consequences, and reality, not emotions and hype. Agile frameworks are a very good example of how this trap works.

Agile frameworks easily become a gold cage of moral superiority.

I have many good conversations with colleagues, online and offline, about Agile frameworks. Often with some disagreement. One recurring topic is this: Agile frameworks do not provide an exact toolkit. They offer principles and ideas instead. Many people see this as a failure. And they are right. There is a problem. Many Agile attempts fail because the wrong tool is used, or no proper tool is used at all.

From there, a common conclusion follows: Agile frameworks failed; therefore, we should “fix” them by inventing a complete toolkit. That conclusion always puzzled me. Nothing in Agile forbids using tools. Quite the opposite. Agile encourages adaptation, context, and choice, even if it does not spell out “go find the right tool now” in bold letters. We already have an enormous number of tools for different situations and constraints. Most of the time, we do not need to invest in new tools all over again. We need judgment.

Well, to my shame, just before writing this article, I spent two hours at a lathe making a special tool to clean the thread of a 19th-century screw. That happens. But it is rare.

So why do so many people fail to do the same in software and organizations? Why do they stay inside the framework as if it were a jail, even when the door is wide open? Recently, while writing a comment on LinkedIn about morality and moral arguments (in the context of “being a pet parent is morally superior to being a responsible pet owner”), something clicked.

Agile, as it is often practiced today, is not only about principles or science. It carries a strong sense of moral superiority. You see it constantly: posts about how Agile is “better” than Waterfall (whatever that word means today, nobody knows, but it is surely bad, as bad as Donald Trump) or how teams “suffer” under bad management.

Moral framing replaces technical and economic reasoning.

And this is the trap.

Moral superiority becomes the compass. Inside the framework, everything feels clearly good or bad. Outside of it, the compass disappears. Leaving the framework means losing moral certainty. So people stay inside, even when it no longer works.

For some of us, this is not a problem. We do not need moral arguments at all.

Agile, in its essence, is just the scientific method applied to software development and business processes. Hypotheses. Feedback. Evidence. Outcomes. Consequences. Courage to change when reality disagrees. Very practical things.

Seen this way, Agile still works even when you step outside formal boundaries. You stay agile without clinging to the label.

So, using moral arguments is dangerous because it does two things.

First, it easily replaces rational reasoning. “We are right because we are better” becomes a substitute for explanation and evidence.

Second, it shifts focus from clients and outcomes to ourselves. From value and impact to our own righteousness.

That is a perfect recipe for conscious learning of helplessness and blindness.

Engineering is not about proving we are good people. It is about using technology to make other people’s lives better. Goals, businesses, clients, and consequences come first. And let psychoanalysis deal with rich inner worlds.

Engineering (and Agile!) deserves rationality back.