Feature Flow - Erhöhung der Geschwindigkeit mit Kanban

Vor einigen Monaten wurde ich in ein Software-Entwicklungsteam aufgenommen, das einige Probleme hatte, seinen Prozess richtig zu gestalten. Das Team arbeitete nach den Regeln von Scrum. Abgesehen von regelmäßigen Produktionsfreigaben wurde alles gemacht: Sprints, Planung, Retrospektiven, Scrum Board usw. Dieses Team brauchte nicht allzu viele Erklärungen zu Scrum, so dass ich mich sofort in die Entwicklung stürzen konnte, zumindest dachte ich das. Sie hatten Probleme, die Sprints richtig hinzubekommen, ihre Geschwindigkeit nahm ab und die Stimmung war schlecht. Glücklicherweise gelang es uns, unseren Prozess zu ändern, indem wir einige grundlegende Scrum-Praktiken änderten und einige davon durch Lean-Praktiken ersetzten, inspiriert durch die neuen Kanban-Artikel und -Präsentationen. Die Produktivität ist jetzt höher als je zuvor und wir können uns jetzt auf das konzentrieren, was wirklich wichtig ist: Produktqualität und Kundenzufriedenheit.

Laufende Arbeiten Als ich bei diesem Team anfing, gab es ein großes Problem: Dinge zu erledigen. Das Hauptsymptom war die Frustration des Managements und des Teams über das Projekt. Die erste 3-Wochen-Timebox (Sprint) endete mit etwa 30% (!) aller Funktionen, die noch in Arbeit waren, obwohl sie natürlich alle fertig und versandbereit sein sollten. Die bisherige Lösung für dieses Problem bestand darin, die erwartete Geschwindigkeit in jedem Sprint zu senken, damit der nächste Sprint pünktlich stattfinden konnte. Aber am Ende des nächsten Sprints trat das gleiche Problem auf, so dass die Geschwindigkeit von Sprint zu Sprint sank. Die Besprechungen zur Sprintplanung waren nicht sehr angenehm, da das Team durch das fehlende Engagement stark belastet wurde und der Rest der Organisation immer noch Druck ausübte, damit das Team sein Tempo beibehielt. Dieser Druck von beiden Seiten erdrückte die Moral. Das Team reagierte auf den Druck, indem es härter arbeitete. Die meisten Mitarbeiter hatten 2 oder 3 Aufgaben gleichzeitig in Arbeit. Wenn ein Entwickler eine Aufgabe abschloss, waren die Tester zu sehr damit beschäftigt, etwas anderes zu testen, so dass sie dem Entwickler direktes Feedback geben konnten. Wenn der Tester ein Problem mit einer neuen Funktion fand, arbeiteten die Entwickler bereits an etwas anderem, so dass der Tester warten musste. Einfach ausgedrückt: Es wurde zu viel Wert auf lange und harte Arbeit gelegt, nicht auf Zusammenarbeit und das, was wirklich wichtig ist: Funktionen. Ich glaube, dass die meisten dysfunktionalen Verhaltensweisen von dem System herrühren, in dem sich die Menschen befinden, daher habe ich mich zunächst mit dem größten Problem dieses Teams befasst: Druck und Vorhersehbarkeit. Die meisten Scrum-Master fordern das Team auf, in jedem Sprint die gleiche (oder eine höhere) Geschwindigkeit zu erreichen. Dieser Druck sollte ein Team dazu bringen, sein Bestes zu geben. Es kann aber auch schiefgehen, wenn das Team nicht liefert. Kein Fokus, kein Stolz, kein zufriedener Kunde. Die Folge für dieses Team war, dass die Retrospektiven schlecht waren und die Planungsbesprechungen eine große Belastung darstellten. Die Produktivität des Teams sank in den Tagen nach dem Sprint und es brauchte neuen Mut, um den nächsten Sprint zu beginnen. Da sie einen ineffektiven Arbeitsprozess hatten, bestand das einzige Ergebnis jedes Sprints darin, die erwartete Geschwindigkeit zu senken, um sicherzustellen, dass wir berechenbar waren. Schätzung und Vorhersagbarkeit sind nur ein Mittel zum Zweck, und da sie der Beseitigung der eigentlichen Ursache im Wege standen (und die Stimmung im Team drückten), beschloss ich, die Planungssitzungen und Sprinttermine zu streichen. Kanban Die Lösung wurde von Corey Ladas' Präsentation auf der Agile2008 über Kanban inspiriert. Eines der Werkzeuge, die Corey zu seinem Projekt hinzufügt, ist eine Begrenzung der "in Arbeit befindlichen Aufgaben". Das war genau das, womit das Team zu kämpfen hatte (erinnern Sie sich an den großen Haufen unerledigter Aufgaben?). Die erste Änderung, die wir vornahmen, bestand also darin, die Spalte 'in Arbeit' auf 8 Aufgaben zu begrenzen. Wir haben 3 Wochen damit verbracht, die Zahl der offenen Aufgaben von 21 auf 8 zu senken, ohne dass wir neue Arbeit aufgenommen haben. Natürlich fiel es dem Team schwer, mit dieser neuen Grenze zurechtzukommen. Sie waren es gewohnt, immer dann neue Arbeit aufzunehmen, wenn sie irgendwie blockiert waren, das war nun nicht mehr erlaubt. Es dauerte einige Zeit, bis das Team wirklich lernte, dass die Aufnahme von zu viel Arbeit einen Rückfall in die überlastete Arbeitsweise bedeuten würde. Dem Impuls zu widerstehen, den WIP zu erhöhen, ist immer noch eine Disziplin, aber wir halten uns jetzt gegenseitig im Zaum. Dadurch konnte sich das Team stärker darauf konzentrieren, Dinge zu erledigen und die systemischen Probleme (Hindernisse) beim Fluss der Features zu erkennen. Wir haben den Begriff Feature Flow verwendet, um das Ziel des Teams zu beschreiben: Features sollen ohne Unterbrechungen durch das Team fließen. Jedes Feature, das sich in einem Wartezustand befindet oder einfach mehr als ein paar Tage braucht, wird analysiert. Es wird so schnell wie möglich erledigt, indem weitere Teammitglieder hinzugezogen werden. Wenn wir feststellen, dass eine Funktion nicht vorankommt, nehmen wir nicht noch mehr Arbeit auf, sondern versuchen, die Ursache dafür zu finden und zu beheben. Aus genau diesem Grund haben wir die Qualität und die Möglichkeiten unserer Build-Umgebung einige Male verbessert: um zu verhindern, dass unser Funktionsfluss in Zukunft blockiert wird. Als wir das Limit für die Anzahl der laufenden Arbeiten einführten, haben wir auch vorübergehend keine Planungstreffen mehr abgehalten, denn unser erstes Ziel war es, die Anzahl der laufenden Arbeiten auf 8 zu reduzieren. Der interessante Nebeneffekt war, dass wir einige Wochen lang arbeiten konnten, ohne dass eine Planungssitzung nötig war. Also haben wir die Planungssitzung mit festem Termin gestoppt und durch eine Ad-hoc-Planungssitzung ersetzt, wann immer das 'Sprint-Backlog' austrocknete. Ausgehend von unserem grob geschätzten Produkt-Backlog stellte unser Product Owner in jeder Planungssitzung Funktionen im Wert von ein paar Tagen vor. Das Tolle daran war, dass sich die Prioritäten im letzten Moment ändern konnten, solange das Team noch nicht mit der Arbeit an einer Funktion begonnen hatte. Da die Sprint-Planungssitzungen immer recht anstrengend waren, hielten die nur einstündigen Planungssitzungen die Energie des Teams konstant.Dieser einfache Kanban-Prozess funktionierte ziemlich gut und unsere Geschwindigkeit stieg wieder auf ein anständiges Niveau. In meinem nächsten Blog werde ich einige zusätzliche Verbesserungen erläutern, die wir vorgenommen haben, wie wir die Tester und Entwickler dazu gebracht haben, synchron zu bleiben und warum wir wieder eine leichtgewichtige Planung eingeführt haben.