+43-676-330-4803KontaktImpressum en de

Blog

Ampel, reloaded

Bei Ultimate Software in Florida gibt es ein interessantes Ampelsystem. Die Ampellogik funktioniert basierend auf einem probabilistischen Forecast: Beträgt die Wahrscheinlichkeit 90 Prozent oder mehr, dass das Team das Backlog bis zum Releasetermin abarbeitet, steht die Ampel auf Grün. Auf Gelb bei einer Wahrscheinlichkeit zwischen 70 und 90 Prozent und auf Rot bei einer Wahrscheinlichkeit von 0 bis 70 Prozent. Das hat den großen Vorteil, dass man immer und vor allem frühzeitig den tatsächlichen Zustand eines Projekts völlig transparent erkennen kann. Niemand kann den Stand der Dinge beschönigen – nur was fertig ist, macht die Ampel grüner. Es zahlt sich übrigens definitiv aus, die Ultimate Case Study von  Steve Reid, Prateek Singh und Dan Vacanti zu lesen.

Wie ihr euch wahrscheinlich vorstellen könnt, ist das Thema Forecasting in meinen Trainings immer ein vieldiskutiertes Thema. Und man kann es drehen und wenden wie man will: Obwohl damit in den seltensten Fällen überschwänglich positive Erfahrungen verbunden sind, stehen die Leute auf Projekt-Ampeln.

Das kann ich verstehen, und gerade weil die Ampel so beliebt ist, würde ich sie gerne auf den Kopf stellen. Die Schwierigkeit ist doch (und eigentlich ist es sogar vollkommen schräg): Man startet ein Projekt mit Grün, obwohl zu diesem Zeitpunkt die höchste Unsicherheit besteht. Damit die Sache noch etwas schwieriger wird, sind die Anreize für Projektmanager mit dem Status Grün verknüpft. Je länger man die Grünphase halten kann, desto besser ist der Projektleiter. Wenn man die Schwierigkeiten nicht mehr vertuschen kann, springt die Ampel auf Rot – zwei Wochen vor Projektende. Jetzt hat man natürlich keine Zeit mehr zu reagieren und das Projekt wird gekonnt an die Wand gefahren.

Was passiert de facto in den meisten Projekten: Weil die Projekte auf Grün starten, sind die Verantwortlichen in der ständigen Versuchung, das Risiko nach hinten zu puffern. Wie gesagt, ist der Projektbeginn die Phase der höchsten Unsicherheit. Also starten wird doch einfach auf Rot, wenn wir die Ampel unbedingt haben wollen! Dann heißt es nämlich, zu arbeiten und die Arbeit immer wieder genau anzusehen, damit die Ampel auf Grün springt und auch grün bleibt. Die Fortschritte, genauso aber die Probleme werden dann rechtzeitig sichtbar und man kann die Risiken adressieren.

Was meint ihr? Was hindert uns daran, die Ampel umzudrehen?

Lean Business Agility E011: Backlog Management bei TOP@SBB mit Michael Beyer

In Episode 011 von Lean Business Agility bin ich zu Gast bei Michael Beyer von den Schweizerischen Bundesbahnen (SBB) in Bern und wir unterhalten uns über ihr Backlog-Management. Mikes Bereich spielt eine zentrale Rolle innerhalb der SBB, da bei ihm Topologie-Daten des Schienennetzes (Signale, Weichen, Geschwindigkeiten, etc.) zusammenlaufen, damit man eine Vorhersage machen kann, auf welchen zum Beispiel die Fahrzeitberechnung für Planung und Prognose basiert. In der Natur dieses Bereichs liegt, dass er sehr viele Stakeholder hat und deswegen ein Backlog-Management ein sehr wichtige Aufgabe ist. Wie Mike das macht, erzählt er in diesem Video.

Abonniert den YouTube Kanban von Lean Business Agility, den Podcast bei iTunes oder holt euch den RSS Feed.

Lean Business Agility E010: Maslow’s Take on Management mit Marc Burgauer

In dieser Episode spricht Marc Burgauer über Maslows Management-Ideen. In der Wissensarbeit weiß die Mitarbeiterin mehr über ihren Job als ihr Manager. Der Manager als Informationsvermittler wird somit stark in Frage gestellt. Marc hebt Maslows Einblicke hervor, wie Organisationen Menschen verwandeln und befähigen können.

Holt euch das Buch Eupsychian Management von Abraham H. Maslow: http://amzn.to/2qWrDwD

Abonniert den YouTube Kanban von Lean Business Agility, den Podcast bei iTunes oder holt euch den RSS Feed.

Praktische Erfahrung mit Blocker Clustering

Blocker Clustering – ein Thema, das mich seit einigen Jahren beschäftigt, darf natürlich auch nicht im neuen Buch Kanban in der Praxis fehlen. Neben einer detaillierten Erklärung, wie Blocker Clustering funktioniert und was man damit erreichen kann, gibt es auch ein Interview mit einem intensiven Anwender: Matt Philip, Director of Learning and Development bei ThoughtWorks in St. Louis, Missouri. Dieses Interview gibt es als quasi Appetizer auch hier im Blog nachzulesen. Viel Spass!


