> Fallstudie Hypoport

Kanban in der Softwareentwicklung

Im September 2011 haben wir bei Hypoport im Europace Classic-Team Kanban & Kaizen eingeführt. Im März 2012 haben das Hypoport-Team und wir zu einem Abend der offenen Tür eingeladen, um die Erfahrungen und Erkenntnisse auch an andere Entwicklerteams der agilen Community in Berlin weiter zu geben. Aus Sicht eines Besuchers hat Sebastian Stein auf seinem Blog eine ausführliche Darstellung veröffentlicht, Stephan Voigt hat die Veranstaltung mit Bildern dokumentiert und für Hypoport hat Andreas Hertel, einer der Gruppenleiter von Europace Classic, eine Beschreibung des ersten Abends auf dem hauseigenen IT-Blog veröffentlicht.

Wir hatten bei Versand der Einladung mit etwa 20 bis 30 Besuchern gerechnet, tatsächlich erhielten wir aber über 150 Anmeldungen, die wir im ersten Anlauf gar nicht alle berücksichtigen konnten. Um das große Interesse zu befriedigen, haben Hypoport und wir uns dann erstens dazu entschieden, eine weitere Veranstaltung durchzuführen und zweitens die wesentlichen Informationen in Form dieser Fallstudie bereit zu stellen.

Zur Fallstudie Wir zeigen in diesem Artikel, wie es gelungen ist, die Abarbeitung von Aufgaben aus dem Projekt- und dem Tagesgeschäft in einem kontinuierlichen Prozesse zu integrieren, wie sich das Team jetzt an Performance- und Qualitätsmetriken ausrichtet und wie die Resultate aussehen.



Kanban & Kaizen aus Sicht der Geschäftsführung und der Mitarbeiter


Die Ausgangslage
_______________________

Das Europace Classic Team der Hypoport AG entwickelt und betreut eine Onlineplattform für Immobilienkredite. Ende 2011 wurde über diese Plattform zwischen 1,5 und 2 Milliarden Euro pro Monat abgewickelt. Das Europace Classic Team umfasst rund 25 Mitarbeiter, die in drei Teams aufgeteilt sind. Zwei sind Entwicklerteams, das dritte Team betreut die auf der Plattform bereitgestellten Dokumente wie Vertragsunterlagen, Kreditanträge und ähnliches.

Besagtes Team hatte bereits Erfahrungen mit Scrum als agiler Vorgehensweise gesammelt. Gegen Ende 2011 stellte sich die Situation wie folgt dar:
  • Alle Führungskräfte haben ein einjähriges Schulungs- und Trainingsprogramm durchlaufen und sind mit agilen Konzepten vertraut
  • Es existiert ein allgemein akzeptiertes System zur Gesamtkoordination der Teams: Ein Single-Source-Board für die zentrale Publikation aller Aufgaben, sowie zeitlich aufeinander abgestimmte Gesamt- und Teil-Teambesprechungen
  • Das Management unterstützt aktiv die Einführung agiler Methoden in allen Unternehmensbereichen 
  • Führungsebenen und Team von Europace Classic sind trotz der Anwendung agiler Methoden(Scrum) mit der Gesamtproduktivität nicht wirklich zufrieden. Insgesamt herrscht der Eindruck von mangelndem “Flow” vor.

Das Ziel
___________

Die Leitungsebene, d.h. Geschäftführung und Teamleiter kannten das Grundkonzept von Kanban & Kaizen und gingen davon aus, dass es damit möglich sein könnte, folgende Ziele zu erreichen.
  • Auf der Produktebene die Entwicklungsgeschwindigkeit zu erhöhen, die Reaktionszeit bei Fehlern zu senken und die Qualität zu verbessern;
  • Die Zusammenarbeit im Team zu verbessern und die Motivation zu steigern: “mehr Fokus und mehr "Flow”


Die Umstellung auf Kanban & Kaizen
________________________________________________

