Wie ihr aufhört, Geld an Software-Schätzungen zu verschwenden

Wenn ihr das hier lest, gehört ihr mit hoher Wahrscheinlichkeit zu einer dieser beiden Gruppen:

Unternehmer oder Führungskraft, frustriert davon, dass Teams den Aufwand regelmäßig unterschätzen.
Angestellte, die ebenso betroffen wie frustriert davon sind, dass eure Vorgesetzten auf Schätzungen bestehen und sie dann anfechten, weil sie ihnen zu groß erscheinen.

Egal in welchem Lager ihr steht, ihr seid damit keineswegs allein und euer Frust ist berechtigt. Aus eigener Erfahrung würde ich behaupten, dass die meisten Unternehmen damit zu kämpfen haben, und bisher habe ich kein einziges gesehen, das dieses Thema zu einem Nicht-Problem gemacht hätte.

Noch frustrierender ist, dass die meisten Lösungsversuche das Problem nur verstärken, indem sie zusätzliche Zeremonie und Verbindlichkeit zu einer Tätigkeit hinzufügen, die von Anfang an im Grunde Verschwendung ist. Sezieren wir ein paar der häufigen Probleme, um zu zeigen, warum das so ist.

”Ich bin nicht erfahren genug, um gut zu schätzen”

Als Junior/Mid habe ich es gefürchtet, Schätzungen abzugeben, weil ich rückblickend das Gefühl hatte, sie ohnehin nicht einhalten zu können, egal was ich tat.

Gleichzeitig hielt ich auch an den folgenden Überzeugungen fest:

Mit mehr Erfahrung werde ich besser darin, sodass ich es als Senior mit Sicherheit und guter Genauigkeit hinbekomme.
Mit der Zeit wird es einfacher.
Es gibt bestimmt Unternehmen, die das geknackt haben und es richtig machen.
Wenn ich mehr Dinge berücksichtige (Urlaub, Krankheitstage, Feiertage, Puffer für technische Schulden, …) und mehr Zeit in die Vorausplanung stecke, würden die Schätzungen besser werden.

Doch anstatt sich zu bestätigen, lösten sich all diese Überzeugungen auf, je weiter ich auf meinem Weg als Engineer voranschritt. Hier ein paar Gründe dafür:

Heute würde ich behaupten, dass Erfahrung allein kein wesentlicher Faktor dafür ist, gut zu schätzen. Klar, sie hilft ein wenig, aber verschiedene Wege können zur selben Rolle führen, und zwei Seniors können völlig unterschiedliche Schätzungen abgeben, je nach ihrem Werdegang: die Kulturen früherer Arbeitgeber, die Arbeit in verschiedenen Teams mit verschiedenen Prozessen, Projektwissen usw. Das ist schon ein Indiz dafür, dass Schätzungen höchst subjektiv sind.
Vielleicht gibt es Unternehmen, die das geknackt haben, aber bis heute habe ich keines gesehen. Und wenn es wirklich jemandem gelungen wäre, würden wir diese Ansätze längst überall in der Branche verwenden.
Im Gegensatz dazu, sich einfach eine Zahl auszudenken, kann mehr Aufwand bei Schätzungen euch gelegentlich eine etwas bessere Vermutung liefern. Oft genug aber auch nicht. Und nun bezahlt ihr für Tage (oder Wochen) Arbeit, die keine konsistenten oder verlässlichen Ergebnisse bringt. Je länger der geschätzte Zeitraum, desto größer werden die Fehlermarge und die Nutzlosigkeit der Schätzung. Und selbst wenn alle erstellten Schätzungen genau genug wären, bleibt die große Frage, ob dieser Aufwand an Geld und Mühe nicht woanders weitaus besser aufgehoben wäre.

Eine Schätzung wurde abgegeben und dann massiv angefochten

Der PM bittet um eine Schätzung für die anstehende Arbeit. Der Entwickler zieht sich zurück, rechnet 3-4 Stunden lang herum und kommt dann zurück mit: “8 Wochen”. Der PM, schockiert, sagt: “Ich hatte eher mit 2 gerechnet, können wir nichts streichen?”. Nach einigem Hin und Her und 1-2 weiteren verlorenen Stunden einigt man sich auf irgendetwas zwischen 2-4 Wochen. Die eigentliche Arbeit dauert am Ende ohnehin 12 Wochen. Kommt euch bekannt vor? Die ganze Zeit über finden Meetings statt, in denen ständig nachgefragt wird, wie es dazu kommen konnte, was die Dinge weiter verzögert und mehr Geld verbrennt. Die Antwort ist ohnehin immer eine Variation von “wir haben etwas entdeckt, das wir anfangs nicht berücksichtigt hatten”.

