Die IODA Architektur

Über die Jahre haben einige grundlegende Architektmodelle um unsere Gunst gekämpft. Mir fallen ein in chronologischer Reihenfolge ein:

• MVC (Ja, das rechne ich zu Architekturmodellen, weil es Leute gibt die sagen, "Unsere Software hat eine MVC-Architektur.)

• das Schichtenmodell

• Pat Hellands Executants, Emissaries und Fiefdoms
• Alistair Cockburnss Hexagonal Architecture aka Ports-and-Adapters
• Jeffrey Palermos Onion Architecture
• Robert C. Martins Clean Architecture

Auch ich habe mir erlaubt, dieser Liste einen Eintrag hinzuzufügen. 2005 kam mit die Idee der Softwarezellen. Die habe ich in einigen englischen Blogartikeln beschrieben - allerdings sind da über die Jahre die Bilder abhanden gekommen :-(

Leider ist es über die Jahre mit der Wartbarkeit/Wandelbarkeit von Software trotz dieser schönen Architekturmodelle nicht wesentlich besser geworden. Auch Anwendungen, die sich einen Schichtenmodells rühmen, waten heute meist im tiefen Brownfield.

Woran kann das liegen?

Ich glaube nicht, dass die Architekturempfehlungen falsch sind. Es steckt eine Menge Beachtenswertes in ihnen. Doch es muss auch noch etwas fehlen. Sonst wäre die Situation der Codebasen nicht so, wie sie ist.

Gemeinsamkeiten

Ich versuche mal, die obige Vielfalt ein wenig zu ordnen. Dann wird klarer, was da ist. Immer eine gute Sache, bevor man etwas verbessert.

Verantwortungsstruktur

Die augenfälligste Gemeinsamkeit aller Architekturmodelle ist die Benennung und Trennung von Verantwortlichkeiten. MVC und Schichtenmodell z.B. sagen ganz klar: Es gibt drei wesentliche Aufgaben in (jeder) Software. Die sollten in unterschiedlichen Modulen[1] realisiert werden.

Bemerkenswert ist, dass die Verantwortlichkeiten alle inhaltlicher Art sind. Sie beziehen sich auf die Herstellung von Verhalten zusammengesetzt aus unterschiedlichen Aspekten. So gehört zum Verhalten einer Software z.B. die Erzeugung von Seiteneffekten auf Bildschirm (Presentation Layer des Schichtenmodells oder View bei MVC) oder Festplatte (Data Access Layer des Schichtenmodells oder DB bei Clean Architecture) sowie ganz wesentlich die Domäne (Business Logic Layer des Schichtenmodells oder Entities bei Clean Architecture).

Beziehungsstruktur

Die identifizierten Verantwortlichkeiten setzen die Architekturmodelle in Beziehung. Sie definieren, welche Verantwortlichkeit mit welchen anderen in einem Abhängigkeitsverhältnis steht. Dabei geht es immer um funktionale Abhängigkeiten, d.h. Dienstleistungsbeziehungen.

Beim Schichtenmododell ist das am einfachsten: jede Schicht ist nur von der darunterliegenden abhängig. Auch die Clean Architecture hält die Abhängigkeiten unidirektional: sie weisen von außen nach innen. Bei MVC und seinen Verwandten hingegen sieht es anders aus.

System-Umwelt-Trennung

Und schließlich geht es auch noch um eine deutliche Trennung von Softwaresystem und Umwelt. Den Verantwortlichkeiten an der Systemgrenze kommt eine besondere Bedeutung zu. Das stellen insb. die Hexagonale Architektur und Softwarezellen heraus.

Bei den Softwarezellen nenne ich diese Schale deshalb ausdrücklich Membran. Über Adapter findet ein bidirektionaler Austausch der Domäne mit der Umwelt statt.

Anders als die Hexagonalen Architektur unterscheiden Softwarezellen jedoch, wie sie mit der Umwelt in Verbindung stehen. Dass die Umwelt auf sie einwirkt, ist davon zu trennen, dass sie auf die Umwelt einwirken. Ersteres geschieht durch Portal-Adapter, Letzteres durch Provider-Adapter.

Holarchie

Nur die Softwarezellenarchitektur schlägt darüber hinaus noch vor, Softwaresysteme auf mehreren Abstraktionsebenen mit dem selben Mittel zu beschreiben. Die Softwarezelle selbst ist damit Modellierungselement.

Mit dem Schichtenmodell kann man eine Software einmal in Schichten zerlegen. Mit der Onion Architektur kann man eine Software einmal aufgebaut aus Schalen beschreiben. Aber mit Softwarezellen kann eine Software nicht nur einmal in Portale, Provider und Domäne zerlegt werden, sondern auch noch in kleinere Softwarezellen.

Das Softwarezellenmodell ist mithin selbstähnlich hierarchisch. Auf jeder Ebene der Hierarchie befinden sich Softwarezellen, die wiederum aus Softwarezellen zusammengesetzt sein können.[2]

Eine solche Hierarchie, bei der die Teile gleichzeitig Ganze sind, wird auch als Holarchie bezeichnet.

Das gemeinsame Problem: Funktionale Abhängigkeiten

Das sieht doch alles ganz ordentlich aus, oder? Mehr oder weniger detailliert werden inhaltliche Verantwortlichkeiten in funktionale Abhängigkeit gesetzt. Mal laufen die in die eine Richtung, mal in die andere. Wenn es damit nicht funktioniert, dann wird man das Modell wohl noch nicht sauber oder fein genug angewandt haben. Was sollte man auch anders tun?

Meine Vermutung ist, dass das Problem tiefer liegt, wenn trotz der Architekturmodelle die Software in die Unwartbarkeit rutscht. Nicht sauber mehr davon anwenden hilft dann, sondern aufhören und etwas anderes tun.

Woran könnte es denn aber liegen, dass es nicht einfach klappt mit diesen Modellen?

Ich denke, die Separierung von Verantwortlichkeitskategorien ist nicht das Problem. Sie ist dringend nötig. Zuviel davon kann es kaum geben. Lieber die Verantwortlichkeiten etwas differenzierter sehen, als zu viel davon in einem Modul zu versammeln. Das Single Responsibility Principle (SRP) und seine Verwandten (SoC, SLA, ISP) sind nicht umsonst eines der immer wieder beschworenen Fundamente der Softwareentwicklung.

Auch die deutliche Trennung eines Softwaresystems von der Umwelt durch eine explizite Membran ist nicht das Problem. Sie dient dazu, dass Softwaresystem im Sinne des SRP zu fokussieren und von äußeren Einflüssen zu entkoppeln.

An einer holarchischen Sicht, die ohnehin von den meisten Modellen nicht thematisiert wird, kann es auch nicht liegen. Im Gegenteil: Ich denke, mehr davon würde der Softwareentwicklung helfen. Sie macht die Zerlegung von Kompliziertem einfacher, weil die Zerlegungsebenen immer wieder mit denselben Mitteln beschrieben werden.

Was bleibt sind also die Abhängigkeiten.

Ja, ich denke, dass die funktionalen Abhängigkeiten zwischen inhaltlichen Verantwortlichkeiten das Problem sind. Logische Kopplung lässt sich nicht vermeiden. Die jedoch mit funktionaler Kopplung auszuweiten, öffnet der Ausbreitung von Veränderungen Tür und Tor.

Alle Architekturmodelle kranken an funktionalen Abhängigkeiten. Dabei ist es egal, ob die von links nach rechts oder oben nach unten verlaufen. Funktionale Abhängigkeiten sind böse!

Das wissen Sie aus Ihrem täglichen Leben: Solange Sie eine Aufgabe allein erledigen können, ist alles gut. Die Schwierigkeiten explodieren, sobald Sie davon abhängig sind, dass Ihnen jemand etwas zuliefert. Sie verlieren damit die Hoheit über die Erledigung. Wenn etwas nicht klappt, interessiert es den Abnehmer Ihrer Leistung nicht, ob Sie das zu verschulden haben oder Ihr Zulieferer. Sie sind Verantwortlich für das Ergebnis. Und schon fängt das Micro-Management an. Und schon seufzen Sie unablässig, “Wenn man nicht alles selbst macht…”

Inhaltsunabhängige Verantwortlichkeiten

Um aus dem Problem der funktionalen Abhängigkeiten zwischen inhaltlichen Modulen herauszukommen, schlage ich nun ein neues Architekturmodell vor. Es unterscheidet sich sehr grundlegend von den vorgestellten - aber genau das macht seinen Charme aus, finde ich. Aber der Reihe nach…

Unabhängige Module

Aus den funktionalen Abhängigkeiten kann man sich nicht herausdefinieren. Schichtenmodell wie Clean Architecture leiden gleichermaßen unter ihnen. Da hilft keine Änderung der Ausrichtung der Abhängigkeiten. Nicht die Richtung ist entscheidend, sondern ihre schiere Existenz.

Das bedeutet, eine bessere Architektur muss funktionale Abhängigkeiten komplett abschaffen. Welche Verantwortlichkeiten man auch identifizieren mag, die Module, in die man sie kapselt, sollten unabhängig von einander sein.

Auf das Schichtenmodell bezogen würde das bedeuten: Presentation Layer, Business Logic Layer und Data Access Layer haben keine funktionalen Beziehungen zu einander. Keine. Nicht direkt, nicht indirekt. Sie kennen sich nicht einmal.

Solche Module nenne ich Operationen.

Verbindende Daten

Natürlich können Operationen nicht komplett unabhängig von einander sein. Dann könnte man aus ihnen ja nichts Größeres zusammensetzen. Aber funktionale Abhängigkeiten im Sinne von request/response Dienstleistungsaufrufen gibt es nicht.

Stattdessen kommunizieren die Operationen mittels Nachrichten. Sie tauschen also Daten aus. Und sie können auch Zustand, sogar gemeinsamen haben. Das heißt, Operationen sind von Daten abhängig.

In der Objektorientierung können Daten allerdings selbst wieder Funktionen anbieten. Sind Operationen dann nicht von diesen doch funktional abhängig?

Technisch ist das richtig: Logik[3] in einer Operation ruft Logik in Daten auf.

Doch “inhaltlich” ist das für mich nicht gravierend. Die Logik in Daten ist ja dünn. Sie bezieht sich nur auf die Daten selbst, dient nur der Strukturherstellung und Konsistenz. Domänenlogik hat nichts in Daten zu suchen.

Daten sind für mich auf einer Stufe mit APIs. Die müssen Operationen ja auch benutzen können. Daran lässt sich nichts ändern. Am besten deshalb, wenn APIs Black Boxes sind. Dann können sich Operationen nicht an ihre Interna koppeln. Dasselbe gilt für Daten. Datenstrukturen sind selbstgeschriebene APIs zur Verwaltung von Speicher. Wie eine Liste oder Queue oder ein Baum aus einem Framework, den Operationen nutzen.

Angezogene APIs

Operationen können nicht funktional unabhängig sein. Sie können ja nicht alle Logik selbst schreiben, die nötig ist, um Verhalten zu erzeugen. Sie müssen auf die Schultern von Riesen steigen, um Daten zu persistieren, Grafiken zu animieren, zu drucken, zu komprimieren, zu verschlüsseln, zu kommunizieren usw.

Die Logik von Operationen muss sich deshalb abhängig machen von _API_s aller Art, die solche Dienstleistungen anbieten.

APIs kapseln Logik, anderer Leute Logik ;-) Für die nutzenden Operationen sind sie Black Boxes des notwendigen Logik-Übels. Denn wenn sich an der Implementation von APIs etwas ändern, dann muss Operationslogik u.U. nachgezogen werden.

Integrierte Prozesse

Auch wenn Operationen von Daten abhängig sind, kennen sie einander nicht. Es fehlt ihnen der funktionale Zusammenhalt, der nötig für das Gesamtverhalten eines Softwaresystems ist.

Den herzustellen ist nun eine ganz eigene Verantwortlichkeit. Die herauszustellen ist zentral für meinen Architekturmodellvorschlag.

Es braucht eine Instanz, die unverbundene Einzelteile zu einem Ganzen zusammensetzt. Diese Leistung nenne ich Integration.[4] Einzelteile werden in und zu etwas größerem integriert.

Für die Integration sind ebenfalls Module zuständig. Doch die enthalten keine Logik. Sie sollen nicht selbst mit Logik verhalten herstellen, sondern fügen andere Logik (Operationen) lediglich so zu Prozessen zusammen, dass in Summe Verhalten entsteht. Ohne Logik sind diese Prozesse nicht imperativ, sondern deklarativ; die Darstellung erfolgt in Form von Datenflüssen.

Im Sinne des SRP halte ich das für sehr konsequent. Integration ist eine ganz eigene Verantwortlichkeit, wie Operation zu sein oder Daten zu strukturieren.

Integrationsmodule sind zu diesem Zweck abhängig von Operationen, d.h. sie kennen sie, um sie “zusammenstecken” zu können. Doch eine funktionale Abhängigkeit besteht nicht. Denn Integrationen enthalten keine Logik.

Die IODA Architektur

Haben Sie es bemerkt? Die Module, von denen ich bisher gesprochen habe - Integration, Operation und auch Daten -, haben keinen inhaltlichen Bezug mehr. Das Architekturmodell, welches ich vorschlage, interessiert sich nicht dafür, ob sie ein Modul View nennen oder Business Logic oder Adapter oder Portal oder Use Case usw.

Die Verantwortlichkeiten des Architekturmodells sind orthogonal dazu. Und sie sind viel universeller.

Ich nenne es die IODA Architektur, weil damit seine Bestandteile in Richtung der Abhängigkeiten benannt sind.

In dieser Architektur gibt es Abhängigkeiten. Ohne Kopplung kein Verhalten erzeugt durch mehrere Beteiligte. Aber die sind unterschiedlich stark funktional. Vor allem fehlen aber funktionale Abhängigkeiten zwischen den “Arbeitspferden”, den Operationen. Sie tragen die Logik-Last eines Softwaresystems.

Auch diese Struktur ist wieder rekursiv zu verstehen. Jedes Modul kann, wenn seine Aufgabe zu umfangreich wird, wieder nach IODA zerlegt werden. Das gilt insbesondere für Operationen.

Zusammenfassung

Das unausgesetzte Problem des unwartbaren Codes wird nicht gelöst, in dem wir inhaltliche Module immer wieder neu in funktionale Abhängigkeiten verstricken. Ich bin davon überzeugt, wie müssen diesen ausgetretenen Pfad verlassen. Das Pferd der funktionalen Abhängigkeitshierarchien ist totgeritten.

Stattdessen müssen wir uns auf grundlegende und universelle Verantwortlichkeiten besinnen und die weitgehend unabhängig halten. Das geschieht durch “ausbluten” von Datenstrukturen, d.h. Modulen, die Daten sind. Sie dürfen nur minimale Logik enthalten. Und das geschieht durch die Konzentration von Logik in Operationen, die einander nicht kennen (vgl. Prinzip der gegenseitigen Nichtbeachtung).

Dem Metamodell von Software muss das, was getan wird, egal sein. Welche Operationen, welche Daten es gibt, ist unwichtig. Aber dass es Operationen und Daten gibt, dass Operationen durch spezielle Instanzen zu einem Ganzen integriert werden, das kann dem Metamodell nicht egal sein.

So entsteht Software als Summe von Prozessen, deren Schritte in Operationen implementiert sind, die Daten konsumieren und produzieren unter Zuhilfenahme von APIs.

Wenn das keine allgemeingültige Beschreibung jeder Art von Software ist, dann weiß ich auch nicht mehr ;-)

