Cost of Delay (III)

Nochmal zum Thema Cost of Delay, also zu den Verzögerungskosten, die auftreten, wenn ein Produkt oder Feature zu langsam fertig wird. Diese Kosten werden gemessen in (ungefähren) Geldbeträgen, die verpassten oder verzögerten Gewinnen entsprechen. Auf den ersten Blick erscheint das Zwangsläufig und nicht weiter erwähnenswert, bei näherer Betrachtung ist darin aber eine eigentlich offensichtliche Implikationen enthalten, die aber manchmal vergessen wird.

Um Verspätungskosten finanziell messen oder schätzen zu können, ist etwas ganz Grundlegendes nötig: ein Business Case des Produkts oder Features nämlich, für das diese Kosten ermittelt werden sollen. Das ist in vielen Fällen auch gut möglich, etwa bei neuen Autos oder Computerspielen, bei neuen Funktionen komplexer und abstrakter Produkten wie z.B. Betriebssystemen oder Online-Portalen ist es dagegen deutlich schwieriger und ggf. sogar unmöglich.

Noch am Einfachsten ist es in Fällen, in denen diese Funktionen kostenpflichtig gekauft oder abonniert werden können. In derartigen Konstellationen lassen sich nach Fertigstellung die Gewinne rückwirkend auf die "verpassten" Monate übertragen, oder alternativ kann bereits während der Planung von einem voraussichtlichen Gewinn ausgegangen werden, dessen drohendes Verpassen ggf. kurzfristige Mehraufwände rechtfertigen kann.

Schwieriger wird es, wenn neu erstellte Features nicht separat monetarisierbar sind. Ein Umweg den man hier gehen kann, ist der über die Marktforschung: wenn eine Neuerung ein Differenzierungsmerkmal ist (oder ein Differenzierungsmerkmal eines Wettbewerbers egalisiert) kann man annehmen, dass Umsätze (und damit Gewinne) ganz oder teilweise auf sie zurückzuführen sind, was sich dann annäherungsweise in Geld quantifizieren lässt.

Praktisch unmöglich wird die Ermittlung von Cost of Delay, wenn die jeweilige Funktionalität weder separat vermarktet wird, noch von Kunden als Differenzierungsmerkmal wahrgenommen wird (oder überhaupt separat wahrgenommen wird). Ein internes Diagnose-Programm wäre ein Beispiel dafür. Natürlich ist es aus Produktsicht sinnvoll und mehrwertstiftend, es ist aber nichts, das man einem Kunden in Rechnung stellen oder ihm gegenüber vermarkten könnte.

Für derartige Funktionen ist eine separate Ermittlung von Verspätungskosten schlicht nicht machbar, was eigentlich auch kein Problem ist - schliesslich müssen sie nicht zwanghaft für jedes Feature gemessen werden. Entweder fallen sie ganz aus derartigen Betrachtungen heraus, oder sie entsprechen der kompletten Verspätungskostensumme des Gesamtprodukts - dann nämlich, wenn dieses ohne die einzelne Funktion nicht verkauft werden kann oder darf.

Der Vollständigkeit halber: Wird in überregulierten Umgebungen versucht, eine kategorische Anwendung dort zu erzwingen, wo das eigentlich nicht geht, ist meistens Cargo Cult die Folge. Dann kann es z.B. sein, dass für Funktionen ohne Business Case einer "nach Bauchgefühl" ermittelt wird, z.B. mit Planning Poker. Diesen Wert kann man dann in die Dokumentation schreiben um den Vorganben gerecht zu werden, es ist aber nicht mehr als Business-Theater, das man auch sein lassen kann.

Modular Monoliths and Other Facepalms

 Eines der folgenschwersten Missverständnisse der Softwareentwicklung ist, dass die Rolle des Architekten eine rein technische ist. Ich glaube, dass es sich um eine zutiefst soziale Rolle handelt, eine bei der man sowohl in der Lage sein muss, komplexe Inhalte an Andere zu vermitteln, als auch zu extrahieren, was Andere meinen, wenn sie bestimmte Schlagworte benutzen. Kevlin Henney gelingt hier beides gleichzeitig.

Was er ausserdem dankenswerterweise herausstreicht ist, dass diese Rolle Geduld und Nachsicht erfordert. Sein André Gide-Zitat bringt es auf den Punkt: "Alles wurde bereits gesagt, aber da niemand zuhört müssen wir es ständig wiederholen." Ein Architekt der dazu nicht bereit ist, wird es schwer haben seinen Job gut auszuüben. Im übrigen eine bemerkenswerte Parallele zu allen Methodiker-Berufen.

Soziotechnische Systeme

Ein kurzer Ausflug auf die Meta-Ebene. Sowohl die Entwicklung von Software als auch die Fertigung von Hardware-Produkten finden im Überschneidungsbereich von zwei Systemen statt: einem sozialen System, bestehend aus den beteiligten Menschen und den zwischen ihnen stattfindenden Interaktionen und einem technischen System, bestehend aus verschiedenen miteinander verbundenen Geräten und IT-Programmen. Beide zusammen bilden dann so genannte Soziotechnische Systeme.

Das soziale (Teil-)System bilden im engeren Sinn alle an der Produkterzeugung beteiligten Menschen, egal ob sie planen, konzipieren, programmieren, montieren, testen, dokumentieren, absichern oder sonstige Tätigkeiten durchführen. Im weiteren Sinn können noch weitere Gruppen dazugehören, etwa Anwender, Auftraggeber oder Regulierer. In beiden Fällen bestehen diese Systeme aber nicht nur aus den beteiligten Menschen, sondern auch aus den sie verbindenden Interaktionen (z.B. der Kommunikation).

Das technische (Teil-)System hat ebenfall zwei Dimensionen: zunächst umfasst es alle Werkzeuge, die von den Angehörigen der sozialen Systeme benutzt werden; im Fall der Software-Programmierung etwa Computer und Build Pipelines, im Fall der Hardware-Fertigung können es Fliessbänder und Stanz-Maschinen sein. Als zweite Dimension kommen Elemente dazu, die die beteiligten Menschen steuern und anleiten, z.B. Ticket-Tools oder akkustische Signale, die auf durchzuführende Tätigkeiten hinweisen.

Aufbauend darauf kann man diskutieren, ob in letzter Konsequenz nicht alle Arbeit in soziotechnischen Systemen stattfindet (selbst in der Manufaktur gibt es Werkzeuge und selbst einen Vollautomaten muss irgendjemand anschalten), es gibt aber Vorgehensweisen, die zwingend soziotechnisch sind - die, bei denen es um hohe Reaktions- oder Liefer-Geschwindigkeit geht (Agile und Lean), wären ohne Automatisierung einfacher Arbeiten und menschliche Eingriffe bei Technikversagen schlicht zu langsam.

Und um auch das noch stärker herauszustreichen: hohe Reaktions- oder Liefer-Geschwindigkeit kann in vielen Fällen bedeuten, dass die Abläufe im Wortsinn rasend schnell werden, etwa dann, wenn in einer Lean-optimierten Fabrik pro Minute hunderte von Nägeln oder Bleistiften erzeugt werden oder neue Software in Sekunden auf tausende Geräte geladen wird. Es kann aber auch bedeuten, dass die Anfertigung einzelner Prototypen "nur noch" Wochen dauert, statt Jahre (siehe hier).

Zu guter Letzt: wenn man sich darauf einlässt, dass nach Agile, Lean oder verwandten Ansätzen arbeitende Organisationen soziotechnische Systeme sind, erledigen sich auch auch schnell die Diskussionen, ob sie aufgrund des technischen Fortschritts nicht obsolet werden. Agiles Arbeiten kann genauso wenig durch Künstliche Intelligenz abgelöst werden wie Lean durch 3D-Druck, denn das sind lediglich technische (Teil-)Systeme. Was dagegen möglich ist, ist diese in Agile und Lean zu integrieren.