• Thomas Meloche

Agile Isn't Really Good for All Projects

Updated: Feb 4

Executives, managers, and team members frequently say to me, “You know agile isn’t really good for all projects.”

I respond, “Tell me about one?”

Agile has a soft and squishy definition. They may be right depending on how they see, use, and experience processes labeled with the term agile. So I have learned to not to assume I know what they are talking about, not react with emotion. Instead I respond with curiosity, asking questions about what they are thinking.

Quick retorts or comebacks defending agile are simply silly. They never work. Believe me, I've tested it.

When someone says "Agile isn't good for all projects," they are not attacking me, nor agile. They are simply sharing their view of the term agile. They are sharing how their brain views the term. This is a function of all of their unique and individual life experiences. It is always a very different view than mine. Their comment can become a delightful opportunity to see the world through their eyes.

It is amazing what you learn when you listen.

I heard examples of dozens of different types of projects people think would not be a good choice for agile: embedded controllers, Mars landers, giant enterprise-wide data ports, scientific instruments, etc. It is fun to hear about their projects, their concerns, and their very legitimate desires about how they wish to work.

Their projects and concerns are interesting, once we get beyond fuzzy words and labels. No two definitions or agile are ever the same and we quickly discover we need to leave the agile label behind.

We instead discuss fundamental ways to achieve the outcomes we desire on difficult projects. What do they suggest? We may actually actually agree on at least three or four key ways to make their example project better. Frequently we discuss:

  • Shorter cycles times

  • Prioritized work queues

  • Regular demonstrations of working solutions

  • Incremental delivery

I am always happy if we discuss shorter cycle times. As a matter of principle, the folks with shorter cycle times tend to win.

If we take the time to explore together ideas about achieving outcomes we always discover something wonderful. We learn how differently we use words to understand our world. We find our project can be improved in many of the same ways even if we give them different names. I may call a process which delivers the four elements above agile. But if they don't call it by the same name, it is certainly not worth quibbling about. Agile is just a label. It is a label that didn't even exist when I first starting having great success with those four elements.

What do I care about the label. Perhaps it isn't even that great of a label.

When you hear some say, “You know agile really isn’t good for all projects,” let that start, not stop, the conversation.

“Why no, no I don’t. Tell me about one?”

Then listen. Ask clean questions. Discover how other people can truly be endlessly interesting.

“Take input from reality and respond to it.” –Kent Beck's definition of Agile. I like Kent's definition.


©2020 by Tom Meloche.