This blog post will be less pragmatic than my usual ones, but I need to get this off my chest. Why do I encounter so many Agilists that are less agile in mindset than many of the project managers I know who work on Waterfall projects? Does any of this sound familiar to you and drive you as mad as it does me? You may have heard:

  • “This is not true Agile.”
  • “This is not called a User Story, it’s a PBI (or vice versa).”
  • “Method X is not Agile, Method Y is much more Agile.”
  • “Sprints need to be x days long and not any longer.”

I have even heard that some methodologies prevent people with their highest training certifications from being certified in other methods. I cannot confirm this, but if true, it is madness in my view.

This reminds me of all the passion and silliness of this scene from Monty Python’s Life of Brian:

Let’s make one thing clear: There is no award for being Agile according to any one Agile method. This level of dogma is completely unnecessary and is taking too much energy in Agile discussions.

What we are trying to do is deliver better solutions faster. And, all the methods and tools out there are for us to combine to achieve that. Of course, when you are not mature, you should follow one of the methods more strictly to get used to the new way of working and then later combine it with other elements. (Shu Ha Ri is a common concept we use to explain this). But, we need to focus on our main goal. I appreciate that it is often harder to measure outcomes than compliance to a specific method, but it’s worth it.

<<< Start >>>



<<< End >>>

So, if you encounter an Agile coach that is dogmatic or only follows one method while speaking disrespectfully of all others, be careful. He or she might be able to help you a few steps of the journey, but you should look for someone more open minded to help you in the long term.

There are a lot of good talks and articles out there that challenge the “folklore” of software delivery. I find it extremely interesting to read about people who diverge from the “scripture” and do research to prove or disprove what we think we know. A couple of examples:

If you know of more examples, let me know. I love it when concepts get challenged.

Mirco Hering

Global DevOps Practice Lead – IT Transformation & Delivery

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog