Am 9. November berichtete ich in der Kanban-User-Group beim LWIPCGN#5-Treffen über eine von mir durchgeführte Kanban-Einführung. Ein kurzer Artikel von mir dazu:
Zielsetzung und Situation vor der Einführung
Eine Firma will ihre internen Abläufe verbessern, da es immer wieder zu Konflikten zwischen Projektleitung und Entwicklung kommt und die Produktivität – gefühlt – zu gering ist. Die Firma möchte gerne agile Methoden, allen voran Scrum einsetzen, da diese mutmaßlich für sie passen. Die Rahmenbedingungen sind durch ständig wechselnde Anforderungen und sehr kleine Aufgaben und kleinteilige Projekte (ca. 2/3) und wenige größere Projekte (ca. 1/3) geprägt. Mein Vorschlag war, erst einmal nicht Scrum einzuführen, sondern mit Kanban zu beginnen.
Das Angebot
Es ist eine eher kleine Firma, so dass ich möglichst Minimalinvasiv vorgehen wollte. Vier Tage sollten reichen:
- Analyse der Ist-Situation
- Workshop mit zwei Teilen: Information (Kanban-Schulung) und Aktion (Kanban-Board etc. für die Firma erstellen)
- Begleiteter Live-Gang
- 2 halbe Nachsorgetage
Die Durchführung: Analyse
Als zentrales Anliegen aller Mitarbeiter wurde der Bedarf nach mehr Kommunikation ausgemacht. Die Mitarbeiter wollen mehr über die Tätigkeiten der anderen und Änderungen in Projekten erfahren. Des Weiteren entdeckte ich Unterschiede in der Wahrnehmung von Schätzungsgrößen, wie Manntagen, Aufwand und Dauer.
Die Durchführung: Workshop
Zunächst habe ich die grundlegenden Ideen zu agilen Methoden dargelegt und zur Abgrenzung Scrum grob erklärt. Danach zeigte ich den Mitarbeitern die Kanban-Regeln und -Methoden an einem Beispiel. Abschließend fragte ich die Mitarbeiter mittels einer Brainstorming‐Runde nach ihren Problemen und den Wünschen. Sie wurden im Konsens von allen Mitarbeitern angenommen und im Anschluss als Schriftstück ausgehändigt.
Nach der Mittagspause sollten zwei gemischte Gruppen in einem Workshop die Regeln von Kanban auf die Firma als Unternehmen anwenden. Hierfür gab es zwei einstündige Phasen, zwischen denen eine Kontaktpause der beiden Teams statt fand. Ich stand zur ganzen Zeit zur Beantwortung von Fragen bereit und griff moderierend ein. Am Ende des Tages wurden beide Entwürfe, die nicht grundlegend voneinander abwichen, in einer Konsensentscheidung von den Mitarbeitern zusammengeführt.
Die Durchführung: Live-Gang
Zur Einführung waren natürlich noch nicht alle Tätigkeiten in Tickets erfasst und es tauchten viele Fragen auf, die aber schnell beantwortet werden konnten. Grundsätzliche, strukturelle Probleme des Boards oder der Karten wurden aber bewusst auf die erste Retrospektive am folgenden Freitag geschoben.
Der Paradigmenwechsel vom Push- (Projektmanagement beauftragt Entwicklung) zum Pull-Prinzip (Entwicklung holt sich eigenständig die Aufträge) braucht natürlich eine Eingewöhnungs- und Einarbeitungsphase, so dass hier nicht von Anfang an alles ohne Reibungen ablief. Ich bat zwei Mitarbeiter, verstärkt darauf zu achten, dass das Entwicklungsteam seine Rolle ernst nimmt und beginnt auszufüllen.
Erstes Nachtreffen: Die Rückmeldungen
- Kommunikation hat sich verbessert.
- Es ist mehr Arbeit die Zettel an das Kanban-Board zu pinnen, als alles nur im Ticketsystem zu machen.
- Ich kann mehr an einem Stück arbeiten.
- Kleine Aufgaben von 5‐10 Minuten werden aufgebläht und werden durch das Pull-Prinzip nicht mehr sofort fertig.
- Wir haben viele Retrospektiven gemacht und es geht voran.
- Das Kanban-Board hat sich schon verändert.
- Ich kann noch nicht abschätzen, ob wir immer im Budget waren.
- Ich kann nun gar keine Termine mehr zusagen.
- Wir arbeiten immer noch mit dem gleichen Prozess, das ist nicht gut. Pull-Prinzip klappt immer besser.
Erstes Nachtreffen: Meine Vorschläge
- Ab sofort die Durchlaufzeiten der Tickets messen, damit Flaschenhälse nach der Engpasstheorie (http://de.wikipedia.org/wiki/Theory_of_Constraints) aufgelöst werden können.
- Kleine Aufgaben möglichst automatisieren und en block abarbeiten. SLA mit den Kunden von einem Tag vereinbaren, oder pro Tag einen Service‐Verantwortlichen in der Entwicklung einsetzen.
- Für länger laufende Projekte Scrum einsetzen.
- Damit Termine vorhersagbarer werden die maximal pro Mitarbeiter mögliche Arbeit weiter begrenzen. So steigt die Auslastung und Effizienz und sinkt die Variabilität der Schätzungen.
- Eine Möglichkeit zu „planen“ ist ein sog. Backlog Replenishment Meeting (Nachschubbesprechung), in der die PMs, TPMs und ein Vertreter der Entwicklung den Nachschub für den Backlog bespricht und abschätzt.
- Auf Projekte mit festen Terminen/Zusagen könnte man mit einer ScrumBan-Swimlane reagieren, die getaktet ist: Immer Mittwochs wird alles was da drin ist Released. Somit weiß die Entwicklung um den festen Termin und kann sich darauf einstellen
Zweites Nachtreffen / Mein Fazit
Wirkliche Veränderungen zum ersten Nachtreffen gab es meiner Meinung nach nicht. Sie verdammen Kanban nicht, aber agil arbeiten Sie meiner Meinung nach noch nicht. Das liegt aber nicht an Kanban als Methode, sondern am fehlenden menschlichen Faktor. Viele denken anscheinend, dass die Intelligenz im Kanban-Board steckt und nicht täglich davor steht.
Das Pull-Prinzip wird nicht gelebt. Teilweise, weil die Entwickler Angst/Respekt davor haben, teilweise, weil das (Projekt-)Management der Versuchung nicht widerstehen kann Kontrollmechanismen unter einem Kanban-Deckmantel einzuführen.
Das wichtigste Fazit für mich lautet daher: Kanban als Methode kann man in kurzer Zeit einführen. ABER: Agiles Arbeiten kann ich nicht mit 4 Tagen Aufwand einführen.
Es ist eine Kulturänderung, die in vielen kleinen Details passiert oder eben nicht, wenn es nicht mindestens eine(n) gibt, der darauf achtet. Der/Diejenige kann Unternehmensintern sein, meiner Meinung nach kann dies aber in den aller seltensten Fällen so geleistet werden.
Deswegen werde ich eine Kanban-Einführung wohl nicht mehr in dieser Kürze angehen. Vielmehr werde ich mir mehr Zeit und Raum für die wirklich wichtigen Dinge geben: Den Kulturwandel.
