- Wenn von außerhalb des Entwicklungsteams Druck ausgeübt wird, Schätzungen ohne neue Fakten zu senken, werden Schätzungen wie ein Verhandlungsgegenstand behandelt, wodurch Vertrauen und die Qualität agiler Planung gleichermaßen leiden.
- Der tatsächliche Arbeitsaufwand lässt sich vom Entwicklungsteam meist nicht beliebig reduzieren; Teams schätzen den erwarteten Aufwand auf Basis von Team Velocity, Daten zu abgeschlossenen Storys und aktuellem Durchsatz.
- Wenn Prozesse übersprungen oder die Qualität gesenkt wird, um niedrigere Schätzungen zu erfüllen, kann der Zeitplan kurzfristig kürzer wirken, dürfte später aber mit höheren Kosten zurückkommen.
- Ein produktiveres Gespräch lautet nicht „setzt es niedriger an“, sondern betrachtet gemeinsam Budget, zeitintensive Teile, große Unbekannte, Alternativen, Story-Splitting und frühe Validierung.
- Wer bei festem Funktionsumfang nur die Zahl senkt, erzeugt bei Kunden falsche Erwartungen an den Lieferzeitpunkt; stattdessen sollte diskutiert werden, Funktionen mit hohem Aufwand und geringem Wert herauszunehmen.
Welche Verzerrung Druck auf Schätzungen ohne neue Fakten erzeugt
- Häufig kommt es vor, dass Stakeholder außerhalb des Entwicklungsteams mit begrenztem technischem Wissen oder begrenztem Verständnis der Codebasis versuchen, Schätzungen zu senken, indem sie sagen: „Nein, dafür ist weniger Aufwand nötig.“
- Nach außen hin fordern sie eine „bessere Schätzung“, tatsächlich wollen sie aber oft eine niedrigere Schätzung.
- Wenn Schätzungen als verhandelbare Zahlen behandelt werden, landen Stakeholder und Entwicklungsteam bei einer Einigung, mit der beide unzufrieden sind, und das Business entwickelt schlechte Erwartungen daran, wann Software an Kunden ausgeliefert werden kann.
- Als zugehörige Quelle wird Is tasking developers with creating detailed estimates a waste of money? verlinkt.
Schätzen ist eher Vorhersage als Kontrolle
- Es gibt Fälle, in denen man eine Schätzung infrage stellen kann:
- wenn das Entwicklungsteam intern eine Story bespricht
- wenn es neue Fakten gibt, die den tatsächlichen Arbeitsaufwand beeinflussen
- Wenn externe Stakeholder, die Implementierungsdetails nicht verstehen oder keine neuen Informationen liefern, eine niedrigere Schätzung verlangen, ist das ähnlich, als würde man Meteorologen sagen: „Die Vorhersage für morgen ist falsch und das Wetter wird besser.“
- Meteorologen kontrollieren das Wetter nicht, sondern erstellen Vorhersagen auf Basis von Wissen und Beobachtungsdaten.
- Auch Entwicklungsteams kontrollieren den tatsächlichen Arbeitsaufwand kaum; sie schätzen den erwarteten Aufwand auf Basis von Wissen und Daten.
Was Entwicklungsteams kontrollieren können – und was nicht
- Entwicklungsteams schätzen anhand etablierter Team Velocity, Daten aus der Prüfung abgeschlossener Storys und eines Prozesses, der sich von Sprint zu Sprint verbessert.
- Um den Arbeitsaufwand zu verringern, könnten sie Teile des Prozesses überspringen und Software niedrigerer Qualität liefern.
- Das ist nicht empfehlenswert.
- Oft bezahlt man später einen deutlich höheren Preis dafür.
- Teams können ihre Geschwindigkeit verbessern, sollten beim Schätzen aber nicht den erwarteten künftigen Durchsatz, sondern den aktuellen Durchsatz zugrunde legen.
- Wenn im Unternehmen Gespräche nach dem Muster „dann arbeitet man eben länger“ aufkommen, ist ein solches Umfeld nahezu ein Rezept für die Katastrophe.
- Als Erfahrungsberichte dazu sind drei Reddit-Kommentare verlinkt:
Welche Gespräche man statt Zahlendrücken führen sollte
- Softwareentwicklung ist komplex und dauert oft länger, als Menschen denken.
- Wenn Stakeholder davon ausgehen, dass nur ein bestimmter Betrag ausgegeben werden kann, sollten sie statt einer niedrigeren Schätzung Folgendes diskutieren:
- wie viel für diese Story ausgegeben werden kann
- welche Teile der Story die meiste Zeit beanspruchen
- wo die größten Unbekannten liegen
- welche Alternativen es gibt, um zeitintensive Teile und Unbekannte anzugehen
- Auch Optionen, die Validierung und Lieferung verändern, sollten gemeinsam geprüft werden:
- Story in mehrere Teile schneiden und ausliefern
- jeden Teil so früh wie möglich validieren
- wenn möglich mit einem Prototyp validieren
- Insbesondere Funktionen, die viel Aufwand erfordern, aber den geringsten Wert haben, sollten aus der Story herausgenommen werden.
Terminfragen nützlicher formulieren
- Produktiver als Fragen nach niedrigeren Schätzungen sind Fragen, die die Beziehung zwischen Funktion, Zeitplan und Umfang klarer machen.
- Als Fragen, die in einem separaten Beitrag behandelt werden, sind folgende verlinkt:
- Wann kann Feature A geliefert werden?
- Was kann bis zum Ende des nächsten Quartals geliefert werden?
- Kann Feature A bis zum Ende des nächsten Quartals geliefert werden?
- Verlinkter Beitrag: converting story points to hours
2 Kommentare
So würde der ursprüngliche Artikeltitel übersetzt mit DeepL:
Gibt es jemanden, der sagt: „Nein, das ist weniger anstrengend als das!“?
Kommentare auf Hacker News
Die Analogie, dass „Vertriebsmitarbeiter dazu zu drängen, Absatz/Quote zu erhöhen, so sei, als würde man von Meteorologen Sonnenschein verlangen“, wirkt in diesem Kontext nicht besonders unfair.
In Wirklichkeit entspricht es eher der Aufforderung, effektiver zu arbeiten, um dieselbe Arbeit schneller zu erledigen.
Wenn man Vertriebsmitarbeiter ihre Quote selbst festlegen lässt, werden sie, weil ein Abschluss viel Komplexität und Unbekannte enthält, eine Zahl wählen, die sie sicher erreichen können, um nicht wie Versager dazustehen.
Diese Zahl kann aber unter dem liegen, was das Geschäft braucht; deshalb setzt man eine höhere Quote und bringt sie dazu, sie auch mit etwas zusätzlicher Anstrengung zu erreichen.
Das ist besonders wichtig, wenn die Vergütung direkt an das Erreichen dieser Zahl gekoppelt ist.
Trotzdem schreiben Vertriebsmitarbeiter nicht ständig Artikel darüber, dass „selbst gesetzte Quoten heilig sind, nur Vertriebsmitarbeiter sie festlegen dürfen und das Management, das höhere Leistungen verlangt, ahnungslos ist“.
Eine passendere Analogie wäre, wenn das Vertriebsteam zu einem konkreten Deal sagt: „70 % Abschlusswahrscheinlichkeit, etwa 5 Mio. US-Dollar jährlicher wiederkehrender Umsatz“, und das Management antwortet: „Können wir daraus 80 % und 7 Mio. US-Dollar machen?“
Es mag möglich sein, sowohl die Abschlusswahrscheinlichkeit als auch den Preis zu erhöhen, aber wie beim Fertigstellen einer Funktion in der halben Zeit braucht es irgendwo eine größere Änderung oder einen Kompromiss.
Allerdings ist es deutlich besser, früher als geschätzt fertig zu werden, als Schätzungen in Wunschziele umzudeuten.
Am besten ist es, Arbeit anhand von Prioritäten und Voraussetzungen zu ordnen, genügend entwicklungsbereite Storys vorzuhalten und in dringenden Fällen Tickets strategisch zuzuweisen, auch wenn man damit langfristig die Kosten einer ungleich verteilten Teamkompetenz in Kauf nimmt.
Bei Zeitdruck sollte man aus allen Funktionen alles entfernen, was „nice to have“ ist, oder es ans Ende des Backlogs verschieben; Unterstützung durch andere Teams oder externe Experten sollte strikt zeitlich begrenzt werden.
Unnötige Meetings und Störungen müssen beseitigt werden, Entwickler sollten Meetings ablehnen oder ihren Kalender blocken können, und die Messlatte für Refactoring sollte vor einem Termin so angehoben werden, dass es nur dann passiert, wenn der Nutzen gegenüber den Kosten klar ist – man leiht sich gewissermaßen aus der Zukunft.
Man muss jedoch sehr vorsichtig sein, diese Vorgehensweise nicht zum Standardarbeitsmodus zu machen.
Wenn man 10 % der Leads konvertieren kann, muss man, wenn statt 4 Abschlüssen 5 nötig sind, grob gesagt etwa 10 weitere Leute anrufen.
Ein besserer Vergleich für Software wäre, ohne Erfahrung und ohne genau zu wissen, welche Probleme auftreten werden, eine neuartige Art von Gebäude zu errichten, etwa ein Wohnhaus als geodätische Kuppel.
Und dann soll man eine genaue Schätzung abgeben und wird anschließend gedrängt, sie weiter zu senken.
Das Wichtigste ist dabei Täuschung gegenüber Kunden, und damit ist nicht einfach eine „normale Übertreibung, die gut fürs Unternehmen ist“ gemeint.
Es geht darum, Versprechen zu machen, die das Unternehmen nicht halten kann, oder künftige Funktionen zu verkaufen, die einen Death March erfordern, bei dem Qualität und Nachhaltigkeit geopfert werden.
Selbst wenn die C-Level-Führung das nicht sieht, treten die Folgen ein.
Das heißt nicht, dass man Entwicklerschätzungen bedingungslos glauben sollte, aber das ist ein noch tieferes Rabbit Hole, in das ich jetzt zu müde bin hinabzusteigen.
Es macht nur das Verständnis des Zeitplans unrealistischer.
Es ist durchaus möglich, andere kreative Lösungen für dasselbe Problem zu finden oder zu verstehen, welchen Umfang man reduzieren kann, um das Ziel zu erreichen.
Aber das ist etwas völlig anderes als „genau dieselbe Arbeit einfach schneller machen“.
Wenn es um Schätzungen geht, stellen sich Entwickler oft kaum auf die Seite des Business und versuchen nicht zu verstehen, warum Schätzungen nötig sind und warum eine kürzere Schätzung immer besser ist als eine längere.
Stattdessen versuchen sie, die heilige Sphäre der Softwareentwicklung zu verteidigen, und vergrößern die Kluft zwischen Ingenieuren und „allen anderen“.
Dabei treten Zynismus und Spott zutage, was am Ende zu unrealistischen Schätzungen führt.
Ich war Entwickler, PO, Manager, Director und CTO, aber es überrascht mich immer noch, wie weit die meisten Entwickler von der Realität der Wertlieferung und des Zeitfaktors entfernt sind.
Als Entwickler hat man eigentlich Glück, wenn man gefragt wird, wie lange etwas dauert, und die Gelegenheit bekommt, die eigene Schätzung zu erklären, Einwände zu entkräften und sie zu verteidigen.
Die traurige Realität ist, dass Entwickler oft schlecht darin sind, sich an Gesprächen auf Business-Ebene zu beteiligen und Gedanken, Ideen, Bedenken und Vorschläge so auszudrücken, dass PMs und Manager die Komplexität der Arbeit sehen und eine gesunde Kosten-Nutzen-Diskussion führen können.
Man sollte schauen, ob Lead-Entwickler an Business-Meetings teilnehmen, ob das Entwicklungsteam Zahlen und Budgets sieht, gemeinsam an der Roadmap mitarbeitet und zusammen mit Business-/UX-Leuten Nutzerforschung und Feature-Brainstorming betreibt.
Wenn nicht, ist kaum zu erwarten, dass Entwickler das Business verstehen.
Die Trennung von Entwicklung und Business führt dazu, dass alle in ihren Silos sitzen und erwarten, dass andere Fachleute die eigenen Probleme gut verstehen; daraus entsteht die Sakralisierung der Softwareentwicklung.
Viele Unternehmen funktionieren trotz extrem versiloter Rollen einfach irgendwie weiter, und weil weiter Geld hereinkommt, scheinen sie fälschlich zu glauben, dieser Ansatz sei in Ordnung.
Meist will nur jemand eine Zahl in eine PowerPoint für Organisationspolitik einfügen.
Manchmal geht es darum, zu entscheiden, ob man A oder B macht; in diesem Fall ist legitim nur eine relative Schätzung nötig, niemals eine absolute.
Gelegentlich gibt es eine echte Deadline, aber auch dann braucht man keine Schätzung, sondern „Können wir dieses Datum schaffen?“ oder, noch nützlicher: „Was müssen wir tun, um dieses Datum zu schaffen?“
Möglichst nah am Business zu arbeiten ist gut, und der Grund, warum man überhaupt Software einsetzt, ist normalerweise, ein Business-Bedürfnis zu lösen.
Aber bei Schätzungen liegen sie wirklich oft falsch und wir richtig.
Wenn kürzer immer besser ist, können wir ab jetzt alle Schätzungen mit 1 Tag angeben. Ist das besser?
Wenn ein Entwickler Code schreiben, schätzen und nach Business-Zeitplan liefern kann, ist diese Person kein Angestellter, sondern Gründer.
Gewünscht sind naive Leute, die wie Gründer liefern, aber keinen Gewinnanteil bekommen.
Egal wie groß deine oder meine Anstrengung ist: Das Baby kommt dadurch nicht schneller.
Daran ist nichts unklar.
Der Ärger liegt in der Formulierung, als könnten Entwickler wissen, wann etwas fertig wird.
Die Fähigkeit, schnell Wert zu liefern, ist unabhängig von der Fähigkeit, die benötigte Zeit zu schätzen.
Man kann bei Schätzungen völlig danebenliegen und trotzdem großen Wert liefern.
Wenn es tatsächlich eine Methode gäbe, die Dauer von Softwarearbeit zu schätzen, würden Unternehmen so wie sie Produktteams haben auch professionelle Schätzer einstellen.
Es gäbe keinen Grund, Entwickler damit zu beauftragen.
Natürlich kann es sonst auch niemand, und Entwickler treffen immerhin die Untergrenze, also nervt man sie weiter damit; aber der Prozess selbst ist offensichtlich töricht.
Um zu wissen, wie lange etwas dauert, müsste man alle Schritte auflisten, die zur Erledigung nötig sind; in der Softwareentwicklung ist das unmöglich.
Entwickler können für gegebene Anforderungen eine Untergrenze angeben, und wenn absolut nichts Unerwartetes passiert, wäre vielleicht auch eine genaue Schätzung möglich; bei 95–98 % der Projekte fällt die Schätzung jedoch kürzer aus als die Realität.
Am Ende wird die „Entwicklerschätzung“ zu einem Maß dafür, wie viel Puffer ein Entwickler in diesem Projekt einbauen möchte.
Nach Schätzungen zu verlangen setzt den Rahmen des Gesprächs völlig falsch.
Die eigentliche Frage sollte nach dem Input der Entwickler zu den Problemen sein, die das Business jetzt hat, zu den Problemen, die in sechs Monaten wahrscheinlich auftreten, und zum Kosten-Nutzen-Verhältnis ihrer Lösung.
Danach sollte man qualitative Entscheidungen treffen, die Risiken reduzieren.
Das beste Ergebnis von Softwareschätzungen ist, dass alle sie ignorieren und vergessen; alle anderen Ergebnisse zerstören Business-Wert.
Ich verstehe den Punkt, und in Organisationen mit verantwortungslosen Beteiligten ist das reale Risiko auch groß.
Die Analogie mit Meteorologen finde ich allerdings nicht besonders gut.
Für Meteorologen ist es die Kernaufgabe, das Wetter vorherzusagen; typische Entwickler dagegen sind Menschen, die in diesem Wetter arbeiten, und haben vergleichsweise wenig Erfahrung mit präzisen Vorhersagen.
Was einen als Stakeholder frustriert, sind absurde Schätzungen, die weder bei der eigentlichen Arbeitszeit anfangen noch bei einem realistischen Zeitraum enden.
Das gilt besonders auf der Ebene von Mikroaufgaben: Aufgaben von höchstens 30 Minuten, die man mit den nötigen Zugriffsrechten selbst schneller erledigen könnte, für die aber Schätzungen von mehreren Wochen zurückkommen.
Selbst dann, wenn sie im Betrieb erhebliche Kosten verursachen und in die Kategorie „alles stehen und liegen lassen und erledigen“ fallen.
Natürlich dauert eine 30-Minuten-Aufgabe wegen Tests und Dokumentation nicht wirklich nur 30 Minuten, aber je näher eine Schätzung an völligen Unsinn herankommt, desto stärker leidet das Vertrauensverhältnis.
Es macht einen Unterschied, ob nach der tatsächlichen Arbeitszeit für eine bestimmte Aufgabe gefragt wird oder nach der verstrichenen Zeit von jetzt bis zum Deployment.
In fast allen Teams wird beides davon dominiert, dass Arbeit auf irgendetwas wartet, im zweiten Fall aber besonders stark.
Die tatsächliche Zeit an der Tastatur ist im Vergleich zu Abstimmung und Terminplanung meist kaum mehr als ein Rundungsfehler.
Wenn ein Team nicht gezielt an kontraintuitiven Arbeitsweisen gearbeitet hat, wartet ein durchschnittliches Ticket überwältigend viel länger, als tatsächlich daran gearbeitet wird.
Außerdem sieht das Team dieses Ungleichgewicht überhaupt nicht und erkennt auch nicht, dass es wichtig ist.
Man will es schnell fixen und weitergeben.
Das Problem ist: Ohne vollständig automatisiertes Continuous Deployment sind 30 Minuten eben keine 30 Minuten.
Diese 30-Minuten-Aufgabe muss darauf geprüft werden, ob sie andere Abteilungen betrifft, sie braucht Terminabstimmung, Ankündigung und Deployment, und es können noch 2–3 weitere Personen beteiligt sein.
Ist es eine geplante Arbeit, sind es über mehrere Personen hinweg fast 2 Stunden; ist es ein Hotfix oder Support-Ticket, werden daraus bei einem QA-Prozess über automatisierte Tests hinaus 4–6 Stunden Produktivitätsverlust.
Wenn dann noch sechs weitere Personen „30-Minuten-Aufgaben“ anfragen, deren Auswirkungen auf andere im Unternehmen unklar sind, wird gar nichts mehr fertig.
Unser Team hat einen Hotfix-Flow, aber dafür muss es wirklich ein Notfall sein, der den Geschäftsbetrieb des Unternehmens zum Stillstand bringt.
Von ganz offensichtlichen Fällen abgesehen, muss die Anfrage von Abteilungsleitungsebene oder darüber kommen.
Der Schaden, nicht jedes dringende Ticket sofort zu erledigen, ist viel geringer als der Schaden, wenn ein Fix für eine einzelne Person Probleme für mehrere andere schafft oder verhindert, dass strategisch wichtige Großprojekte fertig werden.
In der Organisation sollte es eine Möglichkeit geben, die nötigen Zugriffsrechte zu vergeben.
Wenn die Antwort ungefähr „Das ist nicht meine Aufgabe“ lautet, dann ist diese Organisation auf stark vernetzte Komponenten mit klar abgegrenzter Verantwortung ausgelegt.
In so einer Organisation ist es nur folgerichtig, dass Kommunikationskosten die Output-Leistung vollständig dominieren.
Wenn sie gut koordiniert ist, ist die Qualität hoch, und bei klaren Rollen kann auch der Durchsatz hoch sein, aber niedrige Latenz wird man nie bekommen.
Die Reaktionszeit wird zugunsten anderer Dinge geopfert.
Dass für eine triviale Aufgabe eine Schätzung von einer Woche herauskommt, ist in so einer Struktur zu erwarten.
Bei einem vollen Zeitplan wird neue Arbeit wahrscheinlich erst in einigen Wochen zugewiesen, und wenn wegen kleinteiliger Zuständigkeiten zwei oder mehr Personen nötig sind, summieren sich die Wartezeiten immer weiter.
Wenn das nicht zur Arbeit passt, dann passt die Organisation selbst nicht zu dieser Arbeit.
Für alle Beteiligten ist das ineffizient.
Unser Team hat viel Autonomie, wir zählen keine Stunden und werden nicht von außen an Produktivität gemessen, aber bei Bedarf bleibt keine Zeit, den Code aufzuräumen.
Wenn ich eine „30-Minuten“-Aufgabe sehe, bringe ich sie ins Review am Morgen und frage, ob wir bei der Arbeit an diesem Thema auch benachbarte Dinge mit erledigen sollten.
Selbst wenn es nichts gibt, plane ich einen Tag ein; bei einem Projekt, das ich sehr gut kenne, einen halben Tag.
Die eine Hälfte des Tages geht dafür drauf, den Code durchzugehen, die andere für Updates wie kleine Kommentare, Versions-Upgrades, Code-Verbesserungen oder Umbenennungen von Variablen.
Ich halte es für zeiteffizienter, einzelne Beitragende ebenfalls in diese Richtung zu drängen.
Neue Individual Contributors lernen in dieser Zeit alten Code kennen, und solange sie am Ende keine großen Änderungen vornehmen, werden auch Legacy-Probleme reduziert.
Der einzige Zauberstab in der Softwareentwicklung ist Vereinfachung der Anforderungen.
Anforderungen sind immer falsch.
Sie sind zu breit, zu vage oder beruhen auf falschen Annahmen.
Die wirklich herausragende Fähigkeit besteht darin, einige Annahmen zu verwerfen und eine vereinfachte Lösung vorzuschlagen.
Das ist der beste und einzige Weg, Zeitpläne zu verkürzen.
Wenn Anforderungen einfach sind, werden sie leichter vollständig und korrekt, aber die tatsächlichen Anforderungen lassen sich möglicherweise nicht vereinfachen.
In diesem Fall braucht man bessere Spezifikationen.
„They write the right stuff“ über die Shuttle Software Group erzählt im Grunde von genau so einer Arbeit: https://www.fastcompany.com/28121/they-write-right-stuff
Die meisten Software-Bugs sind eigentlich Anforderungs-Bugs, und wenn es gute Anforderungen gibt, wird Software absurd schnell gebaut.
Ich habe ein Projekt gesehen, das mit völlig klaren und stabilen Anforderungen aus einem leeren Repository in 2 Monaten bis zum Production-Deployment kam.
Umgekehrt habe ich auch gesehen, wie sich die Implementierung eines Features von etwa 30 Zeilen wegen vager und ständig wechselnder Anforderungen über Monate hingezogen hat.
Im Moment gibt es nur ein paar Dutzend Einträge, aber in ein paar Jahren sollen es Tausende sein.
Die Designer entwerfen auf Basis eines 20-seitigen Product-Requirements-Dokuments den gesamten Such-Flow, und erst nachdem alle Planung und Vorbereitung abgeschlossen sind, wird Engineering hinzugezogen, um Stories zu schreiben und die Arbeit zu schätzen.
Sie haben in der Regel genug Domänenwissen und wissen in diesem Kontext, was nötig ist, um etwas zu bauen.
Es lohnt sich, darüber zu sprechen, wie man den Scope verändert, um eine Kosten-Nutzen-Balance zu erreichen, die zu den Stakeholdern passt
Ich habe sowohl gesehen, dass Entwickler von zu viel notwendiger Arbeit ausgehen, als auch, dass Nicht-Entwickler die entscheidenden Teile ignorieren, die den Zeitaufwand erhöhen
Manchmal versucht man, eine verallgemeinerte Lösung zu bauen, obwohl tatsächlich nur nötig wäre, dass jemand einen Tag lang vor einer Tabelle sitzt und das abarbeitet
Das Problem, dass Schätzungen oft hinterfragt werden, wenn sie zu hoch sind, aber fast nie, wenn sie zu niedrig sind, ist genau der Punkt, den Planning Poker adressieren will
Die Idee ist, dass alle unabhängig voneinander die Schwierigkeit einer Aufgabe nennen und man dann diskutiert, wenn die Erwartungen auseinandergehen
Wahrscheinlich übersieht irgendjemand etwas
Der Grund, warum ich etwas für einfach halte, kann ebenfalls sein, dass ich den komplexen Teil des Problems übersehen habe – oder dass ich eine sauberere Lösung sehe
Ein gutes Beispiel ist, wenn Kunden mathematisch oder physikalisch unmögliche Anforderungen stellen
Man kann den ganzen Tag Planning Poker über solche Wünsche spielen und trotzdem bei einem unmöglichen Kompromiss landen
Als ich Freelancer war, bevorzugte ich es, mir das Problem gründlich erklären zu lassen, mir bei Bedarf über die Schulter der Person anzusehen, die das Problem aktuell löst, dann für ein paar Tage zu verschwinden und mit einem Design zurückzukommen, von dem ich glaubte, dass es das Problem am elegantesten und zuverlässigsten löst
Wenn jemand nicht viel Erfahrung mit komplexen Problemen hat, kann er sein Problem meist ganz gut erklären, aber keine Lösungen vorschlagen
Denn Lösungen orientieren sich immer an dem begrenzten Modell dessen, was man kennt
Ich habe viele seltsame Anforderungen gesehen, die nur dadurch entstanden sind, dass mehrere Leute Annahmen aneinandergekettet haben, obwohl sie in Wirklichkeit niemand verlangt hatte
Zum Beispiel eine unendlich skalierbare Microservice-Architektur und eine vollständige Single-Page-App zu bauen, nur damit ein Dutzend interne Nutzer Daten als Excel-Tabelle herunterladen kann
Es setzt voraus, dass das Team mit dem gesamten Funktionsumfang ausreichend vertraut ist und versteht, wie man ein System verwendet, das mit den unvermeidlichen Unterschieden umgeht, dass A etwas in X schafft und B in X*3
Schon die Diskussionen darüber, wie schlecht Scrum betrieben wird, zeigen, dass diese Voraussetzungen keineswegs garantiert sind
Außerdem wird nicht berücksichtigt, dass das Team durch Fluktuation und neue Funktionen jederzeit aus diesen Voraussetzungen herausfallen kann
Viel zu oft läuft es darauf hinaus, dass man sich nur gegenseitig die Augenbrauen hochzieht und am Ende „X macht es, also gilt X’ Schätzung“ herauskommt, oder dass man Durchschnitt/Minimum nimmt und nur die Person bestraft wird, die höher geschätzt hat
Wenn es so läuft, weiß ich nicht, warum man überhaupt Poker spielt
Das ist noch machiavellistischer
Der Mittelsmann will einen Bei Kopf gewinne ich, bei Zahl verlierst du-Deal
Er möchte profitieren, indem er seiner Gegenseite eine niedrige Zahl präsentiert, um sie zu überzeugen
Also nutzt er alle möglichen Techniken, um den Entwickler dazu zu bringen, die gewünschte Zahl zu nennen, aber ohne dass es wie eine Anweisung oder Nötigung wirkt
Denn wenn es so aussieht, wird diese Zahl zu seiner eigenen Zahl, und das Spiel ist kaputt
Wenn es dann aber zwangsläufig viel länger dauert, kann er auf die vom Entwickler gelieferte Zahl zeigen und sagen, er habe nur weitergegeben, was er gehört habe, und trage keine Verantwortung
Die einzige Sprache, die solche Typen verstehen, ist, die Folgen einer Bitte um „Überprüfung“ der Schätzung immer nach oben gehen zu lassen und damit eine Botschaft zu senden
Erstens sollten Schätzungen nützlich sein, damit sich das Business anpassen kann, aber in der Realität gibt es keinerlei Anpassung
Der PM steht unter Druck seines Chefs, ungefähr bis zu einer Deadline fertig zu werden
Wenn meine Schätzung am Ende ohnehin niemanden interessiert, warum schätzen wir dann?
Zweitens hat das Team keinen Anreiz, realistisch zu schätzen
Bekommt man eine Medaille, wenn man richtig liegt? In der Praxis gehen alle Anreize dahin, den Arbeitsumfang über Schätzungen aufzublähen
Drittens ist dieser ganze Schätzungstanz mit seinen Ritualen nur etwas, das Manager übernehmen, um effektiver und einflussreicher zu wirken, als sie tatsächlich sind
Als Engineer habe ich klar gesagt: „Das lässt sich nicht schneller machen, also drückt mich nicht, nur um die Zahl zu bekommen, die ihr hören wollt“
Fertig ist es, wenn es fertig ist; ich werde es robust und gut machen, also stört mich nicht
Als Manager habe ich jedoch dann auf kleinere Schätzungen gedrängt, wenn es aus geschäftlicher Realität entscheidend war, innerhalb eines festen Zeitraums irgendetwas zu liefern
Selbst wenn wir ein Kartenhaus bauen und Ecken abschneiden mussten, mussten wir zumindest lange genug überleben, um uns später mit dem Problem zu befassen
Damals kam aus dem Engineering genau der Widerstand, den ich in dieser Position vermutlich selbst geleistet hätte
Nämlich: Das ist eine schreckliche Idee, sie wird uns in Zukunft scheitern lassen, und wenn wir späteren Schmerz vermeiden wollen, müssen wir jetzt die Laufarbeit erledigen
Ich bin wieder Engineer, aber die Erfahrung als Manager hilft mir ziemlich dabei, mit dieser Kluft umzugehen
Das sind die Leute, die „bis 11 gehen“
Wenn man wie beim Verstärker von Spinal Tap die normale Maximalleistung auf 9 setzt, bleibt noch eine Stufe Luft, wenn sie es wollen
Natürlich arbeitet man dadurch langsamer als eigentlich
Aber wenn man Entwickler will, die „bis 11 gehen“, ist klar, dass es nur eine Methode gibt, die funktioniert
Mein Manager und dessen Vorgesetzter, die willkürliche Deadlines durchdrücken, nicht weil der Kunde wartet, sondern um bei ihren Chefs gut auszusehen, sind genau so
Wenn die Schätzung zwangsläufig scheitert, heben alle die Hände und fangen an, Leute wegen ihrer eigenen schlechten Schätzungen in Leistungsverbesserungspläne zu stecken
Was gewinnt man als Engineer davon, unter diesem Dauerstress zu leben und sogar Zeit mit Familie und Freunden zu verpassen?
Nur, damit die unfähige Schätzung des eigenen Managers gut aussieht
Einer der ältesten Tricks ist, eine Vision zu entwerfen, Versprechen zu machen und dann zu sagen: „Ich habe meinen Teil getan, jetzt muss Engineering seinen Teil tun“
Ich muss an einen Manager denken, der während der Fertigstellung eines Releases, manchmal wenige Stunden vorher, ohne Ankündigung Features hinzufügte
Er fügte sogar Features zu Releases hinzu, die bereits abgeschlossen waren
In seinem Kopf sah es offenbar so aus, als sei ein Feature sofort erledigt, sobald man es nur an ein Release hängt
Die größte Schwierigkeit ist, dass Leute sofort eine Schätzung verlangen, wenn das Projekt gerade mal in einem Absatz beschrieben ist.
Außerdem fühlt es sich immer so an, als hinge es davon ab, wie viel Technical Debt vorhanden ist, nachdem man sich den Code angesehen hat.
Die einzige vernünftige Antwort, die ich bisher gegeben habe, war: „Ich muss Sie dazu drängen, die Anforderungen belastbar zu machen, und vor dem Start 1–2 Tage einplanen, um die Codebasis einzufrieren, zu auditieren und Risiken zu finden.“
Kann man das noch besser machen?
Ziel ist nicht, perfekte Karten zu erstellen, sondern mindestens ein Ticket für alles anzulegen, was im Projekt offenbar zu tun ist.
Dann entstehen mehrere Einzeiler-Karten wie „API-Endpunkt für Batch-Erstellung bauen“ oder „Daten aus bestehender Tabelle in neue Tabelle migrieren“.
Wenn es 5 oder mehr Karten sind, schätze ich mit
((Anzahl Karten / Anzahl Entwickler) * geschätzte Arbeitstage pro Karte) + erwartete Urlaubstage.Das ist sicher nicht exakt, aber der PM und dessen Chef haben damals das Gefühl, dass die Schätzung durchdacht und vernünftig war.
Wenn später eine Verzögerung nötig wird, lässt sich leicht erklären: „Wir sind davon ausgegangen, dass alle Karten ähnlich viele Tage brauchen, aber diese beiden Karten waren größere Ausreißer als erwartet.“
Das ähnelt dem normalen Sprint-Prozess, aber man muss die Sprint Velocity nicht über ein Bauchgefühl hinaus verfolgen.
Die Unternehmensführung verlangt Schätzungen mit fast keinen Informationen, und wenn man sagt, man müsse mehr herausfinden und sich die Codebasis ansehen, heißt es, man brauche „einfach“ eine Schätzung, um zu entscheiden, ob diese Arbeit genehmigt wird und ob das Projekt gemacht wird.
So dreht man sich im Kreis und landet schließlich bei einer großen Schätzung, weil sie all die Unbekannten enthält, einschließlich dessen, dass man nicht einmal den Umfang kennt.
Dann ist es der Führung zu groß und zu teuer.
In Agile-Begriffen ist das ein Spike-Ticket mit 3 Punkten, und das Ergebnis sind detaillierte Anforderungen, Liefergegenstände und Schätzungen samt abgewogenen Trade-offs.
Das ist ein völlig normaler Ansatz.
Vor dem Spike kann man eine Schätzung abgeben, aber sie sollte so stark wie möglich mit Vorbehalten versehen sein.
Zum Beispiel: „Mit 60 % Sicherheit unter 3 Wochen, mit 80 % Sicherheit 5 Wochen, mit 90 % Sicherheit 6 Wochen.“
Im Allgemeinen lehne ich Deadline-Schätzungen über 1–2 Wochen hinaus ab und bevorzuge, wenn möglich, Schätzungen pro Teilstück.
Etwa: „Dieses Projekt besteht aus 7 Liefergegenständen, die jeweils 1–2 Tage Arbeit dauern.“
Denn etwas kann zwar 10 Tage Engineering-Arbeit sein, aber die Berechnung eines Fertigstellungstermins wird durch geänderte Prioritäten und Ähnliches praktisch bedeutungslos.
Wenn „Manager“ das nicht verstehen, wird es leider schwer, friedlich zu bleiben.
Kümmere dich nicht um Code-Schulden und Qualität, sondern wirf hastig etwas raus, das gerade so funktioniert.
Dann sind sie zufrieden.
Eine typische Hacking-Szene in einem Actionfilm sieht so aus:
Anführer: „Wie lange dauert es, den Mainframe zu hacken?“
Techniker: „Der gegnerische Hacker ist wirklich gut, mindestens 2 Stunden.“
Anführer: „Du hast 1 Stunde. Mach es.“
Danach fliegt man durch ein 3D-Dateisystem.
Jedes Mal, wenn ich so eine Szene sehe, füge ich dem Techniker innerlich eine Erzählstimme hinzu:
„Die echte Schätzung waren 20 Minuten. Wahrscheinlich bin ich nach etwa 50 Minuten fertig und fliege dann noch 10 Minuten beschäftigt durch das 3D-Dateisystem, damit der Anführer nicht auf dumme Ideen kommt.“
Das stimmt nicht ganz.
Viele Features können in mehreren Abstufungen gebaut werden, von sehr skelettartig bis komplett vergoldet.
Manchmal schätzt ein anderer Entwickler für ein Feature, das aus meiner Sicht höchstens einen Tag dauern sollte, 2 Wochen, weil er viele tatsächlich nicht angefragte Zusatzfunktionen annimmt oder weil er etwas weiß, von dem ich nicht wusste, dass es nötig ist.
Wenn man gebeten wird, eine Schätzung zu ändern, sollte man das als Einladung verstehen, Anforderungen und vorgeschlagene Implementierung etwas weiter zu diskutieren.
Vielleicht gibt es eine viel einfachere Lösung, die 90 % erreicht und akzeptabel ist.
Meteorologen haben diese Option nicht.
Der Unterschied zwischen dem Hineinwerfen einer einfachen Combo-/Select-Box und dem Bau eines viel besseren Custom-UI-Elements, das besser zur Situation passt, lässt sich Leuten außerhalb der IT nur schwer vermitteln.
Man kann es mit Bildern erklären, aber solange Stakeholder es nicht sehen und anfassen, wissen sie immer noch nicht, was passiert.
Deshalb muss man es meistens tatsächlich funktionsfähig bauen und zeigen.
Es gibt Kunden, die sagen „bitte so einfach wie möglich“, und wenn man ihnen dann eine Prototyp-GUI, eine fertig gestaltete GUI und anschließend den Prototyp zeigt, nicken sie die ersten beiden ab, ohne sie überhaupt anzusehen.
Drängt man sie, spielen sie mit dem Prototyp herum und sagen trotzdem „gut, machen wir weiter“, um dann, nachdem sie die tatsächlich laufende Version auf dem Testserver ausprobiert haben, zu sagen: „Das ist nicht das, was wir gemeint haben.“
Das habe ich von Zwei-Personen-Ehepaarläden bis hin zu Fortune-500-Unternehmen erlebt, bei denen ein Regional Director und ein globaler CTO ihre Meinung äußern.
Das ist die Frontend-Seite; Backend und DevOps sind noch einmal ganz andere Probleme, aber auch dort ist der Unterschied zwischen skelettartig und vergoldet groß.
Inzwischen kenne ich dieses Spiel, und heutzutage verdiene ich mit diesem kaputten Prozess gutes Geld.
1975 schrieb Fred Brooks:
„Ein Kind zur Welt zu bringen dauert 9 Monate, egal wie viele Frauen man darauf ansetzt.“
Besser kann man es nicht ausdrücken.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Jede zusätzliche Person macht es langsamer.
Die schnellste Lieferung bekommt man, wenn man den Solo-Entwickler nicht stört und ihn einfach arbeiten lässt.