---

1. Für mich sind Module Container für Code zur Entwicklungszeit zum Zwecke der Entkopplung. Logik in Modulen zusammenzufassen kapselt sie, um höhere Wandelbarkeit zu erzielen. Mit “Modul” meine ich kein Sprachkonstrukt einer speziellen Programmiersprache, sondern jedes Mittel, um Logik zu bündeln und Teile von ihr von außen unzugänglich zu machen. Unterprogramme sind insofern genauso Module wie Klassen oder Bibliotheken. ↩

2. Mit dem Schichtenmodell oder MVC ist eine solche Zerlegung nich möglich. Mit der Hexagonalen Architektur oder auch Onion/Clean Architecture wäre die selbstähnliche hierarchische Zerlegung jedoch denkbar - nur habe ich sie in der Literatur bisher nicht beschrieben gesehen. ↩

3. Logik sind für mich der Code, der Verhalten herstellt. Das sind Transformationen/Ausdrücke, Kontrollanweisungen und Hardware-/API-Zugriffe. ↩

4. Manchmal denke ich auch, es handelt sich um Komposition oder Koordination. Aber “Integration” war irgendwie zuerst als Begriff in meinem Kopf, so dass ich ihn nun stehenlasse. ↩

Die Selbstlern-Challenge - Retrospektive

Zehn Wochen sind wie im Flug vergangen, seit ich zur Teilnahme an einer Selbstlern-Challenge eingeladen hatte.

Das Angebot

Die Herausforderung war, sich selbstständig über einen Zeitraum von 10 Wochen in das Thema Flow Design & Co einzuarbeiten. Einzige Bedingung: Als Dokumentation des Dranbleibens am Thema sollte mir jede Woche eine Frage per Email geschickt werden - die ich dann selbstverständlich auch beantwortet habe.

Zehn Teilnehmer hatte ich gesucht und in weniger als 24 Stunden auch gefunden. War das ernsthaftes Interesse am Thema? Oder vielleicht doch nur Interesse am “Preisgeld”? Jedem der durchhält, hatte ich einen 50€ Amazon-Gutschein versprochen. Wie sich herausstellte, waren solche Überlegungen unbegründet. Wer dabei geblieben ist, hat sich intensiv mit dem Thema auseinandergesetzt. Zwei Teilnehmer schrieben sogar, sie seien an dem Gutschein gar nicht interessiert.

Erkenntnis #1: Beim nächsten Mal werde ich zur Wahl stellen, das “Preisgeld” ausgezahlt zu bekommen oder es zu spenden.

Warum hatte ich überhaupt ein “Preisgeld” ausgesetzt? Weil ich einen zusätzlichen Anreiz zum Mitmachen bieten wollte. Der sollte nämlich hoch sein, um meine Hypothese zu bestätigen. Bevor ich die aber erläutere hier erstmal die “Gewinner”…

Die “Gewinner”

Von 10 Teilnehmern haben 5 durchgehalten. Der Austausch mit ihnen war unterschiedlich intensiv. Beim einen waren es über 80 Emails, die zwischen uns hin und her gingen, beim anderen nur 4, dafür aber noch Chats in Slack.

Erkenntnis #2: Veränderungen während des Challenge vermeiden. Als ich nach einigen Wochen Slack als weiteres Kommunikationsmedium angeboten habe, kam es zu einigen Irritationen. Manche nahmen diesen neuen Kanal freudig auf und haben sich auch untereinander darüber ausgetauscht. Andere waren verwirrt bis verärgert und wähnten eine unlautere einseitige Vertragsänderung. Dabei wollte ich doch nur nett sein… Aber so kann es gehen. Deshalb: Wenn die Sache einmal läuft, Füße stillhalten.

Ach, ja, die “Gewinner”. Die gab es natürlich nicht, weil es nichts zu gewinnen gab. Es war ja kein Wettbewerb. Eher sollte es wohl heißen, die “Durchhalter” oder “Finisher”. Gewinner waren alle inklusive mir. Denn wir haben einiges gelernt - auch die, die nicht durchgehalten haben. Hoffentlich.

Über die Ziellinie haben sich diese 5 Teilnehmer gefragt:

• Manuel Beetz
• Benjamin Beisner
• Karsten Peiler
• Max Schmidt
• Benjamin Seblu

Herzlichen Glückwunsch! Die Gutscheine sind schon verschickt.

Leider war die Auswertung nicht ganz so einfach, wie gedacht. Zuerst hatte ich mir noch aufgeschrieben, wer wann eine Frage gestellt hat. Doch im Eifer der Email-Kommunikation ist das dann nicht mehr so klar gewesen. Wann war eine Frage die Wochenfrage, wann nur eine weitere? Am Ende musste ich also die ganze Kommunikation nochmal durchsehen und habe sogar die Teilnehmer gebeten, das nochmal zu prüfen.

Erkenntnis #3: Zumindest die Einreichung der wöchentlichen Frage sollte stärker formalisiert sein. Solange die Erfolgsbedingungen so einfach sind und von normaler Kommunikation kaum unterscheidbar, braucht es dafür einen Rahmen. Es hätte gereicht zu fordern, dass die Wochenfrage in einer Email mit einem Betreff geschickt wird, in dem die Fragennummer steht, z.B. “Selbstlern-Challenge Frage #3”.

Die Hypothese

Die Teilnehmer haben immer wieder mal gefragt, was denn meine Hypothese gewesen sei. Und auch Sie mögen sich gefragt haben, warum da einer bereit ist, 500€ dafür zu bezahlen, dass man ihm 100 fragen stellt. Müsste es nicht umgekehrt sein? :-)

Ja, als Geschäftsmodell taugt der Ansatz nicht wirklich. War ja aber auch so nicht gedacht. Ich habe vielmehr in Forschung investiert. Ich wollte herausfinden, ob meine Ansicht über das autodidaktische Lernen in unserer Branche “korrekt” ist.

Eine wissenschaftliche Studie ist das nun zwar nicht geworden, aber ich denke, eine Antwort habe ich dennoch bekommen. Hier meine Ausgangshypothese:

Ich glaube nicht daran, dass Entwickler autodidaktisch eine Methode wie Flow Design & Co neben ihrem Job lernen können.

Diese Hypothese hatte sich in mir über längere Zeit gebildet. Das wurde mir besonders bei einem Seminar Ende letzten Jahres bewusst. Da sagte ein Teilnehmer beim abschließenden Feedback, er fände den Ansatz gut, könne ihn aber frühestens in 2–3 Monaten in einem nächsten Projekt anbringen. Darauf erwiderte ich, er müsse schauen, dass er bis dahin im Thema drin bliebe, er müsse für sich weiter üben. Und der Teilnehmer sagte selbstgewiss, das würde er selbstverständlich. Damit hätte er Erfahrung.

Das war zu schön zu hören, um wahr zu sein. Deshalb schlug ich vor, er könne mir doch jede Woche als Resultat seines Übens eine Frage schicken. Das Angebot nahm er allerdings nur halbherzig an. Und dann bin ich gemein geworden: Ich habe ihm 2 Monate lang alle 2 Wochen eine Email geschickt und freundlich nachgefragt. Darauf hat er einmal geantwortet - und dann nicht mehr. Für mich bedeutet das: Er hat nicht geübt. Er hatte sich schlicht überschätzt. Guten Willen möchte ich ihm nicht absprechen. Nur nützt der nichts, wenn er nicht umgesetzt wird.

Als ich damit meine Hypothese als bestätigt zur Ruhe betten wollte, habe ich dann aber doch ein schlechtes Gewissen bekommen. Deshalb der Selbstlern-Challenge.

