Dieser Artikel wird sein langer Zeit wieder ausführlicher sein. Meine Motivation dafür ist eine aktuelle Diskussion auf Twitter, die mich an den drei wesentlichen Erkenntnissen vorbeiführt, die ich in den letzten 15 Jahren hatte.

1. Informatik ist eine geisteswissenschaftliche Querschnittsdisziplin, die unglücklicherweise von Techniker:innen ausgebildet wird
2. Die Ausbildungen im Change Management, in agilen Methoden und in der Arbeit mit Organisationen, die auf dem Markt angeboten werden, sind größtenteils kritisch zu sehen, weil zu wenige davon fundiert sind
3. Nicht alle relevanten Fähigkeiten zur Gestaltung menschlichen Miteinanders lassen sich durch Trainings erlernen

Glückliche Informatiker:innen

Wir Informatiker:innen können, sofern wir nicht in die Theoretische oder Technische Informatik abbiegen, eine Sache, die in der heutigen Zeit fundamental ist: Wir haben es gelernt, Ambiguität in formale Spezifikationen zu transformieren. In der Sprache der Informatik: Wir können aus Anforderungen Software programmieren.

Diese Fähigkeit ist einerseits brilliant, andererseits kreuzgefährlich. Sie ist brilliant, weil sie uns hilft, nütztliche Software für Menschen zu bauen, die nicht in der Lage sind, zu beschreiben was sie eigentlich wollen. Daher wurden auch Konzepte wie agile Softwareentwicklung erfunden - oder aus anderen Disziplinen adaptiert, je nach Ego.

Sämtliche interaktiven Systeme wären unmöglich, wenn die Informatik nicht im Laufe der Jahrzehnte Wege gefunden hätte, mit den Widersprüchlichkeiten der Anforderungen konsistent umzugehen. Damit meine ich nicht, dass die Informatik sie auflöst oder eliminiert. Sie kann durch Requirements Engineering und Requirements Management oder seit der Jahrtausendwende in Form von Usability Engineering Wege bieten, mit diesen Widersprüchen umzugehen.

Leider hat das lange Zeit kaum Eingang in die Curricula von Informatikstudiengängen gefunden, so dass der Umgang mit Widersprüchen für die meisten Informatiker:innern etwas ist, das eher intiutiv geschieht, als handwerklich beherrscht wird.

Das einzige Buch, dass sich aus der Perspektive von Informatiker:innen mit diesem Thema beschäftigt, ist Phil Armours The Laws of Software Process. Andere Werke, die sich annähern, wie etwa die meisten Bücher zum Requirements Engineering, kommen bewusst von der anderen Seite und sehen die Artefakte der Informatik als Ergebnis, nicht als Fundament. Daher ist für viele gute Softwareentwickler:innen der Zugang zum Requirements Engineering nach wie vor sperrig.

Nichtsdestotrotz erlaubt uns diese Fähigkeit, ob nun bewusst oder unbewusst, hochgradig zielorientiertes Erschaffen hochkomplexer Artefakte, die selbsttätig geistige Arbeit verrichten. Ich rede hier nicht von künstlicher Intelligenz, sondern von ganz normaler Geschäfts- oder Freizeitsoftware. Die vollzieht auch schon sehr schwierige geistige Prozesse, die wir ihr vorher beigebracht haben.

Und unabhängig davon, dass der Chaos Report jedes Jahr erklärt, dass die meisten Projekte scheitern, bauen wir diese Softwaresysteme mit einem Erfolg, der ans Unglaubliche grenzt.

Ich hatte aber oben auch erwähnt, dass diese Fähigkeit kreuzgefährlich ist. Das liegt daran, dass sie uns arrogant macht. Wir arbeiten uns sehr schnell in fremde Domänen ein, entwickeln Methoden mit denen das fix geht, zwingen andere Disziplinen, unsere Sprachen zu lernen, bauen schnell, was benötigt wird und ziehen weiter zum nächsten Projekt. Dieses schnelle Einarbeiten und oberflächliche Verstehen reicht in den meisten Fällen, eine ausreichend gute Software zu bauen, mit der die Menschen arbeiten können. Es reicht aber nie und nimmer, um ihre Aufgaben zu übernehmen. Schon gar nicht reicht es aus, um die Erklärungen für ein Warum auch nur annähernd zu verstehen.

