Over a career, good programmers spend much more of their time in professional education than in their college classes. Much of this professional training is tied up with certification programs. But good education needs feedback — all the way to the defining charters of the trainers and their organizations.
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.
So now, even as a trainer who is sullied by certification, I can feel better about the feedback loop being open. It feels more like a community should feel, a community honing and growing a body of practice and mutual support. Become part of the process. Let's grow Scrum together. Go to this web page to see how to get involved.
Scrum is not always applicable as a methodology. I sometimes fail to recognize when a sprint or standup is applicable; I did standups with the exact same scenario without knowing about scrum, as it was the perfect fit for that situation; but I also erased iterations and used Kanban instead when Lean did fit better the situation than artifical iterations did.
I'm not against creating a project management pattern language, not at all, that would be wonderful!
But, why to have Scrum as a basis?
Years ago, when people weren't clear that RUP is 'tailorable', and _shold_ be tailored for each project separately, IBM created the Rational Process Library, and its software utility, the Rational Method Composer (don't ask me why such a software is needed; I've never worked for IBM) with the exact same purpose basically... (You can see it here: http://www-01.ibm.com/software/awdtools/rmc/library/ )
Yet RUP failed. We have this Scrum thing here instead, I'm in doubt if it's as much applicable as they try to represent it; it may make wonders but I also account it for some disasters (I know, methods don't fail, people do; but people can fail by adhering strictly to a method without recognizing context first).
So, I'm in for a comprehensive Pattern Language and perhaps a process to build up a process (in the Alexandrian sense) about development methodologies, including patterns of Scrum, with their context, as it's hugely missing right now and people try to apply scrum patterns everywhere.
Just like in education, the best scrum masters and RUP managers are not those who know what to apply: the best ones are who know what not to apply.
With all the respects to Bob Martin, human civilization tends to build pyramids. Even the american democracy has its leaders. You can only change the way they're selected, that's the difference between a kingdom and a democratic republic.
I think there are people who are better at leadership than at code, and vica-versa.
This doesn't mean I'm in for Scrum Certifications, I've never had one, and I don't want one, exactly because Scrum sometimes doesn't fit and I want to treat it as a methodology amongst the millions rather than The methodology I represent.
What works in the group of 10 people, won't work in 100 groups of 10 people, even if the Scrum Masters are solely masters of ceremonies. I've seen Scrum fail, and I've seen Scrum fail badly.
A derivation lattice showing common and useful ways to diverge from Scrum core would be very helpful as well, similar to Roy Fielding's REST derivation lattice (an awesome diagram) or Peter Van Roy's Programming Paradigms chart.
The basic idea behind Scrum Masters isn't leadership in the traditional sense. Besides, everyone comes into a team with different talents and emerges from that team's projects with an ever-growing skill set.
A saying that I live my life by: Am I trying to prove the skills I already have in an effort to assert who I am, or am I pushing myself to grow and build new skills in an effort to continuously evolve who I am?
Earlier in my career, I was very much in the former camp. I wanted to prove how smart I was for having a Computer Science degree and knowing a billion programming languages, etc. It was very egotistical. These days, I just like learning cool things and becoming quite good at them.
Here is a good example of how Scrum-like team building helped me. Earlier in my career, I was very poor at communicating big picture details about a project. All I wanted to talk about was my very narrow area of expertise. As a result, other programmers who integrated with my code struggled to see potential problems in my design. Through Scrum-like projects, I was forced to be responsible for big picture details for a month once every 6 months.
Practice has a way of improving you in a way no other form of learning can.
I'm perfectly aware what Scrum Mastership is about. Yet while you define its non-leadership property as an advantage, I define it as a disadvantage in certain situations.
Therefore I say that we should define, in which situations is this leaderless group model adequate, and especially, when it isn't so.
(Perhaps it's in somewhere in JC's Organization Patterns, I don't have it here with me right now.)
Still I say that leaderless organizations don't scale. While it's perfectly sound to not have a leader in a group of 10, if that group of 10 is in fact a subgroup of a thousand, I feel there's an urge to have much clearer hierarchy than Scrum does propose.
And since most of software development efforts nowadays take place in large-scale organizations, the implicit need for leaders does arise. (You can call a rose by any name...) I believe this natural urge is behind this notion of certificates. Large communities have their officers.
I hope we can agree that the worst thing you can do in a software system is to pretend a false architecture. I believe the same applies to software creator organizations.
While I certainly agree that learning new things is needed, and that you should try out yourself in more and more fields to build an ever-growing skillset, from the view of the software system to be built, it's better if its builders excel at what they need to do in order to bring out a truly great system for their users.
So, being Agile, given the situation (part of an enterprise, working on huge-scale projects), perhaps it's clear leadership sometimes which brings the best software on the table.
When does this apply, and when this doesn't is something we should answer. I can't believe in contextless statements, that group responsibility is always better than leadership, or learning new things is always better than serve by excelling at what you're good at.
That's why I'd like to see a pattern description of Scrum too.