Es gibt eine endlose Liste möglicher Gründe dafür, einige häufige sind:

Die Arbeit bringt Abhängigkeiten zu anderen Teams mit sich. Es braucht viel Abstimmung und Prioritätenverschiebung, um sie zu erledigen.
In typischerweise stressigen Umgebungen muss eine ganze Menge “done is better than perfect”-Code aufgeräumt werden, um die Feature-Entwicklung zu ermöglichen.
Der “minimale” Umfang ist eigentlich gar nicht so minimal und könnte in kleineren Häppchen ausgeliefert werden.
Versteckte Arbeit: Die Devs, die am Feature arbeiten, wurden abgezogen, um bei anderen Schätzungen, Incidents usw. zu helfen. Ein, zwei Stunden hier und da summieren sich über Monate. Geteilte Aufmerksamkeit und Kontextwechsel fordern einen hohen Tribut bei der Auslieferung.
Der Entwickler hat zugleich mehr auf dem Spiel und weniger Verhandlungsmacht, daher lässt er sich leichter zu unbequemen Zahlen drängen.

”Wir müssen einfach besser schätzen”

Das wurde weiter oben schon teilweise angesprochen, aber es verdient einen eigenen Abschnitt.

Alle sehen, dass Schätzungen oft gerissen werden und schlicht nicht wie beabsichtigt funktionieren. Aber “wir brauchen irgendeine Zahl, um unsere Arbeit planen zu können”, also ist der Reflex, z. B. eine Arbeitsgruppe mit Seniors, Architekten, PMs usw. zu bilden, um eine gründliche Schätzmethodik zu erarbeiten, was in einer akribischen und komplizierten Excel-Tabelle endet, in die Arbeitspakete mit Risikostufen usw. eingetragen werden.

Jetzt habt ihr eine ganze Menge Zeit einer Reihe hochtalentierter Leute aufgewendet, um im Grunde das Projektmanagement-Pendant zu einem astrologischen Geburtshoroskop zu erstellen: etwas, das sehr kunstvoll und professionell aussieht, aber nichts bedeutet. Sobald ihr mit der eigentlichen Arbeit beginnt, stoßt ihr auf viele Dinge, die euer ~~Horoskop~~ Schätzblatt nicht vorhergesehen hat, und das Auslieferungsdatum verschiebt sich viele Male.

”Gib mir jetzt einfach eine grobe Zahl, wir passen sie später an”

Diese Zahl liegt mit ziemlicher Sicherheit weit daneben. Jetzt bringt ihr entweder jemanden in eine schwierige Lage oder ihr werdet selbst in eine gebracht. Es ist ein verbreiteter Witz (aber auch gängige Praxis), dass “grobe Zahlen” sofort zu Zusagen werden. Wenn eure Pläne hauptsächlich von solchen hastig abgegebenen Schätzungen abhängen, dann sind sie ohnehin nicht viel wert.

Wie sind wir in diesen Schlamassel geraten?

Schätzungen sind einfach ein sehr naheliegender und intuitiver Weg, um z. B. einen Preis von einem Auftragnehmer oder einen Termin von einem Entwickler zu verlangen. Ihr könnt sie dann zur Rechenschaft ziehen, wenn die Termine gerissen werden, sodass am Anfang alles planbar und risikoarm wirkt.

Außerdem kostet das Anfordern von Schätzungen im Grunde keine Mühe und erfordert keinen Prozess. Hätten sie wie erwartet funktioniert, würde das Management einfach danach fragen, die Zahlen in sein säuberlich organisiertes Gantt-Diagramm eintragen und weiter in die Zukunft planen, während alles pünktlich ausgeliefert wird.

Doch wir wissen, dass die Dinge keineswegs so funktionieren. In vielen Fällen ist es schwer, auch nur einen Monat im Voraus zu planen, weil Änderungen an den Geschäftsanforderungen täglich hereinkommen. Die Termine werden dann verschoben und künftige Arbeit wird umsortiert und neu priorisiert. Regelmäßig.

Und wenn wir merken, dass ein Arbeitsstrang nicht nach Plan läuft, wollen wir wissen, wie lange es jetzt “wirklich” dauern wird, also drängen wir Leute, die ohnehin unter Stress stehen, uns eine weitere Schätzung zu geben. Das kann noch ein paar Mal passieren, bevor die Arbeit schließlich ausgeliefert wird.

“Aber nochmal”, denkt ihr vielleicht mit bereits gereizter Stimme, “wir müssen planen können und wir brauchen Zahlen!”.

Ja, und ich stimme sogar zu. Aber ihr wollt, dass euch diese Zahlen tatsächlich etwas Nützliches sagen, und ihr wollt, dass euer Plan etwas wert ist. Ihr werdet auch ein bisschen Aufwand hineinstecken müssen.

