Sent from Hauptstadt!

Gestern fand beim Finanzdienstleister Hypoport ein Abend statt, in dem mehrere Entwicklungsteams der Hypoport ihren Einsatz von Kanban und Kaizen vorstellten. Organisiert wurde der Abend von Loop-2, ein Beratungsunternehmen im Bereich agile Entwicklungsmethoden. Mein Dank an Loop-2 und Hypoport für die Einladung!

Es war ein sehr sympathischer Abend, der mit ca. 50 Teilnehmern auf sehr großes Interesse stieß. Zunächst wurde in einem Vortrag kurz Kanban in der Softwareentwicklung vorgestellt und zu Scrum abgegrenzt. Nach einer anschließenden Fragerunde ging es dann in Gruppen in die Teamräume von Hypoport, um direkt an den Planungsboards das Vorgehen durchzuspielen. Gerade dieser Teil war sehr wertvoll für mich, da ich hier die praktische Umsetzung miterleben konnte.

Die Hypoport betreut den elektronischen Marktplatz Europace, über den Finanzprodukte wie Bausparverträge vertrieben werden. Laut Aussage Hypoport beträgt das monatliche Transaktionsvolumen über 1,3 Milliarden Euro! Technisch basiert Europace auf Oracles PL/SQL Programmiersprache. Es kümmern sich 3 Entwicklungsteams mit je ca. 10 Mitarbeitern um die Wartung und graduelle Weiterentwicklung von Europace. Alle 3 Teams setzen Kanban für die Planung und Steuerung ihrer Arbeit ein.

Kanban und Kaizen in wenigen Worten

In der (IT) Industrie ist es eine häufig gelebte Unart, dass Mitarbeiter gleichzeitig an mehreren Projekten arbeiten. So wird zum Beispiel eine neue Produktversion vorbereitet, gleichzeitig aber auch Fehler behoben und der Vertrieb bei Demonstrationen des Produkts unterstützt. Durch diesen multiplen Projekteinsatz muss der Mitarbeiter mehrmals täglich zwischen verschiedenen Aufgaben wechseln. Jeder Wechsel führt zu einer gewissen Zeit, in der der Mitarbeiter nicht produktiv ist, da er sich zum Beispiel erneut in die andere Aufgabe einarbeiten muss oder die unterbrochene Arbeit dokumentiert, damit er sie später fortsetzen kann. Die folgende Grafik illustriert einen typischen Arbeitstag mit mehreren Wechseln zwischen 3 Aufgaben A, B und C.

Ziel von Kanban ist es, die Aufgabenwechsel zu vermeiden, damit weniger Zeit verloren geht. Würde man die Aufgaben A, B und C nacheinander abarbeiten, könnte man schon an einem Tag beträchtliche Freiräume schaffen, wie die nächste Grafik zeigt.

Obwohl in beiden Fällen genau die gleichen Aufgaben bearbeitet werden, ist man im zweiten Fall spürbar schneller, da man weniger Zeit durch Aufgabenwechsel verliert. Dieser Idealzustand wird bei Kanban dadurch erreicht, dass ein Mitarbeiter immer genau eine Aufgabe annimmt und diese zunächst vollständig abarbeitet. Wichtig dabei ist, dass der Mitarbeiter oder das Team selbst bestimmt, wann die nächste Aufgabe begonnen wird. Dies wird als Pull Prinzip bezeichnet.

Ein integraler Bestandteil von Kanban ist Kaizen. Kaizen bedeutet kontinuierliche Prozessverbesserung bzw. organisationelles Lernen. Ziel ist es, den gelebten Prozess durch Reflektion ständig weiter zu entwickeln und zu verbessern. Wichtig dabei ist, Kritikfähigkeit und Änderungsbereitschaft in der Organisationskultur zu verankern.

Umsetzung Kanban bei Hypoport

Soweit hört sich Kanban wie ein weiterer wohlklingender Beratungsansatz an. Interessanter ist, wie es in der Praxis umgesetzt wird. Gestern Abend wurde die Umsetzung an den Planungsboards der Europace Teams demonstriert.

Eine Hauptaufgabe bei Europace besteht in der Wartung der Plattform. Kunden melden Fehler über den Support. Auch Änderungswünsche an bestehenden Funktionalitäten wie Reports werden angenommen. Weiterhin wird die Plattform weiterentwickelt, etwa um neue Finanzprodukte zu unterstützen. Jede dieser verschiedenen Aufgaben wird in einem Ticketsystem (man nutzt JIRA) erfasst und mit einem Identifizierer versehen. Am Produktplanungsboard entscheidet der Produktverantwortliche über die Priorisierung der verschiedenen Aufgaben. Das Produktplanungsboard sieht etwa so aus.

