Direkt zum Hauptbereich

Disruption Points

Nicht alle Teams haben das Glück sich nur um ihr aktuelles Projekt kümmern zu können. Oft gibt es Altlasten wie kritische Bugs in anderen Systemen oder Betriebsprobleme usw. welche von dem Team auch behandelt werden müssen. Die meisten dieser Punkte sind kritisch genug, um nicht bis zum nächsten Planning warten zu können.

Oft tröpfeln die Tasks so im Tagesverlauf ein und werden, da es wichtig ist und auch nicht so viel, nebenbei erledigt.

Alles eigentlich kein Problem und man könnte sagen, dass es geht einfach in der Velocity mit auf. Wenn man nun aber doch mal einen Überblick haben möchte, wie viel das denn nun in einem Sprint ausmacht, dann kann man diese Unterbrechungen via "Disruption Points" festhalten und visualisieren.

Dazu bekommt jedes Teammitglied ein paar Klebepunkte. Nach jeder Unterbrechung klebt der entsprechende Entwickler einen seiner Punkte auf das Chart.

Das Chart führt auf der x-Achse die Tage der Iteration  und auf der y-Achse die Minuten, welche die Unterbrechung gedauert hat.


Der Punkt wird auf der x-Achse bei dem entsprechenden Tag und auf der y-Achse bei der Anzahl der für die Unterbrechung benötigten Zeit platziert.

Für jede Unterbrechung sollte ein eigener Punkt verwendet werden.

Wer es detaillierter benötigt, kann in der Punktfarbe variieren. z.B. für jedes Teammitglied oder je nach Art der Unterbrechung.

Bei der Auswertung ist zu beachten, dass mehrere kleinere Unterbrechungen grössere Auswirkungen haben können als eine Große.

Kommentare

  1. Das finde ich eine gute Idee! Hast Du schon praktische Erfahrungen damit gesammelt?

    AntwortenLöschen
  2. Ich bin gerade dabei und werde nach ein paar Iterationen berichten. Über weitere Erfahrungen (hier als Kommentar) würde ich mich natürlich auch freuen!

    AntwortenLöschen

Kommentar posten

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte. Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen ve rteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Mit dem Rücken am Tellerrand

Es ist gut auch mal über den Tellerrand zu schauen. Manchmal sind wir so in "unserer Welt" gefangen, dass wir den Rest gar nicht mehr wahr nehmen. Zum Beispiel muss ich mich immer wieder daran erinnern, dass nicht alle Menschen mindestens ein Smartphone haben. Oder das agile noch lange nicht Mainstream ist. Nur weil wir uns in einem Umfeld bewegen, in dem die Dinge so scheinen wie sie sind, heißt das noch lange nicht, dass dem auch so ist. Ein Typisches Beispiel für den Unterschied von Realität und Wahrnehmung der Realität. Aber auch um neuen Ideen eine Chance zu geben, welche scheinbar nicht funktionieren können, weil sie nicht in unsere Gedankenwelt passen ist es sinnvoll ab und an über den Tellerrand zu schauen. Heute habe ich noch einen Tweet, welcher darauf hinweist gesehen: Wenn uns das einmal bewusst geworden ist, dann neigen wir (oder zumindest geht es mir so) dazu möglichst oft über diesen Tellerrand zu schauen. Dabei kann es aber passieren, dass wir so

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität. Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus: Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit. Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist. (Was nun was bedingt, lass ich mal dahingestellt) Dadurch haben sich natürlich auch di