The person is actually talking about a broad range of things that don't just apply to agile. It's a little bad to compare this area to religion but, for agile,

The person is actually talking about a broad range of things that don't just apply to agile. It's a little bad to compare this area to religion but, for agile, the analogy is apt because people feel it's the "only" way to do things. What this person is talking about is a part of engineering where no theory or science applies. Take these two examples: 1. Solving the problem of the shortest distance between A and B involves a line... this is covered by mathematical geometric theory. 2. The best way to travel from point A to point B in the United States is not covered by theory. The two examples illustrate a dichotomy: 1. Problems that can be solved with mathematical theory or science. 2. Problems that can be solved with "Design" Problem space 2 is the umbrella that agile falls under. Usually when we hit a problem related to 2 we employ the word "design." The design of a house, Object oriented design, the design of a bridge, the architecture design of the program, UX design... etc. etc. "Design" is a method to find a solution to a problem space that is either too complex or we have little theoretical understanding. Designing something is akin to guesstimating a solution. We do not have any proof that a "design" solution we arrived at is the "best" solution, we only know that it is "a" solution (after verification of correctness). Agile is like object oriented programming because both are methods created by guesstimation aka "design." There is no theory or proof (though there could be correlations) that either is the best possible solution. Agile is especially religious because of the specificness of it: A series of random rules to manage a project out of a solution set where trillions of rules and external factors apply. Intuitively, there is literally no way agile is the "best" solution. Until we can quantify the effectiveness of a project and until we experimentally employ other structures and methods for project management and SCIENTIFICALLY compare the effectiveness of all these methods can we begin to iterate toward a solution that is closer to "best."