Agil, Kanban, Scrum, Softwareentwicklung

Yes We Kanban

Yes We Kanban

In meinem aktuellen Projekt wird eine Softwarelösung für ein Versicherungsunternehmen erstellt. Wir verwenden Scrum, also: Selbstorganisiertes Team, Beobachtung und Anpassung, Product Owner, Scrum Master, Iterationen, Product Vision, Product Backlog, User Stories mit Story Points.

Die Akteure sind auf die vier Standorte Berlin, Frankfurt, Aachen und Paderborn verteilt. Die Sub-Teams eines jeden Standortes sind spezialisiert:

Berlin: Kunde
Frankfurt: Fachlichkeit
Aachen: Entwicklung
Paderborn: Scrum Master

Die dauerhafte Zusammenziehung aller Akteure an einem Standort ist nicht gegeben. Stattdessen treffen wir uns alle zwei Wochen zum Sprint Review, zur Sprint Retrospektive und zur Planung der kommenden Sprints. Es gibt Schwerpunktwochen, in denen wir uns an einem Standort treffen und kritische Themen bis zur Fertigstellung bearbeiten. Die Schwerpunktwochen wirken sich qualitäts- und produktivitätssteigernd auf unserer Arbeit aus.

Wir standen vor der Frage, wie wir unsere Arbeit in den Zeiten koordinieren, in denen wir nicht alle gemeinsam an einem Standort arbeiten. Dazu haben wir mehrere Maßnahmen ergriffen:

Telefonische Stand Up Meetings: Jeden Morgen um 09:00 findet eine 15minütige Telefonkonferenz statt, die für uns die Funktion des Stand Up Meetings übernimmt.

Elektronische Aufgabenliste: Durch die Verteilung der Teams haben wir uns gegen ein gemeinsames physisches Taskboard entschieden (also keine Zettel an den Wänden). Stattdessen haben wir im memYAK, unserer web-basierten Kommunikationsplattform, eine Aufgabenliste geführt (vgl. Abbildung „memYAK Aufgabenliste“). Dort wurde der Bearbeitungsstatus und der verantwortliche Bearbeiter gepflegt. Jedes Teammitglied konnte neue Aufgaben erstellen und bei allen Aufgaben den Status und die Verantwortlichkeit verändern. Die möglichen Statuswerte waren nicht vorgegeben, stattdessen konnte der Status als Freitext erfasst werden. Bei den Sprint Reviews wurde diese Liste überprüft. Es zeigte sich regelmäßig, dass der Status einiger Aufgaben nicht aktuell gehalten wurde und dass tatsächlich einige Aufgaben nicht erledigt waren, nur weil der Bearbeitungsstatus nicht für alle Beteiligten transparent war. Dieses Problem trat auf, obwohl die Aufgabenliste für alle Beteiligten zugänglich war und obwohl in den täglichen Stand Up Telefonaten der Aufgabenstatus besprochen wurde.

memYAK Aufgabenliste

memYAK Aufgabenliste

Elektronische Kanbantafel: Obwohl das Problem in den Sprint Reviews sichtbar wurde und wir versuchten, den Status aktuell zu halten, hatten wir immer wieder mit dieser Schwierigkeit zu kämpfen. Ich vermute, das liegt daran, dass die listenorientierte Aufgabendarstellung zur Abbildung von Arbeitsschritten nicht intuitiv genug ist. Daher wurde memYAK um eine elektronische Kanbantafel erweitert (vgl. Abbildung „memYAK Kanbantafel“).

memYAK Kanbantafel

Die wichtigsten Merkmale der Kanbantafel:

  • Die Bearbeitungsschritte, also die Statuswerte, sind konfigurierbar, so dass wir unseren Arbeitsfluss abbilden können. Zeigt sich im Verlauf der Arbeit, dass zusätzliche Arbeitsschritte explizit gemacht werden müssen, können diese einfach hinzugenommen werden. Jede Spalte in der Kanbantafel entspricht einem Status. Normalerweise durchlaufen die Aufgaben alle Arbeitsschritte von links nach rechts.
  • Jeder Arbeitsschritt kann mit einem Limit versehen werden. Das Limit gibt die Obergrenze für die Anzahl der Aufgaben an, die in einer Spalte enthalten sein dürfen. Bei der Einführung der Kanbantafel in unserem Projekt haben wir uns zunächst gegen die Verwendung von Limits entschieden.
  • Die Kanbantafel bietet die Möglichkeit der automatischen Aktualisierung. Das bedeutet, wenn im Stand Up Telefonat eines der Teammitglieder den Status einer Aufgabe verändert, wird diese Änderung auf den Bildschirmen aller anderen Teilnehmer des Stand Up Telefonates angezeigt.
  • Nach wie vor kann jedes Teammitglied jederzeit neue Aufgaben erfassen und alle Aufgaben modifizieren.
  • Neben der Priorität und der Verantwortlichkeit können hierarchische Kategorien mit den Aufgaben verknüpft werden. In obigem Screenshot sind z.B. alle Aufgaben dargestellt, die in der Kategorie Taskboard/Sprint 13 geführt werden. Ist eine Aufgabe mit Ablauf von Sprint 13 nicht erledigt, wird sie zu Taskboard/Sprint 14 neu kategorisiert (da wir ohne Limits und mit Scrum arbeiten, ist die hier vorgestellte Kanbantafel identisch mit einem Taskboard, wie wir es aus Scrum kennen).

Die Einführung dieser Kanbantafel hat in unserem verteilten Entwicklungsszenario die Transparenz des Aufgabenstatus erhöht. Die Teammitglieder achten stärker auf einen aktuellen Status, in der Folge verlaufen die Übergaben von Aufgaben zwischen den Teammitgliedern reibungsloser, es werden weniger Tätigkeiten übersehen und bei den Stand Up Telefonaten haben alle Beteiligten einen intuitiv verständlichen Überblick über die Aufgaben der aktuellen Iteration. Eine Stauung der Arbeit bei einzelnen Arbeitsschritten wird schnell sichtbar, so dass wir die Möglichkeit haben, gegenzusteuern.

Das Kanban-System innerhalb von memYAK führt eine Statistik, durch die der Arbeitsfluss (Cumulative Flow) und die Durchlaufzeiten protokolliert und visualisiert werden.

arbeitsfluss

 

durchlaufzeit

 

wartezeit

Im hier geschilderten Fall der verteilten Teams hat die elektronische Kanbantafel uns gute Dienste erwiesen. Wir sollten in der agilen Softwareentwicklung jedoch nur dann elektronische Werkzeuge verwenden, wenn sie auch einen zusätzlichen Nutzen für den Kommunikationsprozess der Teammitglieder stiften. Manchmal sind Haftnotizen an einer Kanbantafel in einem Teamraum völlig ausreichend.

Advertisements
Standard