Neues aus dem Projektalltag: Was KANBAN alles kann


Es gibt Stimmen, die sagen, dass KANBAN nur etwas für Zulieferer von Autoteilen ist und man damit am besten Schrauben produzieren kann. Dies ist sicher eine Sicht auf KANBAN, aber nicht die einzige…

Wo kommt KANBAN eigentlich her?

KANBAN wurde 1947 von Ōno Taiichi, im Automobilkonzern Toyota in Japan entwickelt und bedeutet übersetzt „Karte, Beleg oder Tafel“. Seine damals revolutionäre Idee bestand daraus, die Fertigung nach dem Verbraucherprinzip zu organisieren, sprich der Verbraucher nimmt seinen Bedarf an Ware / seine Anforderungen selbst aus dem Regal und das leere „Regal“ wird erkannt und automatische aufgefüllt. Ein weiterer Faktor für diese Art der Steuerung von Arbeitsabläufen war und ist der Faktor Zeit. Der Kunde erwartet eine schnelle und kurzfristige Lieferung und dies zu einer entsprechenden Qualität.

Machen wir nun einen Zeitsprung von 69 Jahren, sind wir  in unserm Projekt im IT Bereich bei eine großen deutschen Bank, wo das GFT Team im Auftrag des Kunden KANBAN implementiert und zum Leben erweckt hat

Methodisch: Die Bank hatte entschieden, KANBAN IT-weit einzuführen – und damit waren wir eines der Pilot-Projekte.

Fachlich: Zwei bestehende, geschäftskritische Anwendungen der Bank mussten neben der Wartung auch stets um neue Anforderungen des Kunden / Fachbereichs der Bank angepasst werden – kurzfristig und nach Priorität, welche im Tagesgeschäft auch Veränderungen unterlag. Ideen des Fachbereiches wurden von der IT im Anforderungsmanagement gesammelt und in gemeinsamen Jour Fix-Terminen anhand einer Liste besprochen, priorisiert und für die Entwicklung / Umsetzung nominiert. So weit, so gut!

Ein negativer Seiteneffekt dieser Methode war, dass die „Anforderungsliste“ stets angewachsen ist und es keine wirkliche Transparenz gab „woran das Team aktuell arbeitete“ und wie weit die einzelnen Entwicklungen waren. Auch Abhängigkeiten fachlicher, technischer Art waren nicht sichtbar. Das Thema Qualität in Bezug auf das fertige Produkt und die vorgeschriebenen Rahmenprozesse (Frameworks) im Haus waren nicht zu jedem Zeitpunkt der Entwicklung sichtbar und somit messbar. Auch wurden durch Umpriorisierung die Arbeit an einer Entwicklung gestoppt und dann entweder „vergessen“ oder bei Wiedereinstieg in die Entwicklung fast von vorn wieder angefangen, da sich zwischenzeitlich Änderungen ergeben hatten.

Warum nun gerade KANBAN für unseren Kunden?

KANBAN sammelt und priorisiert Ideen und macht sie nach der „Selbstbedienung“ des Kunden auf dem Board des Entwicklungsteams sichtbar. Wurden sie einmal aus dem Ideenspeicher (Backlog) gepullt, durchlaufen sie einen festgelegten einheitlichen Entwicklungsprozess, auf dem es feste Phasen und „Definitions of Done“ gibt. Die „Definitions of Done“ sind gemeinsam definierte Übergangskriterien für die nächste Phase der Entwicklung der einzelnen Softwarepakete. Sichtbar sind vom ersten Moment auch die Teammitglieder, welche an der Umsetzung arbeiten – mehr dazu später!

Neben der größeren Transparenz über den Stand der Anforderungen / Entwicklungen macht diese Methode auch den Aufwand neben der reinen Entwicklung sichtbar. Aufwand, den unsere Kunden aufgrund der immer strengeren, regulatorischen Anforderungen zu erbringen haben.

Die Implementierung von KANBAN bei unserem Kunden

Im ersten Schritt wurden alle bestehenden Anforderungen des Fachbereiches auf Karten aufgenommen, digital im Team Foundation Server von Microsoft und tatsächlich physisch auf Karten gedruckt. Mit entsprechend farblicher Gestaltung wurde zudem sichtbar gemacht, wofür welche Karte steht. In unserem Fall reine Softwareentwicklung oder ausschließlich Dokumentationsarbeiten.

