Wider den Kompliziertismus!

Die Welt ist ein ungeheuer komplexer Ort.

Alle Dinge interagieren ständig aufgrund physikalischer, chemischer und evolutionärer Gesetze miteinander.
Die Interaktion zwischen Menschen ist mit enormen Komplexitäten behaftet.

Zwischen Menschen aus unterschiedlichen Kulturen, Ländern, Städten, manchmal sogar Stadtteilen und ganz sicher aus unterschiedlichen sozialen Herkünften gibt es enorme Unterschiede.Jeder Mensch ist anders. Jeder Mensch hat zeitabhängige Stimmungen.

Die Systeme, die wir in IT-Projekten bauen, sind manchmal ganz einfach. Als Modelle der physisch-technischen, sozialen oder kulturellen Wirklichkeit aber oft sehr, sehr komplex.

Schon kleinste Abweichungen im Verständnis oder der Definition eines Begriffs können weitreichende Folgen in der Systemmodellierung haben. Beispiel: Die Modellierung der Ehe in einem IT-System: Nur zwischen Mann und Frau? Zwischen gleichgeschlechtlichen Partnern? Jeweils wie vielen Personen welchen Geschlechts? In welchem Mindestalter? Was sind die damit verbundenen Rechtsgüter? Was, wenn die Ehe im Ausland geschlossen wurde, wo andere Regeln gelten? Welchen Einfluss haben gemeinsame voreheliche oder aus früheren Partnerschaften stammende Kinder? Spielt die kirchliche Trauung irgendeine Rolle?

Die Welt ist komplex, keine Frage.

Was ist die angemessene Reaktion darauf?

Einige Menschen blähen ihre Einschätzung jedweder Aufgabe grundsätzlich und systematisch auf. Komplex ist für sie das Gleiche wie kompliziert. Sie vermuten und berücksichtigen vorauseilend schon einmal alle denkbaren (und im Zweifel auch nicht denkbare) technischen, organisatorischen und fachlichen Komplikationen – und schlagen am Ende noch einen Risikoaufschlag drauf.
Wenn ein Satz in einer Anforderung komplizierter oder weniger kompliziert interpretiert werden kann, wählen sie immer die kompliziertere Interpretation. Sie wählen die kompliziertesten Architekturen und Implementierungsmuster, betreiben furchtlos das Aufhäufen technischer Schuld. Aufwands- und Preisabschätzungen treiben sie per Hau-den-Lukas in die Höhe, bis die Glocke klingelt.
Provokant formuliert: Komplexität wird zur Ideologie der Kompliziertheit, zum Kompliziertismus. Alles ist irre kompliziert und kaum beherrschbar, lasst es uns noch komplizierter machen.

Warum macht jemand das? Angst, die Aufgabe zu unterschätzen. Frühere schlechte Erfahrung. Überforderung, durch die ein paar Bäume wie ein großer, dunkler Wald aussehen. Viel Feind, viel Ehr. Geldschinderei gegenüber dem Kunden. Ressourcenschinderei gegenüber dem eigenen Chef. Vorauseilende Begründung für das eigene Versagen (“ich hab ja gleich gesagt, dass das irre komplizert ist”). Aufblähen der eigenen Wichtigkeit und demonstratives Zur-Schau-Stellen kritischen Denkens.

Einfachste oder zumindest in der Regel gut beherrschte Dinge werden so mühelos zu kaum überwindbaren Hürden, zu Sorgen, zu Angstbergen, zu Problemen.

Ich bin sehr erfolgreich mit dem gegenteiligen Ansatz. Ich glaube, dass es die Aufgabe von Projektleitern, Architekten und Beratern ist, die jeweils eleganteste und damit oft einfachste Lösung zu finden.

Ich gehe dabei oft zunächst von der naivstmöglichen Annahme aus. Wie würde die einfachste Lösung aussehen?
Natürlich bleibt die Lösung dann meist nicht so einfach. Ich schaue dann, welche zusätzliche Komplexität ich unbedingt berücksichtigen muss. So wird die Lösung Schritt für Schritt komplexer, aber in einer sehr kontrollierten Weise und nur auf Basis von verifizierten Annahmen.

Jederzeit beachte ich Vereinfachungsmöglichkeiten: Welche Anforderungen sind ähnlich und können generisch behandelt werden? Wo bestehen Anforderungen nur noch aus historischen Gründen, die heute eigentlich keine Bedeutung mehr haben?
Wo kommt die Anforderung überhaupt her? Wenn es niemanden mehr gibt, der weiß, warum es eine Anforderung gibt, ist sie vielleicht obsolet.

Oder als Scum Master/Agile Coach: Muss der Prozess wirklich so aufwändig sein? Muss wirklich eine monatelange Tool-Auswahl gemacht werden oder weiß das Team eh schon, welches der Sieger sein wird? Braucht es eine Earned-Value-Analyse oder reicht ein einfaches Burndown?Braucht es wirklich ein Zehn-Mann-Team oder wird nicht alles viel einfacher, wenn man zwei Fünf-Mann-Teams bildet? Hat das Sprint Commitment für dieses Team wirklich einen Mehrwert oder performt es auch ohne optimal?
Muss wirklich in Story Points geschätzt werden oder reichen Personentage?

Das Ziel: Die ohnehin schon komplexe Welt nicht ohne Not kompliziert machen.

 

Tabu: Probleme anderer Leute

Ich behaupte, dass es einer der größten Problemauslöser in Projekten und tatsächlich auch im sonstigen Leben ist, anderer Leute Probleme zu lösen.
Glauben Sie nicht? Ein paar Beispiele:

Der Kunde stellt in einem Festpreis-Projekt seine Spezifikation zu spät fertig. Das Team beginnt trotzdem schonmal mit der Implementierung, weil die vom Kunden gewünschte Deadline so eng ist. Effekt: Der Abschluss der Spezifikation verzögert sich, weil der Kunde sieht, dass es ja trotzdem vorangeht. Entwickelt das Team etwas, das er gar nicht haben wollte, kann er immer noch sagen: das war gar nicht so spezifiziert. Vielleicht entwickelt das Team auch eine hypergenerische eierlegende Wollmilchsau, um jeder potentiellen Anforderung des Kunden entsprechen zu können – wenn sie denn irgendwann kommt.

Das Projektteam hat versucht, das Problem des Kunden zu lösen, die Spezifikation nicht vor Projektbeginn fertigzustellen.

Der Freiberufler beginnt mit der Arbeit, obwohl er noch keinen Vertrag hat (“Vertrag ist irgendwo im Einkauf unterwegs. Machen Sie sich keine Sorgen.”). Effekt: Der Vertragsabschluss zieht sich, und die Verhandlungsposition der Freiberuflers über die Bedingungen des Auftrags wird schwächer und schwächer. Im Extremfall heißt es dann am Ende: “Ihre Rechnung zahle ich nicht, wir hatten doch noch gar keinen Vertrag!” Der Freiberufler muss vor Gericht ziehen und wird ggf. nur ein “marktübliches” Honorar aufgrund der offensichtlich erbrachten und vom Auftraggeber nicht gestoppten Leistung nachfordern können, das deutlich unter dem angestrebten liegt.

Der Freiberufler hat das Problem des Auftraggeber zu lösen versucht, die eigenen Prozesse nicht im Griff zu haben oder die Beauftragung nicht rechtzeitig angestoßen zu haben.

Das andere Teilteam sollte eine Schnittstelle zum Import von Daten liefern. Sie wird nicht rechtzeitig fertig. Das konsumierende Teilteam programmiert also erstmal gegen einen Mock. Die Schnittstelle ist immer noch nicht fertig. Das Team programmiert die Schnittstelle heroisch selbst, erreicht dafür aber nicht die eigenen Ziele.

Die gelieferte Datenqualität ist grauenvoll. Weil der Zulieferer der Daten so schwer greifbar ist, entwickelt das Team über Wochen einen Bereinigungsalgorithmus und hochflexible Darstellungsmechanismen.

Ein Team-Mitglied performt einfach nicht, aus welchen Gründen auch immer. Die restlichen Team-Mitglieder wollen keine Kollegenschweine sein, decken den Minderleister und arbeiten selbst eine Stunde mehr am Tag, erst über Tage, dann Wochen, dann Monate.

Die Deadline für das neue Projekt ist viel zu eng gesetzt, das Verkaufsteam sagt dem Auftraggeber trotzdem zu, die Entwickler beginnen einen “Todesmarsch” mit zehn Stunden Arbeit täglich und Wochenendarbeit, oft in dem Wissen, dass die Aufgabe dennoch nicht zu schaffen ist.

Das Management schafft es einfach nicht, auch nur grundlegende Vorgaben zur Arbeitsweise, Qualitätsanforderungen und Zielen der Software-Entwicklung zu machen. Die Teams organisieren selbständig Workshops und Seminare, um das Führungsdefizit auszugleichen. Effekt: Ein Glaubenskrieg zwischen den Teams und am Ende innerhalb der Teams geht los, ob Scrum oder Kanban, Merging oder Baselining, sind Senior-Software-Ingenieure mehr verantwortlich für ein Team-Ergebnis als “normale” Ingenieure, Cloud oder nicht… und viel Zeit und Motivation gehen verloren.

Das Management lässt die Teams in hallende Großraumbüros mit zu wenig Besprechungsräumen ziehen. Niemand kommt mehr in den Flow, die Arbeitsleistung sinkt um 50-75%. Die Entwickler behelfen sich mit Noise-Cancelling-Kopfhörern oder kommen besonders früh oder bleiben besonders spät, weil es da ruhiger ist. In den regulären Arbeitszeiten wird entweder kaum noch miteinander gesprochen, weil es ja alle stört, oder es schert sich niemand mehr um den Krach, denn es erwartet ja eh niemand mehr hohe Leistungen.

Der Abteilungsleiter trifft einfach keine Entscheidungen. Die Mitarbeiter entwickeln telephatische Kräfte um herauszufinden, was der Chef denn wohl wollen können würde und arbeiten unter Annahmen. Der Chef staucht die Mitarbeiter im Problemfall zusammen (“Das habe ich nie so entschieden!”) und streicht im Erfolgsfall die Lorbeeren ein.

Fallen Ihnen mehr Beispiele ein?

Mein Tipp: Lösen Sie nicht anderer Leute Probleme bzw. nehmen sie nicht anderen ihre Verantwortung ab. Weisen Sie den Verantwortlichen auf sein Problem hin und bieten sie die Hilfe an, die Sie im Rahmen Ihrer Fähigkeiten, Möglichkeiten und der eigenen Verantwortung leisten können.

 

Binsenweisheiten und Ewige Wahrheiten (Teil 1)

Zu meinem Posting “Binsenweisheiten – It’s simple, but not easy!” kam mir der Gedanke, dass es interessant wäre, reale oder vermeintliche Binsenweisheiten einmal aufzulisten, weitere von den Lesern dieses Blogs zu sammeln und zu diskutieren, wie “binsig” oder “ewig” sie denn nun wirklich sind.

Hier ist also meine absichtlich provokativ unvollständige Liste. Ich bitte um Ergänzungsvorschläge im Kommentarbereich:

  1. Die Geschwindigkeit eines geeigneten Teamaufbaus hängt mindestens von der Verfügbarkeit von Mitarbeitern der benötigten Qualifikation, der Verfügbarkeit von Arbeitsmitteln und der Parallelisierbarkeit der Aufgaben ab.
  2. Verantwortung ist nicht teilbar – entweder man ist ganz verantwortlich oder nicht verantwortlich (siehe “Über Verantwortung (Teil 1)“).
  3. Die Behebung eines spät gefundenen Software-Bugs kostet exponentiell mehr, als die eines früh gefundenen.
  4. Menschen arbeiten nicht schneller, wenn sie Angst haben.
  5. Änderungen gerade in Entwicklung befindlicher Anforderungen kosten zusätzliches Geld, manchmal viel Geld.
  6. Auch externe Berater sind Menschen mit Menschenwürde, Bedürfnissen, Privatleben, Stärken und Schwächen.
  7. Einem verspäteten Projekt mehr Mitarbeiter hinzuzufügen, macht es noch später.
  8. Nur was Du misst, kannst Du steuern.
  9. Umsatz ist nicht Gewinn.
  10. Wenn die Entwicklung eines Features mehr kostet als es einbringt, sollte man es nicht entwickeln.

Fallen Ihnen weitere ein? Widersprechen Sie einer der obigen vermeintlichen Binsenweisheiten? Was ist Ihre Erfahrung mit dem eigenen Befolgen solcher Grundregeln?