In Defense of Certified Scrum Training

I have been reading and hearing criticism of certified Scrum training sponsored by the Scrum Alliance for almost as long as that body has been in existence. As a QA guy on an incipient Scrum team, I heard colleagues dismiss such training and the resulting certifications as superficial or worse. A couple of years later when I began making my living as an Agile trainer and coach, I encountered even fiercer denunciations of certified training from colleagues and from some members of the broader Agile community. I kept an open mind throughout, but did often wonder what all the fuss was about.

Recently, during the last year really, I have come to a new appreciation for certified training. Certified training, to put it bluntly, defines the parameters for the content. In the case of certified Scrum training, what is presented and learned must be Scrum, which a clearly identifiable thing consisting of the well-known values, roles, ceremonies, and artifacts. The Scrum Alliance goes to some length to ensure that its certified trainers do not teach something that is not Scrum under the label "Scrum." Some agilists get utterly bent out of shape over this seeming restriction. But to me, it makes perfect sense. No one anywhere is saying that agilists cannot teach something other than Scrum and plenty of such training is going on to great benefit of the individuals and organizations that embrace it. Kanban certainly fits that bill perfectly. But, and this is the key point, Kanban is not Scrum and should not be labeled as such.

Another benefit of certified training occurs at the organizational level. I have worked with clients that claimed a sincere desire to become "agile," but immediately rejected the implications of Scrum. In a non-certified environment, it is all too easy for a client to dispute the value of basic Scrum practices and simply demand something that looks and smells a lot like what they are doing today, hoping that the consultant, trainer, or coach can just make it all work without any of that painful organizational change stuff. In a certified Scrum environment, the selling of "fairy dust" (or snake oil or whatever metaphor you prefer) is not possible, or at the very least, much less likely. If a client wants Scrum, it's Scrum they'll get, with all the pain and eventual exhilaration that transition entails. If it turns out that the client really doesn't want Scrum, at least everyone can agree on that point and make the appropriate decisions.

Now I'm no wide-eyed naif. I am fully cognizant of the limitations of the entry level certifications. Being a Certified ScrumMaster does not make one a masterful, or even competent, ScrumMaster. I have learned this excruciatingly painful lesson first-hand in my coaching life. That is not to say, however, that the two-days of training are worthless. When competently delivered, trainees understand the Scrum framework, the roles and rhythms, and how to move forward with Scrum. As with any type of education, individuals make what they will of that abstract knowledge. Some bandy the title about as if it meant they were Scrum experts. It doesn't take much effort to expose the hollowness of such claims. Others use the certification as the gateway to successful Scrum practice, gained through hard, daily, on-the-ground experience either as ScrumMasters or in some other role on a Scrum team. But blaming certification in general for the sins of what is really a small number of people is neither valid nor useful.

I don't know what the future holds, obviously, but for now and for the foreseeable future I believe Scrum is the most broadly applicable framework for new product development and as such, I support certified training and certification in Scrum.

All for now....

...-.-