Im Jahr 1880 wurde die erste Betonbrücke in Deutschland auf der Kunst- und Gewerbeausstellung in Düsseldorf präsentiert. Beton als Baustoff hatte seinen unaufhaltbaren Siegeszug begonnen. Das ist 140 Jahre her. Eine lange Zeit, wenn man auf die rasanten Entwicklungen in unserer Gegenwart blickt. Eine Zeit, in der Bauingenieure, Statiker und Architekten sehr viel Erfahrungen im Umgang mit Beton machten, lernten und Bauwerke schafften, die die Gesetze der Schwerkraft aufzuheben scheinen. 

Im März 2015 wurde der lange überfällige Abriss und Neubau einer Betonbrücke in Lübeck in Angriff genommen. Als Umsetzungszeitraum wurden zwei Jahre angesetzt. Das Projekt darf ohne Untertreibung als "business as usual" bezeichnet werden. Keine Schnörkel, keine Weltrekorde, keine Experimente. Ein Projekt also, dass reibungslos verlaufen sollte. Eigentlich.

Freigegeben für den Verkehr wurde die Brücke in Lübeck letztendlich am 30.10.2019, also mit einer Verzögerung gegenüber dem ursprünglichen Plan von 2 1/2 Jahren. Auch die Projektkosten waren erheblich höher als initial geschätzt.

Ist das nicht verwunderlich, bei einem Gewerk, das auf über mehr als hundert Jahre Erfahrung zurückgreifen kann? Warum ist es so schwer, selbst in so einem Fall einen Plan aufzustellen, der mehr oder weniger 1:1 umgesetzt werden kann? 

Eine Brücke ist in der Regel ein Unikat. Mir sind keine zwei Straßenbrücken bekannt, die identisch sind. Selbst wenn sie es wären, die Umgebungen, in denen sie gebaut werden, sind andere. Damit gibt es technische und logistische Herausforderungen, die bei jedem Bau andere sind. In Lübeck war dies zum einen der sandige und sumpfige Grund, der die Gründung der Brücke erschwert hat, zum anderen war die Brücke Teil einer zentralen Verkehrsader Lübecks. Daraus leitete sich der Wunsch des Auftragsgebers ab, bereits während der Bauzeit einen einspurigen Verkehr zu ermöglichen. Und dann waren da noch etliche kleine und große Nicklichkeiten in der Zusammenarbeit zwischen Bauherr und Auftragnehmer.

Die Komplexität eines Projekts ergibt sich nicht allein aus der Komplexität der Materie, sondern auch und gerade durch die Komplexität der Umgebung. Genügend Ansatzpunkte, damit etwas anders kommt als gedacht. Insbesondere wenn man diese Punkte nicht im Blick hat. Das ist ein wesentlicher Unterschied zwischen erfolgreichen Bauprojekten und weniger erfolgreichen. Die situative Reaktion eines Bauteams auf unerwartete Wendungen, die Kooperation aller Beteiligten, der Wille, für ein Ziel auch mal einen Plan aufzugeben, ist für den Erfolg eines einmaligen Bauprojekts auch nach tausenden Jahren Baugeschichte immer noch wichtiger als alles andere. 

Wenn dies also bei Ingenieursaktivitäten gilt, die untrennbar mit der Geschichte der Zivilisation der Menscheit verbunden sind, um wieviel mehr gilt dies bei Softwareprojekten, die es gerade einmal seit gut 80 Jahren gibt. Und moderne Software hat erheblich mehr Ähnlichkeit mit den einzigartigen Brückenbauten auf dieser Welt als mit den Bauprojekten von Viebrock und anderen Anbietern von Eigenheimen. Dazu schreibe ich vielleicht einen zweiten Baublog.

Erstaunlicherweise ist dies kein Allgemeinplatz. Auch im Jahr 2020 wird von Softwareprojekten erwartet, dass Pläne gemacht und umgesetzt werden, Budgets eingehalten, Zeitvorgaben erreicht werden. Ein Verständnis für die Unwägbarkeiten der modernen Softwareentwicklung fehlt zuweilen völlig. Hinzukommt, dass die Möglichkeiten, die wir als Softwareentwickler haben, mit jedem Jahrzehnt exponentiell gewachsen sind. Wer glaubt, aus dem Erfolg eines Projekts aus dem letzten Jahrzehnt auf den unumgänglichen Erfolg eines neuen Projekt setzen zu können, der wird sehr oft mit Enttäuschung umgehen lernen müssen. Und dann kommt neuerdings hinzu, dass alles mit allem verbunden ist oder sein soll.

Von erfolgreichen Betonbauern könnten wir lernen, dass Agilität und gute, kooperative Zusammenarbeit zwischen Auftraggeber und Auftragnehmer keine Mittel sind, um initiale Pläne umzusetzen, sondern die Schlüssel, um mit den ganzen Unbekannten auf eine Weise umzugehen, die im Sinne der Kunden und des Geschäfts ist. 

Dieses Zitat des englischen Mathematikers George E.P. Box kam mir kürzlich in den Sinn als ich mich mit einem der Prinzipien der agilen Software-Entwicklung auseinandersetzte: Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

Bis zu dem Tage hatte ich mir nicht allzu viele Gedanken über das Wort selbstorganisiert gemacht. Es besagte für mich bis dato im Großen und Ganzen, dass die Ergebnisse eines Entwicklungsprozesses im wesentlichen von dem Team bestimmt werden, das an der Entwicklung beteiligt ist und nicht in Form von Vorschriften, Anweisungen oder gar Befehlen festgelegt sind. 

Scott Ambler hat dieses Prinzip das radikalste der hinter dem Agilen Manifest stehenden Prinzipien genannt. Das hätte mir zu denken geben können. 

Die Unterzeichner des Agilen Manifests beziehen sich auf Ideen aus der Systemtheorie. Diese beschreiben, wie sich bestimmte Systeme entwickeln. Dort bezeichnet Selbstorganisation die Fähigkeit eines Systems, sich aus sich selbst heraus zu organisieren, ohne dass erkennbare äußere steuernde Elemente vorliegen. Das hatte ich nicht verstanden.

Interessant sind die offenen Systeme. Diese stehen mit ihrer Umgebung in Wechselwirkung und ständigem Austausch. Wenn man von selbstorganisierten Teams innerhalb eines Unternehmens redet, dann redet man implizit über ein offenes System. Es ergibt sich die Frage, woran man ein selbstorganisiertes Team erkennen kann. Und man stellt automatisch die Führungsfrage. Wenn es keine erkennbaren äußeren steuernden Elemente gibt, wie sieht dann Führung aus?

Auf der QCon 2009 hat Joseph Pelrine dies anhand zweier Modelle versucht zu verdeutlichen: zuerst hat er Forschungsergebnisse zu einer Schleimpilzart präsentiert, die in der Lage ist, in einem Labyrinth den kürzesten Weg zu einer Nahrungsquelle zu finden (Nature 407, 470 / 28 September 2000). Danach erläuterte er anhand von Hühnersuppe, dass nur die richtige Menge an zugeführter Energie für den Kocherfolg entscheidend ist.

Ich halte beide Modelle für falsch. Die Umgebung eines selbstorganisierten Teams wird anders als das Labyrinth durch das Team beeinflusst und verändert. Und die Zutaten einer Hühnersuppe sind keine Agenten innerhalb eines Systems. Sie haben keine Wahlmöglichkeit bezüglich ihrer Reaktion auf die zugeführte Energie.

Beide Modelle waren nützlich. Ihre Vereinfachungen haben mich dazu veranlasst, meine bisherige Position zu diesem agilen Prinzip kritisch zu hinterfragen und zu verändern.

Insbesondere verstehe ich nun, warum das 1970 von Robert Greenleaf veröffentlichte Modell der dienenden Führung (servant leadership) in diesem Zusammenhang so hip geworden ist. Scheint es doch den inhärenten Widerspruch selbstorganisierter Teams in Unternehmen mit hierarchischen Strukturen aufzulösen.