+43-676-330-4803KontaktImpressum en de

Posts Taged Metriken

Lean Business Agility E029: Initial Forecast

Die Situation kennt sicher jeder: Eine Person kommt bei der Tür herein und sagt: “Wir müssen ein Angebot für ein Projekt erstellen und müssen wissen, bis wann ihr es fertigstellen könnt.” Oder auch ganz hoch im Rennen ist die Frage: “Bis wann könnt ihr dieses Feature liefern?” In dieser Episode spreche ich mit Troy Magennis darüber, wie man einen initialen Forecast erstellt, um eine Antwort auf diese Anfragen zu erhalten.

Troy ist Berater für Metriken und Forecasting.

Sorry für die schlechte Bildqualität. Es regnete in Strömen und der dunkle Kinosaal war der einzig ruhige Ort, den wir finden konnten.


Lean Business Agility Video BlogAbonniert den YouTube Kanal von Lean Business Agility oder den Podcast bei iTunes oder Overcast oder holt euch den RSS Feed.

Lean Business Agility Youtube ChannelLean Business Agility iTunes PodcastLean Business Agility Overcast PodcastLean Business Agility RSS Feed

Lean Business Agility E024: #ContinuousForecasting

Ihr wollt wissen, wie es funktioniert, wenn ~50 Entwicklungs-Teams, gesamt ~900 Personen keine Schätzungen machen sondern wissen, wenn Arbeit fertig wird? Dann schaut euch diese Episode von Lean Business Agility an – #ContinuousForecasting mit Prateek Singh.

Prateek Singh ist Principal Agile Coach bei Ultimate Software in South Florida, USA.

Abonniert den Lean Business Agility YouTube Channel oder den iTunes Podcast oder den Overcast Podcast oder den RSS Feed.

Little’s Law und Systemstabilität: Ein Interview mit Daniel Vacanti

Daniel S. Vacanti ist ein Softwareveteran. Er hat als Java Developer/Architect begonnen und arbeitet seit über 15 Jahren mit Lean und Agile-Methoden. Dan war ganz wesentlich daran beteiligt, Kanban zu entwickeln, und war 2007 im ersten Kanban-Projekt involviert. Mit seinem Unternehmen „Actionable Agile“ hat er sich auf Prognose-Tools spezialisiert und er ist der unbestrittene Meister flussbasierter Metriken.

Klaus: Du bist einer der Experten für flussbasierte Metriken und du hast dich mit Little’s Law intensiv beschäftigt. Warum ist Little’s Law so wichtig?

Dan: Die kurze Antwort lautet: Es ist nicht wichtig. Oder besser gesagt, es ist nicht auf die Art und Weise wichtig, wie viele Leute denken. Vergiss einfach die Mathematik. Meistens wird Little’s Law deterministisch verwendet: Die Zahlen werden eingesetzt und Little’s Law spuckt dann die Antwort aus. Bei dieser Herangehensweise gibt es zwei Probleme:

  1. Little’s Law blickt in die Vergangenheit, nicht in die Zukunft – dazu später mehr.
  2. Little’s Law ist in Kontexten hilfreich, in denen man nur zwei Metriken messen kann, während die dritte zu schwierig, zu teuer oder zu schwierig und zu teuer zu messen ist. In unserer Welt ist es sehr einfach, alle drei Flussmetriken zu messen, also sollte man Little’s Law nie für Berechnungen nutzen. Die fehlende Flussmetrik selbst genau zu messen, ist in diesem Fall der richtige Weg.

Trotzdem ist es wichtig, die Annahmen zu verstehen, die zusammenspielen müssen, damit Little’s Law funktioniert. Es ist nicht nur eine Gleichung, es ist eine Gleichung und ein Set von Annahmen. Mein Rat ist: Vergesst die Gleichung und fokussiert euch auf die Annahmen. Denn sie sind eine Richtschnur für die Policies, die zuerst etabliert sein müssen, damit ein Prozess vorhersagbar wird. Natürlich unter der Annahme, dass man auf Vorhersagbarkeit Wert legt.