Mit dem Challenge wollte ich herausfinden, ob nicht sogar unter günstigeren Bedingungen das autodidaktische Lernen fehlschlägt. Aber nochmal zur Präzisierung: Die Hypothese bezieht sich auf das Lernen einer Methode, d.h. von etwas, bei dem man, wenn man es anwendet, relativ schlecht Feedback bekommt.

Wer sich autodidaktisch einen API beibringen will oder ein Tool lernt, der bekommt sofort bei der Anwendung Feedback. Was er tun will klappt oder nicht. Wenn es nicht klappt, kann das natürlich frustrierend sein. Aber meist klappt zumindest so viel, dass es relativ leicht ist, dran zu bleiben. Dann wird man besser und sucht nach Wegen, es in der Praxis anzuwenden.

Bei Methoden wie TDD, agilem Vorgehen, einem neuen Sprachparadigma oder eben auch Entwurfsansätzen wie Flow Design (oder das gute alte OOD) ist das jedoch anders. Ob man es gut macht, lässt sich nicht sofort ablesen. Es braucht größere Übungen und mehr Zeit, um Effekte festzustellen. Zumindest, wenn man autodidaktisch lernt. Lernt man mit Trainer, bekommt man sofort Feedback.

Dass es mit dem autodidaktischen Lernen nicht einfach ist, hatte ich ja schon in einem Selbstversuch demonstriert.

Der Selbstlern-Challenge hat es den Teilnehmern jedoch einfacher machen wollen. So gemein bin ich also doch nicht, oder? ;-) Nicht nur habe ich ein “Preisgeld” ausgesetzt, ich habe mich auch als Accountability Partner zur Verfügung gestellt. Ich habe also meiner Hypothese quasi ein Bein gestellt.

Dennoch war das Ergebnis offen…

Die Auswertung

Ist meine Hypothese nun falsifiziert worden? Hm… Um ehrlich zu sein, mit 50% “Gewinnern” hatte ich nicht gerechnet. 2–3 wären mir lieber für meine Hypothese gewesen ;-) Aber besser 50% als 90% sage ich mir nun.

Man kann die 50% natürlich so oder so auslegen.

a) Es haben mehr Teilnehmer durchgehalten als erwartet. Die Hypothese kann also nicht wahr sein. Autodidaktisches Lernen ist in der Branche kein Problem auch für Methoden. Hypothese falsifiziert. b) Es haben 50% der Teilnehmer nicht durchgehalten. Das ist ein großer Prozentsatz, der umso stärker zu bewerten ist, da es zusätzliche Anreize und Unterstützung gab. Im Grunde war das Lernen gar nicht ganz autodidaktisch. Echt autodidaktisches Lernen wird mit einer noch höheren Abbrecherquote belegt sein. Hypothese nicht falsifiziert.

Hm… Was nun?

Sie werden es mir nicht verdenken, ich tendiere zu Erklärung b). Meine Gründe:

1. Die Teilnahme war echt freiwillig. Hier war also die intrinsische Motivation sehr hoch.
2. Das Durchhalten wurde explizit belohnt. Der Effekt eines “Preisgeldes” mag nicht groß gewesen sein, aber ich würde ihn auch nicht ignorieren.
3. Die Pflicht, mir jede Woche “Rechenschaft abzulegen” hat sicher einen Zug ausgeübt. Da war jemand, der sich erstens dafür interessiert, das man voranschreitet, und der zweitens enttäuscht werden konnte.
4. Zu den Bedingungen gehörte, dass ich alle Teilnehmernahmen nennen darf. Es bestand also die Möglichkeit, als Abbrecher öffentlich gemacht zu werden.
5. Es musste nicht nur aus Texten gelernt werden, sondern da war jemand, der einem über Verständnishürden hinweggeholfen hat. Das macht Lernen einfacher und somit motivierender.

In Summe sind das so viele “Hilfestellungen” für das autodidaktische Lernen, dass mir eine 50% Abbrecherquote hoch erscheint und ohne solche “Unterstützung” noch viel höher gelegen hätte.

Bottom line: Autodidaktisches Lernen ohne Förderung und Forderung funktioniert nicht in unserer Branche. Mit Förderung meine ich, dass Unterstützung gegeben wird in Form von Zeit und anderen Ressourcen. Mit Forderung meine ich, dass die Nutzung der Förderung eingefordert werden muss. Jemand muss daran ziehen. Sonst vertrocknet die Förderung ungenutzt aus verschiedenen Gründen. Ohne Nachfragen wird anderes nach einer initialen Hochmotivationsphase schnell wichtiger. Damit bleibt das Lernen trotz der (passiven) Förderung auf der Strecke.

Erkenntnis #4: Wer sagt, “Ach, ich bleibe schon dran am Thema…” der überschätzt sich sehr wahrscheinlich. Es braucht einen echten Plan, wie man Lernstoff außerhalb einer Seminarumgebung tatsächlich weiter übt und dann in die Anwendung kommt. Ist der nicht kristallklar im Hinblick auf fördernde und fordernde Elemente, dann liegt Wunschdenken vor.[1]

Fazit

Die 10 Wochen haben Spaß gemacht. Es war schön, mit motivierten Teilnehmern zu arbeiten. Das hat mich weitergebracht. Ich habe wieder etwas mehr über Flow Design gelernt. Aber ich habe auch etwas über distance learning gelernt.

Erkenntnis #5: Nur eine Frage als Zeichen des Fortschritts zu erwarten, ist zu wenig. Es braucht etwas mehr methodische Anleitung für die Teilnehmer. Ein “Challenge-Tagebuch” fällt mir da ein, ein Portfolio und zumindest für Meilensteine im Lernstoff konkrete Aufgaben.

Auch wenn ich meine Hypothese bestätigt finde, bin ich nicht frustriert. Ich denke, es wurde etwas deutlicher, wie Angebote für das selbstständige Lernen aussehen müssen. Denn nur das skaliert am Ende. Wer möchte, dass sich eine Methode verbreitet, muss als Lehrer aus dem Weg treten, sonst ist er ein Nadelöhr.

Aber wohin treten? Darüber habe ich etwas gelernt. Herzlichen Dank an alle Teilnehmer, dass sie dabei mitgeholfen haben!

---

1. Das behaupte ich nun so apodiktisch, um die für mich deutliche Tendenz klar zu machen. Ich will nicht sagen, dass niemand so lernen kann. Sicher gibt es den einen oder anderen… nur habe ich von denen noch nicht viele gesehen. Und gerade die, die es von sich laut behauptet haben, sprangen eher zu kurz. Autodidaktisches Lernen einer Methode ist so gut oder schlecht möglich, wie als Kettenraucher ein hohes Alter zu erreichen. Es gibt Beispiele davon - nur würde ich die nicht zur Nachahmung bei der Lebensplanung oder Kompetenzausbildung empfehlen. ↩

Entwickeln im Uhrzeigersinn

Was ist der Unterschied zwischen Software Craftsman und Software Engineer? Darüber kann man natürlich lang und trefflich debattieren. Doch mit den von mir vorgestellten Arbeitsweisen, ist die Unterscheidung einfach und augenfällig, glaube ich.

Wie beschrieben, arbeiten wir als Softwareentwickler sowohl als Handwerker (H) wie als Ingenieure (I) und auch als Forscher (F).

Arbeitsweisenverhältnisse

Allerdings sind die Anteile der drei Arbeitsweisen nicht gleich. Für mich dominieren I und F; H macht den kleinsten Teil aus.

Der tapfere Software Engineer wird das aber noch etwas anders sehen. Für ihn wird der Entwurf eine größere Rolle spielen als Forschung oder Codierung. Codieren kann man lassen und Forschung, z.B. beim Bug Fixing, ist mit guter Entwurfsvorarbeit nicht so häufig nötig, oder?

Das steht im Gegensatz zur Sicht der eher haptisch veranlagten Software Craftsmen, denke ich. Den Löwenanteil der Arbeit hält man dort für handwerklich. Warum sollte man sich sonst “Craftsman” nennen?

Forschung wird man auch noch groß schreiben (müssen), weil Anforderungsanalyse und Code-Analyse nicht zu läugnen sind. Doch der Entwurf, allemal der explizite, steht im Hintergrund. Am Ende spricht ohnehin nur der Code die Wahrheit, oder?

Eine unterschiedliche Einschätzung des Mischungsverhältnisses scheint mir eine erste augenfällige Differenz zwischen den Lagern der Engineers und der Craftsmen.

Ein anderer die bevorzugte Bewegungsrichtung durch die Arbeitsweisen.

Arbeitsweisenreihenfolge

Software Craftsmen favorisieren TDD, um nicht in die BDUF-Falle zu geraten. Das scheint handwerklicher als ein ingenieursmäßiger Entwurf vorab. Doch damit entkommen sie dem Thema Planung nicht. Sie verschieben es nur. Für mich bewegt sich der Software Craftsman bevorzug gegen den Uhrzeigersinn durch die Arbeitsweisen:

Am Anfang steht Forschung. Anforderungen müssen analysiert werden. Daraus ergeben sich Tests in rot (F). Die werden im nächsten Schritt handwerklich möglichst einfach (KISS) auf Grün gebracht (H). Und daran schließlich sich dann eine Refaktorisierung. Für die muss man jedoch einen Entwurf haben (I). Denn so handwerklich Refaktorisieren in einer IDE aussehen mag, ohne Vorstellung von einer Zielstruktur geht es nicht. Die aber ist Ingenieursarbeit.

Der Software Engineer denkt da anders. Er bewegt sich mit dem Uhrzeigersinn durch die Arbeitsweisen:

Auch bei ihm steht die Forschung am Anfang. Anforderungen in Form eines Lastenheftes müssen analysiert werden. Das Ergebnis ist ein Pflichtenheft (F). Dafür wird im nächsten Schritt ein Lösungsentwurf erarbeitet (I); UML ist dafür als Werkzeug gedacht. Und erst am Ende steht eine Implementierung des Entwurfs (H).

Arbeitsweisenfrequenz

Ein weiteres Unterscheidungskriterium im Hinblick auf das “Arbeitsweisenrad” scheint mir die Geschwindigkeit, mit der Software Engineers und Software Craftsmen es drehen. Die Engineers drehen es langsamer als Craftsmen.

Nicht, dass Engineers keine Iterationen kennen würden. Aber Sie glauben daran, dass man durch Forschung und Entwurf ein größeres Rad drehen kann. Craftsmen hingegen sind erpicht auf Feedback vom Kunden. Deshalb favorisieren sie schnellere Drehungen.

Zusammenfassung

Kein Wunder, wenn sich Software Engineers und Software Craftsmen immer wieder sprachlos gegenüberstehen, oder? Das wussten Sie natürlich schon vorher ;-) Aber ich hoffe, durch die Brille der Arbeitsweisen HIF sehen Sie nun deutlicher, woran das liegt. So lassen sich die unterschiedlichen Positionen besser kommunizieren, finde ich. Der Blick ist differenzierter.

Die genauen Prozentzahlen der Arbeitsweisen, sind dabei nicht so wichtig. Es geht um die groben Verhältnisse. Ohnehin verschieben die sich nach Projekt und Anforderungen auch immer wieder etwas. Deshalb zählt die Tendenz.

Durch diese Aufschlüsselung habe ich für mich z.B. realisiert, dass ich weder Software Engineer noch Software Craftsman bin. Ich hänge irgendwo dazwischen:

• Für mich dominiert weder I noch F, aber H hat definitiv den kleinsten Anteil.
• Für mich dreht sich die Softwareentwicklung im Uhrzeigersinn.
• Für mich dreht sich das Rad im wesentlichen alle 4 bis 16 Stunden. Das ist der wichtigste Zyklus, um ein Inkrement herzustellen (d.h. einen feedbackfähigen Codezuwachs). Innerhalb dessen kann es kürzere TDD-Iterationen geben - muss es aber nicht. Oberhalb dessen kann es längere Release-Iterationen geben - muss es aber nicht.

Und wenn der nächste Selbstverständnis-Hype aufkommt… dann haben Sie nun ein kleines System, mit dem sie ihn analysieren können.

Unschätzbare Arbeitsweisen

Wer über das Thema Schätzen reden will, muss zunächst eine klare Vorstellung davon haben, was denn da eigentlich geschätzt werden soll. Das ist interessanterweise aber nicht der Fall.

Viel wird über Anforderungen gesprochen. Aber wenig über die Arbeit, die die Anforderungen in lauffähigen Code transformieren soll. Das scheint nicht nötig, weil es doch sonnenklar ist: das ist Codierung. Und in der Codierung haben die Entwickler doch viel Erfahrung. Das ist ihr Job. Also sollten sie auch schätzen (oder eher berechnen) können, wie lange die Umsetzung der nächsten Anforderungen dauert.

Nichts könnte jedoch weiter von der Realität entfernt sein. Es ist zwar richtig, dass Softwareentwickler “Männer, die auf Code starren” sind - doch deshalb ist Softwareentwicklung nicht gleichzusetzen mit Codierung, d.h. mit dem Schreiben von Code.

Manager, Kunden, Laien, selbst Softwareentwickler haben ein zu simples Verständnis für das, was Softwareentwicklung ist. Kein Wunder, dass sich aus dem dann eine Forderung ableitet, die nicht zu erfüllen ist, nämlich die der Vorhersage von Aufwänden für die Umsetzung von Anforderungen.

Und leider tut die Softwareentwicklung nicht viel dafür, ihr Bild zu korrigieren. Wer sich “Software Craftsman” nennt, darf sich nicht wundern, wenn man von ihm wie von jedem anderen Handwerker ein genaues Angebot haben will. Da nützt die ganze Beschwörung von Qualität und Berufsehre nichts. Selbstverständlich sollen Handwerker Qualität liefern - aber bitteschön zum vorher festgelegten Termin und fixen Kosten.

Wenn das der Software-Handwerker nicht schafft… dann ist die Enttäuschung verständlicherweise groß. Dabei kann es nicht anders gehen. Der Software-Handwerker muss in dieser Hinsicht enttäuschen. Das liegt in der Natur seiner Arbeit. Er ist nämlich kein Handwerker. Das muss er nur selbst verstehen.

Weisen der Arbeit

Alle Arbeit ist nicht gleich. Nicht nur die Bandbreite ihrer Inhalte ist riesig. Sie unterscheidet sich auch noch fundamentaler in der Weise, wie sie verrichtet wird. Damit meine ich nicht schnell oder sorgfältig, sondern noch grundlegender eine Haltung, einen Anspruch, einen Zweck.

Die uns vertrauteste Arbeitsweise ist die, bei der ein Auftrag zügig und geradlinig umgesetzt wird. Da gibt es kein Zögern, da ist alles klar, da wird zugepackt und das Ergebnis nach allen Regeln der Kunst hergestellt. So stellt ein Bäcker Brötchen her, so repariert ein Schuster Schuhe, ja, selbst ein Musiker spielt so ein Repertoirestück.

Diese Arbeitsweise nenne ich handwerklich. Als Handwerker sind Vorgabe und Ziel klar. Ebenso klar ist es für den Handwerker, mit welchen Methoden, Materialien und Werkzeugen er sie umsetzt.

Handwerker sind dabei für mich jedoch nicht nur Berufstätige mit einem Gesellen- oder Meisterbrief. Nein, jeder Mensch ist Handwerker. Immer wieder über den Tag verteilt. Wenn Sie morgens ein Brot schmieren, dann sind sie Handwerker. Wenn Sie Wäsche waschen, sind Sie Handwerker. Selbst wenn Sie Ihrem Kind etwas vorlesen, sind Sie Handwerker.

Handwerker haben ein Handwerk gelernt. Sie haben im Umgang mit Methoden, Materialien und Werkzeugen in unterschiedlichsten Situationen Erfahrungen gesammelt. So ist die nächste Situation für sie kaum eine Überraschung. Sie wissen, was zu tun ist.

Die Aufgabe des Handwerkers ist es, Vorgaben/Pläne/Entwürfe in nutzbare Ergebnisse zu überführen. Handwerker stellen her. Das sogar immer wieder. Sie sind grundlegend reproduzierend tätig. Sogar so sehr, dass sich ihre Arbeit erst taylorisieren und dann automatisieren lässt. Industrielle Fertigung ist Handwerk on steroids.

Aber natürlich sind wir nicht den ganzen Tag Handwerker. Das können wir nämlich nur sein, wenn erstens die Vorgaben klar sind und wir zweitens für die Umsetzung viel Erfahrung haben. Insbesondere die Vorgaben fehlen jedoch oft. Es gibt keinen Plan.

Planen ist jedoch eine andere Arbeitsweise als handwerkern. Sie ist fundamental kreativ. Denn planen, entwerfen, designen erschafft ein Bild von etwas Neuem. Einen Tisch nach Plan zu bauen, ist etwas anderes, als den Plan für einen Tisch zu entwerfen. Vorher war da keine Vorstellung von einem Tisch, jetzt ist sie da - zunächst nur auf Papier, aber immerhin.

Es ist die Aufgabe von Ingenieuren, zu planen, zu entwerfen, zu konstruieren. Handwerker bauen, Ingenieure “erfinden” (vlg. dazu auch “Discussion of the Method” von B. V. Koen).

Und wieder meine ich damit nicht Berufsgruppen, sondern eben Arbeitsweisen, in denen jeder Mensch Tag für Tag tätig ist. Wenn Sie Ihren Tag planen, sind Sie Ingenieur. Wenn Sie sich überlegen, wie der Weihnachtsbaum in diesem Jahr geschmückt werden könnte, sind Sie Ingenieur. Genauso, wenn Sie sich Gedanken darüber machen, wie Sie am besten ein Bewerbungsschreiben strukturieren.

Ingenieure erdenken Neues, Handwerker manifestieren Neues. So kurz kann man es fassen.

Beide Arbeitsweisen brauchen jedoch ein Fundament. Das besteht aus Kenntnissen, Wissen, Erfahrung. Das zu erarbeiten, braucht wiederum eine andere Arbeitsweise: das Forschen.

Es ist die Aufgabe von Forschern, Wissen zu produzieren. Damit bringen sie jedoch nichts Neues in die Welt, sondern beschreiben vielmehr “nur”, wie die Welt ist.

Um Forscher zu sein, muss man freilich nicht studieren. Jeder Mensch ist Forscher. Wenn Sie die Bedienungsanleitung des neuen Fernsehers studieren, forschen Sie. Wenn Sie Tagebuch schreiben, erforschen Sie sich selbst. Wenn Sie Schlittschuhlaufen lernen, forschen Sie ebenfalls.

Lernen ist Forschung. Analyse ist Forschung. Sie können es nicht vermeiden, jeden Tag aufs neue die Welt zu erforschen. Ganz grundsätzlich ist dafür kein spezielles Werkzeug und schon gar kein Doktorgrad nötig. Blindes trial and error reicht aus - aber mit etwas mehr Systematik mag es schneller gehen.

Forscher liefern die Grundlagen, Ingenieure entwerfen darauf aufbauend Neues und Handwerker stellen es her.

Arbeitsweisenverhältnisse

Vielleicht gibt es noch weitere fundamentale Arbeitsweisen. Aber auch langes Nachdenken hat sie mir nicht entdeckt. Einstweilen fühle ich allerdings auch kein Defizit. Die drei Arbeitsweisen Handwerker (H), Ingenieur (I) und Forscher (F) machen es mir leicht, Berufe und Tätigkeiten ganz unterschiedlicher Art zu erklären. Es kommt nämlich auf das Mischungsverhältnis an.

Jede Arbeit setzt sich aus H, I, F zusammen, wie Farben sich aus unterschiedlichen Anteilen von Rot (R), Grün (G) und Blau (B) ergeben.

Zunächst die zu den Arbeitsweisen gehörenden Berufsgruppen:

• Handwerksberufe: Als Handwerksberufe - Klempner, Tischler, Bäcker usw. - bezeichnen wir solche, bei denen die Arbeit einen überwiegenden Anteil von H hat. I und F kommen auch vor, aber definieren die Arbeit nicht; der HIF-Code ist für mich (80%/10%/10%). Beispiel 1: Natürlich muss ein Bäcker, wenn er eine Hochzeitstorte backen soll, zuerst die Wünsche des Hochzeitspaares erfahren (F). Dann muss er die eine oder andere Idee zu deren Erfüllung entwickeln (I). Letztlich jedoch wird der größte Teil der Arbeit in die Herstellung fließen (H). Beispiel 2: Der KfZ-Mechaniker muss bei einer Inspektion den Zustand eines Wagens prüfen (F). Eine Reparatur oder Wartungsarbeit (H) macht dann jedoch das aus, was wir mit diesem Beruf vor allem verbinden.
• Ingenieursberufe: Wie die Bezeichnung sagt, liegt in Ingenieursberufen - Elektrotechniker, Maschinenbauer usw. - der Schwerpunkt auf I. Natürlich müssen Ingenieure auch forschen, z.B. wenn sie verstehen wollen, was eigentlich ihr Auftrag ist. Und Ingenieure legen auch Hand an, wenn sie z.B. Prototypen bauen (H). Letztlich geht es jedoch um den Entwurf des Neuen, die “Erfindung”. Es soll etwas erdacht werden, das es vorher noch nicht gab (I). HIF-Code (10/80/10).
• Wissenschaftler: Wissenschaftler schaffen Wissen (F). Das ist ihr Auftrag. Dafür müssen sie natürlich auch einen Versuchsaufbau entwerfen (I) oder sogar Daten nach den Regeln der mathematischen Kunst auswerten (H). Doch unterm Strich ist das, was sie tun, ihr Zweck, die Ermittlung dessen, was schon ist. Das fassen sie in Worte - so dass andere Wissenschaftler, aber auch Ingenieure und Handwerker darauf aufbauen können. HIF-Code (10/10/80).

Das war einfach und naheliegend, oder? Die Berufsgruppen, von deren Namen die Arbeitsweisen abgeleitet sind (oder umgekehrt?), konzentrieren sich jeweils zu vielleicht 80% auf die sie bezeichnende Arbeitsweise. Wie ein RGB-Code eine Farbe, so bezeichnet die Mischung der HIF-Werte einen Beruf.

Das lässt sich weiterspinnen. Hier die Mischungsverhältnisse für weitere “Berufsgruppen”, wie ich sie sehe:

• Kunsthandwerker: Wenn der Handwerker-Code HIF(80/10/10) lautet, dann hat der Kunsthandwerker HIF(50/30/20). Er setzt nicht einfach nur einen Entwurf handwerklich um, sondern fertigt diesen Entwurf auch an (I). Außerdem muss er “die Welt” beobachten, um herauszufinden, was ihr gefallen könnte (F).
• Künstler: Auch wenn es heißt “Kunst kommt von Können”, so ist der Künstler nicht vordringlich ein Handwerker. Ich sehe seinen HIF-Code eher bei (30/30/40). Der Künstler will die Welt darstellen, das Wahre herausarbeiten. Dazu muss er sie intensiv studieren (F) und dann eine geeignete Abbildung entwerfen (I). Die handwerkliche Umsetzung ist dann nur noch der kleinere Teil - den große Künstler immer wieder ihren Assistenten überlassen haben.
• Virtuose: Den Virtuosen sehen wir als Künstler. Für mich ist er jedoch eher ein Handwerker. Er muss zwar das Material, das er darbietet, gründlich erforschen und dann seine Interpretation erarbeiten. Doch das, worauf es ankommt, ist am Ende die Reproduktion. Also sehe ich hier einen HIF-Code von (50/20/30).
• Chirurg: Chirurgen sind weitestgehend Handwerker. Dass sie lange studiert haben und die Sache komplizierter ist als eine Autoreparatur, ändert daran nichts. Ich sehe das HIF-Verhältnis so: (70/20/10). Ein wenig Forschung ist noch nötig, um zu erkennen, was wirklich das Problem des Patienten ist (F) - manchmal auch noch während der OP. Dann wird die beste Herangehensweise entworfen (I). Die Operation schließlich besteht im Ausführen von lange geübten Handgriffen entlang anerkannter Pfade. Kaiserschnitt, Herzklappentransplantation, Billroth-II-Resektion, Staroperation, Hernienoperation… das alles tut man überall auf der Welt gleich. Und manches wird schon quasi am Fließband erledigt.
• Hausmeister: Der Hausmeister ist im Wesentlichen ein Handwerker. Er tut, was er kann, selbst. Aber er ist andererseits auch für Gebäude verantwortlich. Daher muss er zuvor analysieren/beobachten (F) und dann das richtige Vorgehen planen (I) - bei dem ihm Handwerker helfen. Ich sehe den HIF-Code bei vielleicht (60/20/20).
• Sportler: Man könnte meinen, ein Sportler sei ein Handwerker. Im Wettkampf ist er das auch. Aber die meiste Zeit performt er nicht, sondern trainiert. Und dazu gehört viel Forschung und Entwurf. Strategien wollen erarbeitet werden (I), die eigenen Leistungsparameter müssen erkundet werden (F). Sportler lernen ständig. Für mich ist der HIF-Code bei (50/20/30) - und das passt schön zum Virtuosen. Der Sportler als Virtuose des Körpers.
• Schüler: Schüler sind zuallererst Forscher. Ihre Aufgabe ist es, Wissen aufzubauen. Lernen bedeutet, das zu beherrschen, was schon in der Welt ist. Also ein HIF-Code von (10/10/80).
• Lehrer: Lehrer hingegen sind eher Ingenieure. Ihre Aufgabe ist es, Pläne dafür zu entwickeln, wie Schüler am besten lernen. Das entspricht eher HIF(30/50/20).

Natürlich sind die HIF-Anteile ständig im Fluss. Mir geht es auch nicht um exakte HIF-Verhältnisse. Die Idee der Mischungsverhältnisse ist das Entscheidende. Dass eben Arbeit überhaupt durch unterschiedliche Anteile an H, I und F charakterisiert ist. Nicht nur die professionelle Arbeit, sondern auch das, was wir täglich tun. Jeder Tag zuhause ist eine neue Mischung aus H, I und F.

Zum Abschluss nun das Mischungsverhältnis, das Sie wahrscheinlich am meisten interessiert. Wie sind H, I und F bei der Softwareentwicklung verteilt? Ich sehe das so:

• Softwareentwickler: Softwareentwickler sind anders als andere. Als hätten wir das nicht immer gewusst ;-) Ich sehe einen HIF-Code von (20/40/40). Handwerker im Sinne der obigen Definition sind Softwareentwickler nur zu einem kleinen Teil. Der Schwerpunkt ihrer Arbeit liegt auf Forschung und Ingenieursarbeit. “Software Engineering” ist also treffender als “Software Craftsmanship” - und liegt trotzdem daneben. Denn anders als bei der Berufsgruppe Ingenieur besteht Softwareentwicklung nicht zu 80% aus Ingenieursarbeiten, sondern teilt sich die 80% mit der Forschung. Das eben macht den Charakter der Softwareentwicklung aus. Es ist viel zu forschen: Kundenwünsche müssen analysiert werden, Technologien müssen evaluiert und erlernt werden, dito Paradigmen und Methoden. Vor allem ist jedoch Quellcode ständig zu studieren, bevor daran Änderungen angebracht werden können. Nach der Forschung kommt der Entwurf. Der findet immer statt, auch wenn Sie nie am Flipchart stehen und UML-Diagramme malen. Softwareentwickler machen sich zunächst immer irgendwelche Gedanken darüber, wie der Code aussehen sollte, bevor sie ihn schreiben. Im Großen wie im Kleinen. Da werden APIs entworfen oder Testreihenfolgen bestimmt. Daten(bank)strukturen werden entworfen. Algorithmen und Lösungsansätze ebenso. Und erst ganz zum Schluss gießt die Softwareentwicklung diese Entwürfe in Code. Da ist dann Handwerk gefragt.

Das HIF-Mischverhältnis der Softwareentwickler ist dem der Künstler am nächsten. Künstler arbeiten sehr iterativ. Künstler machen Prototypen. Künstler können sehr detailverliebt sein. Künstler schauen genau hin. Der eine oder andere mag also ausrufen “Siehste! Das habe ich doch gewusst!”

Dennoch sind Softwareentwickler keine Künstler. Ihre Aufgabe ist schlicht eine andere: Der Künstler soll Wahrheit ausdrücken, die Softwareentwicklung nützliche Werkzeuge herstellen. Das Produkt des Künstlers ist irgendwann fertig und wird nicht weiter verändert. Software hingegen kommt nie zur Ruhe. Von der Analogie “Softwareentwickler sind wie Künstler” halte ich unterm Strich also nichts.

(Un)Schätzbarkeit

So viel der Vorbereitung. Softwareentwicklung (wie auch alle anderen Arbeiten) ist eine Kombination aus drei grundsätzlichen Arbeitsweisen.

Diese drei Arbeitsweisen sind nicht nur in ihren Ergebnissen sehr unterschiedlich, sie lassen sich auch unterschiedlich gut schätzen.

Die handwerkliche Arbeitsweise lässt sich gut abschätzen. Sie ist wenig kreativ. Handwerk arbeitet reproduktiv. Das ist im Grunde sogar seine Definition. Deshalb gibt es auch so viel mehr berufliche Handwerker als Ingenieure und Wissenschaftler. Nicht umsonst ist der Anspruch an jeden Handwerker, einen treffenden Kostenvoranschlag machen zu können, wenn es um die Reparatur einer Heizung geht oder den Bau eines Wintergartens.

Anders ist es für die Arbeitsweise Ingenieur. Die ist hochkreativ. Hier wird “erfunden”. Hier findet Problemlösung statt. Und niemand weiß, wie lange das dauert. Ingenieure entwickeln schließlich Neues. Das braucht Versuch und Irrtum. Dafür gibt es keine berechenbare Geschwindigkeit. Ingenieursarbeit lässt sich mithin nicht schätzen. Oder wenn, dann nur in sehr grobem Rahmen auf der Ebene von Größenordnungen.

Dasselbe gilt für die Arbeitsweise Forschung. Wie lange die Analyse eines steinzeitlichen Grabes dauert, wie viel Aufwand die Erforschung der Kernfusion brauchen wird, wann man die Kundenanforderungen wirklich verstanden hat… das alles lässt sich nicht vorher abschätzen. Oder eben nur wieder auf der Ebene von Größenordnungen.

Das bedeutet für die Softwareentwicklung:

Mit einem HIF-Code von (20/40/40), also 80% Ingenieurs- und Forschungstätigkeit, ist Softwareentwicklung nicht sinnvoll schätzbar.

Manager, Kunden, Laien und auch viele Softwareentwickler glauben, Softwareentwicklung sei vor allem Handwerksarbeit. Deshalb wird immer wieder ein “Kostenvoranschlag” gefordert. Für einen gegebenen Scope (Anforderungen an Funktionalität und Effizienz) soll berechnet werden, wie viel Zeit und damit Geld zur Umsetzung gebraucht werden.

Für eine handwerkliche Leistung eine ganz selbstverständliche Frage. Nur leider ist Softwareentwicklung wenig handwerklich. Deshalb sind die Antworten unbefriedigend und immer wieder sehr weit von der Umsetzungsrealität entfernt. Das Resultat: Streit, Druck und mangelnde Qualität.

Aufgrund einer falschen Prämisse entsteht eben kein korrektes Ergebnis.

Kunden können nicht einschätzen, wie viel Analyse und Entwurf für die Umsetzung von Anforderungen nötig sind. Dass es sich um eine handwerkliche Tätigkeit handle, ist eine Annahme aus Unverständnis bis Ignoranz. Softwareentwickler können die Anteile auch nur sehr schwer abschätzen - und unterschätzen sie regelmäßig. Softwareentwickler sind übertrieben selbstbewusst oder naiv, was ihre Erfahrung in puncto Tools, Technologien, Paradigmen, Methoden oder schlicht das Verständnis des teameigenen Quellcodes angeht. Vom Verständnis der Anforderungen ganz zu schweigen.

Hinzu kommt die Arbeitsatmosphäre in vielen Projekten. Sie ist geprägt von Unterbrechungen aller Art. Selbst bei halbwegs realistischer Einschätzung des Aufwandes kann kaum gesagt werden, wie lange es dauert, bis er erbracht ist. Dringendes aller Art schiebt sich ständig zwischen die konzentrierte Arbeit an einer abgeschätzten Aufgabe.

Das bedeutet unterm Strich:

Abschätzungen von Softwareentwicklungsaufwänden funktionieren nicht - solange der handwerkliche Arbeitsanteil nicht klar erkennbar deutlich überwiegt und für die Dauer der Umsetzung Störungsfreiheit zugesichert werden kann.

Wie oft ist das aber der Fall? Ich halte das für eine Ausnahme. Es ist nicht unmöglich, doch so selten, dass darauf kein ethisches Geschäftsmodell aufgebaut werden kann.

Handlungsempfehlung

Für Ihre Entwicklungspraxis ergeben sich Konsequenzen aus dieser Analyse. Wenn Sie ehrlicher und ruhiger und mit höherer Qualität arbeiten wollen, dann sollten Sie bei der nächsten Aufforderung zur Abgabe einer Schätzung folgende Schritte durchlaufen:

1. Machen Sie sich und dem Auftraggeber klar, dass keine Schätzung gefordert wird, sondern ein “Kostenvoranschlag”, d.h. eine Berechnung mit der Genauigkeit von 5–10% in Bezug auf Kosten und Termintreue. Man glaubt ja, Sie seien Handwerker.
2. Werden Sie zum Forscher: Analysieren Sie die Anforderungen im Hinblick auf die für die Umsetzung wahrscheinlichen Aufwände an Forschung und Entwurf. Seien Sie schonungslos ehrlich zu sich und dem Auftraggeber. Vertuschen Sie keine Unsicherheiten. Legen Sie das bekannte Unbekannte (also zu Erforschende) auf den Tisch. Bemühen Sie sich außerdem, weiße Flecken, also das unbekannte Unbekannte zu identifizieren.
3. Weisen Sie die Schätzung zurück, solange der Handwerksanteil bei der Umsetzung geringer als 80% ist.

Seien Sie transparent, was diese Schritte angeht. Erklären Sie dem Auftraggeber Ihre Haltung. Die ist differenziert und offen und realistisch - auch wenn sie ihm nicht gefällt. Geben Sie ihm womöglich diesen Artikel zu lesen. Er darf mich auch gern kontaktieren für Nachfragen :-)

Ich behaupte nicht, dass diese Haltung einzunehmen leicht für Sie ist. Aber ich bin fest davon überzeugt, dass sie in Übereinstimmung mit der Natur von Softwareentwicklung und insofern ehrlich und ethisch ist.