Genau das glauben wir aber. Der Geschäftsführer einen mittelständischen Softwareentwicklungsunternehmens meinte einmal zu mir: “Software-Engineers können alles.”

Besser kann man das Problem nicht in Worte fassen.

5 Jahre für Theoretiker, 2 Tage für Praktiker

Eine Meisterausbildung im Handwerk dauert in etwa so lange, wie ein Masterstudium. Das Bachelorstudium dauert so lange, wie die Gesellenausbildung. Das hat Gründe.

Diese Gründe bestehen nicht in der gerne zitierten 10.000-Stunden-Regel, sondern daran, dass es drei Dinge braucht, um für das Verstehen eines Themengebiets bereit zu sein:

1. Faktenwissen - der einfachste Teil
2. Methodenwissen - schon schwieriger, weil hier Fakten verbunden werden müssen und Widersprüche sichtbar werden
3. Übung in der Anwendung von Methoden - nicht schwierig, aber zeitintensiv und manchmal sehr ermüdend

Wenn jemand diese Schritte durchlaufen hat, ist dieser Mensch bereit, das Themengebiet zu verstehen. Er oder sie ist bereit zu beginnen. Er oder sie hat es aber noch nicht verstanden, sondern lediglich gelernt, in dem Themengebiet tätig zu sein (ich vermeide hier bewusst das Wort “arbeiten”).

Großzügig kann man diese drei Schritte mit Shu aus dem ShuHaRi-Konzept gleichsetzen. Das ist nicht ganz korrekt, reicht aber für die weiteren Erklärungen an dieser Stelle.

Mit dem Abschluss dieser drei Schritte befindet man sich mittem im Shu und kann sich auf den Weg zum Ri machen.

Das ist in einem Studium gekennzeichnet durch den Übergang vom Bachelor zum Master oder im Handwerk vom Eintritt in die Meisterlehre.

In Summe verbringen sowohl die Master eines Studiums als auch die Meister:innen des Handwerks ungefähr fünf Jahre mit ihrer Ausbildung. Das ist ziemlich viel Zeit innerhalb eines Menschenlebens.

Wenn ich also jemandem begegne, der einen Masterabschluss in Soziologie hat, einen Meisterabschluss im Tischlern oder einen - wie ich - einen Master in Informatik, kann ich diese Tatsache in allen Fällen gleichermaßen respektieren. Alle drei mussten Zeit aufwenden und die Erreichung ihrer Meisterschaft nachweisen.

Nun begegnen mir immer wieder Menschen, die fordern, dass der Zugang zu dem, was die Meister:innen tun dürfen, allen offen stehen müsste. Die Essenz der Meisterschaft müsste doch auch in zwei Tagen vermittelt werden können. Und es gibt hunderte von Angeboten auf dem Ausbildungsmarkt, die genau das offerieren.

Das hat mich, wenn es ums Programmieren geht, früher tierisch geärgert. Heute ist mir das egal, weil die meisten Organisationen informelle Mechanismen haben, die fast immer erfolgreich sicherstellen, dass die Menschen, die an die kritischen Codestellen fassen, dazu auch in der Lage sind.

Es ärgert mich aber immer noch, wenn es um andere Themenkomplexe geht, insbesondere Organisationsveränderung und agiles Coaching. Hier werden jedes Jahr Konzepte, die die Soziologie vor 100 Jahren verworfen hat, neu erfunden, weil sich kaum jemand die Mühe macht, sich mit dem vorhandenen Wissen zu beschäftigen. Ich rede nicht davon, dass bekannte Konzepte neu bewertet werden, weil sich der Kontext verändert hat. Ich rede davon, dass Menschen Konzepte neu erfinden, weil sie noch nie die Namen Adorno, Habermaas, Parsons oder Luhmann gehört haben.

