I’ve been doing XP for 22 years, and was on Ward’s wiki as the C2 project was being executed, watching the ideas grow in real time. I worked for Pivotal for the last 5 years. Here are my thoughts.<p>Agile alone is insufficient to successful products, which the original proponents would tell you. It’s a body of practices. There are more practices than just those. People seem to want “12 steps to an easy rich life” and want to scream when someone offers only 6 of them.<p>Most of the Agile practices the industry has adopted and evolved without calling them agile. So in that sense, it’s a “success”.<p>But agile coaches often are so focused on the original 20 year old practices and they miss the bigger picture of business and products and supporting technology, and the evolution that’s taken place in each during that time.<p>Any software method that is delivering software for users to consume has to be complemented by outcome-focused approaches like user-centered design, product development, customer development, and budgetary funding / management practices that don’t weaponize the use of openness, sharing, and metrics for political purposes that hurts people’s self worth. If you’re missing those, agile isn’t going to help you much.<p>Ultimately just letting engineers be engineers is partly how we got into this mess in the first place. People don’t know how to organize themselves without some kind of constraints: design constraints, time, physics, customer constraints, quality, etc. Talented teams turned loose that ultimately deliver little of value is a cliche at this point. Agile tries to use time as a constraint to limit active work in progress to force the delivery of customer visible / valuable results that can be tweaked. It’s not the only way to constrain the problem space, but “cost of delay” does have a fairly universal explanatory value in showing what really matters to a business, as lean product development and manufacturing has shown. But that might not be the outcome you’re looking for.<p>whatever process or practices you do, Agile or not, it has to be organized end-to-end to be tied to some kind of tangible mission or outcome or else it’s just a form of self-deception. For example, if we think products need to be usable and solve actual problems, and that design can evolve, then Product owners need to speak for the Customers and have the power to make decisions. Engineers need to be empowered to make the technical decisions. These seem obvious but they’re rare: committees and political strings attached are the norm. If you get both an empowered balanced team of product, design, and engineering you’ve got potential for an engine of collaboration and learning, which is the whole point. Don’t build projects, build human/techno systems that grow and improve and evolve.<p>Agile is also not universally applicable and much of the resentment stems from a religious conversion therapy or Developer Rehab approach to marketing (even though some really could use a stint in rehab). Agile is applicable to some kinds of software (user-Centered software in particular), which happens to be a big chunk of industry. It isn’t applicable to everything, such as deeply technical components, pure or applied scientific R&D, or certain kinds of exploratory work. Nor is it applicable to jobs with set and unchangeable requirements.<p>People are best to understand there are a spectrum of practices and processes suited to different environments and stages of organizational evolution. Or they could reject such complexity and nuance and just adopt SAFe, I guess.