PS: Softwareentwicklung als Ganzes halte ich übrigens für eine Forschungstätigkeit. Der Zweck der ganzen Entwicklungsarbeit ist die Erforschung dessen, was den Kunden befriedigt. Das weiß der Kunden nämlich selbst nur sehr ungenau. Mit jedem Release lernt er sich besser kennen. Durch Versuch und Irrtum nähert er sich dem an, was wirklich hilft. Das ist Forschung. Um diesen Zweck zu erfüllen, arbeitet der Entwickler mit HIF(20/40/40).

Co-location als kontraproduktiv erachtet

Wo ein Entwicklungsteam noch an einem Ort sitzt, sollte es verteilt werden. Entwicklungsteams, die gebildet werden sollen, fangen am besten gar nicht erst an, sich an einem Ort zu versammeln. Verteilte Teams sollten der Default sein.

Die Sonne lacht in Hamburg, ein frischer Wind weht an der Alster. Ein guter Tag, um sich unbeliebt zu machen :-) Deshalb diese Vorschläge. Irgendwann muss ich damit mal raus. Warum nicht heute?

Ja, so denke ich inzwischen immer mehr. Co-location ist ein Problem.

Aber der Reihe nach:

Im Jahr 2001 wurde das Agile Manifest unterzeichnet von 17 umtriebigen Geistern - alle weiß, männlich, vor allem Amerikaner und im Durchschnitt zu dem Zeitpunkt wohl um die 50 Jahre alt. Das sage ich so, weil ich glaube, dass wir Agilität wie sie seitdem von den Unterzeichnern gepredigt und von anderen übernommen wurde, davon nicht unabhängig sehen dürfen. Die Unterzeichner sind auch nur Menschen. Sie sind mithin Kinder ihrer Zeit und ihrer Erfahrung. Sie hatten und haben einen je eigenen Horizont, in dem sie denken und innovieren können. Genauso wie Sie und ich ebenfalls.

Scrum wurde von Schaber/Sutherland Mitte der 1990er entwickelt. Da war Schwaber schon 50 und Sutherland wahrscheinlich auch. Sie haben sich darin eingebracht mit allem besten Willen und all ihrer Erfahrung. Nicht weniger - aber eben auch nicht mehr.

Die Frage ist daher: Was war ihre Erfahrung? Und was für ein Ziel lässt sich daraus ableiten?

Das Ziel beschreibt am Ende das Agile Manifest: Es geht um den Softwareproduktionsprozess. Der soll flüssiger werden, der soll näher am tatsächlichen Bedarf laufen. Die Softwareentwicklung soll sich nicht ablenken lassen durch eingefahrene Regularien, Werkzeuge, Dokumentationsanforderungen, Vertragsverhandlungen oder überdimensionierte, schnell veraltende Pläne.

Gut so! Das Manifest enthält wunderbare vier Maximen.

Und dennoch: Es geht um Produktivität. So sehen denn auch die Mittel aus, die zum Einsatz kommen:

• Statt einmaliger Großplanung lieber iteratives Vorgehen in Lernschleifen.
• Statt technischer Meilensteine lieber inkrementelles Vorgehen für schnelleres Feedback.
• Statt Abteilungsgerangel lieber cross-functional teams.
• Statt langsamer indirekter Kommunikation über Hierarchieebenen hinweg lieber schnelle persönliche Kommunikation auf Augenhöhe durch co-location aller Teammitglieder.

Habe ich noch etwas vergessen? Bestimmt. Aber ich glaube, das sind die zentralen Mittel agiler Softwareentwicklung. Auf die sind 50jährige Männer nach intensiver Beobachtung und Diskussion gekommen.

Das ist wunderbar - außer, wenn es nicht wunderbar ist ;-) Denn es steckt in diesen Mitteln Zeitgeist und technische Möglichkeit. Man wusste es halt nicht besser, man konnte nicht anders. Doch seitdem hat sich die Welt gedreht. Wir sind 20 Jahre nach Scrum, 14 Jahre nach dem Agilen Manifest.

Innerhalb meines bescheidenen Horizonts halte ich das iterative/reflektierende Vorgehen für zeitlos. Auch am inkrementellen Vorgehen habe ich nichts auszusetzen. Außer, dass ich es oft noch für zu grobgranular halte und die Iterationen mir zu lange dauern. Aber grundsätzlich bin ich ganz dafür. Und auch die cross-functional teams sind für mich eine sine qua non. Nur so lassen sich Abhängigkeiten flüssig entschärfen.

Bei der co-location hingegen bin ich nicht mehr dabei. Hier sehe ich die weithin real existierende agile Praxis in den 1990ern verharren. Schwaber, Jeffries, Martin & Co sind eben keine digital natives. Sie hatten Email, aber auch wenn Ward Cunningham mit von der agilen Partie war, waren Wikis kein für die Massen verfügbares Werkzeug. Social Media waren in den Kinderschuhen wenn überhaupt Smartphones gab es noch lange nicht. Verteilte Versionsverwaltung lag noch in der Zukunft. Infrastruktur in der Cloud zum kleinen Preis ließ sich noch nicht denken.

Und so sah man sich außerstande, etwas anderes als co-location für die Zusammenarbeit zu empfehlen. Das war ja auch viel besser, als Leute auf office cubicles zu verteilen, oder?[1]

Irgendwie schon. Aber dann doch wieder nicht. Denn ich sehe durch die co-location drei fundamentale Probleme in der Praxis entstehen:

1. Co-location öffnet Unterbrechungen Tür und Tor. Wer im team room nahe beieinander sitzt, kann die Kollegen schnell mal ansprechen. Das ist auch Sinn und Zweck. Fowler sagt: “[I]t promotes lots of informal and deep communication between people on the team.” Was für den, der einen anderen anspricht eine tolle Vereinfachung ist, ist für den Angesprochenen hingegen oft das Gegenteil, nämlich eine Erschwernis seiner Arbeit. Wer angesprochen wird, wird unterbrochen, d.h. aus seinen Gedanken gerissen, im Arbeitsfluss gestört. Da macht es auch nichts, dass der Ansprechende ganz wohlmeinend oder sehr bedürftig ist. Unterbrechungen stören die konzentrierte Herstellung von Resultaten. Das gilt für Unterbrechungen durch Manager, die plötzlich im Raum stehen, genauso wie für Unterbrechungen durch Teammitglieder - oder auch selbstverschuldete Unterbrechungen durch Social Media Benachrichtungen.
2. Co-location leistet unentdeckten Abhängigkeiten Vorschub. Wer im team room sitzt, muss sich tendenziell weniger Gedanken machen über das, was er braucht, um seine Resultate zu erzielen. Abhängigkeiten von Technologien oder Anforderungsverständnis müssen nicht vorher entdeckt und aus der Welt geschafft werden, sondern können ja im Zweifelsfall jederzeit durch Nachfrage bei einem Kollegen aufgelöst werden. Irgendwer weiß immer Bescheid, dafür ist das Team doch cross-functional. Daraus entstehen nicht nur Unterbrechungen für Kollegen, sondern auch geringere Produktivität. Denn so wie ein Koch produktiver ist, wenn er in Phasen arbeitet, also z.B. Gemüse erst komplett schneidet, so ist Softwareentwicklung auch produktiver, wenn sie in Phasen arbeitet; das sind mindestens Analyse, Entwurf, Implementation.[2]
3. Co-location fördert monolithischen Code. Wenn auch nur irgendetwas an Conways Gesetz ist, dann dürfen wir uns nicht wundern, dass 14 Jahre Agilität den monolithischen Anwendungen nicht den Garaus gemacht haben.[3] “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” Und was für eine “communication structure” soll ein co-located team im team room haben? Eine sehr, sehr enge. Was bedeutet das für das “design”, d.h. die Struktur ihres Produktes Software? Es wird aus eng verbundenen Teilen bestehen.

Auch ich habe meinen Hintergrund. Vor dem sehe ich auf Agilität. Ich bin weniger am Prozess interessiert als am Code.[4] Der muss wandelbar, evolvierbar sein, sondern ist die Softwareentwicklung nicht zukunftsfähig.

Ja, da sehe ich das große Problem unserer Tage in der Softwareentwicklung: Wandelbarkeit. Sogar nicht nur Code, sondern auch Teams (und Unternehmen) müssen wandelbar sein, sich also anpassen können. Dazu gehört natürlich Reflexion, wie sie in der Agilität drinsteckt. Doch es braucht noch mehr. Ohne passende Strukturen lassen sich Ergebnisse der Reflexion nur schwer oder gar nicht umsetzen.

Die meisten Projekte leiden nicht unter technologischen Schwierigkeiten. Wir haben Hardware und Frameworks und Dienste, die leistungsfähig genug sind, um die Effizienzanforderungen an Software zu erfüllen. Das war bis vor 10 Jahren noch ganz anders. Deshalb war Wandelbarkeit für die Agilität auch kein großes Thema. Clean Code kam erst sieben Jahre nach dem Agilen Manifest und 13 Jahre nach Scrum.

Doch nun haben sich die Zeiten gewandelt. Wandelbarkeit ist das zentrale Thema - wenn man nicht grad dem nächsten noch besseren Framework hinterherjagt. Auch die aktuelle µService-Bewegung ist ein Ausdruck des Leidens am Monolithen, an der Unwandelbarkeit.

Und wodurch sind wandelbare Strukturen gekennzeichnet? Durch lose Kopplung. Ein älteres Prinzip gibt es wohl kaum in der Softwareentwicklung.

Lose Kopplung entsteht durch Kapselung (klare Schnittstellen, Autonomie, geringe Abhängigkeiten) und asynchrone Kommunikation.

Wenn man diese Eigenschaften für ein Softwaresystem will, wie ist das zu vereinbaren mit co-location im team room? Wie können lose Kopplung und auch wandelbare verteilte System einfach entstehen, wenn die, die sie herstellenn sollen, einander auf dem Schoß sitzen?

Hier sehe ich die vorherrschende Implementation von Agilität gegen eine Wand laufen. Man macht es sich schwer bis unmöglich, das zentrale Problem der Softwareentwicklung unserer Zeit zu lösen, wenn man als Default für die Teamorganisation den team room setzt.

Entwickler, die man im selben Raum zur selben Zeit sehen will, können eine Menge herstellen - aber entkoppelte Strukturen bzw. wandelbare Software ist sicherlich nicht das Produkt, was ihnen am leichtesten aus den Fingern fließt.

Das Agile Manifest ist gut, wofür es gedacht ist: Produktivität. Es kommt aber an seine Grenzen, wenn es Mittel verschreibt, die der Erfüllung anderer Anforderungen im Wege stehen, hier der Wandelbarkeit.

Deshalb mein radikaler Vorschlag: Geben wir die co-location auf! Setzen wir die Verteilung von Teams als Default. Befreien wir Teammitglieder von Bindungen an Raum und Zeit.

Wir haben genügend Kommunikationsmittel und Tools, um jederzeit Kontakt aufzunehmen zu Kollegen, egal wo sie sich befinden. Chat, Telefon mit Anrufbeantworter, Diskussionsforen, Wikis, Issue Tracker, Repositories, Videokonferenzen, online Whiteboards und was es noch alles gibt in tausend und einer Ausprägung. Asynchrone Kommunikation in unterschiedlicher Geschwindigkeit ist kein Problem. Jeder ist immer erreichbar. Gut so! Wir können unsere Anliegen immer zustellen - ohne den anderen zu unterbrechen. Das sorgt für konzentrierte Arbeit. Das ist gelebte Autonomie: Ich bestimmte selbst über die Nutzung meiner Zeit.

