Scrum might be a starting set of processes adopted by an agile organization, but an organization that is concerned with "doing Scrum right" is not Agile.
I agree that anyone who is dogmatic about "doing Scrum" for its own sake is missing the point, as is anyone who is "doing Scrum" in order to just make their team more organized or productive. That said, within the constraints of the current business world, Scrum is the best way that I have seen to resolve the necessary tensions of creating software products and let people and interactions take center stage.
But I'd love to hear your experience and advice.
I get the "no true Scotsman" sense myself. What book(s) was most helpful in pinning down what scrum is and isn't?
Thinking about it, the book that actually taught me to understand what the early agile people thought was Christopher Alexander's book "The timeless way of building." The book is about architecture rather than software, but the underlying idea is right on. It starts by addressing what is the point of building? Some people try to optimize speed, or predictability, or how good the building looks. But Alexander says the point of a building is to be lived/worked in, and it should be measured by how it improves the human lives of people around it. This implies doing the design and building in a whole different way, and thinking about the relationships between builders and users in a different way.
The "agile" idea is similar. People who try to "use agile" to accomplish their goal of just making software really fast, or making lots of money, are missing the point. Agile is actually about building software that is good, in a way that is sustainable for users, builders, and a company, and makes everyone involved better. If you use Scrum in the context of those values, you may succeed.
But the vast majority of people who adopt scrum, and perhaps the majority of consultants and explanations trying to "sell" Scrum, just use it to wring every ounce of effort out of your employees, or to ship something crummy fast. That ends up not really working, and in my experience making environments even worse than they were before.
But there is an enormous difference between his real idea of "design patterns" and the much more static idea that you see in, for example, the Gang of Four book. The easiest way to see this is to consider that the methods and goals of "A Pattern Language" are centered around making buildings that add to the quality of human life (and the first few patterns deal with the goal of world peace), and would be totally useless to someone building a gulag. Whereas the patterns in the GoF book are just about preventing code duplication, and would find themselves just as useful in a program for violating people's privacy as one designed with a more benign purpose.
By definition, I think that would have to be the Scrum Guide [1].
"Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum."
In my view, stories are tokens for conversation. Now when I deal with teams who are writing down more than a few words, I look for barriers to conversation. E.g., not all the right people sitting together, or too much work in process.
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.
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.
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.
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.
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.
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.