Zuverlässige Voraussagen (Forecasts), wann größere Software-Features fertig werden:  Wer hätte das nicht gerne?

Manche Teams oder Organisationen machen seit Jahren extrem verlässliche Voraussagen zu ihrer jeweils nächsten Softwarelieferung. 

Andere versuchen es und scheinen mit ihren Voraussagen gegen eine Wand zu laufen. Irgendwann verlieren sie die Lust, es überhaupt noch ernsthaft zu versuchen. 

Den betroffenen Teams und ihren Managern ist meist nicht klar, woran es liegt: 

• Ist es der aktuell gewählte Ansatz?
  (“Schätzen wir unsere Story Points vielleicht falsch?“)
• Liegt es an mangelnder Einsicht in die Relevanz von Forecasting?
  (“Entwickler wollen einfach coden und haben auf Schätz-Meetings keine Lust”)
• Trauen die Teams sich vielleicht nicht, realistische Vorhersagen zu machen, weil dies Konflikte und Reibungen auslöst? 
• Oder liegt es an grundsätzlichen Eigenschaften der Aufgabenstellung, gegen die zumindest kurzfristig gar kein Kraut gewachsen ist?

Was steckt hinter diesen unterschiedlichen Szenarien?

Warum ist Forecasting wichtig?

In den meisten Bereichen muss es Terminabsprachen geben. Marketingkampagnen müssen abgestimmt werden, Lizenzgebühren werden fällig, Produktionsstraßen rollen an. In all solchen Fällen gibt es natürliche Termine, die Synchronisationspunkte mit dem Rest der Welt darstellen. 

Und auf der etwas dunkleren Seite gibt es immer noch den künstlichen Termin. Ein Manager hat mir sein “Erfolgsrezept” mal in der Kaffeeküche erklärt:
“Ich setze immer einen unmöglich frühen Termin, damit sich das Team nur auf das Wesentliche konzentriert.”

Woher die Termine auch kommen, von der hellen oder der dunklen Seite, eines ist klar: Verfügt ein Team nicht über das nötige Instrumentarium zum Forecasting, zum flexiblen Scoping und praktiziert damit nicht laufend faktenbasierte und effektive Termin- und Scope- Kommunikation, kommt es im Nahfeld irgend eines Termins unweigerlich zum Unheil.

Der häufigste Fall ist, dass irgendwann so viel Druck entsteht, dass das Team nach außen hin mit quietschenden Reifen liefert. Tschaka! Die Probleme dringen aber ins verborgene Innere der Software ein. Code wird nicht mehr richtig nach-strukturiert. Tests und Validierungen werden weggelassen. Manuelle Schritte werden nicht automatisiert. Man spricht von technischen Schulden. Wenn aber Druck in dieser Form endemisch ist, werden diese Schulden wahrscheinlich nie zurückgezahlt. 

Aus einem Mangel an Transparenz und entsprechender Kommunikation im Umfeld von Terminen entsteht also Druck und daraus relativ direkt schlechte Qualität.

Später wird in diesem Artikel klar werden, dass die Kausalkette auch in der Rückrichtung funktioniert. Aus verminderter Qualität folgt nämlich auch die verminderte Fähigkeit, Voraussagen zu machen. 

Eine Negativspirale kann also in Gang kommen, aus der es sehr schwer ist, auszubrechen. 

Betrachten wir dagegen den positiven Fall, in dem Forecasting gut funktioniert. Hier passiert rund um den Termin das, was sich der Manager mit dem „künstlichen Termin“ eigentlich gewünscht hatte: Eine Fokussierung. Aus der transparenten Kommunikation darüber, was fertig wird und was nicht, werden sinnvolle Entscheidungen abgeleitet. 

Diese Art der transparenten Kommunikation schafft auch Vertrauen zwischen der Stakeholder-  und Teamseite,woraus wiederum viele positive Entwicklungen folgen. 

Welche Voraussetzungen gibt es?

Kein Forschungscharakter der Arbeit

Es gibt angrenzend zur Softwareentwicklung Bereiche, in denen Forecasting fundamental nicht möglich ist  – beispielsweise manche Aufgaben in der Data Science oder der künstlichen Intelligenz.  

Diese Art von Arbeit lässt sich am ehesten mit einer Suche nach dem Haustürschlüssel in einer sehr großen Wohnung vergleichen (Forschung).  Die Dauer der Suche hängt davon ab, an wie vielen Stellen man suchen muss und man weiß nie, ob man den Schlüssel überhaupt noch findet. In einer solchen Umgebung streuen die Zeiten, in denen Wert generiert wird, so stark, dass Forecasting mit Bordmitteln nicht funktioniert. 