Schritt zwei – das KANBAN-Board – war die Neugestaltung und das Sichtbarmachen des KANBAN-Prozesses auf einem physischen Board für das Team in SWIM-Lanes. Der Entwicklungsprozess im Team wurde in seinen einzelnen Stufen wie „Soon to come“ (Product Backlog), „next to come“ (vom Kunden priorisierte, gepullte Karten), „Analyse“, „Entwicklung“, „Test“, „User Acceptance Test“, „Go Live“ auf dem Board dargestellt. Diese Phasen wurden in Spalten sichtbar und jeweils wiederum unterteilt in „in Arbeit“ und „Done“. Eine wichtige und zentrale Ergänzung waren schließlich das Definieren der festgelegten Übergangskriterien einer Karte in die nächste Phase: die „Definitions of Done“. Basierend auf den Rahmenprozessen der Bank, Qualitätsstandards der Bank und nicht zuletzt auf den Erfahrungen der Teammitglieder.

Wichtig hierbei: Eine Karte folgt dem Prozess stets in eine Richtung. Sie bleibt auf der SWIM-Lane im „Fluss“. Nach dem Pullen des Kunden von der Analyse bis zum Go-Live. Es gibt kein Zurück. Nur ein Stopp, wenn Probleme bei der Umsetzung im Wege auftauchen. Probleme werden nach der Identifizierung durch Magnete auf der Karte sichtbar gemacht. Sie begleiten die Karte, bis sie gelöst sind. Um diesen Prozess am Laufen zu halten und nicht zu überfrachten, wurde je Phase des KANBAN-Prozesses die maximale Anzahl an Karten definiert (Work in Progress). Dieser WIP darf nicht überschritten werden. Beispiel: Ist in der Phase Analyse der WIP erreicht, kann der Fachbereich keinen neuen Aufgaben pullen. Dies ebnet den Weg für eine konstante Umsetzung von Aufgaben und verhindert, dass Anforderungen während des Prozesses aus den Augen geraten und Staub ansetzen. Die Verantwortung für das Board übernimmt der KANBAN-Master. Er achtet darauf, dass die Methodik eingehalten wird und hinterfragt auch Karten, welche schon länger in einer Phase „hängen“.

KANBAN-Board für 2 Produkte
KANBAN-Board für 2 Produkte
KANBAN-Board für 8 Projekte
KANBAN-Board für 8 Projekte

Schritt drei: Die Teammitglieder haben sich alle einen Avatar ausgesucht, welcher auf einem Magnet die Karten kennzeichnet, an der das Teammitglied gerade arbeitet. Ab der Testphase kamen dann auch Avatare des Fachbereiches, aus den Reihen der fachlichen Tester hinzu. Die Darstellung von Abhängigkeiten spielt im KANBAN-Prozess eine große Rolle und wurde ebenfalls mit Magneten dargestellt. Diese kamen ab dem Zeitpunkt der Identifikation der Abhängigkeiten auf die Karte und sind über den ganzen Prozess „mitgewandert“, wodurch eine erhöhte Transparenz in Bezug auf die Testphase und den Go-Live erreicht wurde.

Wie wird KANBAN gelebt?

