It's interesting because "agile" can fail on both sides. This lampoons the enterprise side, in which you adopt "agile" practices inside rigorous change control and long requirements documents. But there is also the cowboy/ninja failure mode, in which "agile" is used to rule out any strategic thinking, technical design, or requirements gathering.<p>Not only can you fail on both sides, but you can be too far on one side and think that you haven't gone far enough.<p>I've had startups tell me they were doing Scrum, but it had gotten so hard to estimate their work that they had "broken agile" by having "grooming sessions" to talk to stakeholders about upcoming work before it got into sprint. They were shocked to learn this was a required part of Scrum and that many books recommended that being up to 10% of the team's time.<p>Another company I talked with was so concerned about their developers "continuously delivering" code that they were fighting to be "more Scrum" by changing their QA folks to be in a staggered sprint one week after the developers. They were shocked to learn that this was a widely-tried and widely-panned approach that was philosophically opposed to the roots of Scrum.<p>Now, I remember hearing examples like these before I had really dived into Scrum, and assuming it was a "no true Scotsman" where, whatever you did, someone would find a way to say it wasn't Scrum. But after some very good books and talking with experienced people (who were involved in the early stages, not bandwagon consultants), I now feel like I actually understand what Scrum is for and when it works, and can quickly spot people who don't understand the philosophy. Has anyone else experienced this? I wonder whether it is real experience or just an illusion my brain has created to give meaning to many months of painful trial and error.<p>Nowadays I think of scrum as being about holistic product creation, about building a team that can deliver what customers will pay you for over the long-term. That requires breaking down most "process" to get "one-piece flow" on a complete team working as one to deliver new features. But it also includes the team building its own processes to make sure they are building the right thing to a high level of quality.<p>That vision is anathema to cultures that value technical prowess, or pure speed, or meeting corporate objectives, or anything else other than building a team that can deliver value to customers over the long term. It's a challenge and a priority change for both corporate political environments and built-to-flip startups. And it's surprisingly hard to find a company that wants to pay you to build things their customers like, rather than using some other metric.