> 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
I get the "no true Scotsman" sense myself. What book(s) was most helpful in pinning down what scrum is and isn't?
I recommend "The Scrum guide" and "Extreme Programming Explained" as ways to learn about the systems themselves.
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.
It is indeed, and the book I mentioned is the prequel to his book "A Pattern Language."
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.
I get the "no true Scotsman" sense myself. What book(s) was most helpful in pinning down what scrum is and isn't?