Interessanterweise sieht man es Aufgaben in der Softwareentwicklung von außen nicht unbedingt an, ob sie eher mit Forschung oder mit geordnetem Handwerk vergleichbar sind.  

Finden Aufgaben nämlich in einem Codebereich statt, der hinreichend kaputt und schlecht strukturiert ist, kann die Arbeit schnell mal Forschungscharakter annehmen.  

Beispiel: Eine Entwickler:in will etwas scheinbar einfaches verändern. Das klappt beim einen Mal direkt und so einfach wie erwartet. Bei der nächsten ähnlichen Aufgabe stößt die Entwickler:in aber zufällig (!) auf gravierende Hindernisse. Um diese zu umgehen,  muss sie etwas umbauen, was wiederum zufällig (!) unerwartete Konsequenzen nach sich zieht usw.  Man spricht von “Accidental Complexity”. Fachlich einfache Dinge können unerwartet(!) sehr aufwändig werden. Die Zeitdauer streut in erheblichem Maß, genau wie bei typischer Forschungsarbeit. 

Ähnlich verhält es sich mit einer Fehlersuche. Manche Fehler sind trivial und werden schnell behoben. Andere brauchen Tage und Wochen. 

In so genannten Legacy – Systemen kommen beide Dinge zusammen: Ein hohes Maß an “Accidental Complexity” und häufig entstehende Fehler. Forecasting ist hier kaum noch möglich. 

Die Rolle von Craftsmanship in der Software

Ganz anders im handwerklich hochwertigen Bereich der Softwareentwicklung (Craftsmanship). Hier gestaltet das Team (oder mehrere Teams) ein Produkt, dessen lineares (!) Anwachsen über die Zeit zu beobachten ist und dessen letztendliche Größe und Gestalt zunehmend abschätzbar wird.  

• Fehler werden nicht nachträglich gesucht, sondern durch gründliche Tests vor(!) der Entwicklung vermieden (Test Driven Development oder TDD).
• Accidental Complexity wird kontinuierlich abgebaut, indem die Software laufend restrukturiert (aufgeräumt) wird. Refactoring ist Teil von TDD. 
• Regressionsfehler werden durch einen hohen Grad der Testautomatisierung vermieden.
• Integrationsrisiken werden durch kontinuierliches, automatisiertes Integrieren laufend adressiert.
• Akzeptanzprobleme werden durch kontinuierliche Lieferung von nutzbaren Features und entsprechendes frühes Feedback vermieden.

Das Team behält so nachhaltig die Kontrolle und verhindert das Abgleiten in den Legacy-Bereich.

Software Craftsmanship ist also mehr als die halbe Miete, wenn es um die Fähigkeit eines Teams geht, gutes Forecasting zu machen. 

Weitere Voraussetzungen zum Forecasting 

Forecasting hat aber noch ein paar zusätzliche Voraussetzungen, die ich hier kurz erwähnen will. 

Einfach gesagt müssen sich zukünftige Inkremente mit den bereits fertiggestellten vergleichen lassen.

Einige Fragen, mit denen man das eigene Umfeld überprüfen kann:

• Welche Qualitätsaspekte wurden bisher bei Inkrementen überprüft, welche sollen erst später zum Release überprüft werden? Steht z.B. zum Schluss noch ein Penetrationstest durch eine Sicherheitsfirma an, müsste man das Forecasting evtl. noch unter Vorbehalt stellen. 
• Wie aussagekräftig ist das bisherige Nutzerfeedback?
• Spielen sich kommende Inkremente evtl. an neuen technischen Schnittstellen, neuen Subsystemen oder in neuen Programmiersprachen ab?
• Wie vergleichbar sind organisatorische Abhängigkeiten und Schnittstellen?
• Wie vergleichbar sind zukünftig zu verarbeitende Daten mit den bisherigen?
• Wie vergleichbar ist die Teamzusammensetzung bisher und in Zukunft?

Oft hat man bezüglich all dieser Fragen für eine gewisse Zeit z.B. für ein paar Wochen oder Monate stabile Verhältnisse. Ich nenne das eine semi-stabile Umgebung. Man kann im Team laufend neu schätzen und lernen. Was dann funktioniert, ist das sogenannte  „Rolling Wave Forecasting”. Selten oder nie hält diese Stabilität über einen längeren Zeitraum hinweg. Jahrespläne sollte man in der Regel nicht zu ernst nehmen oder schlicht darauf verzichten. 

Sehr gute Teams (und insbesondere Product Owner) setzen sich mit diesen Unwägbarkeiten intensiv auseinander und gestalten ihr Backlog laufend so, dass in jedem der unwägbaren Bereiche früh Erfahrung entsteht. 

Wie sich aus der oben aufgeführten Liste zeigt, ist Forecasting eine interdisziplinäre Sache. Es kann nur funktionieren, wenn alle Seiten mitmachen.  

