On Lean and Agility

Es ist gerade wieder die Zeit des Jahres, in der ich mich über den Umgang mit der staatlichen Bürokratie freuen kann, denn die Verlängerung der Arbeitnehmerüberlassungs-Lizenz steht an. Was das ist und warum es Unternehmensberatungen wie meiner aufgezwungen wird wäre nochmal ein eigenes Thema, was mir bei der Durchführung jedesmal ins Auge springt ist aber, dass es sich um ein extremes Beispiel von Conway's Law handelt.

Unter diesem Gesetz versteht man das immer wieder anzutreffende Muster, dass Organisationen ihre Software spiegelbildlich zu ihren Organisationsstrukturen oder Kommunikationsflüssen aufbauen. Mit anderen Worten: zu jeder Teilorganisation gehört auch ein spezifischer Teil der Gesamt-Software, und da jede Teilorganisation ihren Softwareteil vor allem für sich selbst optimiert, wird die Benutzererfahrung uneinheitlich und dadurch kompliziert und verwirrend.

Bei der Arbeitnehmerüberlassungslizenzverlängerung kann man das in Reinform beobachten. Man beginnt auf einer Seite der Bundesagentur für Arbeit und wird von dort für das Einloggen zum Behörden-Identifikationsdienst Bund ID weitergeleitet. Auch der leitet aber weiter, und zwar zur deutschen Ausweis-App, bei der der Login endlich stattfindet. Alle drei Dienste (Arbeitsagentur-Seite, Bund ID und Ausweis-App) haben völlig unterschiedliche Aussehen und Abläufe.

Als jemand der sein Geld in der Software-Industrie verdient bekomme ich das zwar jedesmal hin, ob ein normaler Benutzer das auch schaffen würde, habe ich aber immer bezweifelt. Mittlerweile hat sich gezeigt, dass diese Zweifel berechtigt sind. Eine Studie des Vereins NExT, in dem Digitalexperten der öffentlichen Verwaltung zusammengeschlossen sind, zeigt, dass beim Versuch verschiedene "digitale Behördengänge" durchzuführen, bis zu 90 Prozent (!) der Menschen frustriert aufgeben.

Ohne den Begriff Conway's Law zu benutzen, erklären die Verfasser, dass genau das ein Hauptgrund für die hohen Abbruchquoten ist. In ihren Worten: "Die Kernursache ist, dass Digitale Identitäten in Deutschland primär als isolierte, technische Basiskomponenten entwickelt wurden, anstatt sie konsequent Ende-zu-Ende (E2E) aus der Perspektive der Nutzenden in die Verwaltungsservices zu integrieren." Auch eine passende Visualisierung gibt es:

Grafik: NExT - CC BY-NC 4.0

Was aus der Studie noch hervorgeht, ist, dass Conway's Law keineswegs der einzige Frustrationsfaktor ist, es werden also nicht alle Abbrüche ausschliesslich darauf zurückgehen. Da die dadurch bedingten Systembrüche und das Springen zwischen völlig unterschiedlichen Anwendungen als die "Kernursache" identifiziert werden, kann man bei bis zu 90 Prozent Abbrüchen aber davon ausgehen, dass über die Hälfte der Nutzungsversuche den Auswirkungen dieses Gesetzes zum Opfer fallen.

Ich muss gestehen, dass ich diesen Text gerne mit einem optimistischen Ausblick beenden würde, mich aber nicht ganz traue. Auf der einen Seite hört man erfreulich viel Positives über die Arbeit des neuen Digitalministeriums, das sich auch gerade des oben genannten Problems annehmen will, auf der anderen Seite gibt es einen Bericht des Bundesrechnungshofs, der bemängelt, dass ausgerechnet das (noch) nicht geschafft wird. Wir müssen also abwarten, wie sich alles entwickelt.

Eines der zahlreichen "Gesetze" des Projektmanagements ist Kidlin's Law. Es ist nicht völlig klar, woher es stammt (die manchmal zu lesende Zurückführung auf eine angebliche Romanfigur des Schriftstellers James Clavell ist falsch, sie findet sich in keinem seiner Bücher), dafür ist es aber mittlerweile weit verbreitet. Es lautet "If you write a problem down clearly and specifically, you have solved half of it", also "Wenn man ein Problem klar und konkret formuliert, hat man es schon halb gelöst".