Wie in anderen agilen Methoden lebt KANBAN auch vom Teamspirit. Das Team muss hinter dem gemeinsam entwickelten KANBAN-Prozess stehen und ihn gemeinsam mit Leben erfüllen. Wie haben wir dies nun umgesetzt? In dem wöchentlichen Jour Fixe mit dem Fachbereich wurden Anforderungen besprochen, priorisiert und wenn möglich neue Karten in die Phase next to come gepullt. Teilnehmer des Jour Fixe waren dabei Vertreter des Fachbereiches, der Produktverantwortliche von IT, der Projektleiter, der KANBAN-Master, Business Analysten und bei Bedarf auch Entwickler. Für das Entwicklungsteam haben wir ein tägliches „Morning-Meeting“, Dauer maximal 15 Minuten, installiert. Dies fand in einem Think Tank vor dem KANBAN-Board statt und wurde vom KANBAN-Master moderiert. Teilnehmer waren alle Teammitglieder, Projektleiter, Entwickler und Business Analysten. Jeder Teilnehmer hat kurz berichtet, woran er gestern gearbeitet hat, was er heute tun wird und ob es Probleme oder neue Abhängigkeiten gibt, die ihn daran hindern, etwas umzusetzen. Bei freier Kapazität haben sich die Entwickler neue Karten aus der Phase „next to come“ gezogen und in die Analysephase überführt. In der Analysephase hat sich zunächst ein Business Analyst die Karte zugeordnet und analysiert, ob die Entwicklung eine Auswirkung auf bestehende Dokumente wie Liefervereinbarungen, Schnittstellen oder bereits bestehende Konzepte hat. Anschließend hat der Entwickler seine Analyse gestartet. Waren die Definitions of Done für die Analysephase erfüllt und der WIP in der nächsten Phase nicht erreicht, wurde die Karte vom Entwickler weiter gepullt. Nach der Entwicklung und der Kontrolle entsprechenden Definitions of Done folgte die Phase UAT-Test und nach positivem Test und den entsprechenden Definitions of done die letzte Phase Go-Live. In der Go-Live-Phase wurde die entwickelte Software für den Produktionseinsatz gemäß dem Change Management des Kunden vorbereitet und alle regulatorischen Anforderung aus dem Framework „Change Management“ der Bank erfüllt.

Erfahrungswerte aus dem Einführungsprojekt

Folgende „Lessons Learned“ konnten wir aus unseren Erfahrungen ableiten:

  • KANBAN bietet neben der sehr guten Transparenz auch die notwendige Flexibilität bei der Priorisierung und Anpassung der Prozesse auf neue Vorgaben aus den jeweiligen Frameworks
  • Eigenverantwortung der Teammitglieder wird gefördert und diese trägt wiederum den Prozess
  • Es werden keine Zeitlimits vorgegeben, denn Durchsatz steht vor Auslastung und diese ist optimiert, da die Mitarbeiter mit freien Kapazitäten im Morning Meeting eigeninitiativ pullen.
  • Manche Anforderungen scheinen zwar ein Eigenleben zu haben und verhalten sich wie eine Auto auf der Überholspur, nachts, ohne Blinker… Aber auch diese werden über gute „Definitions of Done“ spätestens beim Einscheren kurz vorm Go-Live identifiziert und sanft auf die Spur gebracht
  • Eine regelmäßig durchgeführte Retrospektive unterstützt die Weiterentwicklung des Teams und ist unverzichtbar.
  • Der KANBAN Master ist eine zentrale Rolle im Team mit methodischem Schwerpunkt, der den „Flow“ unterstützt und das Board notfalls auch anpasst
kanban_gft_projekt_anforderungen

Innerhalb von zwei Monaten konnten die Anforderungen aus Projekten, Fachbereich und technischen Notwendigkeiten von 170 auf 118 reduziert werden, indem 52 Anforderungen umgesetzt wurden. Nach sechs Monaten waren noch etwa 60 Anforderungen für beide Produkte offen. Die hohe Anzahl der Umsetzung von Anforderungen gerade in den ersten zwei Monaten resultiert daraus, dass erst einmal bereits begonnene Entwicklungen abgeschlossen wurden, bevor an neuen Bausteinen gearbeitet wurde.

Nach dem ersten halben Jahr mit der KANBAN-Methode in diesem Projekt können wir bestätigen, dass:

  1. eine erhöhte Transparenz geschaffen,
  2. die Entwicklungszeiten verkürzt und
  3. die Qualität gesteigert wurde!

Schrauben produzieren funktioniert nach KANBAN – Softwareentwicklung und Projekte auch!

Post a Comment

* indicates required

Comment Area

  1. Philipp F.13. November 2016

    Interessanter Artikel. Ursprünglich bin ich nur hier drauf gekommen, da ich mich als Aktionär mal wieder über aktuelle Themen von GFT aufschlauen wollte. Ich kenne KANBAN aber auch aus meinem beruflichen Alltag und erkenne da sehr vieles wieder. Insbesondere, dass der Erfolg von KANBAN vom Teamspirit abhängt, kann ich bestätigen. Ist das KANBAN-Konzept in IT-Umgebungen eines der Schwerpunkte bzw. Trends momentan, die hier von Unternehmen beauftragt werden?