Klaus: Wenn es um Metriken geht, wollen die meisten gleich mitten in sexy Themen wie das probabilistische Forecasting springen. Ist das deiner Meinung nach ein guter Startpunkt?

Dan: Das Problem dabei ist meistens, dass man für Dinge wie Monte-Carlo-Simulationen das Wissen um die Systemstabilität voraussetzen muss. Hier zeigt Little’s Law, was in ihm steckt. Folgt der Prozess den Annahmen von Little’s Law, dann weist der Prozess auch eine gewisse Stabilität auf und man kann allmählich damit beginnen, ausgefeiltere Techniken wie eben eine Monte-Carlo-Simulation ins Spiel zu bringen. Wenn aber der Prozess die Annahmen von Little’s Law immer wieder bricht, dann ist der Prozess per definitionem instabil und jegliche Art von Forecast – ob probabilistisch oder anders – ist äußerst fragwürdig. Deswegen gefällt mir auch dein Ansatz in diesem Buch sehr gut: Du etablierst zunächst eine sehr einfache Metrik, um Feedback über die Stabilität des Systems zu bekommen.

Klaus: Die eigentliche Formel zu Little’s Law lautet L = λ×W, aber wir verwenden DLZ=WIP/DS (DLZ: Durchlaufzeit; DS: Durchsatz). Worin liegt der Unterschied bzw. was sind die Konsequenzen daraus?

Dan: Eigentlich sind beide Formeln legitime Definitionen von Little’s Law, wenn man davon ausgeht, dass die Beziehung von Durchschnittswerten betrachtet wird. Der Unterschied liegt in der Perspektive: L = λ×W betrachtet den Prozess aus der Sicht der Ankünfte im System. DLZ=WIP/DS beleuchtet den Prozess hingegen aus der Sicht der Abflüge. Obwohl beide Formeln Little’s Law repräsentieren, macht der Wechsel der Perspektive den großen Unterschied. Wie ich bereits gesagt habe, gibt es zwei Seiten: die Gleichung und die Annahmen hinter der Gleichung. Die Annahmen hinter DLZ=WIP/DS sind andere als bei L = λ×W. Das ist wichtig zu wissen, denn wie ich gesagt habe, versteht man Little’s Law nur, wenn man die Annahmen dahinter versteht. Zuerst muss man sich darüber im Klaren sein, ob man sich mehr um die Ankünfte oder um die Abflüge kümmern will, denn diese Perspektive hat Einfluss auf alle Policies, die man für Vorhersagen heranzieht.

Klaus: Wie können die Leser und Leserinnen dieses Buchs Little’s Law in ihrer täglichen Arbeit mit Kanban-Systemen einsetzen?

Dan: Indem sie die Annahmen dahinter verstehen und in ihren Prozessen Policies etablieren, durch die diese Annahmen nur minimal verletzt werden. Wie gesagt, wenn die Vorhersagbarkeit eine wesentliche Rolle spielen soll.

Klaus: Wie sehen diese Annahmen also aus?

Dan: Wenn man die Durchsatzversion von Little’s Law verwendet, geht man von den folgenden fünf Annahmen aus:

  1. Die durchschnittliche Input- bzw. Ankunftsrate sollte gleich wie die durchschnittliche Output- oder Abflugsrate sein.
  2. Jede Arbeit, die gestartet wird, wird irgendwann fertiggestellt und verlässt das System auch wieder.
  3. Der Work in Progress sollte am Anfang und am Ende des für die Berechnung herangezogenen Zeitintervalls einigermaßen gleich sein.
  4. Das durchschnittliche Alter des Work in Progress nimmt weder zu noch ab.
  5. Durchlaufzeit, Work in Progress und Durchsatz müssen mit konsistenten Einheiten gemessen werden. Man sollte also zum Beispiel nicht für die Durchlaufzeit den Tag als Einheit verwenden und für den Durchsatz die Woche.