Wegen des unklaren Ursprungs ist nicht völlig klar, was genau die ursprüngliche Intention des Verfassers war, aus der Praxis des Projektsmanagements (und hier besonders des Anforderungsmanagements) lässt sich aber eine Erklärung von Kidlin's Law herleiten. Sie baut auf dem erstaunlich häufigen Phänomen auf, dass Menschen sich so stark in die Umsetzung einer Lösung vertiefen können, dass sie das ursprüngliche Problem aus den Augen verlieren.

Klassische Beispiele für dieses Phänomen sind die Feature Requests grosser Lasten- und Pflichtenhefte, in denen oft mit erstaunlichen Detailgrad zu programmierende Workflows, Funktionen oder Formulare definiert werden, ohne das klar ist, wer das braucht, und wozu. In sehr vielen Fällen führt dieses Unwissen dazu, dass am Ende suboptimale oder unnötige Ergebnisse entstehen, deren Erstellung aber nicht unwesentlich Zeit (und damit Geld) kostet.

Ein Ausweg aus diesem Missstand besteht daraus, die ursprüngliche Problem- oder Bedarfs-Beschreibung in die Anforderung aufzunehmen oder mit ihr zu verbinden. Bei ihrer Vorstellung, bei der Erarbeitung der Umsetzung oder Lösung und bei der Vorstellung der Ergebnisse kann dann darauf referenziert werden, was idealerweise dazu führt, dass die suboptimalen oder unnötigen Ideen gar nicht erst erwogen, oder zumindest schnell verworfen werden. 

Findet das statt, sind die stattdessen erzeugten Ergebnisse mit grosser Wahrscheinleichkeit besser auf die Zielgruppe und ihre Bedürfnisse ausgerichtet und auch schneller fertiggestellt (da weniger Aufwand in gut gemeinte, aber unnötige Arbeiten fliesst). Diese Effektivitäts- und Effizienzeffekte sind es, die hinter dem Versprechen von Kidlin's Law stecken, dass eine klare und konkrete Formulierung eines Problems bereits die Hälfte des Lösungsweges beinhaltet.

In der Praxis bildet Kidlin's Law den (ggf impliziten) Hintergrund für viele der üblichen Zielsetzungs- oder Aufgabenstellungs-Formate, etwa für Produktvisionen, Unternehmensmissionen, Job to be done-Statements, User Stories, Big Bets und viele weitere. Sie alle sind Ziel- und Problemformulierungen, die als Ergänzung zu einer Anforderung oder Umsetzungsidee dafür sorgen, dass diese sich nicht versehentlich in eine nicht zielführende Richtung entwickeln.

In der englischen Sprache gibt es die schöne Firur des Razors (Rasiermessers) mit dem ein Vorgehen bezeichnet wird, bei dem man überflüssige oder verwirrende Elemente von einer Überlegung "abrasiert" werden. Das was danach übrigbleibt soll klarer und verständlicher sein als der Ausgangszustand. Der Bekannteste ist vermutlich Occam's Razor ("The simplest explanation is usually the best one."), es gibt aber auch weitere, wie zum Beispiel diesen hier.

Cockburn's Razor ist benannt nach Alistair Cockburn, einem der initialen Unterzeichner des Manifests für agile Softwareentwicklung. Wann genau er entstanden ist lässt sich nicht mehr genau zurückverfolgen, es wird aber vermutlich irgendwann nach Mitte der 90er Jahre gewesen sein, da Cockburn erst ab dieser Zeit einen Bekanntheitsgrad hatte, der es möglich machte, seinen Namen für die Popularisierung von Vorgehensmodellen zu benutzen. Er lautet:

Don't add stept to process until you need them
Delete steps from process as soon as you can
Apply this to every file, every process doc, every CSV Column
If it doesn't serve Ring 0 right now, archive it or delete it

Alistair Cockburn, Cockburn's Razor

Diese Faustregel wirkt auf den ersten Blick eingängig, da sie ein einfacher Weg ist, um sowohl soziale als auch technische Prozesse schlank zu halten, sie ist aber in vielen Organisationen nur schwer umzusetzen. Der Hauptgrund dafür ist der vor allem in grösseren Einheiten stark verbreitete Wunsch, möglichst viel Standardisierung, Vergleichbarkeit und Stabilität zu haben, welcher wiederum auf der Hoffnung beruht, dadurch die Transparenz und Steuerungsfähigkeit zu erhalten.