Die Auftaktveranstaltung
Den Startpunkt bildete ein Kompaktseminar, an dem das gesamte Team teilnahm. In diesem wurden die Grundkonzepte von Kanban & Kaizen vorgestellt und mit allen Beteiligten die Frage der grundsätzlichen Eignung von Kanban & Kaizen geklärt. Nach dem sowohl Entwickler als auch Produktmanager und Business Analysten das Vorgehensmodell grundsätzlich positiv beurteilten, war die notwendige Voraussetzung für den Start der mehrtägigen Workshops gegeben.

Die Workshops
Die Teilnahme an den direkt am nächsten Tag beginnenden Workshops war freiwillig und nicht an die Übernahme von späteren Rollen oder Aufgaben gebunden. Die Tagesergebnisse wurden jeweils vor Beginn des nächsten Arbeitsschritts mit den Teilnehmern und der Geschäftsführung reflektiert und das weitere Vorgehen gemeinsam abgestimmt. Die Priorität und Bearbeitungstiefe der jeweiligen Tagesthemen wurde auf diese Weise vollständig auf den Informations- und Organisationsbedarf des Teams abgestellt.

Die Workshops umfassten ein Programm von drei Tagen im ‘kleinen’ Kreis, gefolgt von einem Tag mit dem Gesamtteam für die Implementierung der neuen Planungs- und Steuerungswerkzeuge. Zur Qualitätssicherung und Nachbereitung wurde nach 30 Tagen noch ein weiterer Review-Tag mit den Gesamtteams durchgeführt.

In den Workshops wurden in einem strukturierten Prozess alle anstehenden Themen rund um Kanban & Kaizen in einem Dreischritt abgearbeitet:
  1. Vertiefende Vermittlung von Detailwissen
  2. Vorstellung von etablierten Good-Practice-Lösungen 
  3. Erarbeitung einer auf die spezifischen Anforderungen des Teams angepassten Lösung.


Abbildung 1: Kanban-Workshop


Tag 1:

  • Analyse des Gesamtprozesses und Visualisierung der bestehenden Abläufe
  • Entwurf eines ersten Schemas für die Arbeitsplanung und das Monitoring
  • Entwicklung der ersten konkreten Boards für die Projektplanung und die Steuerung des Tagesgeschäfts
Tag 2:
  • Ausarbeitung der Definitions of Done, mit denen der Entwicklungsprozess systematisch in messbare Teilprozesse untergliedert wird
  • Definition von Limits für die Zahl der gleichzeitig in Arbeit befindlichen Aufgaben
  • Ausarbeiten von Signalen für prioritäre und termingebundenen Aufgaben sowie für die Meldung von Verzögerungen und Qualitätsproblemen
Tag 3:
  • Festlegung von Interventionsmechanismen und Benachrichtigungsregeln im Falle von auftretenden Arbeitsengpässen
  • Definition von Metriken für Qualität, Performance und Geschäftsentwicklung
  • Regeln und Rollen für die Durchführung von Kaizen-Meetings zur kontinuierlichen Verbesserung der Entwicklungsprozesse


Die Ergebnisse
____________________

Bei Hypoport bestand zum Zeitpunkt der Umstellung auf Kanban bereits ein etabliertes System für die Erfassung von neuen Anforderungen, Änderungswünschen und Fehlern. Wie üblich stammen diese aus einer Vielzahl an unterschiedlichen internen und externen Quellen. 

Der Product-Owner sichtet, systematisiert, bewertet und priorisiert alle Anfragen in Zusammenarbeit mit der Geschäftsleitung, dem Vertrieb, dem Marketing, dem Support und den Entwicklern. Die Ergebnisse dieses Prozesses werden in das sogenannte Single-Source-Board eingespeist, von dem die Vertreter der Teams jeden Morgen in Abstimmung mit dem Product Owner (Produkt Manager) die zu bearbeitenden Arbeitsaufträge auswählen und zur Weiterbearbeitung an die Teams weiter geben.