Am besten ist es, sich einen Moment Zeit zu nehmen und über den eigenen Prozess nachzudenken: Hat man die Ankunfts- und Abflugsrate von Arbeit im Auge oder kommt Arbeit schneller ins System, als sie fertiggestellt wird? Um das festzustellen, kann man zum Beispiel die in diesem Buch vorgestellte Stabilitätsmetrik verwenden. Achtet man darauf, wie alt die Arbeitseinheiten sind, an denen gerade gearbeitet wird, oder bleiben Arbeiten über willkürliche Zeitspannen liegen? Wenn man sich diese Dinge nicht ansieht, bricht man die Prinzipien von Little’s Law. Jedes Mal, wenn man einer der grundlegenden Annahmen zuwiderhandelt, wird der Prozess instabiler. Je instabiler der Prozess wird, desto schwieriger wird es, einen genauen Forecast zu erstellen. In meinem Buch „Actionable Agile Metrics for Predictability“ geht es in erster Linie darum, stabile Prozesse auf Basis von Little’s Law zu schaffen, um genaue Forecasts erstellen zu können.

Klaus: Warum kann man nicht einfach die Formel von Little’s Law verwenden, um Forecasts zu erstellen?

Dan: Das hat zwei Gründe. In erster Linie kann man mit Little’s Law keine Forecasts anstellen, weil Dr. Little selbst gesagt hat, dass man es nicht kann: „However, let it be noted that the determinism and exactness are after the fact, i.e., the sample path is known. This is not all bad. It just says that we are in the measurement business, not the forecasting business.” Wer Little’s Law für das Forecasting einsetzen will, ist auf dem Holzweg, weil es speziell für den Rückwärtsblick auf Basis bereits gesammelter Daten entwickelt wurde – nicht für eine Vorausschau, bei der es viele verschiedene Ausgänge geben kann.

Aber selbst wenn man Little’s Law für das Forecasting einsetzen könnte, würde man das nicht wollen. Es basiert auf dem Verhältnis von Durchschnitten. Es gibt ein exzellentes Buch, das diesen Punkt detailliert behandelt: „The Flaw of Averages“ (vgl. Savage 2012). Das Tückische an den Durchschnitten ist im Wesentlichen, dass auf Durchschnitten basierende Pläne im Durchschnitt scheitern. Selbst wenn man einfach zwei Zahlen in die Formel einsetzen könnte, damit sie eine dritte Zahl als Forecast ausspuckt, sollte man im Hinterkopf behalten, dass die dritte Zahl nur einen Durchschnitt angibt – und Durchschnitte haben für einen Forecast keinen Nutzen.

Klaus: In deinem Buch schreibst du über „Flow debt“ – auf Deutsch könnte man etwas holprig „Flussschuld“ dazu sagen. Kannst du erklären, was du damit meinst?

Dan: Flow debt bedeutet einfach, dass man sich Durchlaufzeit von einer Arbeitseinheit im Arbeitsprozess „leiht“, um sie einer anderen Arbeitseinheit im Arbeitsprozess zu geben. Kurzfristig kann man den Prozess dadurch beschönigen, weil bestimmte Arbeiten schnell durch den Prozess gepusht werden. Langfristig trägt diese Strategie aber nur dazu bei, den Prozess weniger vorhersagbar zu machen. Express-Tickets sind dafür das beste Beispiel: Sobald Teams eine Express-Anfrage bekommen, unterbrechen sie meistens das, woran sie gerade arbeiten. Natürlich hat diese Policy den Vorteil, dass die Express-Tickets im Prozess schneller vorankommen und die Durchlaufzeit dieser Arbeitseinheiten sieht auch gut aus. Diese schöne Durchlaufzeit hat aber ihren Preis: Bei allen anderen Arbeiten, die für das Express-Ticket gestoppt wurden, erhöht sich die Durchlaufzeit. Irgendwann muss diese Schuld beglichen werden und das passiert in Form von schlechterer Durchlaufzeit der verspäteten Arbeiten, wenn sie dann endlich fertiggestellt werden. Bessere Durchlaufzeit, die zum Preis schlechterer Durchlaufzeit erkauft wird, bezeichne ich als „Flow debt“. Jedes Mal, wenn man bestimmte Arbeitseinheiten in einem bereits laufenden Arbeitsprozess bevorzugt behandelt, entsteht Flow debt. Der Preis, den man dafür bezahlt, ist die wachsende Unvorhersagbarkeit des Systems.


