How Not To Be Agile

People tend to view agile as an excuse to bypass planning and jump straight into implementation. It is tempting. 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. These things tend to end in a slightly annoyed "...but it is best practice."

Confession: I’ve been guilty of this myself, and I’ll probably do it again soon enough.

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 require 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 in increments. Chipping away at the problem. How you navigate that journey is ultimately up to you, within whatever constraints or requirements exist.

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