"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen.
Im Mai dieses Jahres stieß ich auf eine Stellenanzeige, vermutlich auf Stepstone gefunden, die die folgende Passage enthielt: "(...) Define and track KPIs related to Agile/DevOps (velocity, cycle time, deployment frequency, MTTR etc). (...)" Velocity bedeutet ja Geschwindigkeit, und schneller, besser, höher, weiter wird von Auftraggebern und Entscheidern vermutlich intuitiv immer als erstrebenswert angesehen, eventuell aber, ohne genau zu spezifizieren, was dadurch nachher anders sein soll als vorher. ("Ich habe zweimal so viele Story Points abgearbeitet wie im Sprint zuvor." - "Tja, aber leider braucht der Kunde das, was du über deine vielen Punkte gebaut hast, gar nicht...")
Ich muss ehrlich zugeben, dass ich inzwischen ein mehr als unterschwelliges Unwohlsein empfinde, wenn ich z. B. in Stellenanzeigen in Aufgabenlisten gleich ganz oben etwas von "Velocity" lese, die "getrackt" und "berichtet" werden muss. Für mich klingt das nach dem verzweifelten Versuch, in einem komplexen Umfeld trotzdem möglichst umfassende Kontrolle über alles behalten zu wollen. Total agil, versteht sich.
Glaskugel-Ansagen zu Beginn von Projekten/Initiativen/...
Das Konzept der "Velocity" beruht auf der Illusion, Unwägbarkeiten und Komplexitäten, die in der Zukunft liegen, wenigstens annähernd voraussagen zu können. Das ist tatsächlich nicht der Fall. Werden die einer Velocity zugrundeliegenden Story Points dafür genutzt, um eine Diskussion über anstehende Arbeiten anzustoßen und genauer auf Arbeitspakete zu sehen, ist dies eine gute Wirkung. Wie es danach aber nicht selten weitergeht - siehe Velocity messen, in der ja immer noch bestehenden Hierarchie nach oben berichten und am besten noch das Team mit der niedrigsten Velocity öffentlich an den Unternehmenspranger stellen (eine öffentliche Zurschaustellung von Velocities völlig unterschiedlicher Teams und deren "Sprintziel-Erreichungsgrad" habe ich tatsächlich einmal in einem Arbeitsumfeld erlebt) - ist unerfreulich und nicht zielführend.
Was mach' ich bloß, wenn der fragt, wann sein Kram fertig ist?
Gemeinsam ist "klassischen" oder "agilen" Settings in vielen Unternehmen, dass man noch immer einen (einigermaßen) feststehenden Geldbetrag für ein weit in die Zukunft hinein durchgeplantes Ergebnis bereitstellt. Auf dem Weg dorthin wird immer wieder vom Kunden gefragt, wie lange es denn noch dauert, bis das Ergebnis da ist und auch benutzt werden kann (unerhört! ;-)). Um diese Auskunft geben zu können, greift der Mensch zu einem Verfahren, das ihm subjektiv dabei hilft, den Aufwand für die notwendigen Arbeiten vorhersagen zu können: er schätzt.
Leider liegen Schätzungen nicht selten weit von dem entfernt, was dann tatsächlich passiert. Dazu kommt noch, dass sie, obwohl sie offiziell als Schätzung deklariert werden, in großen Initiativen scheinbar als einziger Rettungsanker und Strohhalm gesehen werden und in den Gehirnen nahezu aller Beteiligten eine stille Mutation zu "zutreffende Zukunftssituation" durchmachen. Da wir aber noch nicht in die Zukunft gucken können, kann diese Haltung nur zu Enttäuschung führen.
Dieser Artikel beschäftigt sich mit (noch) nicht so populären, aber aus meiner Sicht überdenkenswerten Optionen zur Prognostizierbarkeit von Arbeitsaufwänden bzw. Lieferungen.
Tame Flow
In unserem Lean Coffee hatten wir einmal einen Experten namens Steve Tendon zu Gast, der absichtlich ein wenig gegen den populären Strich striegelte und uns damit zum Nachdenken anregte. Vor einiger Zeit kamen mir meine Notizen zu diesem einige Jahre zurückliegenden Termin wieder unter.
Das von Steve vorgestellte Konzept heißt "Tame Flow" (siehe /1/). Sichtweise des Referenten als Informationsbrocken: Story Points sind "mental acrobatics". Das Management fragt schließlich: "Wann bekomme ich das?", und dafür sind Story Point-Angaben als Antwort nutzlos. Aber es gibt damit noch weitere Probleme.
Die dunkle Seite der Schätzung
"Estimates always have a dark side", führt Steve Tendon weiter aus, denn die Menschen, die die Schätzungen vornehmen, werden oft und gerne für diese Schätzungen verantwortlich gemacht, so als handele es sich um angekündigte Tatsachen, die dann (in den allermeisten der Fälle) aber leider doch nicht eintreffen, wie wir alle ja täglich in unseren Projekten erfahren.
Das gleiche gilt in meinen Augen für alle Arten von Projekten, in denen Schätzungen oder akribische Planungen vorgenommen werden. Ich erinnere mich noch gut an die endlosen Wochen der Lähmung, wenn im ersten Quartal eines Konzerns, in dem ich als Berufsanfängerin arbeitete, Heerscharen von Menschen (was das allein kostet!) Planungen für alles und nichts vornahmen, nur um im Verlauf der Zeit zu erkennen, dass doch wieder alles ganz anders gekommen war.
Daher lautet Steves Empfehlung, überhaupt keine Schätzungen zu verwenden, da diese hauptsächlich ein toxisches Arbeitsumfeld erzeugten, siehe enttäuschte Erwartungen und Suche nach Schuldigen (die etwa die Schätzung vergeigt haben - ein skurriles Oxymoron, denn eine Schätzung ist nun mal eine Schätzung, keine Zusage, und die Aussage kann daher nicht "falsch" sein). Aus diesem Teufelskreis kann man, so Steve Tendon, nur schwer entkommen.
Verwendung von Flussmetriken
Steve Tendon empfiehlt den Griff zu Flussmetriken und Analyse des gesamten Systems. Vor diesem Hintergrund ließe sich etwa ein PI Planning zur Engpass-Identifikation im System und zur Priorisierung zu optimaler Wertgenerierung nutzen. (Zu Flussmetriken gibt es zahlreiche Quellen, siehe z. B. auf Scrum.org, wo auch gleich eine Verbindung zu ihrer Nutzung in den Scrum-Events hergestellt wird /2/) So unterstützt er mit anderen Worten den Appell von Klaus Leopold, der schon seit geraumer Zeit immer wieder dringlich darauf hinweist, nicht nur einzelne Teams zu optimieren, weil dies nicht den gewünschten Erfolg haben kann, sondern stattdessen ganze Wertströme zu analysieren. Leopold empfiehlt außerdem, verschiedene Unternehmensebenen beispielsweise über das Flight Level-Modell zu synchronisieren /3/.
Für Steve Tendon stellt der Einsatz von Flussmetriken eine geeignete Alternative zu Story Point-Schätzungen dar. Erstere seien auch leichter anzuwenden, und: „You don’t need story points to have a discussion." (O-Ton aus unserem ganz oben erwähnten Lean Coffee-Spezialtermin.) Er erwähnt auf seiner homepage als Flussmetriken Durchsatz und Zykluszeit. Der Durchsatz könnte beispielsweise die Anzahl der abgearbeiteten User Stories pro Zeiteinheit/Sprint sein. Diese Metrik wird auch von anderen Impulsgebern aufgegriffen (siehe weiter unten "no estimates"). Die Zykluszeit als benötigte Zeit für die vollständige Bearbeitung einer Einheit (z. B. User Story) innerhalb eines Systems gibt wiederum Hinweise darauf, wie leistungsfähig ein Prozess zur Generierung von Wert ist (zum Thema "Prozesseffizienz" siehe außerdem weiter unten "Prozesseffizienz ermitteln"). Eine niedrigere Zykluszeit bedeutet außerdem einen höheren Durchsatz und damit die Fähigkeit, auf veränderte Anforderungen schneller reagieren zu können - etwas, das wir "agil" nennen.
No estimates
Eine ähnliche Empfehlung hörte ich Jahre später in der agilen Community, als mir - in der Theorie - ein alternativer Ansatz für "Schätzungen" in Sprints begegnete. Es handelte sich um die "No estimates"-Bewegung /4/, die bereits im Jahr 2011/2012 ins Leben gerufen wurde. Bis heute aber weiß offenbar noch immer kaum jemand davon oder fast niemand in größeren Unternehmen traut sich, danach zu arbeiten.
Ständig wegbrechende Schätzgrundlage
Der folgende Beitrag illustriert anschaulich, worin das Problem mit den Schätzungen besteht: "(...) In der gelebten Praxis von Organisationen gibt es immer wieder Vorhaben, in denen Rahmenbedingungen vorliegen, die eine realistische Schätzung nahezu unmöglich machen. (...) Jeder Versuch, diese oder ähnliche Projekte mit Aufwandsschätzungen zu versehen, endet lediglich in einem Haufen Datenmüll, da die Wissensgrundlage, auf der die Aufwandsschätzungen stattfinden, ständig wegbricht und sich in veränderter Form neu bildet. (...)" /5/
Glaube an Schätzungen: gefährlicher als der Glaube an Einhörner
Vasco Duarte, der Erfinder des no estimates-Ansatzes, berichtet in einer Keynote von 2016 (!) von einem Programmmanager, der sich lieber auf die Schätzungen von Teams verließ, als die vorliegenden Daten zu analysieren, die, so Duarte, bereits weit im Voraus zeigten, dass das Programm mindestens um sechs Monate verspätet beendet werden würde. Dieser Vorfall sei jedoch wie eine Blaupause für viele Unternehmen, die genauso handelten. Warum?: "Because we believe in estimation." /6/) Dies sei gefährlicher als an Einhörner zu glauben, denn diese seien harmlos, im Gegensatz zu Schätzungen, die ein Unternehmen ruinieren könnten. Stattdessen stellt Duarte zehn Prinzipien vor, die als Substitut für Schätzungen helfen, Projekte in Zeit und Budget mit dem gewünschten Ergebnis durchzuführen (beispielsweise "Rückmeldeschleifen verkürzen", wie es mit anderen Worten auch häufig im Agilen Manifest vorgeschlagen wird).
Vorhersagbarkeit erhöhen
Man nähert sich möglichst weit an eine Vorhersagbarkeit an, was wann geliefert werden kann. Dazu bedient man sich verschiedener Techniken, die im Rahmen agilen Arbeitens bereitgestellt werden: flexibler Scope und aber festes Zeitfenster (welchen Zusatzwert kann ich in diesem Zeitfenster sicher ausliefern?), Vorhandensein einer definition of done (um Programmierung in einem Zeitfenster begrenzen zu können), continuous integration (um immer möglichst "up to date" zu sein und Unwägbarkeiten vor Auslieferung so gering wie möglich zu halten) und andere. Duarte weiß, dass Liefertermine im Geschäftsleben sehr wichtig sind, teils auch aufgrund von Regulatorik, daher wird auch in seiner Welt alles auf die Lieferung von Wert im Rahmen von Lieferterminen ausgerichtet.
Kleiner mentaler Haltegriff - Slicing
Trotzdem möchte der Mensch Information darüber haben, was wohl als nächstes kommt, damit er sich ein wenig orientieren kann. Der No estimates-Ansatz stellt eine Vorgehensweise für das Planning bereit, die nach Neil Killick als "slicing technique" bezeichnet wird /7/. Die elementare Frage lautet "What are some options for delivering value to a customer as soon as possible?”, nie etwas wie "(...) “Build a website that lets them pay their bills!” — you’ve made the classic mistake of jumping into solution mode way too early. (...)"
Duarte nennt sein Alternativmeeting zum gängigen Planning deswegen auch passend "slicing meeting" /8/. Beispiel für das Ansetzen des Schneidewerkzeugs am Arbeitsbrocken: früh Abhängigkeiten zu anderen bewerten, um das Ausmaß der "sozialen Komplexität" einer Anforderung zu erkennen. Danach wird versucht, die Schnittstellen zu anderen außerhalb des Teams so weit einzudampfen, dass für eine wert-haltige Umsetzung eines Inkrementes weniger als fünf Personen benötigt werden, die nicht zum Team gehören. Dies ist natürlich nur eine von mehreren Vorgehensweisen, die insgesamt zur Verfügung stehen und sinnvoll kombiniert werden sollen.
Anzahl sinnvoll geschnittener Stories versus Punkte: Wer gewinnt?
Anhand der Überschrift lässt sich bereits ablesen, in welche Richtung die empirischen Ergebnisse deuten...
In einem Q&A-Meeting im Juni beantwortete Marc Löffler die Frage nach "no estimates" statt Story Point-Schätzungen (die witzigerweise inzwischen auch schon quasi als "klassisch" in der agilen Welt gelten können) folgendermaßen: User Stories werden so klein geschnitten, dass sie immer gut in einem Sprint abarbeitbar sind und dass immer mehrere Stories in einen Sprint passen. Jedenfalls keine Blockade-Stories von acht Punkten ohne jeglichen Puffer, die dann bei aufkommenden Problemen mitten im Sprint wie der Dampfer im Suez-Kanal feststecken (Anm. der Red.). Am Ende des Sprints wird typischerweise nur die Anzahl abgearbeiteter, d. h. Wert liefernder Stories, gezählt. Falls jemand den gleichen Einwand hat wie ich: Die Größe der Stories kann immer mal variieren, diese Unregelmäßigkeit gleicht sich aber über die fortlaufenden Sprints hinweg aus. Nach der mir gegebenen Info habe der schlaue Herr Duarte zwei Varianten der Sprint-Beobachtung genutzt: Abarbeitungsgrad mit seiner neuen Methode mit der reinen Zählung (gut geschnittener) Stories versus Abarbeitungsgrad gemäß klassischer Story Point-Schätzung. Hier ist das Ergebnis aus einem seiner Projekte /9/:
(Quelle: Bildschirmabdruck der Folien Vasco Duartes aus dem in den Quellen angegebenen, auf Youtube verfügbaren Vortrag)
Die Story-Point-Schätzung zeigt Überschätzung der eigenen Leistungsfähigkeit (Vasco Duarte spricht von 20% "auf der falschen Seite"), während die Schätzung der Anzahl der Stories sogar leicht unter der tatsächlich erreichten Anzahl bleibt. Wir erinnern uns: Der Schnitt der hier gezeigten Stories beanspruchte schon Zeit, um Komplexität in jeglicher Hinsicht zu reduzieren, Risiken zu minimieren, das Wichtigste zuerst zu liefern und überhaupt in der Lage zu sein, quasi fortlaufend neuen Wert liefern zu können. Es sind also natürlich äußerst sinnvoll geschnittene Stories.
Die gleiche Analyse wie für drei Sprints wurde für den Zeitraum "fünf Sprints" wiederholt:
(Quelle: Bildschirmabdruck der Folien Vasco Duartes aus dem in den Quellen angegebenen, auf Youtube verfügbaren Vortrag)
Auf der Seite der Story Point-Schätzung zeigt sich zwar eine leichte Verbesserung, aber die Abweichung befindet sich leider immer noch auf der falschen Seite. Die Schätzung der Anzahl abgearbeiteter Stories liefert konstant eine minimale Abweichung vom tatsächlichen Ergebnis, und dies "auf der richtigen Seite", also konservativ geschätzt statt überschätzt.
Empirische Daten weiterer zahlreicher Projekte zur Untermauerung von Duartes Beobachtungen stehen zur Verfügung /10/.
Weitere Blitzlichter zum Schätzen
Schätzungen hängen vom Schätzer ab
In
einer meiner (zahllosen ;-)) Scrum Master-Weiterbildungen wurde in
einem Termin die obenstehende Sichtweise, dass Schätzungen nämlich
fragwürdig seien, noch durch weitere Informationen angereichert:
Erfahrene
Entwickler:innen schätzen Zeit anders ein als unerfahrene und arbeiten
wahrscheinlich in der Regel auch schneller und qualitativ hochwertiger
als letztere. Dazu kommt, dass, je mehr Inhalte in einem Projekt bereits
vorhanden sind, es umso schwieriger wird, neue Features hinzuzufügen,
da die Komplexität insgesamt steigt und dadurch auch immer mehr
Abhängigkeiten entstehen. Damit steigt auch die Fehlerrate (und somit
wiederum die Zeit für deren Verkleinerung). Außerdem nehmen
"Überraschungseffekte" zu, weil es mit fortschreitender Entwicklung
immer schwieriger wird, das Gesamtkonstrukt noch zu überblicken und
Konsistenz zu wahren. Solche Faktoren würden jedoch so gut wie nie
berücksichtigt. "Story Points" würden gedanklich quasi ständig lediglich
mit zeitlichem "Aufwand" gleichgesetzt, da von außen ständig nach
Deadlines gefragt wird, ohne dass aber die hier genannten Faktoren in
diesen Aufwand einfließen würden.
Wie man Schätzmetriken total missverstehen kann
In diesem o. g. Termin aus meiner Weiterbildung bekamen wir ein exotisches Praxisbeispiel erzählt:
Ein
Konzern in Indien verwendete in der Führungsetage Story
Point-Ergebnisse aus Teams zur internen Bewertung von Mitarbeitenden.
Der Auslöser dieser eigentümlichen Maßnahme war ein von der
Führungsetage nicht nachvollziehbarer Wunsch von Mitarbeiter:innen nach
Nach-Schätzungen beim (zeitlichen) Aufwand von Aufgaben, die tatsächlich
länger dauerten als ursprünglich geplant und angenommen.
Die Folgen
des o. g. "Führungsinstruments" waren folgende: War jemand krank, wurde
nicht an dessen Aufgaben weitergearbeitet (man wollte ja den anderen
keine Story Points schenken und damit womöglich deren Karrieren
befördern), es gab Silobildung, da jede:r die eigenen Aufgaben "hortete"
und nicht zusammen daran gearbeitet wurde, und nicht zuletzt
entwickelte sich eine schlechte Grundstimmung, da es plötzlich keine
Kooperation mehr gab, sondern nur noch Konkurrenz.
So kann man in Konzernen den letzten Rest Agilität, der noch nicht unter den Rädern von SAFe zermahlen wurde (ja, ich habe es wieder geschafft, diese Referenz unterzubringen! :-)), durch unpassende oder unpassend angewendete KPI zerstören.
Engpasstheorie
Ein regelmäßiger Gast des Lean Coffee Karlsruhe/Frankfurt, erfahrener Projektmanager in beiden Welten, klassisch und agil, bekundete im Juni 2025, dass er häufig nur eine einzige Kennzahl verwende: den Engpass in einem System. Natürlich kann man sich bei der Analyse dessen auch irren, aber gemäß agiler innerer Haltung könnte man dann wenigstens dazulernen und somit in Zukunft besser werden... (Zur Engpasstheorie siehe z. B. Wikipedia /11/)
Sonstige Impulse
Grundsätzliche Erfolgsfaktoren für IT-Projekte, agil oder klassisch
In einem Beitrag von Vasco Duarte taucht unter anderem auch der "Chaos Report" der Standish Group auf /12/). Dieser Report fragt: "Welches sind die wichtigsten Faktoren, die den Erfolg von IT-Projekten beeinflussen?" und findet die Antwort: "(...) Eine gute Arbeitsumgebung, ein gutes Team und ein guter Sponsor sind einige der wichtigsten Faktoren, die den Projekterfolg beeinflussen. (...)" Scrum Masters und Agile Coaches (wenn Ihr Euren Job macht/man Euch Euren Job machen lässt), ik hör' Euch trapsen... ;-)
Übrigens: Es ist über eine neue KPMG-Langzeitstudie belegt, dass Führungskräfte den Aufwand in Transformationen regelmäßig deutlich unterschätzen /13/. Warum sollte es in diesen höheren Unternehmensebenen auch anders sein als in den Teams? Schließlich arbeiten auch hier Menschen...
Prozesseffizienz ermitteln
"(...) Prozesseffizienz bezeichnet die Fähigkeit, Ressourcen wie Zeit, Geld und Material optimal zu nutzen, um maximale Leistungen in Geschäftsprozessen zu erzielen. Durch die Verbesserung der Prozesseffizienz kannst Du den Workflow effizienter gestalten und die Produktivität steigern. Effektive Strategien zur Erhöhung der Prozesseffizienz umfassen die Automatisierung redundanter Aufgaben und die regelmäßige Überprüfung bestehender Verfahren. (...)" /14/ Ein erfahrener agiler Kontakt sprach bereits vor Jahren wiederholt von der Sinnhaftigkeit, die Effizienz von Prozessen zu messen und daraus adäquate Schlüsse zu ziehen. Interessante Randbemerkung: In einen Open Space brachte ich daraufhin einmal das Thema "Prozesseffizienz" ein, weil ich das Thema noch nicht richtig greifen konnte. Mindestens die Personen, die in meine Session kamen, hatten keine eigenen Anwendungsbeispiele dafür im Gepäck und konnten bei Ansätzen für deren Berechnung in typischen Unternehmensumfeldern ("Wie fange ich an? Wie identifiziere ich geeignete Messpunkte?"... etc.) nicht wirklich weiterhelfen. Es waren alles Leute "vom Fach"... Vielleicht hatten sie alle gehofft, dass eine andere Person etwas dazu wissen würde.
Minimalistischer Ansatz: Nur noch Retrospektiven
Ein Gast unseres Lean Coffees äußerte einmal seinen Ansatz, Erfahrungen in Team(s) nur noch über Retrospektiven einzusammeln, sonst nichts. Leider sind hieraus keine konkreten Details bekannt, aber diesem Ansatz kann zumindest nicht vorgeworfen werden, die Leute mit zu viel Neuem zu überfrachten...
Walk the talk
Falls jemand eigene Erfahrung mit "no estimates" hat, freue ich mich, falls er/sie diese über Kommentare zum Artikel mit allen Leser:innen und der Autorin teilt.
Quellen
/2/ https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events
/4/ z. B. https://oikosofyseries.com oder https://scrum-master-toolbox.org/tag/noestimates/
/5/ https://t2informatik.de/blog/die-idee-no-estimates
/6/ https://www.youtube.com/watch?v=MhbT7EvYN0c, ab 3:56
/7/ https://www.neilkillick.com/blog/the-essence-of-story-slicing-in-agile-development
/9/ https://www.youtube.com/watch?v=cgvB2wWvi8M
/10/ http://bit.ly/NoEstimatesProjectsDB
/11/ https://de.wikipedia.org/wiki/Theory_of_Constraints
/12/ z. B. https://thestory.is/de/journal/chaos-report
/13/ https://klardenker.kpmg.de/financialservices-hub/transformation-erfolgreich-gestalten-2
Kommentare
Kommentar veröffentlichen