Gleich im ersten Workshop wurde beschlossen, dieses vorgelagerte System in der bestehenden Form bei zu behalten und sich auf die neue Aufgabensteuerung auf Teamebene zu konzentrieren.

Da beide Entwicklerteams sowohl Neuentwicklungen in Form von langlaufenden Projekten (>100 Personentage) als auch Maintenance und Fehlerbeseitigung durchführen, musste ein Aufgabenmanagement aufgesetzt werden, das beides gleichzeitig ermöglicht:
  • Planung und Nachverfolgung von projektbezogenen Arbeitsaufträgen
  • Management von Maintenance-Arbeiten und Fehlerbeseitigung 
Dies wurde erreicht, in dem in den Teams zusätzlich zum Kanban-Board, über das schlussendlich alle Aufgaben gesteuert werden, ein vorgelagertes Projekt-Board installiert wurde.


                                   
                            Abbildung 2: Schematische Darstellung der Aufgabenplanung und
                                  -steuerung über Single-Source-, Projekt- und Kanban-Boards


Auf dem Projektboard werden aus den sogenannten Epics (globale Anforderungen in Projektgröße) erst User Stories und dann Arbeitsaufträge (Tasks) generiert. Die konkreten Arbeitsaufträge werden dann nach dem Pull-Prinzip von den Entwicklern einzeln auf das Kanban-Board übernommen. Außerdem ist am Projektboard jeweils der aktuelle Projektstand ablesbar.

Die Maintenance-Aufgaben und Fehlermeldungen werden vom Single-Source-Board direkt in das Kanban-Board übernommen. Dort durchlaufen sie (anders als die Projektaufgaben) zuerst noch eine Analysestation, danach laufen Projekt- und Maintenance-Arbeiten / Fehlerbeseitigungen parallel und gleichberechtigt über das Kanban-Board. 



Die Aufgabensteuerung im Detail
____________________________________________

Vom Single-Source-Board zur Umsetzung

Abbildung 3: Der Gesamtprozess im Detail (klicken für Großdarstellung)


Auf dem Single-Source-Board werden alle Aufgaben konsolidiert, denen der Status “zur Umsetzung” zugewiesen wurde. Das Single-Source-Board wird ausschließlich vom Product-Owner gepflegt. Jeden Morgen treffen sich dieser und Vertreter der Teams vor dem Board, um die Neuzugänge, Veränderungen und Prioritäten zu besprechen. Die Teamvertreter nehmen dann eigenständig Aufgaben vom Board, um diese in die Teamboards zu übertragen. Die Zahl der übernommenen Aufgaben richtet sich dabei nach den freien Bearbeitungskapazitäten im Team - abzulesen am Kanban-Board.

Das Kanban-Board ist das eigentliche Werkzeug zur Planung und Abwicklung aller Arbeitsaufgaben. Es ist in zwei sogenannte Swimlanes unterteilt, eine für die Abarbeitung von kurzfristigen Maintenance-Aufgaben und eine zweite für projektbezogenen Aufgaben. Die obere Swimlane für die Maintenance-Aufgaben beinhaltet einen zusätzlichen Analyseschritt, projektbezogene Tasks werden direkt in die Umsetzung gezogen. Um eine fokusierte und zügige Abarbeitung sicher zu stellen, sind alle am Board sichtbaren Teilprozesse mit Limits versehen. Nur wenn dieses Limit noch nicht erreicht wurden, nimmt das Team neue Aufgaben hinzu.

Die Limits gelten für beide Swimlanes gemeinsam. D.h., dass das Limit von 7 in der Umsetzungsspalte so genutzt werden kann, dass 4 Maintenance- und 3 Projektaufgaben parallel bearbeitet werden können, genauso aber auch jede andere Kombination möglich ist, im Extremfall werden 7 Maintenance-Aufgaben und keine Projekt-Aufgabe bearbeitet oder umgekehrt. Wie diese Verteilung tatsächlich genutzt wird, kann das Produktmanagement je nach Bedarf tagesaktuell entscheiden.

