Viele IT-Manager glauben, mit genug Planung ließen sich Liefertermine einhalten.
In der Realität sind Lieferzusagen reines Glücksspiel. Und das ist keine Übertreibung:
Die Autoren der Arbeit „Why Your IT Project May Be Riskier than You Think“ betonen, dass das Hauptproblem bei IT-Projekten nicht die durchschnittliche Kostenüberschreitung ist (diese liegt laut Studie bei etwa 27 %). Sondern dass jedes sechste IT-Projekt (17 %) völlig außer Kontrolle gerät. Und im Schnitt eine Kostenüberschreitung von 200 % und eine Zeitüberschreitung von fast 70 % hat.
Und das ist nur eine Quelle von vielen: Laut der Standish Group und deren jährlichem CHAOS Report 2020 enden 66 % aller Technologieprojekte, basierend auf der Analyse von 50 000 Projekten weltweit, mit einem teilweisen oder vollständigen Misserfolg.
Die spannende Frage ist also nicht, ob Lieferzusagen scheitern.
Sondern, warum sie immer wieder scheitern – selbst in erfahrenen IT-Organisationen. Die folgenden fünf Wahrheiten zeigen, dass das kein individuelles Versagen ist, sondern ein systematisches Problem.
Wahrheit #1: Softwareentwickler verschätzen sich – immer!
Wie lautet das ungeschriebene Gesetz in der Softwareentwicklung?
Alles kostet doppelt so viel und braucht doppelt so lange.
Wer bereits einige Jahre in der IT verbracht hat, erkennt es bestimmt wieder. Aber was steckt wirklich dahinter?
Die Ursache dieses Problems liegt in der Psychologie des Menschen.
Die Psychologen Lovallo und Kahneman haben diesen systematischen Fehler erforscht. Im Jahr 2003 veröffentlichten sie ihre Erkenntnisse und beschrieben diesen Fehler als Planungsfehlschluss. Dieser beschreibt die Tendenz, die Zeit, Kosten und Risiken künftiger Handlungen zu unterschätzen. Konkret auf die Situation von Softwareprojekten übertragen bedeutet das, dass IT-Teams dazu neigen, den Zeitaufwand zu unterschätzen, die Kapazität des Teams zu überschätzen, Risiken zu ignorieren und tendenziell immer nur „Best-Case-Szenarien“ zu betrachten.
Wann ist der Planungsfehlschluss besonders ausgeprägt?
Nach über 10 Jahren in Softwareteams würde ich sagen: Immer dann, wenn wir Entwickler bitten, die Arbeit in Tagen oder Stunden zu schätzen, ist das Ergebnis ungenau. Ich denke zwar, dass sich dieser systematische Fehler etwas vermindern ließe, wenn Teams mit Planning-Poker oder Magic Estimation relativ die Aufwände schätzen würden. Aber am Ende ist das leider nur „Ergebniskosmetik“.
Solange Menschen schätzen müssen, werden Termine dem Wunschdenken entspringen.
Wahrheit #2: IT-Teams schätzen zum denkbar ungünstigsten Zeitpunkt.
Wann brauchen wir „belastbare“ Schätzungen am dringendsten?
Zum Projektstart, um das Projektende abschätzen zu können. Oder noch besser: noch vor dem Projektstart, bei der Beauftragung, um die benötigten Kapazitäten einschätzen zu können. Oder noch wichtiger: vor der Beauftragung, bei der Angebotsabgabe, um die Kosten für die Entwicklung abschätzen zu können.
Dieser Drang ignoriert nur eines:
Zu Projektstart ist am wenigsten bekannt. Und sofern Teams das Projekt nicht bereits 1:1 vorher umgesetzt haben, sollten wir die Wahrheit nicht auf die leichte Schulter nehmen. Das zu ignorieren kostet Unternehmen viel Geld. Steve McConnell, der Autor von „Software Estimation“, beziffert die Kosten mit dem Vierfachen. Oder anders ausgedrückt:
Der Aufwand kann die ursprüngliche Schätzung um das Vierfache übersteigen.
In meinen „Professional Scrum Product Owner“-Schulungen erkläre ich diese Wahrheit immer am „Kegel der Unsicherheit“. Der Kegel prognostiziert mögliche Lieferzeitpunkte in Abhängigkeit von der Teamleistung.
Was wir daraus auch ableiten können: Je weiter etwas in der Zukunft liegt, desto ungenauer wird die Vorhersage.
Wer zu Projektbeginn einen Termin verspricht, verspricht etwas, was er nicht wissen kann.
Wahrheit #3: Warten ist die Haupttätigkeit in IT-Projekten.
Warum braucht Arbeit länger als geschätzt?
Eine Wahrheit haben wir bereits kennengelernt: Die Entwickler haben sich einfach verschätzt. Allerdings gibt es noch einen weiteren Punkt, der aus meiner Sicht noch gravierender ist. Nach der Autorin Dominica DeGrandis von „Making Work Visible“ ist es so: Während IT-Projektleiter oft auf die Auslastung der Entwickler achten, übersehen sie, dass die Arbeit nur herumliegt.
„Es ist nicht ungewöhnlich, dass Wartezeiten mehr als 80 % der gesamten Durchlaufzeit ausmachen. Viele Organisationen sind für das Problem der Warteschlangen blind. Sie konzentrieren sich eher auf die Auslastung einzelner Ressourcen.“
Tickets befinden sich in Warteschlangen für Reviews, Freigaben oder für die Zuarbeit anderer Teams.
Wenn 80 % der Zeit aus Warten bestehen, schätzen wir nur 20 % der Realität. Dann sollten wir uns auch nicht wundern, dass wir um den Faktor 5 danebenliegen.
Wahrheit #4: Die Unternehmensstruktur ist dein größtes technisches Risiko.
Noch einmal zurück zum Schätzen. Was haben alle agilen Schätzmethoden gemeinsam?
Sie beruhen auf dem Prinzip des Vergleichs. Anstatt Arbeit einer festen Zeit zuzuordnen, vergleichen wir Arbeit in ihrem Aufwand. Nur dabei übersehen wir immer:
Der Aufwand hängt doch vom Team ab.
Soll heißen: Ändert sich die Zusammensetzung des Teams, ändert sich auch die Schätzung. Das Positive daran: Halten wir Teams stabil, kann das die Güte von Schätzungen verbessern. Deshalb gibt es in Scrum feste Teams. Der Zweck ist, die Vorhersagen zu verbessern.
Aber damit nicht genug.
Im Jahr 1968 veröffentlichte der Informatiker Melvin Conway eine Beobachtung. Sie wurde später als Conways Gesetz bekannt. Er stellte fest, dass Organisationen, die Systeme entwerfen, dazu gezwungen sind, Designs zu produzieren, die ihre eigenen Kommunikationsstrukturen widerspiegeln.
Nochmals in einfacher Sprache:
Die Architektur dessen, was du entwickelst, spiegelt wider, wie deine Organisation intern miteinander spricht. Wenn Teams in Silos arbeiten, entstehen auch Silos in den Systemen. Wenn Kommunikationswege indirekt sind, werden Produkte eng gekoppelt und fragil. Wenn Verantwortlichkeiten verstreut sind, bleibt auch die Rechenschaftspflicht unklar, sowohl im Organigramm als auch im Code.
Feste Teams haben also nicht nur eine Auswirkung auf die Güte der Schätzung, sondern auch auf die Qualität der Software. Und wenn wir Teams ständig neu zusammenwürfeln, zerstören wir die einzige Datenbasis, die eine halbwegs solide Vorhersage ermöglichen würde.
Wahrheit #5: Technische Schulden und unfertige Arbeit torpedieren jeden Fortschritt.
Bei Schätzung oder Prognose von Lieferterminen gehen wir stillschweigend davon aus, dass wir auf ein sauberes Fundament aufsetzen.
Aber mal Hand aufs Herz – in Wirklichkeit kämpft jedes Team mit:
- Altlasten,
- Workarounds,
- ungeklärten Bugs und
- angefangener, nie beendeter Arbeit.
Diese unsichtbare Arbeit taucht in keinem Planning-Poker, in keinem Projektplan und mit Sicherheit in keinem Angebot auf. Und sie wächst unkontrollierbar. Lass es mich dir an einem einfachen Beispiel erklären: Integrationstests.
Angenommen, das Team entschließt sich, die Integrationstests später nachzuentwickeln und erst mal nur die Features fertigzustellen.
1 Feature = 0 Tests
2 Features = 2 Tests
3 Features = 6 Tests
4 Features = ???
Du siehst, wo das hinführt, oder?
Ungetane Arbeit – wie nicht erstellte Integrationstests – wächst nicht linear an, sondern exponentiell. Und wir Menschen können uns exponentielles Verhalten nur schwer vorstellen, deshalb können wir es auch nicht schätzen.
In meinen „Professional Scrum Product Owner“-Schulungen visualisiere ich dieses Verhalten mit dieser Grafik. Die erklärt gut, warum unsichtbare Restarbeiten schnell dazu führen, dass wir „nie“ fertig werden oder irgendwann auf Qualität verzichten müssen, um fertig zu werden.
Technische Schulden sind wie Zinsen. Übersieh dabei den Zinseszins nicht.
Mein Fazit:
Verlässliche IT-Lieferzusagen sind eine Illusion.
Sie scheitern nicht an schlechter Planung, ungenauen Schätzungen oder inkompetenten Teams, sondern weil wir Psychologie, Wartezeiten und technische Realitäten ignorieren.
Die unbequeme Wahrh