Selbst wenn es gelingen sollte, diese Quelle ständig nachwachsender Bürokratie zu neutralisieren, bleiben aber ggf. noch Probleme in der individuellen Dimension. Vor allem auf den unteren Ebenen einer Organisation gibt es Menschen, die eine kategorische Ablehnung gegen Prozesse und Meetings jeglicher Art entwickelt haben (siehe hier) und sie darum grundsätzlich alle abrasieren wollen - selbst dann, wenn sie einen sinnvollen Zweck haben. Die müssen überzeugt oder überstimmt werden.

Die Umsetzung von Cockburn's Razor erfordert daher nicht nur ein ständiges Überprüfen und Anpassen, sondern in der Realität auch ein kontinuierliches Informieren, informiert Werden, Überzeugen und Aushandeln. Es ist also keine leichte und eindeutige Lösung, trotzdem aber eine die besser für die Verschlankung und Schlankhaltung von Prozessen geeignet ist als die meisten anderen.

Viel zu häufig werden in Projektmanagement und Organisationsdesign Entscheidungen aufgrund von Bauchgefühl, anekdotischer Evidenz oder unvalidierten Annahmen getroffen. Die Gegenbewegung dazu ist das evidenz- oder empiriebasierte Arbeiten, das entweder auf selbst erhobenen Zahlen oder auf wissenschaftlichen Erkenntnissen beruht. Besonders das Zweite kann aber erneut zu einem Problem werden, denn nicht Alles, was auf den ersten Blick wissenschaftlich erscheint, ist es auch.

Die offensichtlichste Form derartiger unwissenschaftlicher Annahmen sind solche, die oft mit Aussagen wie "es ist allgemein bekannt" begründet werden, bei denen es sich aber eher um Truthinesses handelt, also um Aussagen von eher geringer Richtigkeit, die man aber als so naheliegend empfindet, dass man es für unnötig hält, sie zu überprüfen. "Bei großen und komplexen Aufgaben muss man mehr und detaillierter planen, damit alles funktioniert" wäre ein Beispiel dafür.

Wesentlich schwerer zu erkennen sind Behauptungen, die zwar auf echten wissenschaftlichen Erkenntnissen beruhen, diese aber aus ihrem ursprünglichen Kontext herausreissen, sinnentstellend zitieren oder selektiv verkürzen. Eine flüchtige Recherche kann in solchen Fällen den Eindruck einer soliden wissenschaftlichen Fundierung hervorbringen, ein genaueres Betrachten der Quellen findet nur selten statt. Hier sind einige der häufigsten derartigen Fälle

Der Ringelmann-Effekt

Der Ringelmann-Effekt unterstellt, dass Mitglieder einer Gruppe an gemeinsamen Aufgaben nicht mit ganzer Kraft mitarbeiten, und so versuchen, Arbeit auf ihre Kollegen abzuwälzen (was häufig als Rechtfertigung für Arbeits- und Leistungskontrollen dient). Seinen Ursprung hatte er 1913 in der Forschung zu körperlicher Arbeit in der Landwirtschaft und "bewiesen" wurde er in Tauzieh-Wettbewerben. Eine Übertragbarkeit auf die moderne Arbeitswelt ist hochgradig fraglich.

Die Sieben als ideale Teamgrösse

Die häufig zu hörende Aussage, dass die ideale Grösse eines Teams Sieben Mitglieder wäre, wird meistens mit der Psychologie-Studie The Magical Number Seven, Plus or Minus Two von 1956 belegt. Macht man sich die Mühe diese zu lesen, findet man aber heraus, dass es in ihr um etwas völlig anderes geht - um die Anzahl der Informationsquellen nämlich, deren Input ein Mensch gleichzeitig verarbeiten kann. Daraus eine Teamgrösse abzuleiten ist gewagt (Mensch ≠ Informationsquelle).

Die Dunbar-Zahl

Wenn man so will ist die Dunbar-Zahl die grössere Variante der magischen Sieben, es ist die maximale Anzahl an Menschen, mit denen man soziale Beziehungen unterhalten können soll. Auch hier ist der Ursprung bemerkenswert: es ist die Forschung aus den 90ern an Affen, Naturvölkern und vorindustriellen Gesellschaften, welche die in den letzten 200 Jahren erzielten technischen und sozialen Optimierungen zwischenmenschlicher Kommunikation und Zusammenarbeit weitgehend ausblendet.

Die Tuckman-Phasen

Auch als das Forming–Storming–Norming–Performing-Modell bekannt, geht das Tuckman-Entwicklungsmodell von 1965 davon aus, dass Teams nacheinander die vier genannten Phasen durchlaufen. Der wissenschaftliche Unterbau ist dünn, da es sich nur um eine Meta-Studie von Arbeiten aus verschiedenen, nur schwer miteinander vergleichbaren Fachgebieten handelt. Und: in einer Folge-Studie von 2007 durchliefen nur zwei Prozent (!) von 321 Teams die Tuckman-Phasen.

Man könnte die Liste noch länger machen, bereits jetzt dürfte aber klar sein, wie wenig viele der scheinbar gesichert wissenschaftlichen Erkenntnisse auf die moderne Arbeitswelt übertragbar sind. Bereits durch ein einfaches Querlesen der Originalquellen wird schnell klar, dass deren Forschungs-Gegenstand ein völlig anderer war und er kaum Rückschlüsse auf in Projektmanagement und Organisationsdesign zu beachtende Regelmässigkeiten zulässt.

Das soll übrigens nicht heissen, dass evidenz- oder empiriebasiertes Arbeiten eine schlechte Idee wäre, ganz im Gegenteil. Es heisst aber, dass man die "wissenschaftlichen Erkenntnisse", auf die man sich beruft, zumindest bis zu einem gewissen Grad verstanden haben sollte. Wenn das nicht der Fall ist, ist der Übergang zur Truthiness fliessend.

Die meisten "Gesetze" der Softwareentwicklung oder des Projektmanagement gehen auf Zitate ihrer Urheber zurück (Conway's Law, Hofstadter's Law, Brooks's Law, etc.) und spiegeln daher deren Auffassungen wieder. Ziv's Law, benannt nach Hadar Ziv, Professor der University of California, ist in dieser Hinsicht ein Sonderfall, da es seine ursprünglichen Aussagen verfremdend verkürzt. Bevor wir auf seine eigentliche Form schauen, ist aber hier zunächst die verkürzte:

Software specifications and requirements will never be fully understood

frei nach Hadar Ziv, ca. 1996

Zurückgeführt wird Ziv's Law auf seine im Jahr 1996 zusammen mit Debra J. Richardson veröffentlichte Studie The Uncertainty Principle in Software Engineering. Diese beschäftigte sich trotz ihres Namens allerdings nicht mit der Softwareentwicklung im Allgemeinen, sondern nur mit einem ihrer Teilgebiete: dem Software-Testen. Und in diesem Kontext sollte die Aussage der niemals vollständig verstehbaren Anforderungen und Spezifikationen auch gesehen werden.

Ziv und Richardson legten in ihrer Studie dar, dass sämtliche Anforderungen, und damit auch sämtliche Versuche, durch Tests sicherzustellen, dass sie korrekt umgesetzt wurden, Unsicherheits-fördernden Faktoren unterliegen: die Problembeschreibung muss Umgebungsfaktoren ausblenden um nicht zu ausufernd zu werden, die Lösungsbeschreibung kann nur bekannte mögliche Implikationen enthalten und keine noch unbekannten, und ihre menschlichen Verfasser sind fehlbar und können sich irren.

Bedingt durch diese Faktoren sind praktisch sämtliche Versuche, eine zu erstellende Software zu beschreiben, unvollständig, weshalb sowohl in Bezug auf die Umsetzung als auch in Bezug auf den Test unklar sein muss, ob die zugrunde liegenden Anforderungen wirklich im Sinne ihrer Verfasser verstanden wurden. Diese Unklarheit und ihre Folgen werden bereits auf einer der ersten Seiten von The Uncertainty Principle in Software Engineering adressiert:

Software systems under test include, among others, requirements specications, design representations, source code modules, and the relationships among them. These software artifacts are produced by requirements analysis, architectural design, and coding processes, respectively. Following UPSE [the Uncertainty Principles in Software Engineering], uncertainty permeates those development processes and, consequently, the resulting software artifacts. Plans to test them, therefore, will carry these uncertainties forward

Ziv & Richardson, The Uncertainty Principle in Software Engineering , S.4

Diese Darlegungen wird jeder, der sich schon einmal mit Softwareentwicklung beschäftigt hat, bestätigen können. Ihre grosse Schwäche ist aber, dass sie relativ langatmig und kompliziert formuliert wurden, so dass man sie sich kaum merken kann. Der Versuch, sie auf eine gut zu behaltende Zeile zu verkürzen, ist nachvollziehbar, allerdings kam diese Prägnanz mit einem Preis - der ursprüngliche Bezug zum Software-Test ging verloren, genau wie der Verweis zu den erforschten Unsicherheits-Faktoren.

Die verfälschend verkürzte Version von Ziv's Gesetz, die nur noch besagt, dass Anforderungen und Spezifikationen nie zur Gänze verstanden werden, ist übrigens nicht zwingend unzutreffend. Praxis-Beobachtungen sprechen sogar dafür. Anders als Zivs und Richardsons differenziertere Aussagen ist sie aber nicht mehr durch wissenschaftliche Forschungsergebnisse belegt. Sie ist damit lediglich eine durch anekdotische Evidenz belegte starke Meinung, dessen sollte man sich bewusst sein.

Bild: Wikimedia Commons / David.Monniaux - CC BY-SA 3.0

Von den so genannten "Gesetzen der Softwareentwicklung" oder "Gesetzen des Projektmanagement" gibt es mittlerweile unübersehbar viele, allerdings stehen einzelne deutlich aus dieser Menge heraus. Eines davon ist Brooks's Law, benannt nach seinem Verfasser, dem amerikanischen Informatiker Frederick Brooks¹, der es 1975 im Essay The Mythical Man-Month in seinem gleich benannten Buch zum ersten mal veröffentlichte. Es lautet:

Adding manpower to a late software project makes it later / Das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt sorgt für noch mehr Verspätung

Frederick Brooks, The Mythical Man-Month, S.25

Der Grund dafür, dass Brooks diese Gesetzmässigkeit verfasste war der, dass das übliche Management-Verhalten in Software-Projekten damals genau gegenläufig war.² Tatsächlich erscheint es auf den ersten Blick auch naheliegend - jede einzelne Person kann eine bestimmte Menge Arbeit pro Zeiteinheit erledigen, wenn man also weitere Personen hinzufügt könnte man davon ausgehen, dass in der selben Zeit mehr Arbeit erledigt werden kann. Aber so einfach ist es nicht.

Brooks nannte gleich mehrere Gründe, die dafür sorgen, dass statt einer Beschleunigung eine zusätzliche Verspätung auftritt. Der erste und offensichtlichste: neue Kollegen müssen zuerst eingearbeitet werden um arbeitsfähig zu sein, und das kann in der Regel niemand anderes tun als eine der Personen, die bereits länger mitarbeiten. Für die Dauer der Einarbeitungszeit kann er daher selbst nur eingeschränkt produktiv sein, die Arbeitskapazität nimmt also zunächst ab.

Selbst wenn die Einarbeitung abgeschlossen ist, gehen die verzögernden Effekte aber weiter. Wenn ein Vorhaben ursprünglich für eine geringere Umsetzungsmannschaft ausgelegt war, müssen als nächstes die Umsetzungsplanung und Aufgabenteilung überarbeitet werden, um sicherzustellen, dass synchrone und sequenzielle Abhängigkeiten berücksichtigt werden. Auch das benötigt wieder Arbeitskapazität, die dann bei der Umsetzung fehlt und diese dadurch verzögert.

Nun könnte man davon ausgehen, dass diese Verlangsamungs-Faktoren nur temporär sind. Irgendwann sind Einarbeitung und Umplanung abgeschlossen, und es kann mit erhöhter Geschwindigkeit weitergehen. Aber zum einen ist in den meisten verspäteten Projekten die dafür notwendige Zeit gar nicht gegeben, und zum anderen gibt es noch einen weiteren Faktor, der nicht temporär sondern dauerhaft sind, und der speziell mit den Abläufen der Softwareentwicklung zu tun hat.³

Wenn bei der Entwicklung einer Software neuer Code geschrieben wird, muss dieser danach in den bestehenden integriert werden. Um sicherzustellen, dass dieser danach noch immer funktioniert, sind Tests notwendig, und bei steigender Menge von Code schreibenden Entwicklern steigen auch Frequenz und Umfang der durchzuführenden Tests. Aufgrund dessen wird ein immer grösser werdender Teil der Arbeitskapazität dafür benötigt, die Tests aktuell zu halten, durchzuführen und auszuwerten.

Selbst wenn Softwareentwicklung heute etwas anders funktioniert als zu Brooks Zeit (sein Gesetz ist mittlerweile schon über 50 Jahre alt) haben sich die von ihm beschriebenen grundlegenden Zusammenhänge bis heute erhalten. Man kann daher noch immer davon ausgehen, dass das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt nicht für eine Beschleunigung sorgt, sondern für noch mehr Verspätung, und das nicht nur kurzfristig, sondern dauerhaft.