Prognosen

Einige Erkenntnisse, die wir aus dem Obigen ableiten können, sind:

Anforderungen ändern sich regelmäßig, also würden wir unseren Zeitplan idealerweise bei jeder Änderung aktualisieren und ihn genauso oft verfolgen.
Idealerweise würden die Aktualisierungen des Zeitplans augenblicklich und mit wenig Aufwand geschehen, um Kosten zu sparen.
Schätzungen auf Basis von Erfahrung abzugeben ist unzuverlässig und nicht von großem Wert. Vielleicht gibt es eine bessere Datenquelle, aus der sich Dauern ableiten lassen.
Schätzungen kosten echten Aufwand und echtes Geld und bringen nicht den Wert, der diese Kosten rechtfertigt. Etwas Automatisiertes würde es den Leuten ermöglichen, ihre Zeit stattdessen für wertvolle Arbeit zu verwenden, mit weniger Meeting-Overhead und Stress.

Prognosen sind zwar nicht vollkommen präzise, geben euch aber einen weitaus nützlicheren Anhaltspunkt dafür, wann die Arbeit fertig sein wird. Sie verfolgen das tatsächliche Tempo, in dem Tickets über einen Zeitraum abgeschlossen werden, und projizieren dann ein Datum (oder einen Zeitraum) auf Basis dieser Daten. Das war’s!

Ein Screenshot einer Prognose in Linear, die einen Fertigstellungszeitraum anzeigt

Eine Prognose in Linear: Statt eines einzelnen zugesagten Termins zeigt sie einen Fertigstellungszeitraum, der aus dem tatsächlichen Tempo des Teams beim Abschließen von Tickets abgeleitet wird.

Wenn neue Tickets hinzukommen oder bestehende entfernt werden, oder wenn sich die durchschnittliche Bearbeitungszeit von Tickets ändert, weil manche länger oder weniger lang bis zum Abschluss brauchen, ändern sich die Prognosen entsprechend. Das läuft alles autonom und erfordert praktisch keine Beteiligung des Teams.

Wenn jemand krank wird oder in den Urlaub geht oder wenn ein Feiertag ansteht, spiegelt der Zeitplan das wider.

Ein paar Dinge solltet ihr jedoch im Hinterkopf behalten:

Es dauert eine Weile, z. B. 2-3 Wochen, bis ihr überhaupt aussagekräftige Ergebnisse seht. Eure Daten stammen aus der Messung des tatsächlichen Arbeitsablaufs des Teams, also braucht es etwas Zeit, um genug davon zu sammeln.
Das erste prognostizierte Fertigstellungsdatum wird sich wahrscheinlich oft ändern. Es wird jedoch kontinuierlich aktualisiert, und in der Regel ist es einfach, allen Projektbeteiligten Zugriff auf den stets aktuellen Wert zu geben. Das spiegelt auch die Realität besser wider, da sich die Termine ohnehin mit neuen Erkenntnissen und Änderungen am Umfang verändern.
Euer Team muss ein wenig Disziplin aufbringen und darauf achten, dass die Arbeit korrekt in Tickets erfasst wird und diese laufend aktualisiert werden. Je einfacher ihr euer Projektmanagement gestaltet, desto eher bekommt ihr die Zustimmung eures Teams. Schreibt z. B. kleine Tickets, packt keine Dokumentation hinein, schreibt nur User Stories und verlasst euch auf die Interaktion im Team, um Dinge zu klären, usw.
Manche Projektmanagement-Tools wurden nicht mit diesem Gedanken gebaut und fördern aktiv die “alte Methode”. Es ist unwahrscheinlich, dass euer Unternehmen bald von ihnen wegwechselt, aber sehr wahrscheinlich lassen sie sich über Plugins oder zusätzliche Tools erweitern, um Prognosen zu berechnen.
Das ist genauso ein Mentalitätswandel wie eine Änderung des Arbeitsablaufs. Die Realität gleitender Fertigstellungstermine ist für manche Entscheidungsträger vielleicht nicht so leicht zu akzeptieren wie eine beruhigende, in Stein gemeißelte Zusage (die trotzdem ebenfalls eine Lüge ist). Wenn ihr als Entscheidungsträger das hier lest, ermutige ich euch, die Sache zu unterstützen und die Praxis der Software-Schätzung in eurem Unternehmen zu beenden.

Wie es weitergeht: die #NoEstimates-Bewegung

Hoffentlich habe ich euer Interesse an Prognosen geweckt und euch vielleicht sogar überzeugt, sie auszuprobieren. Es gibt noch viel mehr zu lernen, daher empfehle ich euch sehr, mit denselben großartigen Quellen anzufangen, die mich auf diesen Weg gebracht haben: