I am a Scrum trainer. That means that I teach a project management framework, called Scrum, in public courses and in-house courses world-wide. It's part of how I make my living. I see this as a natural extension of my broader calling as educator and in many ways, training hearkens back to my university days.

On the other hand, it is also different.

As institutions, universities are places for intellectual exchange and growth — growth that comes from dialectic. If learning were not a dialogue, then most education could be achieved through books. Books are a one-way delivery mechanism. Universities, on the other hand, provide opportunities for two-way communication, and good educators learn nearly as much from the university experience as their students do. As educators learn they can change their methods, and even the content of what they are teaching. And, of course, the larger purpose of the educator isn't to pass along the current version of the facts but to challenge students to find them for themselves.

There are always limits. University curricula shape what a professor can or should teach. But even in a university setting these boundaries shouldn't be hard constraints. I remember when teaching a second-year programming course at an American institution, I wasn't supposed to go beyond simple data abstraction. The students were bright and demonstrated an ability to master inheritance and some degree of polymorphism, so I gave them a class project to do a chess program. They self-organized; did their own library research on game-playing algorithms; built tree data structures that they weren't supposed to know about for another year or two. They had a lot of fun doing it, and learned a lot. So did I.

I also have constraints as a Scrum trainer. Like many concepts in the commercial space, Scrum is based on a certification model. Like a course grade or a college degree, certification is supposed to convey a certain degree of competency or demonstration of mastery of the material. It kind of makes sense in an area that's highly standardized or procedural (like knowing standard network configuration procedures), particularly where public health or lives are at stake (such as a certified electrician or plumber).

Certification systems are too often closed-loop systems that deal with codifiable knowledge — knowledge that is based on facts and reason rather than dialectic. Training in preparation for certification is driven by those in the know, who define how those not in the know should act. The information flow is uni-directional, and it can be — and often is — codified in a Body of Knowledge. Certification often operates at the lower levels of the Bloom taxonomy, where memorization or mastery of simple concepts is enough to make the grade.

Every discipline has its domain experts: its inventors, keepers of the flame, or individuals who are passionate enough about the area to make a lifetime investment in its knowledge. In a sufficiently broad domain, like mathematics or plumbing, we find people who are right about the big things most of the time. But the small things change, and even the old dogs can learn new tricks.

Yet even codifiable knowledge changes. It's common to have to re-certify as a plumber every two years. (Compare these qualifications with your favorite software certification.) That's partly because practices evolve. How? Feedback from the trenches makes it back into the Body of Knowledge. It's not just the students who learn, or the instructor — it's the entire discipline that moves forward.

This is the kind of feedback loop that characterizes what today we call agile software development. That, too, is an area within which one can achieve certification, and that brings us back to my role in life as a Scrum trainer. I've learned things from my "students" over the years, and I've learned even more from the trenches. Sometimes, it's been hard to respond. If I'm in a college class and someone points out an error in a book, we congratulate the student, celebrate the learning, and pass on information to the author. It's a bit of a long feedback loop but eventually the problem gets fixed.

When I'm teaching a certification class and someone asks about "burn-up charts" as opposed to the "burn-down charts" that are part of the certification base, it's difficult to be so generous. My students' certification depends on begin able to regurgitate the phrase "burn-down chart," so I have to dutifully correct their "mistake." In some cases I know that the expected answers on the certification evaluation are just simply wrong ("In what order should the product backlog be kept?" They refuse "chronological," which is the right answer, and apparently insist on "priority.") It is frustrating and in the past, the turnaround time for feedback has been worse than for a book in print.

That's the simple stuff. On a higher level of discourse, knowledge evolves. Good education systems accommodate that feedback. It's been sometimes hard as a Scrum trainer to get that loop closed. And there is a balance between anarchy and flexibility in a system of knowledge, as in any system. Experience and vision have their place, as does honoring the role of discoverer or inventor.

All of that is changing today. Jeff Sutherland and Ken Schwaber, who together envisioned and built Scrum, have now envisioned a way to open the feedback loop. We have set up a web site where practitioners world-wide can submit ideas for changing or extending the Scrum framework. We're looking for ideas written in pattern form — a form that hones the thinking of the person proposing the change, and clarifies the intent to Jeff and Ken.