Im ersten Teil dieser Artikelserie habe ich David Snowdens Aussage „We [the IT professionals] focus on recipes, not chefs“ analysiert und festgestellt, dass beim Verfolgen des „Rezept-Ansatzes“ aus meiner Sicht zwei wesentliche Aspekte vergessen werden:
- Es genügt nicht, die Rezepte auswendig zu lernen (genau das tun die Unternehmen, wenn sie ihre Mitarbeiter schulen und zertifizieren lassen). Man muss zunächst Erfahrungen sammeln, bevor man in der entsprechenden Domäne tätig wird. Eigentlich nichts Neues – und trotzdem wird dieses uralte Grundkonzept des Lernens in der IT-Welt nur selten beherzigt.
- Die Existenz der Rezeptsammlungen allein reicht nicht aus. Die Rezepte (oft auch „Best Practices“ genannt) müssen immer an die aktuellen Gegebenheiten des Unternehmens- und Projektumfelds angepasst werden.
Den ersten Aspekt habe ich im ersten Teil ausführlich beschrieben und am Beispiel meiner Sportbootführerscheinprüfung illustriert. Jetzt möchte ich mich mit der Frage beschäftigen, warum das sklavische Befolgen der Rezepte nicht immer zum gewünschten (oder besten) Ergebnis führt.
Projektmanagement by the book
Wie bereits im ersten Teil erwähnt, enthalten die gängigen Standards wie ITIL, PMBoK oder V-Modell Verfahrensanweisungen, die auf praktischer Erfahrung beruhen. Löblich, oder? Allerdings muten die „Best Practices“ oft recht akademisch an. Folgerichtig hat sich um diese Modelle eine regelrechte Schulungsindustrie entwickelt. Aber kann man Projektmanagement in einem Kurs lernen? Bei einem Standard namens „Project Management Body of Knowledge“ (PMBoK) suggeriert schon der Name, dass es sich hier um eine Sammlung von Wissen handelt, das über jeden Zweifel erhaben ist. Warum sollte man als Schulungsteilnehmer über Alternativen nachdenken? Oder darüber, wie man dieses Wissen auf die eigene Projektsituation anpassen kann. Sollte man nicht eher sein Projekt auf die Best Practices anpassen? Sind doch schließlich Best Practices!? Also: Projektmanagement by the book, pardon: PMBoK.
Wer jetzt glaubt, dass ich als bekennender Agiler hier die Generalabrechnung mit dem traditionellen Projektmanagement suche, der irrt. Schließlich empfehle auch ich als agiler Trainer und Coach jedem Team, das erstmals ein agiles Projekt (beispielsweise mit Scrum) durchführen möchte, zunächst das Vorgehensmodell wie gelernt zu verwenden. Erst wenn man „Scrum by the book“ in der Praxis durchgeführt, verstanden und grundsätzlich verinnerlicht hat, soll man sich meiner Meinung nach Gedanken darüber machen, wie man die agilen Praktiken anpassen kann, damit sie dem Projekt noch besser nützen. Genau hier liegt der Unterschied: Agile Vorgehensmodelle sind keine „Best Practices“, sondern, wenn man so möchte, eher „Good Tools“ und „Reasonable Starting Points“. Ihre sorgfältig ausgewählten und aufeinander abgestimmten Werkzeuge erleichtern den Einstieg in die agile Welt, erheben aber nicht den Anspruch der Allgemeingültigkeit. Allgemeingültig sind nur die zugrunde liegenden Werte wie Respekt, Fokus und Verantwortung. Das Handwerkszeug dürfen, ja: sollen die Projekte variieren und ergänzen, wenn es dem Projekt dient (und solange die Werte gültig bleiben). Auch ein Chefkoch kann das Küchenwerkzeug vermeintlich zweckentfremden, wenn es für die Zubereitung eines besonderen Gerichts erforderlich ist. Sein Lehrling hingegen wird sich mehr an die Standards halten, aber durch Beobachtung und Imitation des Chefkochs sein Repertoire erweitern und seine handwerklichen Fähigkeiten verfeinern.
Das Salz in der Suppe
Was aber, wenn man sein Werkzeug, einer Eingebung folgend, verbogen hat und plötzlich feststellt, dass das Ergebnis nicht die erwartete Qualität hat? Ganz einfach: dann hat man etwas gelernt – nämlich, dass der eingeschlagene neue Pfad nicht der richtige gewesen ist. Auch ein Chefkoch liegt ab und zu mit einem neuen Gewürz (oder dessen Dosierung) daneben. Anstatt sich nun enttäuscht anderen, bekannten Gerichten zuzuwenden, wird der Koch variieren: eine geringere Menge des neuen Gewürzes, eventuell andere Zutaten. Und dann wieder probieren – so lange, bis es ihm schmeckt. Bei der Variation kommt dem Chefkoch seine Erfahrung zugute. Sein Lehrling wüsste vermutlich nicht sofort, was dem Gericht noch fehlt, oder ob er mehr oder weniger von der einen oder anderen Zutat nehmen muss. Ihm fehlt die Erfahrung früherer versalzener Suppen, er befindet sich noch in der Lernphase. Doch auch dort gibt es einen Aspekt, den wir alle in der Schule beherzigt haben, der aber bei Vielen im Berufsleben verloren gegangen ist.
Lernen – Üben – Kontrollieren
Erinnern Sie sich noch an die LÜK-Kästen? Seit den 1960er Jahren gehört der rote Kunststoffkasten mit den nummerierten Plättchen zur Standardausstattung der deutschen Grundschulen. Zu dem Kasten gibt es Lernhefte für verschiedene Schulfächer, in denen mehrere Gruppen von 24 Aufgaben zu finden sind – für jedes Plättchen eine Aufgabe. Der richtigen Lösung ist eine Zahl zugeordnet, die sich auch auf dem Boden des roten Kastens findet. Dort wird das Plättchen abgelegt. Sind alle 24 Plättchen im Kasten verteilt, dann schließt man den Kasten und öffnet ihn so, dass die Unterseite oben liegt. Hier ist nun ein Muster zu sehen. Stimmt das mit dem Muster im Aufgabenheft überein, dann wurden alle Aufgaben richtig gelöst.
Mir hat das Lernen mit dem LÜK-Kasten immer viel Spaß gemacht, weil der spielerische Anreiz fast vergessen ließ, dass man tatsächlich lernte. „LÜK“ steht für „Lernen – Üben – Kontrollieren“ (früher schmückte der Imperativ „Lerne – Übe – Kontrolliere“ die Aufgabenhefte, aber das ist für die heutige Zeit wohl zu sehr „erhobener Zeigefinger“). Gelernt wird in Unternehmen auch heute noch (siehe meine Ausführungen zur Schulungsindustrie weiter oben). Wie aber steht es mit dem Üben und dem Kontrollieren? In den Zeiten des „training on the job“ wird der Lehrling oft zum Meister deklariert, ohne zuvor eine fundierte Ausbildung mit vielfältigen Gelegenheiten zum Üben und Ausprobieren genossen zu haben. Der Besuch einer Schulung zum Erlernen des theoretischen Wissens muss als Ausbildung genügen, die praktische Umsetzung geschieht sofort im Tages- oder Projektgeschäft. Die Folgen sind Fehlentscheidungen infolge mangelnder Erfahrung, falscher Anwendung des Erlernten, lückenhafter Ausbildung oder schlicht Überforderung.
Was tun? LÜK beherzigen!
Wenn wieder mehr Zeit investiert wird, um neue Konzepte, Methoden und Technologien in einer sicheren (nicht-produktiven) Umgebung ausprobieren zu können, wird sich dieses Investment schnell rentieren, weil im praktischen Einsatz weniger Fehler gemacht werden und somit weniger Geld „verbrannt“ wird. Bekanntlich ist die Behebung eines Fehlers umso kostenintensiver, je später er entdeckt wird. Natürlich macht auch der geübte Lehrling noch Fehler. Wenn er aber – wie in agilen Projekten üblich – in kleineren Intervallen (1-4 Wochen) entwickelt und anschließend gemeinsam mit den Teammitgliedern seine Softwareentwicklungspraktiken auf den Prüfstand stellt (agiler Fachbegriff: Retrospektive), dann werden diese Fehler recht früh entdeckt und können somit kostengünstig behoben werden. Und wenn die Retrospektive vernünftig durchgeführt wird, dann wird der Lehrling dort von seinem Fehler berichten und gemeinsam mit dem Team nach Möglichkeiten suchen, um diesen Fehler in Zukunft zu vermeiden. Die vereinfachte Form dieser Selbstreflexion ist das „Kontrollieren“ des LÜK-Lernspielsystems. LÜK-bildlich gesprochen, geht es in einer Retrospektive darum zu überprüfen, ob das „Muster“ der letzten Iteration „richtig“ (im Sinne von „zielführend“) gewesen ist. Was das „Lernen – Üben – Kontrollieren“ für die Ausbildung, ist der Deming-Zyklus (Plan – Do – Check – Act) bei der kontinuierlichen Verbesserung von Prozessen und Vorgehensweisen.
Zum Lernen gehört mehr als die Aneignung von Wissen
Aus den genannten Gründen sind Best Practices meiner Meinung nach nur der erste Schritt auf dem Weg zu besserer Software. Ohne fundierte Ausbildung und einen kontinuierlichen Verbesserungsprozess, der das Erlernte mit dem Erlebten in Beziehung setzt und den Methodeneinsatz und die Werkzeugnutzung an den gegebenen Kontext anpasst, nützt der beste Standard nichts. Deshalb plädiere ich dafür, in Unternehmen mehr Zeit für das Lernen zu gewähren. Außerdem soll das Erlernen und Üben neuer Technologien ergebnisoffen sein. Stellt man fest, dass das Neue nicht besser geeignet ist als die bisher verwendeten Technologien und Methoden, dann muss man das auch sagen dürfen, ohne gleich als Bremser und Innovationsverhinderer abgestempelt zu werden. Viel zu oft werden Neuerungen nicht aus der Notwendigkeit des Wandels heraus eingeführt, sondern nur, weil irgendjemand das Neue für interessant (oder karrierefördernd) hält. Das Agile Manifest hat mit „Responding to change“ etwas anderes gemeint…