Software development is an incredibly immature professional discipline, which has lead to people mostly making it up as they go. You also have the rate at which

Software development is an incredibly immature professional discipline, which has lead to people mostly making it up as they go. You also have the rate at which it changes, making it hard for any sort of standard practices to keep up with. Outside of some industries that regulate security and privacy, software development has also never attracted the attention of any regulator that may have an interest in actual quality of workmanship (which would be impossible in any case). Can you imagine the architecture equivalent of shipping terrible code? “This software has bugs” is acceptable, “this brand new building is falling down” isn’t. There’s a standard way to build a house, there’s a standard way to perform heart surgery, there’s nothing close to a standard way to build software, and if you can’t properly plan your work, how can you properly manage it? That seems to be the problem these management fads are trying, and failing, to solve. People hated waterfall because you have to do so much planning up front, and in software development, that process rarely works. Project requirements change, or planning assumptions are proven wrong. So you need a management framework that works without that level of planning. That’s the core of agile in my opinion, only plan a little bit of work at a time. Really I think it just leaves you with the same problems, only now you have a lot of small failures rather than fewer large failures. If you look at the agile shops that succeed, they tend to have good leadership that simply has the competency to plan ahead well. Those teams would likely succeed under any management framework, only with agile you now also have the benefits of continuous delivery.