Very few people have that flexibility of mind, in my experience. It is in the manifesto "while there is value in the items on the right, we value the items on t

Very few people have that flexibility of mind, in my experience. It is in the manifesto "while there is value in the items on the right, we value the items on the left more". I (may) be able to point out you failed here. Agile doesn't reject anything, including process. It just states that it values some things more than others. Process is often vital. I used to write avionics software for the military. As you might guess "move fast and break things" was not our mode of operation. Retrofitting a helicopter requires massive amounts of process and waterfall. You can't not follow a plan. You have to decide where you are putting the electronics, and the specs on rack sizes, power, etc. Then you design the electronics to that. Then it needs to be manufactured, and so on. You can't decide at the flight readiness review that you want a screen on your radio that displays the weather. This is really old stuff. I was taught this (agile way of thinking) in college in 1983 by an electronics professor. He stratified it differently, talking about goals, strategies, and tactics. People get hung up on tactics - "all code must use lower snake_case variables", or "stand up can't be a status report", or, .... But those are all tactics, in service of a goal. You need to remain flexible he lectured (and I agree), and recognize when the goals have changed, and/or when tactics and strategies conflict or make things non-optimal. That's all pretty much what the agile manifesto says, except they impose a weighting on values that I don't think fits all cases. As in my example above, sometimes process is more important, despite the many costs that kind of thing incurs. Cause, you know, we don't want people to die when they fly the helicopter. And in that helicopter retrofit, the SW lead (Hi Paul!) had a saying "design a little, code a little, test a little". It was never waterfall, even back then, though you were in a waterfall process necessitated by the reality of complex projects. It was all about responding flexibly where you can, and being rigid when you can't. You don't push a sw patch 2 days before the flight readiness review. You don't decide to add components to a radio if it exceeds the designed power specs of the power network in the airframe. And so on. You may be able to change a screen element on a flight computer if the pilot suggests something is confusing or sub-optimal, but even that has high costs (revise all the training materials and documentation, simulators, etc, run all pilots through the training, it can run into millions). Always think flexibly about why you are making these decisions, why you are doing this, why you, say, empower people vs canned process, as you stated. Without that, you are just back to unthinking process, claiming to be agile while you are anything but. Back to how I started - I have yet to come across anyone running around extolling a specific methodology, including agile, that was anything but unthinking, inflexible, and unable to answer real world questions. It's just particularly ironic given the name 'agile'. Edit: I left something unsaid, and it's important. The Agile manifesto is at the level of 'strategy', not goal. It is not ever our goal to "respond to change", as it states. That's a strategy. Our goal may or mat not make that strategy possible or desirable. I don't want to kill people, so if I'm making a helicopter change has to be planned out very carefully. Agile is mostly a set of strategies aimed to get working software into the hands of clients as soon as possible because things like specifying what you want, pricing out development costs, and so on are so hard. That often just doesn't hold. While I can't disagree with what is written given the states objectives, I think it is just another somewhat inflexible way of thinking about systems. It works for a lot of bay area type development, but goes off the rails in many other domains if you don't recognize the values listed, and the relative weightings, are based on a number of assumptions about what your real goals are.