Priorisierung, Steuerung von Zielterminen

Über unterschiedliche Kartenfarben, Datumsvermerke und Vorrangsignale können Aufgaben so gekennzeichnet werden, dass alle Entwickler auf einen Blick die jeweiligen Prioritäten ablesen können und eine besonders bevorzugte und schnelle Bearbeitung sicher gestellt wird.



Das Management von umfangreichen Projekten
_______________________________________________________________

Projekte starten mit einer sogenannten Schätzklausur. Während dieser bricht das Team die User-Stories in einem von Scrum übernommenen Vorgehen auf Tasks (Teilaufgaben) etwa gleicher Größe hinunter.


                                Abbildung 4: Kanban-Board (links) und Projekt-Board (rechts). 
                                Ganz links ein Monitor zur Anzeige der Performance- und Qualitätsmetriken


Die Tasks werden alle auf einem ‘Warteplatz’ auf dem Projekt-Board bereit gestellt und dann später von dort aus tagesaktuelle, sobald entsprechende Arbeitskapazitäten frei sind, auf das eigentliche Kanban-Board gezogen.

Der aktuelle Fortschritt der Projekte wird täglich dokumentiert und alle zwei Wochen in einem Projektreview besprochen.

Über die Messung der Bearbeitungsgeschwindigkeit und den täglich aktualisierten Projektstatus können die Entwickler und der Product-Owner jederzeit den erwartbaren Endtermin berechnen. Eine mehrere Wochen vorausschauende Sprintplanung wie in Scrum ist nicht notwendig, sowohl die Produktmanagement als auch die Entwickler können jederzeit neue Aufgaben in die Warteposition einfügen oder von dort wieder entfernen.



Kaizen - Der kontinuierliche Verbesserungsprozess
___________________________________________________________________

Oft ist in Veröffentlichungen nur von "Kanban in der IT" die Rede. Tatsächlich basieren erfolgreiche Kanban-Implementierungen aber vor allem auf der konsequenten Einführung eines Kaizen-Frameworks. Den Kanban liefert die Information über Engpässe und Schwachstellen im Entwicklungsprozess, die zugehörigen Lösungen werden aber im Rahmen des Kaizen-Programms entwickelt. 

Die Identifikation von Engpässen erfolgt über die Limits auf dem Kanban-Board (rot umrandete Zahlen bei den Spaltenüberschriften). Sobald diese überschritten werden, wird ein Rote-Leine-Prozess ausgelöst. Dabei handelt es sich um einen zuvor ausgearbeiteten, für alle Teammitglieder verbindlichen Reaktionsplan, über den folgende Punkt systematisch abgearbeitet werden: Analyse des Problems, Beschluss über eine strukturierte Ad-hoc-Reaktion, Dokumentation des Engpasses sowie verbindliche Wiedervorlage im Rahmen einer systematischen Nachbereitung.



Abbildung 5: Notiz am Board mit Reaktionsregeln beim Auftreten von Engpässen


Alle zwei Wochen trifft das Team sich im Kaizen-Meeting, um unter anderem alle Rote-Leine-Events anhand der Dokumentation nach zu besprechen, gehäuft auftretende, systemische Ereignisse zu identifizieren und daraus abgeleitet konkrete Maßnahmen zur Verbesserung der operativen Abläufe zu entwickeln.



Abbildung 6: Kaizen-Meeting



Die Metriken
____________________

Das Team arbeitet mit einem umfangreichen Satz von Metriken, die täglich Aufschluss geben über das eigene Geschäftsumfeld, die Qualität der Arbeit und die Performance. Alle Metriken wurden vom Team selbst entwickelt.

Alle Metriken bzw. deren Auswertungen sind so aufgebaut, dass sie auf einen Blick verständlich sind. Die Publikation erfolgt mindestens täglich, teilweise sogar in Echtzeit auf Monitoren in den Teamräumen. Das Ziel war dabei, den Entwicklern eine intuitive, unaufdringliche aber jederzeit präsente Rückmeldung über ihre Arbeit zu geben - ohne dass hierfür formale Sitzungen abgehalten werden müssen. Die Datenerfassung wurde soweit wie möglich vereinfacht oder gleich vollständig automatisiert.



Abbildung 7: Performance- und Qualitätsmetriken werden in Echtzeit 
in den Arbeitsräumen angezeigt


Als Kennzahlen für den Geschäftserfolg werden der aktuelle Zinssatz für Immobilienfinanzierungen, die Entwicklung der Transaktionen auf der Plattform und ähnliches täglich veröffentlicht.

Die Qualität wird gemessen über die absolute Zahl der offenen Fehler, die Zahl der Fehler in Relation zu den bearbeiteten Tickets der letzten Monate, die Reaktionsgeschwindigkeit gegenüber den Kunden und die Zahl der Supportanrufe.

Die Performance wird über die Durchlaufzeit, die Zahl der bearbeiteten Tickets und den Business Value (eine betriebsinterne Kennzahl über die Wertschöpfung) ermittelt.



Der Erfolg
______________

Bereits innerhalb der ersten Woche nach der Umstellung auf Kanban & Kaizen gaben Teammitglieder die ersten positiven Rückmeldungen. Ein Entwickler berichtete nach vier Tagen, den ‘produktivsten Tag seit Jahren’ erlebt zu haben.

Tatsächlich läßt sich bei Kanban & Kaizen der Erfolg aber auch in harten Zahlen messen.

Kanban ermöglicht eine systematische statistische Prozess- und Erfolgskontrolle aufgrund der Zerlegung der Anforderungen in Arbeitsaufgaben etwa gleicher Granularität, sowie der Prozesskontrolle über die Limits und die Messung der Arbeitslast und Durchlaufzeiten.

Der Erfolg in Zahlen

Nach der Umstellung auf Kanban war zuerst der bereits in Arbeit befindliche Überhang abzuarbeiten. Abbildung 8 zeigt deutlich, wie zuerst der Block von sich parallel in Bearbeitung befindlicher Aufgaben reduziert wurde. Waren vor der Umstellung immer rund 30 und mehr Aufgaben gleichzeitig in Arbeit, sind es seitdem fünf bis zehn.

Abbildung 8: Fokus statt Multitasking


Durch die Reduzierung der Parallelarbeit werden die Arbeiten, die tatsächlich angefangen werden, auch wesentlich konzentrierter zu Ende gebracht. In Abbildung 10 sieht man, wie dementsprechend auch die Durchlaufzeit deutlich abgenommen hat. Lag diese zuvor bei zehn Tagen und mehr, hat sie sich schließlich auf etwas über vier Tagen eingependelt.

Abbildung 9: Reduzierung der Durchlaufzeit um über 50 Prozent


Der Erfolg im Team

____________________________

Die Umstellung auf Kanban & Kaizen wurde auch von den Mitarbeiter sehr positiv aufgenommen. Zur Kontrolle des langfristigen Erfolgs wurden die Mitarbeiter rund vier Monate nach der Umstellung auch noch einmal anonym nach ihrer Einschätzung befragt. Das Ergebnis spricht für sich: Alle von den Mitarbeitern abgegebenen Bewertungen waren neutral oder positiv, es gab zu keinem Punkt eine negative Bewertung. 
Abbildung 10: Beurteilung von Kanban & Kaizen durch die Mitarbeiter
(Klicken für Großansicht)


Auf die Frage, ob das neue Vorgehen mit Kanban & Kaizen dem früheren Prozess vorzuziehen sei, antworteten vier Monate nach der Umstellung 100% der Mitarbeiter mit "Ja". Visualisiert sah dies dann so aus ....



Abbildung 11: Zustimmungsrate des Teams
(Klicken für Großansicht)





Abbildung 12: Sammelbox für die Visualisierung der erfolgreich abgearbeiteten Aufgaben