I first got interested in Scrum around the time Ken Schwaber published the first two books about it in the early 2000s.
I was impressed that Ken admonished us not to present Scrum as a silver bullet. Instead, we can use Scrum to reveal organizational shortcomings so that management can fix them if they are brave enough to do it: Effort centers on the change in the enterprise that is needed.
We were also advised that Scrum implies more change than most organizations are ready for, but we should not water down the message just because change is hard: The gap between current practices and target practices is a measure of incompetence and competitive risk. The CSM class at that time had an exercise to reveal our own human tendency to make promises we can’t keep: These are habits that we aren’t even aware of anymore. Not all the exercises worked and I wouldn’t call it a “feel good” class – I remember my co-worker rating it a 5/10, similar to how I was flummoxed the first time I heard Kent Beck speak.
We did not spend class time learning about these supposedly-magical Fibonacci numbers I keep hearing about. I’m pretty sure we ignored burndown charts, and very sure I didn’t hear Ken talk about “velocity” or “hyperproductivity.” Ken told us there is nothing new in Scrum, in those days laughing at the idea that he or anyone else could have invented it.
That is the Scrum I signed up to teach: no silver bullet, and realizations that may be uncomfortable.
Scrum’s specific mechanics are not the point, and not needed for teams that have internalized the principles. But there is something to the idea of a simple set of rules that can help a team and organization discover where change is needed, something to the idea of a Scrum Master helping change the organization to allow team self management (not making the team do Scrum) focus on the top priority work, and constantly inspect and adapt.
That’s a useful kind of Scrum. We don’t need to oversell it with hyperbolic claims.