Dieses Interview ist ein Auszug aus dem Buch Kanban in der Praxis, erschienen im November 2016 im Hanser Verlag.

Forecasting mit Modellen und Simulationen – Ein Interview mit Troy Magennis

Troy Magennis and Klaus Leopold at LKCE13

Klaus: Du verwendest Modelle, um unterschiedliche Zukunftsszenarien zu simulieren. Wie bist du darauf gekommen und wann setzt man Modelle und Simulationen am besten ein?

Troy: Ich habe eine elektrotechnische Ausbildung und bin damit vertraut, elektronische Schaltkreise zu simulieren. Das hat sich auch für die IT sehr passend angefühlt. Simulationen – und Monte-Carlo-Simulationen im Speziellen – werden eingesetzt, wenn es zeitlich unpraktisch oder zu komplex ist, eine mathematische Funktion zu formulieren, um ein Problem zu lösen. Simulationen schätzen das Ergebnis schnell und sie erlauben Experimente auf Basis des Modells, um zu messen, welche Maßnahmen die größte Auswirkung haben. Üblicherweise kommt die Monte-Carlo-Simulation zum Zug, wenn es in zusammenhängenden Prozessen viele Inputs gibt, die sich gegenseitig beeinflussen. Nehmen wir das Beispiel der Wettervorhersage, die du ja auch erwähnt hast: Ein kleiner Anstieg der Meerestemperatur verursacht Temperaturunterschiede, die in einem Gebiet die Regenwahrscheinlichkeit verändern. Diese Inputs verstärken sich gegenseitig und manche haben sogar Rückwirkungen auf frühere Inputs. Es ist ein komplexes System. Wir würden von der Wettervorhersage wegen dieser Zusammenhänge nie Perfektion erwarten, aber aus irgendeinem Grund erwarten wir von IT-Projekten absolute Vorhersagbarkeit, obwohl sie eine ähnlich kaskadierende Komplexität aufweisen.

Klaus: Warum ist es denn nicht einfach mit Schätzungen getan?

Troy: Ich habe sehr früh festgestellt, dass jeder Forecast und auch jede Schätzung verzerrt sind, wenn die Auswirkungen von Ereignissen wie Defektraten, zusätzlichen Anforderungen oder Unsicherheiten im Aufwand nicht simuliert werden. Traditionelle Schätzungen gehen von einem Zusammenhang zwischen Aufwand und Zeit aus, aber in komplexen Systemen kann die Arbeit auch einmal stillstehen oder aus unzähligen Gründen blockiert sein. Der Aufwand für eine Arbeit hängt dann überhaupt nicht mit den verstrichenen Kalenderwochen zusammen. Es ist also eine unpassende Relation, so als wenn ich sagen würde: Die Verspätung eines Flugzeugs wegen eines technischen Defekts hängt damit zusammen, dass ich drinsitze. Wir gehen aber immer davon aus, dass die tatsächliche Arbeitszeit einen Großteil der Lieferzeit ausmacht. Das stimmt für die meisten Softwareunternehmen und Softwareentwicklungsprozesse einfach nicht, wenn man zusätzlich zur reinen Entwicklungszeit auch noch die Zeiten für Test, Release und die Wartezeiten im Backlog mit einbezieht. Und diese Zeiten sollte man einkalkulieren, denn aus Sicht des Kunden ist die Arbeit nicht abgeschlossen, wenn die Entwicklung fertig ist, sondern wenn er sie fehlerfrei verwenden kann.