Klaus: In welchem Kontext wendest du Blocker Clustering an?

Matt: Meine Organisation entwickelt maßgeschneiderte Software für unsere Kunden. Daher gibt es bei uns mehr als 30 kleine, crossfunktionale Teams für verschiedene Domänen, von der Gesundheitsfürsorge über den Handel und Produkten für Mobile Apps bis hin zu großen Systemintegrationen.

Klaus: In der Realität von Kanban-Systemen begegnet man den unterschiedlichsten Auffassungen darüber, was eine Blockade ist. Wie habt ihr das für euch definiert?

Matt: Ich rate jedem Team, für sich selbst die passende Definition zu finden, also eine, die in den jeweiligen Kontext passt. Aber ich gebe den Teams auch immer eine Standarddefinition, die ich mir aus dem Buch „Kanban from the inside“ von Mike Burrows geliehen habe: „Eine Blockade ist ein anormaler Zustand, der ein bereits committetes Work Item vom Fortschritt abhält.“ Das erfordert üblicherweise eine Antwort auf die Frage: „Wo liegt unser Commitment-Punkt?“ Ich zum Beispiel würde ein Item nicht als blockiert betrachten, wenn es noch im Backlog liegt. Eines der Teams, mit denen ich gearbeitet habe, hat am Anfang die Storys immer blockiert, wenn es zum Mittagessen gegangen ist. Ich habe die Mitglieder dann darauf hingewiesen, dass das Mittagessen kein anormaler Zustand ist.

Klaus: Wenn ihr Blockaden-Cluster bildet, welche Cluster tauchen dabei immer wieder auf?

Matt: Innerhalb der beiden großen Kategorien „interne und externe Blockaden“ sehen wir oft Cluster wie „abhängige Story“, „fehlende Requirements“, „Umgebung nicht verfügbar“ und „Product Owner nicht verfügbar“. Beim ersten Versuch eines Teams hieß der größte Cluster „unbekannt“. Das war für das Team der Ansporn, das nächste Mal beim Aufschreiben der Blockaden etwas genauer zu sein.

Klaus: Welche Maßnahmen habt ihr ergriffen, um an den Ursachen der Blockaden zu arbeiten?

Matt: In einem Fall stellte sich der größte Blockaden-Cluster als internes Problem dar. Mit der Fishbone-Technik sind wir der Ursache des Problems auf den Grund gegangen und haben einige Lösungsmöglichkeiten gefunden. In einem anderen Fall war der externe Cluster auf einen Kunden zurückzuführen. Das Team machte dem Kunden die Kosten dieser Blockaden deutlich und stellte die Frage, ob das für den Kunden akzeptabel sei – das Team gab dem Kunden also eine Information, damit dieser bessere Entscheidungen treffen konnte.

Klaus: Was waren deine Erkenntnisse?

Matt: Zunächst einmal hilft Blocker Clustering einem Team dabei, überhaupt über die Auswirkungen von Blockaden nachzudenken. Viele Menschen sehen Blockaden ja einfach nur als Ärgernis und nicht als eine Quelle für Prozessverbesserungen. Zweitens streicht das Clustering heraus, dass Blockaden etwas kosten. Im Falle eines Kunden, dessen Product Owner nie verfügbar war, war den Beteiligten nicht klar, dass sie damit große Verzögerungen verursachten und das Team nicht zum Spaß immer wieder Erinnerungen schickte. Solche Blockaden in Tagen zu quantifizieren, schafft sehr schnell ein größeres Bewusstsein für die Auswirkungen des eigenen Handelns. Viele Teams beschäftigen sich intensiv mit dem Schätzen und der Größe der Work Items, vergessen aber dabei, dass schlussendlich Blockaden die Lieferung und die Vorhersagbarkeit stark beeinflussen werden. Blocker Clustering hilft ihnen, systemisch verursachte Blockaden zu erkennen und für die Zukunft zu berücksichtigen oder überhaupt zu vermeiden.

Klaus: Welche Verbesserungen hast du beobachtet?

Matt: Wie jede Technik kann das Blocker Clustering nur zeigen, wo das Problem liegt, und dabei helfen, dieses Problem zu quantifizieren. Es liegt am Team, die Information entsprechend zu verwenden. Ein Team kämpfte zum Beispiel mit Blockaden durch voneinander abhängige Storys. Daraufhin entstand die Idee, die Arbeiten anders zu selektieren, indem wir WIP-limitierte Feature-Swimlanes am Kanban-Board anlegten. Auf der Ebene der Organisation kristallisierten sich Blockaden heraus, die sich über sämtliche Teams rund um Storys erstreckten, die nicht fertig für die Entwicklung waren. Also haben wir im Management ein Gespräch über die Teamstrukturen begonnen und darüber, ob in einigen Teams eine neue oder andere Rolle gebraucht wird. Blocker Clustering kann also Verbesserungen auf mehreren Ebenen anstoßen.


Das Interview und eine genaue Erklärung zur Blocker Clustering gibt es im Buch Kanban in der Praxis, Hanser Verlag, 2016

Noch mehr Material zum Thema Blocker Clustering: