In der IT kommt die Veränderungsmethode Kanban immer häufiger zum Einsatz. Dies ist auch nicht weiter verwunderlich: Denn mit einfachen Mitteln führt Kanban schnell zu nachhaltigen Verbesserungen. Es verspricht klare Arbeitsabläufe, eine gleichmäßigere Auslastung sowie kürzere Durchlaufzeiten und lässt sich ohne weiteres auf jeden bestehenden IT-Prozess sofort anwenden. Dabei lässt sich Kanban nicht nur in der IT, sondern auch in anderen Bereichen einsetzen, die Aufgaben nach Prozessen bearbeiten, wie z.B. im Kundensupport, im Marketing, im Portfolio-Management oder in Medienagenturen.

In der Praxis wird jedoch häufig übersehen, dass es bei Kanban nicht bloß um die Anwendung einer neuen Methode geht. Um Kanban erfolgreich einzuführen, braucht es vielmehr ein umsichtiges Veränderungsmanagement, dessen Durchführung durchaus anspruchsvoll ist. Der folgende Beitrag beschreibt, wie Sie dies in der Praxis bewerkstelligen können. An einem Beispiel wird gezeigt, wie sich die Kanban-Einführung im Bereich der Softwareentwicklung über mehrere Abteilungen hinweg und unter Berücksichtigung aller Betroffenen erfolgreich gestalten lässt.

Ein typisches Fallbeispiel

Manfred Bauer ist Leiter der Softwareentwicklung eines Infrastruktur-Unternehmens mit knapp 800 Beschäftigten. In den letzten Jahren sind immer mehr Aufgaben und Kompetenzbereiche an das Team von Herrn Bauer herangetragen worden. Dies erhöhte nicht nur den Leistungsdruck, sondern sorgte auch für einige Unklarheiten:

• Einzelne Mitarbeiter wissen nicht, von wem sie wann welche Arbeitsaufträge erhalten. Vieles geschieht auf Basis persönlicher Zurufe ganz nach dem Motto: "Wer lauter schreit, kommt früher dran."
• Das Team hat keine Übersicht, welche Entwicklungsaufgaben aktuell hinzugekommen, in Arbeit oder erledigt sind.
• Es gibt weder eine Koordination der einzelnen AuftraggeberAuftraggeber<.>  noch eine klare interne Priorisierung der Aufgaben.

Von einem befreundeten Kollegen hörte Herr Bauer in dieser Zeit erstmals von Kanban – und ist sofort "Feuer und Flamme". Die Praktiken erscheinen bestechend einfach und versprechen eine kompakte Lösung der bestehenden Probleme:

• Durch die Visualisierung des vorhandenen Softwareentwicklungs-Prozesses werden die Abläufe ebenso transparent wie die einzelnen Aufgaben (Tasks).
• Die Definitionen für spezifische Arbeitstypen (z.B. Anforderungen, Wartungsaufgaben oder Bugfixes), WIP-Limits und Serviceklassen kanalisieren den Arbeitsfluss und stellen das unkoordinierte Push- auf ein geordnetes Pull-System um (Bild 1). Mit Serviceklassen ist hier eine Klassifizierung der einzelnen Aufgaben gemeint, mit der sich diese nach Auswirkungen und Risiken unterscheiden lassen. So können diese Tasks z.B. in die Klassen "Standard", "Beschleunigte Bearbeitung" und "Fester Liefertermin" aufgeteilt werden. (Zu WIP-Limits und anderen Grundbegriffen von Kanban siehe auch "Software-Kanban – eine Einführung", Projekt Magazin 04/2011)
• Zukünftig werden alle relevanten Stakeholder regelmäßig in ein sog. "Queue Replenishment Meeting" eingeladen, in welchem gemeinsam die anstehenden Arbeiten besprochen und an die Mitarbeiter verteilt werden.

Bild 1: Kanban-Board mit WIP-Limits und Arbeitstypen

Sogleich macht sich Herr Bauer daran, die internen Arbeitsprozesse seines Teams zu Papier zu bringen. Er definiert WIP-Limits, spezielle Serviceklassen und Metriken, mit denen fortlaufend die Durchlaufzeit und der Durchsatz gemessen werden können. Am Ende kann es Herr Bauer kaum erwarten, die neue Methode seinem Team vorzustellen und dann voll in Richtung Verbesserung durchzustarten…

Die große Ernüchterung