Wohlgemerkt schließt solcher Default der Verteilung nicht die synchrone Kommunikation aus. Zu einem Telefonat oder eine Videokonferenz kann man sich jederzeit verabreden. Das gilt sogar für persönliche Treffen, also Meetings. Niemandem wird verwehrt, sich eine Art der Zusammenarbeit zu wünschen, die für ihn und seine Resultate zuträglich ist. Nur muss das jeder mit den Kollegen verhandeln, denn die mögen andere Vorstellungen davon haben, wie sie ihre Ergebnisse am liebsten erzielen.

Verteilte Arbeit macht es schwerer, dass lokale Resultatsoptima entstehen. Ein Resultat kann weniger einfach auf Kosten vieler anderer Resultate hergestellt werden. Das Ganze wird betont, optimiert - ja, auch wenn ein Einzelner, ein individuelles Resultat dabei einmal zu kurz kommen sollte.

Dass man für verteiltes Arbeit ein paar andere oder gar mehr Soft Skills benötigt, als für die befohlene Arbeit am selben Ort zur selben Zeit wie andere, das mag sein. Man muss sich besser organisieren können, verantwortungsbewusster sein, expliziter und verlässlich kommunizieren… Aber nur weil das schwierig für manche sein mag (ja, auch und gerade für Manager), sollte das nicht bedeuten, dass verteilte Teams nicht anstrebenswert seien. Denn es steht viel auf dem Spiel. Es geht um nicht weniger als die verlässliche Herstellung von Wandelbarkeit. Ohne die gibt es nämlich keine Zukunftsfähigkeit. Sowohl für Code wie für Teams.

Mit verteilten Teams entstehen nämlich nicht nur (einfacher) wandelbare Softwarestrukturen, sondern auch wandelbare Teams. Wo ein Team verteilt arbeitet, ist die Einbindung von neuen Kollegen an beliebigen Orten einfacher. Das ist doch eine gute Nachricht für das Recruiting, oder? Dadurch kommen leichter neue Impulse zu allerlei fachlichen Aspekten ins Team.

Ganz davon abgesehen, dass verteilte Teams weniger hausinterne Infrastruktur brauchen. Heute gibt es alles, was das Entwicklerherz begehrt, in der Cloud. Wer wollte da auch nur einen Server kaufen? Was Entwickler brauchen, sind gute Laptops und viel Internetbandbreite. Gelegentlich noch ein Raum, um tatsächlich mal zusammenzukommen. Am besten mit Beamer/Smartboard und Flipchart. Und das Internet muss stets verlässlich da sein wie Strom aus der Steckdose. Ohne lästige Spezialfirewalls, die Superproxys brauchen, die den Zugriff auf ein DVCS behindern.

Wohlgemerkt, ich rede hier über Entwickler, nicht über sonstige Mitarbeiter von Unternehmen. Was die brauchen, ist eine andere Sache. Aber nur weil die vielleicht etwas brauchen - zum Beispiel ein total supersicheres Firmennetz -, sollte das nicht bedeuten, dass die Softwareentwicklung sich aus Solidarität auch ein Bein hochbinden muss.

Bottom line: Ich glaube, die Zeit der co-location als Default ist vorbei. Angesichts der Kommunikationsmöglichkeiten, die wir haben, hat sie den Punkt erreicht, wo sie kontraproduktiv wird.

Ja, wir haben das Zusammenhocken lieb gewonnen. Irgendwie ist es auch kuschelig mit den Kollegen. Aber was wollen wir? Kuscheln oder wandelbare Software?

Wer kuscheln will, kann z.B. per Chat im Team anfragen, wer mitmachen möchte. Dann kann ein Meeting vereinbart werden. Das sollte jedoch die Ausnahme sein. Synchrone persönliche Kommunikation vieler Teammitglieder macht vielleicht ein gutes Gefühl - aber es wird andererseits auch ganz schnell ganz viel Geld verbrannt.

Die Väter der Agilität haben es gut gemeint. Doch sie waren eben auch begrenzt in ihrer Erfahrung mit Kommunikationstechnologie. Ken Schwaber konnte z.B. nicht anders, als lange Jahre seines Lebens mit Telefon ohne Anrufbeantworter zu leben und zu arbeiten. Dann mit Anrufbeantworter und gelegentlichem Fax. Dann irgendwann später mit Email usw. Kein Wunder, dass er und die anderen co-location als Wunderwaffe empfanden. Irgendwie liegt sie uns ja auch im Blut. Die Bandbreite der Kommunikation ist da so schön hoch.

Aber kuschelige Bandbreite ist eben nicht alles. Wenn ungehinderte Kommunikation in hoher Bandbreite die Norm ist, ist irgendetwas optimiert – und irgendetwas bleibt auf der Strecke. Das ist die Wandelbarkeit.

Drum sage ich: Vorsicht vor der co-location!

So viel Verteilung und Autonomie und Entkopplung wie möglich, so wenig co-location wie nötig.

---

1. Wir können spekulieren, wie das Agile Manifest ausgesehen hätte, wenn 50% der Unterzeichner Frauen gewesen wären. Oder das Durchschnittsalter 25 Jahre. Oder unterschiedliche Kulturen vertreten gewesen wären. ↩

2. Wer hier herauslesen will, dass ich für Big Design Up-Front (BDUF) wäre, liegt falsch. Diese Phasen können manchmal nur Minuten oder Stunden dauern. Selbst in der agile Praktik TDD stecken sie drin - ohne dass das betont würde. 30 Minuten Entwurf mit 2 Stunden folgender Implementation können 5 Stunden vermeintlich reiner Implementation ersetzen, in denen der Entwickler dauernd in unvermutete Abhängigkeiten läuft. Dass man durch beliebig lange Analyse- und Entwurfsphase alle Abhängigkeiten entdecken könnte, behaupte ich auch nicht. Aber ein gesundes Maß an Analyse und Entwurf ist nötig; mehr als oft aufgewandt wird in agilen, co-located Teams. ↩

3. Ganz davon abgesehen, dass Agilität ja nicht Wandelbarkeit als ausdrückliches Ziel hat. Wie man ganz deutlich an Scrum sehen kann, kümmert sich der agile Prozess gar nicht um die Sache - Code -, sondern nur um den Rahmen für die Produktion der Sache. Nicht umsonst hat Jeff Sutherland nun auch ein Buch geschrieben, das Scrum auf alle möglichen Arbeitsfelder anwendet (“The Art of Doing Twice the Work in Half the Time”). ↩

4. Allerdings verschiebt sich dieser Fokus notgedrungen in den letzten Jahren. Denn ich merke, dass ich die Verbesserungen, die mir für Code vorschweben, in Unternehmen nicht gut verankert bekomme, wenn mir der Prozess oder gar die Unternehmenskultur egal ist. Aber das ist ein Thema für einen anderen Artikel… ;-) ↩

Bessere Resultate ohne Abhängigkeit

Wie arbeiten Sie am liebsten, wenn Sie etwas schaffen wollen oder müssen? Was fördert Ihre Konzentration?

Die Menschen sind ja verschieden. Der eine möchte Ruhe haben, die andere Musik hören, der nächste ein Räucherstäbchen anzünden… Fenster auf, Fenster zu, mehr Licht, weniger Licht… Man kann es kaum allen recht machen, oder?

Eine Konstante gibt es jedoch hinter all dieser Verschiedenheit: den Wunsch nach Autonomie.

Sie wie ich möchten die Umstände unserer Arbeit möglichst weitgehend selbst bestimmen. Umso mehr, je stärker wir unter Druck stehen. Wer von uns Resultate sehen will, der sollte uns möglichst freie Hand lassen, wie wir uns einrichten, um sie zu erzielen. Zumindest wenn man uns vertraut, dass wir uns redlich bemühen, diese Resultate auch zu erbringen.

Ich als Freiberufler lebe und arbeite so. Meine “Resultatserzielungsumstände” kann ich zu 100% selbst bestimmen. Das macht mir Freude - und meinen Kunden auch. Verlässlichkeit und Qualität scheinen für sie zu stimmen.

Anders ist das bei den Entwicklern, Testern, Supportern, POs, die ich bei meinen Kunden treffe. Deren Autonomie ist minimal. Sie können (in den allermeisten Fälle) nicht über Arbeitsort, Arbeitszeit, Arbeitsplatz, Arbeitsmittel bestimmen. Ja, sie können sogar nur begrenzt über die Arbeitszeitnutzung bestimmen.

Das finde ich von Tag zu Tag kontraproduktiver. Je häufiger ich solche Umstände sehe und auf der anderen Seite Klagen darüber höre, was alles in Unternehmen nicht läuft, wie es laufen soll… desto mehr denke ich: Da gibt es einen Zusammenhang. Die Grundverhältnisse sind einfach so, dass es nicht besser klappen kann. Unternehmen wünschen sich also etwas, das sie nicht bekommen können, solange sie an ihren Glaubenssätzen festhalten, was die Einschränkung der Autonomie ihrer Mitarbeiter angeht.

Was wollen Unternehmen auch erwarten von Menschen, die offiziell “abhängig beschäftigt” sind? Diese Formulierung müssen Sie sich auf der Zunge zergehen lassen:

• Wer angestellt ist, ist abhängig. Das Unternehmen bestimmt, der Angestellte wird bestimmt. Er ist auf die Gnade des Unternehmens angewiesen - sonst wäre er ja nicht in einem Abhängigkeitsverhältnis. Gleichberechtigung, Augenhöhe, Autonomie sind etwas anderes. Erwachsene sollten solche Beziehungen nicht eingehen wollen - sollte man meinen. Allemal ist zu fragen: Was kann ein Unternehmen erwarten von Abhängigen? Freiwilligkeit und Motivation? Kaum.
• Wer angestellt ist, ist beschäftigt, nein, muss beschäftigt werden. Das hört sich an wie im Kindergarten, wo man Kinder beschäftigt, damit sie nicht auf dumme Gedanken kommen. “Beschäftigung” klingt auch nicht nach Motivation, Energie, Fokus. Wer beschäftigt wird, der tut auch eher nichts aus sich heraus, sondern braucht einen “Entertainer”. Sobald der nachlässt, kommt Langeweile auf.

“Abhängige Beschäftigung” soll etwas optimieren. Historisch gesehen ist sie eine große Leistung. Lieber abhängig beschäftigt im Schutz eines Unternehmens unter Aufsicht von Arbeits- und Sozialgesetzen, als frei, selbstständig, autonom - aber immer auch prekär am Rande des Existenzminimums.

Die positiven Effekte der “abhängigen Beschäftigung” möchte ich nicht schmälern. Doch sie hat eben ihren Preis. Und den zahlen nicht nur Unternehmen, sondern auch die Abhängigen. Der Preis der Abhängigkeit ist die Unterkomplexität.

Abhängigkeits- und Beschäftigungsverhältnisse sind immer hierarchisch. In Hierarchien fließen Segnungen von oben nach unten. Von unten nach oben wird geleistet und erbeten. Das ist klar, simpel, effizient. Das ist das Gegenteil von komplex. So soll es ja auch sein.

Historisch hat das auch lange gereicht, nein, konnte sogar nicht anders sein. Was immer an Resultaten zu erzielen war, war sehr einfach zu erzielen: Wenige denken und planen, viele, viele führen mit einfachen Handgriffen aus. Der kulturelle und bildungsmäßige Unterschied zwischen den Hierarchieebenen war bis neulich noch gigantisch.