Welche Metriken eignen sich?

Die bisherigen Gedanken machen klar, dass es neben den rein zeitlichen Fortschritts-Metriken für gutes Forecasting wichtig ist, laufend die „Linearität“ des Fortschritts und die Vergleichbarkeit des aktuellen mit dem zukünftigen Zustand zu prüfen. Typische Metriken zu diesem Zweck sind z.B. Defect-Count, Mean Time to Repair, Test-Coverage aber auch weichere Faktoren wie der Team Happiness Index oder UX – Metriken wie der Net Promoter Index uvm. 

Forecasting in einem Team

Für die rein zeitliche Betrachtung gibt es natürlich die berühmte Velocity, also die Rate, mit der ein Team bisher Features einer Kategorie pro Zeit fertig bekommen hat. Diese ist so bekannt, dass ich darüber gar nicht viel schreiben muss. Sie funktioniert wunderbar, wenn man ein einzelnes interdisziplinäres Team hat, das selbständig Wert schafft und alles oben Erwähnte zur Linearität und Semi-Stabilität gegeben ist. 

Forecasting im skalierten agilen Umfeld

Was muss beachtet werden, wenn mehrere Teams an einer größeren Software arbeiten und voneinander abhängen? 

Weiterhin ist inkrementelles Vorgehen mit gutem Craftsmanship im Gesamtsystem die zentrale Voraussetzung für gutes Forecasting (mit allen oben beschriebenen Methoden zu erreichen, also mit XP – Praktiken im Kleinen und DevOps Verfahren im Großen). Weiterhin funktioniert Forecasting nur mit der oben erwähnten Semi-Stabilität und auch nur für einen gewissen Zeithorizont. 

Ein wichtiger Faktor kommt im skalierten Bereich hinzu: Bei der Übergabe zwischen Teams kommt es zu Wartezeiten. Und diese Wartezeiten dominieren in aller Regel die eigentliche Bearbeitungszeit (ein typisches Verhältnis von Wartezeit zur Gesamtlaufzeit ist z.B. 80%!). Zudem streuen Wartezeiten auch erheblich. Zur Vorhersage von Features werden in diesen Fällen typischerweise Flow-Metriken aus der Kanban-Welt herangezogen, etwa die mittlere Laufzeit von Features durch alle Teams (Lead-Time), idealerweise sogar die statistische Verteilung von Laufzeiten (Lead-Time-Distribution). Warum? In den Flow-Metriken ist die Wartezeit enthalten. Velocity bezieht nur die geschätzte Arbeit von Paketen mit ein. 

Aber hier zeigt sich gleich die Schwierigkeit von skaliertem Forecasting: Daten zu Flow-Metriken kommen überhaupt erst in relevanter Zahl zustande, wenn die Wartezeiten nicht exorbitant sind. Dazu wiederum müssen die Teams entsprechenden Fokus haben, an wenigen Features gleichzeitig arbeiten (WIP-Limits). Je nach Spezialisierung leiden darunter der Durchsatz und die Auslastung. 

Neben der technischen Reife gehört hier vor allem einiges an organisatorischer Reife dazu. Ein Thema für Bücher und weitere Blogs. 

Will eine Organisation mit skaliertem Forecasting erfolgreich werden, empfiehlt es sich substanziell in Visualisierung von Wertschöpfung (nicht nur der Arbeit), Fokus, breit angelegte Kommunikation auf der Koordinations-Ebene zwischen den Teams, Metriken und kontinuierliche Verbesserung zu investieren. Wer hier nach mehr Halt sucht, ohne gleich SAFe zu installieren, kann sich den Flight Levels von Klaus Leopold zuwenden. 

Fazit

Forecasting ist überall dort überaus wichtig, wo es Termine gibt. 

In Kombination mit flexiblem Scope und proaktiver Kommunikation kann es die Gesundheit des Gesamtsystems erhalten.

Werden XP-Praktiken konsequent eingesetzt, gleitet das System niemals zum Legacy-Code ab, sondern bleibt dauerhaft linear. 

Diese Linearität ist für gutes Forecasting entscheidend. 

Darüber hinaus bedarf es der Bereitschaft und Einsicht, sich als Team interdisziplinär für das Erheben, Pflegen und Modellieren von Forecasting-Daten zu engagieren, da es noch viele andere Unwägbarkeiten, als nur die technischen gibt. 

Rolling Wave Forecasting auf einen Zeithorizont über einige Monate funktioniert dann in aller Regel. Jahrespläne sollte man weiterhin mit sehr viel Skepsis betrachten.

Ich hoffe, mein Überblick über die Welt des Forecasting war wertvoll und für die eine oder den anderen hilfreich.

Ich freue mich über Kommentare und Diskussionen.