Aufgaben werden zunächst entsprechend ihrer Quelle in die verschiedenen Spalten eingeordnet. Ganz oben hängen in jeder Spalte die Aufgaben, die nach Einschätzung des Produktverantwortlichen am wichtigsten sind. Da das Board nur begrenzten Platz hat, hängen auch nur maximal 7 Karten in jeder Spalte. Die restlichen Tickets werden im Ticketsystem verwaltet.

Die Backlog Spalte ganz links ist besonders. Hier hängt der Produktverantwortliche die Aufgaben hin, die als nächstes von den Entwicklungsteams bearbeitet werden sollen. Auch hier gibt die Anordnung der Karten die Reihenfolge vor, in der die Aufgaben abzuarbeiten sind.

Einmal täglich trifft sich je ein Vertreter aus den Entwicklungsteams mit dem Produktverantwortlichen an diesem Produktplanungsboard. Wie bei vielen agilen Entwicklungsmethoden üblich, gibt es einen genau definierten zeitlichen Rahmen (Zeitpunkt und Länge) für das Meeting. Man bezeichnet dies als time-boxed. Jeder Teamvertreter nimmt vom Board so viel Karten aus der Backlog Spalte mit, wie sein Team bearbeiten kann. Nimmt ein Teamvertreter keine Karte mit, ist sein Team mit den bereits zugewiesenen Aufgaben noch ausgelastet. In dem täglichen Treffen werden nicht nur etwaige neue Aufgaben übernommen, sondern jeder Teamvertreter berichtet auch über den Fortschritt am vorherigen Arbeitstag. Solange eine Aufgabe noch nicht von einem Team angenommen wurde, kann der Produktverantwortliche die am Planungsboard sichtbaren Karten verändern. Auch die schon in den Backlog übernommenen Aufgaben können zurück in ihre Spalten verschoben oder vollständig vom Board entfernt werden. Dadurch kann der Produktverantwortliche täglich auf Veränderungen reagieren und zum Beispiel kurzfristig die Behebung eines kritischen Fehlers in Auftrag geben.

Nachdem jeder Teamvertreter in sein Team zurückgekehrt ist, findet dort ebenfalls ein täglich wiederkehrendes Meeting (ein so genanntes Standup Meeting) statt. Dieses ist ebenfalls time-boxed. Das Meeting findet am Teamboard statt. Jedes Teammitglied berichtet zunächst über seine Arbeit am Vortag, welche nächsten Arbeitsschritte anstehen und ob es irgendwelche erkennbaren Probleme gibt, die eine sinnvolle Weiterarbeit be- oder sogar verhindern (so genannte impedients). Dabei wird überprüft, ob das Teamboard den aktuellen Status des Teams korrekt widerspiegelt. Das Teamboard sieht vereinfacht so aus.

Ich habe die Darstellung aus Platzgründen etwas vereinfacht und mich nur auf die Hauptmerkmale konzentriert. In der Realität gibt es zum Beispiel weitere Spalten, die eine Karte ebenfalls durchwandern muss. Die Teammitglieder nehmen entweder die Rolle eines Anforderungsingenieurs (aka Business Analyst), eines Softwareentwicklers oder eines Testers ein. Jede Aufgabe muss zwingen die 3 Funktionsbereiche

• Konzeption,
• Entwicklung und
• Qualitätssicherung

in genau dieser Reihenfolge durchlaufen. In der Spalte ganz links hängen die vom Produktplanungsboard mitgenommenen Aufgaben. Vermutlich stellt meine Grafik einen ungültigen Zustand dar, da im Backlog zu viele Aufgaben übernommen wurden, die an diesem Tag gar nicht mehr in die Konzeption wandern können.

Rechts neben den Spaltenbezeichnungen Konzeption, Entwicklung und neben “in Arbeit” in der Qualitätssicherungsspalte ist mit rot umrandeten Ziffern angegeben, wie viele Karten sich maximal in diesem Funktionsbereich befinden dürfen. Dabei spielt es keine Rolle, ob eine Karte noch in Arbeit ist oder schon auf Abholung durch den nächsten Funktionsbereich wartet. Ziel ist es, nicht auf Halde zu produzieren und einen für den nächsten Funktionsbereich nicht abarbeitbaren Aufgabenstapel zu schaffen. Aufgaben sollen möglichst schnell und ohne Pause den Gesamtprozess durchlaufen. Die Durchlaufzeit einer Aufgabe durch den Gesamtprozess ist damit eine wichtige Kennzahl.

Das Bild zeigt, dass der Funktionsbereich Konzeption mit 4 Karten momentan vollständig ausgelastet ist, während in der Entwicklung noch eine weitere Aufgabe übernommen werden könnte, falls ein Softwareentwickler entsprechend freie Kapazitäten hat. Im Funktionsbereich Qualitätssicherung gibt es lediglich eine Begrenzung der in Bearbeitung befindlichen Karten, da es natürlich Sinn des Prozesses ist, möglichst viele Aufgaben beendet zu haben.

An den “fertig” Spalten von Konzeption und Entwicklung ist in Klammern eine weitere Ziffer angegeben. Diese Ziffer definiert, wie viele Karten mindestens in diesem Bereich liegen müssen, damit der folgende Funktionsbereich jederzeit genügend Aufgaben vorfindet.

Idealerweise wandern die Aufgaben durch die einzelnen Funktionsbereiche. Wird zu irgendeinem Zeitpunkt eine der Boardregeln verletzt, muss sofort im Team nach einer Lösung gesucht werden. Um alle Teammitglieder auf diesen Ausnahmezustand aufmerksam zu machen, gibt es ein vom Team festgelegtes Signal, etwa eine Tröte (nein, keine Vuvuzela). Nachdem eine Lösung gefunden wurde, wird das Auftreten des Ausnahmezustands auf einer weiteren Karte dokumentiert. Dazu notiert ein Teammitglied

• Datum,
• kurze Problembeschreibung und
• kurze Lösungsbeschreibung.

Diese Karten werden in einem speziellen Bereich am Board gesammelt. Auf meiner Grafik habe ich den in der unteren rechten Ecke platziert und mit Kaizen Stapel berzeichnet.

In einem regelmäßig stattfindenden Kaizen Meeting, bei dem Team findet dies wohl aller 3 Wochen statt, werden alle Karten nochmal analysiert. Dabei versucht man zu erkennen, ob zum Beispiel immer wieder die gleichen Ursachen für Probleme verantwortlich sind, etwa unzureichende Fehlerbeschreibungen. Solch eine Retrospektive dient der kontinuierlichen Prozessverbesserung, um zukünftige Probleme zu vermeiden.

Auch bei den Europace Teams kommt es vor, dass eine Aufgabe nicht bearbeitet werden kann, weil zum Beispiel zusätzliche Informationen vom Kunden fehlen. Die zugehörigen Aufgaben dürfen dann für maximal 10 Tage am unteren Rand des Boards geparkt werden. Hier ist natürlich das Ziel, so wenig Karten wie irgendwie möglich dort zu platzieren, denn jede geparkte Karte erhöht die durchschnittliche Durchlaufzeit aller Aufgaben. Moment hat das Team, dessen Board ich gesehen habe, eine Durchlaufzeit von gut 5 Tagen. Darin inbegriffen sind nicht nur die reinen Bearbeitungszeiten in Konzeption, Entwicklung und Qualitätssicherung, sondern auch die Zeit, bis die Lösung entweder produktiv ist oder sofort auf ein Produktivsystem migriert werden könnte. Besonders beeindruckt hat mich die Aussage, dass das Team zweimal wöchentlich einen neuen Produktstand (aka Release) ausliefert. Wenn man bedenkt, wie viel Geschäftsvolumen täglich über diese Plattform geht, ist dies eine extrem beeindruckende Leistung, die nur mit einem sehr gut funktionierenden Entwicklungsprozess möglich ist!

Fazit

Die Entwicklungsteams von Europace arbeiten primär an Wartungsaufgaben wie Fehlerbehebungen und kleineren Änderungswünschen. Genau für solche Einsatzszenario von kleinen ähnlichen Aufgaben mit möglichst kurzer Durchlaufzeit scheint Kanban auch in der Softwareentwicklung sehr gut geeignet zu sein. Stehen größere Weiterentwicklungen an der Europace Plattform bei Hypoport an, nutzen die Teams zur Bearbeitung der Aufgaben eines Projekts ein anderes Vorgehen, das stark an Scrum angelehnt ist.

Beim Lesen meiner Beschreibung des Entwicklungsprozesses sollte man bedenken, dass ich ein paar Details weggelassen habe, um nicht die Speicherkapazität des Internets zu sprengen :-) So übernimmt ein Team nicht unreflektiert eine Aufgabe vom Produktplanungsboard, sondern unterteilt diese nochmal in sinnvolle Teilaufgaben, die dann das Teamboard durchwandern.

Die Vortragenden wurden von den Teilnehmern mit vielen Fragen bombardiert. Dabei hatten sie auf alle Fragen plausible Antworten, etwa, dass man sich auch bei Kanban einen gewissen Pragmatismus bewahren muss, wenn es die Situation erfordert. Auch bei Kanban geht ohne Erfahrung nichts! Eine Frage aus dem Publikum konnten sie aber dann doch nicht direkt beantworten – warum sie überhaupt zu der Veranstaltung eingeladen haben? Für die Mitarbeiter von Hypoport war es schlicht selbstverständlich, ihre Erfahrungen mit anderen zu teilen und zu diskutieren. Viele Teilnehmer waren von dieser Art des Erfahrungsaustauschs sichtlich angetan (ich auch!) und mit etwas Glück gibt es dann demnächst viele weitere ähnliche Veranstaltungen in der Berliner IT Szene. Ich würde mich freuen!