Ken Schwaber is the co-creator of Scrum with Jeff Sutherland. This is Part 2 of a multi-part interview with Ken, covering Scrum credentialing and testing, Scrum coaching, the influence of the Kanban Method for managing work, Ken's thoughts on the future of knowledge work, and more.
Part 1 of this interview is found here.
Ken is the founder of Scrum.Org, a credentialing organization that offers Scrum classes, Scrum certifications and assessments in Scrum skills.
Ken, the norms in typical organizations tends support a very low level of collaboration. Absent a high level of genuine collaboration, the authority for making these important Scrum implementation decisions (such as who becomes the PO or SM) is vested in those who have formal job titles like CEO, CFO, VP, and the like. Often, the policies created by people in these roles are the very things that are creating the need for Scrum in the first place. Isn't this a good argument for more prescriptive implementation guidance from the canonical Scrum defined in the Scrum Guide?
Once again, a very slippery slope as we rely on prescription, our habit of old that got us into so much trouble. Prescriptive guidance is, by its definition, limiting: do this, do not do something else. Since Scrum is a process for complex circumstances (more unknown than known), this means that the prescription by itself will prove wrong more often than not. Then it will create unintended consequences, as well as providing an excuse for why things don’t work. For example, if Scrum said: “Project managers should be the source of Scrum Masters.” This prescription then provides a source of blame, “We would choose another Scrum Master, but Scrum says they must be project managers. Scrum sucks, our Scrum Master sucks, what can you expect?”
Then intention of Scrum is to let people do their best, including making decisions, and then inspect the consequences. If the consequences are something other than desired, the person with the accountability is responsible for making an adaptation to improve the results. Prescription relives this person of this accountability.
We must keep free from methodologists and others who say that Scrum would be so much simpler if the people using it didn’t have to be intelligent and figure out their own problems.
Tell us about the Scrum.Org credentialing process. For example, how does a person become certified as a Professional Scrum Master at Scrum.Org?
Credentialing, or assessment, begins with a widely accepted body of knowledge. With Scrum, that is the Scrum Guide, the definition of Scrum by Jeff Sutherland and myself, the creators of Scrum. The assessment is a set of questions that tests whether a person knows that body of knowledge. We currently certify a person if they demonstrate a knowledge level of 85% or higher.
We also have assessments of a person’s knowledge of using Scrum to build software products. This is the PSM II assessment. The third assessment is whether a person has an adequate degree of knowledge of how to build an increment of software in a Scrum team using a specific technology stack (.NET and JAVA, currently). Scrum.org partners with organizations that develop training programs to help people acquire this knowledge, but training is completely separate from assessment.
People can be knowledgeable without being trained.
Most competent Scrum Masters keep an impediments backlog, in effect adding a custom artifact to their implementation of Scrum. The newest revision of the Scrum Guide includes a new artifact-- the Release Burndown. Can the incorporation of an Impediments Backlog for Scrum be far behind?
Certainly this is an idea! In my book, “Enterprise and Scrum,” I suggest an enterprise product backlog, which is simply a product backlog of organizational impediments. I suspect that there may be many artifacts that are needed and used by people and organizations that will be useful when using Scrum, but not part of its formal definition.
Article Note:
This is Part 2 of the Ken Schwaber interview. Published in segments, Part 1 of this interview can be found here. Watch for the next segment of this interview, where Ken discusses some timely and controversial topics, like Scrum relative to Kanban, community-level Scrum maturity, what's next for the Agile community, and more.