How not to be Agile

People often mistake agile for a “Hail Mary” of impulsive initiatives — a way to act fast without being accountable for the why. This mindset is fundamentally flawed and a major misinterpretation of what it truly means to be agile.

I’ve been in countless meetings, listening to engineers and managers alike push for new initiatives and changes, confidently stating, “We should do this.”

My first question is always: Why?

Often, after some back and forth, we eventually uncover the real problem statement — and that’s great. But sometimes, especially when it’s “tech for the sake of tech,” we can’t even get there.

Guilty confession: I’ve been guilty of this myself, and I’ll probably fall into the trap again at some point.

Still, it’s a fundamentally flawed approach. You should always be able to answer why something needs to be done.

A solution should solve a problem. If it doesn’t, then you’ve only added complexity and stolen valuable time from your team.

Now, back to agile — and how all this ties together. Agile still requires you to define a clear problem statement. In my view, the way you implement and iterate on that problem is what differentiates agile from waterfall. Of course, there are other nuances, but this is the core principle in my opinion.

In agile, you begin with your problem statement and work iteratively toward a solution. How you navigate that journey is up to you, within whatever constraints or requirements exist.

But it always starts with the why — not the what or the how.