In den letzten Jahrzehnten hat sich das nun radikal geändert. Ein Manager ist einem gemanageten Entwickler in nichts voraus. Sie sind in allem gleich - außer in ihrer Position in der Unternehmenshierarchie und damit im Gehalt und damit in den angehäuften materiellen Werten und damit in ihrem Anspruchsdenken. Allerdings leitet sich daraus kein Unterschied in der Angst ab. Angst ist auf jeder Ebene der Hierarchie gegenwärtig. Denn auf jeder Ebene ist man ja abhängig und will beschäftigt werden.

Diese Angst kostet natürlich Energie. Die wird investiert in Handlungen, die höhere Hierarchieebenen gnädig stimmen sollen. Ob daraus jedoch dem Unternehmenszweck dienliche Resultate erwachsen, ist zweitrangig. So kann es dann zu keinen besseren Resultaten kommen. Dass Unternehmen klagen, ist also nicht verwunderlich. Ihr grundsätzlicher Glaubenssatz ist falsch. Der lautet: Weil Angestellte so glücklich über die abhängige Geborgenheit sind, die das Unternehmen ihnen gibt, beschäftigen sie sich konzentriert mit der Erzielung von Resultaten zum Wohle eben dieses gnädigen Unternehmens.

Doch so funktioniert es eben nicht.

Ich glaube zwar daran, dass die meisten Angestellten gute Resultate zuverlässig liefern wollen - nur können sie es nicht. Sie sind umstellt von organisatorischen Mauern. Ihre Freiheitsgrade sind mindestens aus zwei Gründen beschnitten:

• Das Unternehmen traut den Abhängigen nicht. Denn die haben ja eine Beschäftigungsmentalität. Falls man sie nicht konstant bespaßt und beaufsichtigt, langweilen sie sich und tun nichts. Nur wenn ein Regelkorsett eng geschnürt ist, bleibt den Abhängigen quasi nichts anderes übrig, als auch in der Langeweile irgendwie noch ein Resultat zu erzielen.
• Unternehmen sind Zusammenschlüsse von Individuen, um durch ein engeres Verhältnis Energie zu sparen. Neben dem funktionalen Zweck (z.B. Software für Architekten) gibt es also auch einen nicht-funktionalen: Effizienzsteigerung. Der ist tief verankert und wird umso mehr beschworen, je enger der Markt wird. Im Verein mit der überkommenen Grundannahme, dass Abhängige, die beschäftigt werden müssen, weder rechte Motivation noch Kenntnis haben können, wie Ressourcen am besten eingesetzt werden, führt das zu weiteren Einschnürungen durch ein Regelkorsett. Vereinheitlichung, Standardisierung, Konsolidierung sind das Gegenteil von Autonomie.

Wenn ich “die Verhältnisse” so beschreibe, ist das natürlich überzeichnet. Doch nur durch die Überzeichnung wird die Grundhaltung erkennbar, die eben den meisten Unternehmen noch unterliegt. Es ist die der Hierarchie und der Unselbstständigkeit. Da helfen auch nicht 3 Monitore, der höhenverstellbare Schreibtisch oder die unternehmenseigene Kita. All das ist mit Hierarchie und Unselbstständigkeit vereinbar. Denn all das können einfach nur Geschenke und Zugeständnisse eben im Rahmen des überkommenden Paradigmas sein. Ein gelockertes Korsett ist immer noch ein Korsett - insbesondere, wenn man nicht wählen kann, ob man es auszieht.

Das Büro kann eingerichtet sein, wie es will. Mit Tischkicker und Ruheraum. Solange die, die Resultate erzielen sollen und wollen, nicht wahrhaft die Wahl haben, ihre Umstände bestmöglich selbst zu bestimmen, um eben diese Resultate zu erzielen… solange müssen sich Unternehmen nicht wundern, dass es nicht wie gewünscht klappt.

Je länger ich darüber nachdenke, desto mehr glaube ich, dass der Default für die Zusammenarbeit Unabhängigkeit sein sollte. Nur wenn Verlässlichkeit und/oder Resultat zu wünschen übrig lassen, sollte nachgebessert/optimiert werden. So wenig wie möglich.

Unternehmen als Ganzes und Manager in Unternehmen in ihren Bereichen sollten also nicht Regeln einführen, sondern stets Ausschau halten nach Regeln, die entfernt werden können. Denn je weniger Regeln, desto größer die Autonomie der Mitarbeiter. Und je größer die Autonomie, desto eher kann die Konzentration entstehen, die dafür nötig ist, dass Resultate verlässlich in hoher Qualität entstehen.

Wer Resultate sehen will, wer etwas bekommen will, sollte daher mit Geben beginnen. Das geschieht am besten mit einer simplen Frage: “Was brauchst du, um deine Resultate zu erzielen?”

Manchmal wünscht sich die Gefragte dann eine Regel; das ist nicht schlecht, denn dann kommt die Regel von unten, von dort, wo echter Bedarf ist.

Es können jedoch auch Antworten kommen, die dem Paradigma widersprechen. Aber warum davor Angst haben? Kann denn wirklich etwas Katastrophales passieren, wenn man die Leine der Abhängigkeit und der Beschäftigung lockert? Alle Wünsche sind doch nur Hypothesen. Auch der wünschende Angestellte weiß nicht wirklich, ob es stimmt, dass es seinen Resultaten hilft, wenn er nur seinen Wunsch erfüllt bekommt. Deshalb sollte die Wunscherfüllung zunächst als Experiment gesehen werden.

Auch hier gilt “Individuals and interactions over processes and tools” und “Responding to change over following a plan” und “Working software over comprehensive [rule set]” und “[…] collaboration over contract [adherence]”. Die Iterationen der Agilität helfen überall. Eine lernende Organisation gibt es nicht ohne Experimente. Die sollten nicht nur am Markt stattfinden, sondern eben auch intern. Viel mehr intern. Denn dort ist viel Potenzial für Kreativität, Motivation, gar Innovation hinter Mauern aus Regeln angestaut.

Wenn es also im Unternehmen im Allgemeinen bzw. in der Softwareentwicklung im Speziellen nicht läuft, wie es laufen sollte, wenn es knirscht in der Zusammenarbeit, wenn die Unzuverlässigkeit grassiert… dann, so glaube ich, ist eine wesentliche Stellschraube die Autonomie jedes einzelnen Beteiligten. Mehr und mehr Freiheitsgrade helfen. Nicht nur für sauberen Code gilt also: Raus aus den Abhängigkeiten! ;-)

 

PS: Dass Autonomie kein Garant für Erfolg ist, ist selbstverständlich. Sie ist keine hinreichende Voraussetzung. Aber ich halte sie für eine notwendige. Ohne Autonomie, ohne Augenhöhe, ohne Selbstbestimmung und damit einhergehend auch Selbstverantwortung keine wirklich dauerhaft guten Resultate. Autonomie ist insofern im eigenen Interesse jedes Unternehmens.

PPS: Zur gewährten Freiheit muss auf der anderen Seite natürlich auch Fähigkeit treten, damit umzugehen. Die mag nicht bei jedem “Befreiten” in gleichem Maße vorhanden sein. Aber wer seine Aufgaben als Manager schwinden sieht, bekommt hier ein bedenkenswertes neues Betätigungsfeld: die Förderung von echten Mit-Arbeitern. Die Frage bleibt nämlich: “Was brauchst du?” Dieses mal jedoch Bezogen auf die Autonomie: “Was brauchst du, um mit der neu gewonnenen Autonomie zum Nutzen der Resultate am besten umzugehen?”

PPS: Und wer nicht glaubt, dass man mit mehr Autonomie und Augenhöhe Erfolg haben kann, der schaue mal diesen Film: http://vimeo.com/118219210

AUGENHÖHE OmU (dt.) from Daniel Trebien on Vimeo.

Die meisten, die darin zu Wort kommen, sind zwar formal noch “abhängig beschäftigt”, doch ihre Berichte machen deutlich, dass auch in Angestelltenverhältnissen Autonomie und echte Mit-Arbeit möglich ist. Und das ist nur der Anfang.

Die Frage ist daher nicht, ob mehr Autonomie in Ihrem Unternehmen sein sollte, sondern wann das der Fall ist und unter wie großen Schmerzen es dazu kommen wird. Meine Empfehlung: Lieber bald mit der “Entkopplung” beginnen, um mehr Zeit zum Lernen und Anpassen zu haben.

Die Selbstlern-Challenge - Mitmachen und gewinnen!

500€ gibt es zu gewinnen. Ingesamt jedenfalls. Die bin ich bereit, als “Preisgeld” auszusetzen für diejenigen, die erfolgreich mitmachen.

Die Herausforderung

Ich suche 10 Freiwillige, die bereit sind, 10 Wochen lang sich im Selbststudium mit Flow Design auseinanderzusetzen. Das habe ich in einigen Büchern und vielen Blog-Artikeln ausführlich beschrieben. Dazu gehören Themen wie:

• Radikale Objektorientierung / OOP as if you meant it
• Agile Architektur / Die Anforderung-Logik-Lücke
• Softwarezellen

Über die 10 Wochen ist nicht viel zu leisten. Es gibt nur drei Bedingungen:

1. Wer teilnimmt, stellt mir jede Woche mindestens eine ernstgemeinte und nicht triviale Frage zu den obigen Themen. Diese Frage soll als minimale Dokumentation der kontinuierlichen und fortschreitenden Auseinandersetzung mit dem Stoff dienen. “Fragen auf Vorrat” sind nicht erlaubt, ebensowenig “aufholende Fragen”, die eine Woche ohne Frage kompensieren sollen.
2. Wer teilnimmt, reagiert auf Emails von mir zum Lernstoff innerhalb von max. 24h. Dies dient der Sicherung einer verlässlichen, flüssigen Kommunikation zur Beförderung des Lernens.
3. Wer teilnimmt, stimmt zu, dass sein/ihr Name veröffentlicht wird. Außerdem behalte ich mir vor, die Abschnitte zum Lernstoff aus der sich ergebenden Email-Konversation zu veröffentlichen.

Das ist alles. Es gibt keine Prüfung, es gibt überhaupt nichts, das am Ende abzuliefern wäre. Der Weg ist das Ziel :-)

Dieses Angebot gilt vom 27.1.2015 bis zum 17.5.2015 (oder anders: ab 5. KW bis inklusive 20. KW 2015). In der Zeit muss die 10-Wochen-Teilnahme abgeschlossen sein.

Update: Seit 28.1.2015 sind alle Teilnehmerplätze vergeben!

Die Teilnahme

Wer teilnehmen möchte, schreibt mir einfach eine Email. Dann beginnen die 10 Wochen zu laufen. Ich stelle daraufhin Lernmaterialien in Form von Links und Büchern zur Verfügung. Teilnehmer müssen also keinen Cent ausgeben.

Auf Wunsch stelle ich auch Aufgaben, an denen sich Teilnehmer versuchen können.

Der Gewinn

Der Gewinn der Teilnahme besteht natürlich vor allem in Wissens- und Erfahrungszuwachs. Darüber hinaus erhält aber auch jeder erfolgreiche Teilnehmer am Ende noch einen Amazon-Gutschein in Höhe von 50€.

Erfolgreich ist, wer die obigen Bedinungen erfüllt. Mehr ist nicht nötig, weniger allerdings auch nicht.

Die Hypothese

Mit dieser Herausforderung möchte ich eine Hypothese überprüfen, die ich zum autodidaktischen Lernen habe. Welche das ist, kann ich vorher nicht verraten. Damit würde ich die Durchführung des Experiments beeinflussen. Aber ich verspreche, dass ich am Ende der Herausforderung darüber berichte.

 

Und nun: Lasst das Selbstlernen beginnen!