Zwei Monate später ist Herr Bauer mehr als ernüchtert. Von seinem ursprünglichen Feuer ist kaum etwas übrig geblieben. Weder konnten die Durchlaufzeiten reduziert noch die tatsächlichen Engpässe geklärt werden. Stattdessen ist die Skepsis einiger Teammitglieder ebenso angewachsen wie das Unverständnis von Seiten der Kunden. Wieso sollten sie auf einmal Rücksicht auf WIP-Limits nehmen? Warum sollten sie nicht mehr direkt zu den Mitarbeitern gehen können, um ihnen direkt den Arbeitsauftrag für eine Sonderlösung zu erteilen? Und die Mitarbeiter selbst sagen, dass sie nicht wegen jeder Kleinigkeit zum Board gehen und Tickets umhängen wollen. Schließlich ist auch Herr Bauers Vorgesetzter, der IT-Hauptabteilungsleiter, nicht sonderlich begeistert vom Verlauf des angekündigten "Innovations"-Projekts. Doch was war passiert?

Kanban-Mechaniken sind nicht genug

Warum haben sich die kontinuierlichen Verbesserungen nicht eingestellt? Was hat Herr Bauer falsch gemacht? Eine erste Antwort auf diese Fragen könnte lauten, dass die Verwendung der Kanban-Mechaniken alleine eben nicht genug sind. Aus unserer Sicht hat Herr Bauer vor allem drei wesentliche Dinge versäumt:

• Das Softwareentwicklungsteam wurde weder in die genaue Problemdefinition noch in die Lösungsfindung einbezogen. Stattdessen hat Herr Bauer alles alleine gemacht. Damit hat er einerseits gemeinsames Lernen und ein besseres Verständnis für die laufenden Prozesse verhindert. Und andererseits hat er die veränderungstypischen Zweifel und Befürchtungen weiter genährt, dass Veränderungen einmal mehr von oben verordnet werden und nur noch mehr Arbeit mit sich bringen.
• Die Stakeholder, in diesem Beispiel vor allem die Kundenvertreter, das Projektmanagement und das Linienmanagement, wurden nicht davon überzeugt, dass eine bessere Leistung in der Softwareentwicklung nur über eine bessere Abstimmung zu realisieren ist – und nicht über höheren Druck. Darüber hinaus entkräftete Herr Bauer die Vorbehalte der Kunden sowie des Top-Managements nicht ("Bringt mir das überhaupt was?" etc.).
• Die Kommunikation schrumpfte weitestgehend auf einseitige Informationen zusammen. Statt die wichtigsten Stakeholder an der Erstellung des Kanban-Boards und der zukünftigen Arbeitsabläufe zu beteiligen, wurde dies von Herrn Bauer alleine ausgearbeitet und gewissermaßen als "Fertiggericht" serviert. Dadurch ließ sich der Mehrwert des Queue Replenishment Meetings ebenso wenig realisieren wie der Nutzen von Daily Stand-ups oder regelmäßiger Retrospektiven.

Kanban braucht ein professionelles Change Management

Tatsächlich zeigt unsere Erfahrung als Kanban-Trainer und Organisationsberater, dass in der Begeisterung über die bestechend einfachen Regeln und Tools immer wieder das professionelle Management der kontinuierlichen, in kleinen Schritten erfolgenden Veränderung (evolutionäres Change Management) vergessen wird. Vor allem in größeren Unternehmen ist dieses Veränderungsmanagement jedoch alles andere als trivial. Es umfasst im Wesentlichen folgende vier Phasen (vgl. Leopold/Kaltenecker, 2012):

• die Klärungsphase, in der die persönlichen Verbesserungsideen in eine unternehmerische "Kanban-Initiative" übersetzt, Erwartungen und Ressourcen definiert sowie die eigene Rolle reflektiert werden
• die Diagnosephase, in der alle für die Veränderungsinitiative relevanten Stakeholder ihre Sichtweisen und Interessen abgeben und diese zu einem gemeinsamen Katalog von Wünschen und Anliegen verdichtet werden
• die Implementierungsphase, in der dieser Katalog in ein maßgeschneidertes "Systemdesign" transferiert und mit den Stakeholdern ein spezifisches Prozedere vereinbart wird, um Kanban schließlich in den Betrieb zu nehmen
• die Phase des Betriebs, in der es um aktive Führung im Sinne einer kontinuierlichen Verbesserungsarbeit geht

Bild 2: Die vier Phasen der Kanban-Einführung.