How not to be Agile

People often perceive agile as a justification to skip planning and dive right into execution. It's all too tempting, a way to move quickly without having to justify the reasoning behind it. This mindset is fundamentally flawed and a significant misunderstanding of what it truly means to embody agility.

I've found myself in numerous meetings, where engineers and managers advocate for new initiatives and changes, confidently declaring, "We should do this."

My initial question is always: Why?

After some discussion, we often uncover the actual problem statement — and that's progress. Yet, at times, especially with initiatives driven by mere technology fascination, we struggle to reach that point. These situations typically conclude with a somewhat irritated "...but it is best practice."

I must admit, I have been guilty of this behavior myself, and it's likely to happen again.

Nevertheless, it's an inherently flawed approach. You should always be able to justify why a certain action is necessary.

A solution should address a problem. If it fails to do so, then you've only introduced complexity and wasted your team's precious time.

Now, let's circle back to agile — and how all of this connects. Agile still demands a well-defined problem statement. In my perspective, the manner in which you tackle and refine that problem is what sets agile apart from the traditional waterfall approach. There are, of course, other subtleties, but this, in my view, is the fundamental principle.

In agile, you start with a clear problem statement and progress incrementally, gradually resolving the issue. The path you choose to take in this process is ultimately your decision, within the boundaries of any constraints or requirements in place.

But it all begins with the why — not the what or the how.