Die Scrum Alliance arbeitet derzeit an einem „Certified Scrum Developer“. Nun gut, das bisherige Zertifizierungsprogramm aus Scrum Master, Product Owner, Practitioner, Coach und Trainer hat nicht unwesentlich zum Markterfolg von Scrum und Agilität beigetragen; und welche Folgen es für den Ruf von Scrum und agilen Verfahren hat, wenn 50.000 Scrum „Master“ mit einer jeweils zweitägigen Schulung unterschiedlicher Qualität die Industrie stürmen, um es jetzt „richtig“ zu machen, wird die Zukunft zeigen. Warum also das Erfolgsrezept nicht auch auf Entwickler ausdehnen?

Die Antwort ist einfach: Den Schaden, den ein schlechter Entwickler anrichten kann, ist für das Projekt noch bei weitem höher, als den, den ein schlechter Scrum Master anrichten kann: Den Scrum Master tauscht man zur Not aus und muss dann das Team wieder neu aufbauen und motivieren. Das kostet Geld, Zeit und Nerven, ist aber machbar. Schlechte Entwickler aber hinterlassen ihre Hypotheken im Code, die neue Hypotheken nach sich ziehen, ähnlich wie die Verpflichtungen der HRE.

Software Entwicklung ist in hohem Maße erfahrungs-getrieben. Dies gilt insbesondere für testgetriebene Entwicklung und emergente Architekturen, wie sie im Extreme Programming eingeführt und mittlerweile von allen agilen Verfahren inklusive Scrum übernommen wurden (leider nicht immer mit den gebotenen Referenzen). Erfahrungsgetrieben bedeutet aber, dass viel erfahrungsgebundenes implizites Wissen notwendig ist. Wikipedia beschreibt dieses Wissen folgendermaßen:

„Damit ist ein Wissen gemeint, das sprachlich nicht oder kaum weitergegeben werden kann. In solchen Fällen muss der Betreffende durch eigene Erfahrung oder am Modell lernen, das ihm vorzeigt, was nicht vorgesagt werden kann. Beispiel: Wer guten Nudelteig machen möchte, kann Rezeptbücher lesen. Aber in diesen Büchern steht offenbar nicht alles, was gute Teigköche wissen, weil dies nicht vollständig verbalisierbar ist. Das Gefühl für die richtige „Nässe“ des Teigs beispielsweise erwirbt man nur durch Erfahrung.“

Sicher, gerade die Patternbewegung hat sich erhebliche Verdienste erworben, Teile dieses impliziten Wissens zu heben und explizit zu machen, aber eben nur Teile. Die Eleganz eines Designs, die Strategie eines Umbaus lässt sich ebenso wenig explizieren, wie die Struktur eines Teiges. Hier hilft nur: Üben, üben, üben, viele Erfahrungen machen. Aber auch aus den Erfahrungen anderer lernen, fremden Code ansehen, fremde Architekturen — und zwar nicht nur den Beispielcode des MSDN.

Mir ist unbegreiflich, wie sich Informatik-Professoren damit schmücken können, in ihrem Leben keine 1000 Zeilen Code geschrieben zu haben, wie Architekten stolz darauf sein können „nicht mehr zu programmieren“ (man vergebe mir, dass ich hier keine Namen nenne). Kennen Sie einen Chirurgen, der sich damit brüstet, in seinem Leben kaum mehr operiert zu haben, als drei Platzwunden zu nähen? Würden sie ihm Ihr Leben anvertrauen? Davor schützt uns zum Glück die Ärztekammer. Programmieren aber gilt als niedere Tätigkeit, die man am besten möglichst weit weg schiebt, zum Beispiel nach Indien. Diese Missachtung der Programmierkunst ist ein fataler Irrtum, wie ich denke, der unsere Volkswirtschaft Milliarden Euro jedes Jahr kostet.

Sollte der „Certified Scrum Developer“ implizites Wissen wirklich abdecken, könnte er tatsächlich eine Qualifikation transportieren. Sollte er das nicht leisten, wäre es ein weiterer Versuch, den Markt zu segmentieren in Zertifizierte und Ent-Zertifizierte. Darüber hatten Johannes Link und ich uns ja schon Gedanken gemacht. Das wäre schade, war die Agile Bewegung doch einst als innovativer Gruppenprozess gestartet.