Dabei geht es mir gar nicht darum, dass alle agile Coaches Luhmanns Systemtheorie verstanden haben müssen. Wenn mir aber jemand ein Training zum Thema Bottom-Up-Change anbietet und mich dann fragt, was “brauchbare Illegalität” sei, dann ist das ein Problem. Auch wenn das Training gelabelt ist mit “von Praktikern für Praktiker” und nur zwei Tage dauert. Insbesondere dann.

Solche Kurzausbildungen sind vor allem eines: sie sind kurz. Und bei weitem nicht ausreichend, um auch nur einen Bruchteil dessen, was die oben genannten Meister:innen gelernt haben, zu vermitteln. Sie suggerieren aber etwas anderes. Und das ist kritisch.

Und Polonius’ Sicht

gilt halt auch nur für den Witz. Nicht für die Bildung.

Die Fähigen resignieren

Aus den beiden beschriebenen Problemen resultiert derzeit ein drittes - und das ist eines, dass menschlich, gesellschaftlich und ökonomisch wirklich weh tut.

Aussagen wie “Wenn Du es nicht in zwei Minuten erklären kannst, hast du es nicht verstanden.” oder der berühmte Elevator Pitch sind nur zwei Auswüchse, die zeigen, wie der Respekt vor Wissen um Zusammenhänge verschwindet und von einer Haltung des “Einfach mal machen” verdrängt wird.

Das dieses “Einfach mal machen” ohne fundierte Ausbildung echten Schaden anrichten kann, hatte ich in einigen Beispielen in meinem Vortrag über Agile Coaches als Mobbing-Treiber erklärt.

Problematisch ist es aber, weil Menschen im Allgemeinen dazu neigen, sich von Erfolgsgeschichten inspirieren zu lassen und diese zu adaptieren. Deshalb verkaufen sich Success Stories auch so gut und niemand verlangt eine validierbare Erklärung, warum das eigentlich funktioniert hat. Vom wissenschaftlichen Anspruch eines Karl Popper mag ich gar nicht anfangen.

Die Experimente, die wir mit den agilen Methoden oder der Organisationsveränderung machen, betreffen Menschen. Es geht um eine Verantwortung, die wir wahrnehmen müssen und die wir respektieren müssen. Und genau dieser Respekt fehlt, wenn Laien und Quereinsteiger nach Zwei-Tages-Trainings anderen Menschen beibringen, was sie anhand von anekdotischer Evidenz als für sich wirksam erkannt zu haben glauben. Dieser Respekt fehlt uns auch, wenn wir als Software Engineers daran gewöhnt sind, dass Experimente mal eben auf einem Feature Branch billig gemacht werden können. Im schlimmsten Fall wird der Branch gelöscht, wenn es nicht klappt. Schiefgehen kann nichts, weil der Pull Request ja abgelehnt werden kann.

Es gibt aber in Organisationen keine Branching und Merging. Wenn irgendwer ein Pilotprojekt mit Scrum macht, dann wirkt das auf die gesamte Organisation. Das verstehen Soziologen und Organisationspsychologen - Informatiker:innen lernen sowas in ihrer Ausbildung nicht.

Fazit

Die Fähigen resignieren, weil sie aufgrund ihrer Ausbildung, des tiefergehenden Verstehens von Zusammenhängen und der Fähigkeit der Verbindung von Theorie und Praxis vor allem eines können: erkennen und akzeptieren wenn eine Aufgabe zu groß ist.

Die Unfähigen merken häufig nicht einmal im Nachhinein was sie angerichtet haben.

Den Fleiß, vom Unfähigen zum Fähigen zu werden, muss aber jeder von uns selbst aufwenden. Das nimmt uns niemand ab. Dafür gibt es keine Abkürzung, so wünschenswert diese auch wäre.