Klaus: Modelle und Simulationen – das klingt für viele im ersten Moment sehr kompliziert. Lohnt sich diese Vorgehensweise aus deiner Sicht überhaupt bzw. in welchen Zusammenhängen lohnt sie sich?

Troy: Meistens lohnt sie sich. Man muss ja etwas unternehmen, um die Ergebnisse zu erreichen. Wenn die Zahl der Mitarbeiter fixiert ist und der aktuelle Prozess kein bisschen verändert werden darf, zahlt es sich vielleicht nicht aus. Wie auch immer, selbst einfache Modelle können dabei helfen, die Auswirkungen und den Nutzen von Prozessveränderungen in Dollar oder Euros zu beziffern. Mir war es wichtig, Fragen zu beantworten und zu verstehen, welche Auswirkungen es haben würde, wenn zum Beispiel die Defektraten halbiert werden. Welche Fähigkeiten der Mitarbeiter bringen in welchen Situationen den größten Nutzen? Sind Defekte oder fehlende Testumgebungen das größere Problem? Einfache Modelle helfen, diese Fragen zu beantworten, und das geht über die traditionelle Schätzung hinaus. Die Antworten mit Geldeinheiten versehen zu können, hilft bei der Argumentation, warum eine Investition in die Veränderung wert ist, getätigt zu werden. Es hilft, gut informierte und abgewogene Entscheidungen zu treffen.

Klaus: Wie können solche Modelle aussehen?

Troy: Manchmal zeigt schon ein einfaches Spreadsheet die Auswirkung und den Nutzen eines Prozesses vorher und nachher. Ich habe früh herausgefunden, dass ich für die Antwort auf meine Fragen detailliertere Analysen anstellen musste. In meinem Fall wollte ich jeden Schritt jeder Arbeitseinheit modellieren, die den Prozess eines bestimmten Teams durchlief. Also habe ich eine einfache XML-Sprache entwickelt (SimML), mit der sich die Arbeit und der Prozess in Textform beschreiben lassen. Das sind üblicherweise 25 bis 50 Zeilen und es ist ein Mix aus Arbeit, historischen Daten und Definitionen des Teamprozesses. Wenn ich zum Beispiel eine Frage zu den Kosten von Defekten habe, spezifiziert das Modell die aktuelle Defektrate. Dann mache ich einen Forecast für das Lieferdatum und die Kosten, halbiere die Defektrate und sehe mir an, welcher Unterschied sich bei Datum und Kosten ergibt. Der Inhalt des Modells und seine Komplexität ergeben sich aus der Fragestellung. Ich kann gar nicht genug betonen, wie wichtig es ist, sich die Frage zu überlegen, bevor man ein Modell entwirft. Erst, wenn man die Fragen kennt, sollte man sich das einfachste Modell bauen, um die Frage beantworten zu können.

 

Troy Magennis arbeitet seit 1994 in der Softwareentwicklung. Er hat von der Qualitätssicherung bis zur Position des Vice President multinationaler Unternehmen sämtliche Funktionen innegehabt und hat sich vor einigen Jahren mit „Focused Objective“ selbstständig gemacht. Er konzentriert sich jetzt auf das, was ihn am meisten interessiert: Forecasting und die dazugehörigen Simulationen – vor allem Monte-Carlo-Simulationen. In diesem Bereich berät er Unternehmen wie Walmart, Microsoft, Skype oder Siemens.

Troy und ich werden diesen Winter zwei “Improving Kanban – Metrics Special” Trainings gemeinsam halten. Die Trainings sind als KMP II der Lean Kanban University zertifiziert. Meldet euch gleich an, die Plätze sind limitiert! Wien, 4.-5. Dezember und Düsseldorf, 6.-7. Dezember 2017.


Dieses Interview ist ein Auszug aus dem Buch Kanban in der Praxis, erschienen im November 2016 im Hanser Verlag.