Kanban in der IT? Kann das wirklich sein?

Heute möchte ich einen kleinen Einblick geben, welche Arbeitsweisen und -methoden wir in unseren Teams anwenden. Deswegen habe ich mir gedacht, ich stelle euch mal vor, wie wir im Information Management mit der Kanban Methode arbeiten.

Als ich in einer Kaffeepause einem Kollegen aus einem anderen Bereich erzählt habe, dass ich ein Grundlagentraining „Kanban verstehen“ besucht habe, kam sofort die Frage: „Warum? Wechselst du jetzt in die Fertigung?“ „Nein, tue ich nicht – wir setzen das ab sofort bei uns ein“ war meine Antwort und mein Gegenüber war sehr erstaunt. Denn allgemein ist Kanban als eine Methode zur Produktionsprozesssteuerung bekannt und man denkt sofort an die Produktions- und Fertigungsbereiche und an den japanischen Autohersteller Toyota (welcher als Erfinder der Kanban Methode gilt) – und eben gar nicht an IT.

Allerdings eignet sich Kanban als agile Projektmethode auch sehr gut für den Einsatz in IT-Abteilungen und genau das erläutere ich jetzt genauer.

In der IT gibt es nicht nur große Projekte, die mit Projektmethoden geplant und gesteuert sowie mit entsprechenden Softwareprogrammen verwaltet und visuell dargestellt werden. Es gibt auch viele kleine Aufgabenpakete (z. B. Changes) für die diese Vorgehensweise überdimensioniert wäre, da es z. B. keine Meilensteine etc. gibt und sie – für sich alleine betrachtet – oftmals gar nicht sonderlich komplex sind. Aber aufgrund der Vielzahl dieser kleineren Aktivitäten ist es notwendig, dass auch diese koordiniert abgearbeitet werden und sich im besten Fall sogar die Durchlaufzeit reduziert.

Deswegen ist der erste Schritt, den vorhandenen Prozess zu visualisieren. Hierzu wird eine Moderationswand mit Kärtchen oder Haftnotizen verwendet und die zu durchlaufenden Stationen werden als Spalten dargestellt – und schon ist das sogenannte Kanban-Board geschaffen. Jedes Kärtchen symbolisiert eine Aufgabe und wandert mit Fortschreiten des Prozesses von links nach rechts.

Als nächstes gilt es eine Menge für die maximale Anzahl der gleichzeitig zu erledigenden Aufgaben festzulegen, das sogenannte WiP-Limit (WiP= Work in Progress). Durch diese Begrenzung wird vermieden, dass an zu vielen Dingen parallel gearbeitet, aber nichts fertiggestellt wird. Man erreicht also, dass an den einzelnen Aufgaben konzentriert gearbeitet werden kann und diese dadurch schneller erledigt werden. Eine neue Aufgabe kann also erst angenommen werden, wenn eine bestehende Aufgabe abgearbeitet wurde und dadurch wieder Kapazität frei ist. Und wichtig ist auch, dass die erledigte Aufgabe nicht einfach in die nächste Spalte übertragen – und damit jemand anderem zugeschoben – werden kann. Denn auch hier gibt es Limits und jede Aufgabe muss aktiv und eigenverantwortlich vom bearbeitenden Mitarbeiter „geholt“ werden.

Das Ziel von Kanban ist es, einen stetigen Fluss des Prozesses zu erreichen, Wartezeiten zu reduzieren und dadurch einen schnelleren Durchlauf zu realisieren. Durch die einfache Visualisierung am Board entsteht für alle Beteiligten Transparenz über Verteilung und Status der Aufgaben sowie vorhandene Engstellen. Regelmäßig stattfindende Analysen des Boards helfen, Schwachstellen zu erkennen und entsprechende Gegenmaßnahmen einzuleiten. Dadurch gelingt eine kontinuierliche Verbesserung des Prozesses.

Puh – das war jetzt ganz schön viel Theorie. Und wie sieht das jetzt in der Praxis aus?

Mehrere Teams im Information Management arbeiten nun seit ca. 4 – 9 Monaten mit Kanban-Boards. Stellvertretend für alle Boards habe ich das Kanban-Board für den Bereich Logistik & Transport zur Vorstellung ausgewählt. Hier hat sich ein wöchentliches Teammeeting etabliert, in dem das Kanban-Board mit seinen aktuellen Aufgaben mit allen Teammitgliedern besprochen wird.

Einmal im Monat treffen sich die Board-Leitung und die Vertreter aus dem Fachbereich zu einem Review-Termin. Hier wird es dann besonders spannend. Gemeinsam wird besprochen, welche Themen mit welcher Priorität in die Inbox kommen. In unserem Fall dürfen z. B. nur acht Kärtchen in der Inbox hängen und die Wichtigkeit der Themen ist von oben nach unten zu sehen. Anschließend wird jedes Kärtchen in den nachfolgenden Spalten (RoC = Rise of Change, PoC = Planning of Change, DoC = Development of Change und EoC = End of Change*) besprochen. Verzögerungen werden sofort sichtbar – sei es auf Seiten der Entwickler oder z. B. wenn eine Aufgabe schon vor Längerem zum Abnahmetest in den Fachbereich gegeben wurde und dort nicht bearbeitet wird. Auch kann es ab und zu vorkommen, dass ein Kärtchen, welches sich mitten im Prozess befindet, unvorhergesehen keine Priorität mehr hat. Diese Karte wandert dann nach unten in den sogenannten „Friedhof“, oder wie auf diesem Board in den „Trash“.

Durch diesen Abstimmungstermin haben beide Seiten – Auftraggeber und Bearbeiter, in unserem Fall Fachbereich und IM – immer den gleichen Wissenstand über den Status der Aufgaben. Diese Transparenz ist für uns ein wichtiger Schritt zu mehr Fachbereichszufriedenheit, da es uns mit den bisherigen Methoden nicht möglich war, unsere Prozesse zu visualisieren. Außerdem hat der Fachbereich (also z.B. die Kollegen aus Logistik & Transport) direkten Einfluss, welche Aufgaben zuerst umgesetzt werden. Allerdings sind die Fachbereichs-Vertreter auch in der Pflicht, Verantwortung zu übernehmen: z.B müssen Geschäftsprozesse vor der Priorisierung geklärt sein und es braucht die nötige Kompetenz zur Priorisierung der Aufgaben.

Wir stehen noch am Anfang beim Einsatz der Kanban-Methode, aber unsere bisherigen Erfahrungen sind sehr positiv und wir erhoffen uns, dass sich damit eine Kultur der kontinuierlichen Verbesserung etabliert.