This formulation, which should really be an Assert() statement, struck me the other day as I was reading about some of the fallout from the recent changes in the board of directors of the Scrum Alliance. I have read about some of Ken Schwaber's famous (infamous?) conflicts with various members of the Scrum Alliance community. I also have colleagues who have faced the ire of Mr. Schwaber for promoting ideas that Ken found inimical to Scrum.
In a very major sense, I admire Ken for defending Scrum. Indeed, I find his tenacity refreshing, inspiring even. There are so many people who would dilute Scrum for whatever reason. As with some clients I have worked with, some people want to change or even drop key elements of Scrum because they would rather paper over dysfunctions Scrum has exposed instead of fixing the root cause of the problem. Ken's devotion to Scrum has helped me repeatedly in sticking to my guns and insisting that teams I am coaching follow Scrum practices rather than taking the path of least resistance.
Other people believe, not necessarily incorrectly, that they have discovered an optimization to one or more Scrum practices and then want to share their discovery with the rest of the Scrum community. I see no issues with sharing the idea or experience. That in and of itself, however, does not mean that Scrum has been extended, improved, or changed. The Scrum community must validate changes to the basic practices and adopt them as part of Scrum. There should not, in my view, be any restriction on the sharing of experiences and ideas about Scrum.
This brings us to what I see as two problem areas. The first is that the Scrum Alliance is perfectly justified in cautioning Certified Scrum Trainers against teaching practices in CSM or CSPO courses that are not part of the recognized and agreed-upon components of Scrum. Put more simply, no one should be passing off anything that is not Scrum as Scrum in certified training courses. Additional practices, extensions, or differing interpretations of Scrum and its practices should not be suppressed, simply not labeled as certified Scrum.
The second problem arises from extending the first problem beyond the bounds of certified Scrum. Colleagues of mine have been cautioned very strongly against presenting, teaching, or writing about extensions, modifications, or variations on standard Scrum practices, even when those non-standard items are never advertised as parts of certified Scrum. To me, this goes beyond defense of Scrum and into the realm of censorship. New ideas need to be given free hearing and either added to the body of knowledge and practices of certified Scrum or not. That decision rests with the Scrum community, however, and not with any specific individual.
So, to recapitulate, certified Scrum is what the Scrum Alliance says it is and should be taught as such. Other ideas should be given a free and open hearing and freely discussed, but should not be passed off as a part of certified Scrum. At least that's my interpretation.
All for now.