Shownotes
Wie VI und EMACS, nur anders. Also eher nur wie VI: Kanban hat zwei Modi: Betrieb und Verbesserung. Dafür hält die Methoden verschiedene Meeting-Archetypen bereit, die uns bei den beiden Modi unterstützen sollen.
Ich freue mich über Likes und Kommentare bei Instagram: https://www.instagram.com/kanbanin7minuten/
Und Twitter: @KanbanIn7Min
Oder auch einfach über E-Mails! Fragen und Anregungen bitte an post@florianeisenberg.de
Happy Kanban!
Transkript
Lieber zuhören? Hier ist der Podcast:
In dieser Folge sprechen wir mal über die beiden Modi Kanbans.
Geklärt, dass Kanban mehr als Zettel und mehr als Visualisierung ist, ist ja schon. Sonst empfehle ich dir natürlich gerne noch mein Buch.
Aber Kanban ist ja auch kein Rahmenwerk, in dem feste Rollen, Artefakte und Rituale verankert sind. Kanbans Claim ist: "Die Kanban-Methode ist eine Methode zum Betrieb und der Verbesserung von Dienstleistungen."
Über diese beiden Punkte, Betrieb und Verbesserung, will ich jetzt sprechen.
Wir wollen jetzt nicht den nerdigen VI gegen EMACS-Krieg um eine weitere Episode erweitern, aber ich bin ein absoluter VI-Mensch. Für alle, die damit nix anfangen können: VI und Emacs sind Editoren in Unix-Systemen. Und wer das eine mag, mag das andere meistens nicht.
VI hat jedenfalls drei Modi: Kommando-Modus, Einfügemodus und Escapemodus. Sie alle haben unterschiedliche Verantwortlichkeiten: Beim Einfügemodus geht es darum, Inhalte in die Datei einzufügen, also beispielsweise "Hallo Welt" reinzuschreiben. Der Kommandomodus ist dann, ein bisschen meta, dafür da, um sich in der Datei zu bewegen und zu kopieren und zu löschen und so weiter. Und schließlich der Escape-Modus ist dann die höchste Meta-Schicht: Er beschäftigt sich damit, was mit der Datei selbst passieren soll – so etwas wie öffnen, schließen, den Editor beenden.
Ist ein bisschen weit hergeholt, die Analogie, aber als Einleitung reicht sie aus. Denn in der Kanban-Methode selbst sind eben auch zwei Modi verankert. In dem einen Modus beschäftigen wir uns damit, die Arbeit fertig zu bekommen, Hindernisse aus dem Weg zu räumen und den Flow der Arbeit aufrecht zu erhalten. Das ist der Betriebsmodus. Der andere Modus, die Verbesserung, ist dann darüber liegend. In diesem Modus wird darüber reflektiert, wie das System insgesamt über einen längeren Zeitraum läuft. Wir sehen uns hier also an, was wir tun können, damit das System als ganzes besser läuft, unabhängig von den einzelnen Aufträgen.
Im Detail: Wenn wir eine Dienstleistung betreiben wollen, benötigen wir ein paar Dinge.
- Eine Steuerung dessen, welche Aufträge in welcher Menge angenommen werden. Kanban empfiehlt dazu das Commitment-Meeting. Dazu kommt natürlich das Pull-System, das uns Informationen über die aktuelle Aufnahmekapazität gibt.
- Einen Mechanismus zur Beurteilung des Fortschritts und Steuerung der Bearbeitung – das haben wir durch das Kanban-Board.
- Eine Koordination der bearbeitenden Personen – das findet in unserem sogenannten Kanban-Meeting statt.
- Einen Mechanismus, um entstehende Probleme, Blockaden und Risiken an die Oberfläche zu spülen und mögliche Problemlösungen zu besprechen. Auch das soll im Kanban-Meeting passieren, gekoppelt mit unserem Kanban-Board.
- Einen Weg, um die Auslieferung des Ergebnisses an den Auftraggeber zu planen. Das ist insbesondere hilfreich, wenn wir nur eine seltene, aber regelmäßige Auslieferung der Ergebnisse haben. Kanban schlägt dazu ein Delivery-Planning-Meeting vor, aber ich habe das in meinem Leben erst einmal in Grundzügen implementiert gesehen.
Betrieb einer Dienstleistung bedeutet, dass Aufträge angenommen werden, ihre Bearbeitung koordiniert und geleistet wird, entstehende Risiken adressiert werden und die Auslieferung innerhalb der versprochenen Grenzen erfolgt. Dafür bietet uns Kanban ein paar abstrakte Muster – Commitment-Meeting, Kanban-Meeting und so weiter. Die konkreten Implementierungen hängen vom Kontext und natürlich auch vom Reifegrad der Organisation ab. In einer Umgebung mit geringem Vertrauen werden wir wohl kein dezentrales, asynchrones Wiederbefüllen der Eingangsspalte durch die Auftraggeber haben.
Ich habe in meinen Anfangsjahren Betrieb und Verbesserung immer ein bisschen zu sehr zusammengeworfen. Das ging wohl den allermeisten so, bis wir das irgendwann mal etwas sauberer getrennt haben. Da war wohl immer noch die Hoffnung da, dass aus spontaner Erleuchtung während des Betriebs nachhaltige Verbesserung des Systems entstehen würde. Naja. Heute wissen wir's besser. Übrigens eine Erkenntnis, die sich auch bei den Scrum-Menschen erst durchsetzen musste: Da ist die Retrospektive auch erst nachträglich hinzugefügt worden.
Die Verbesserung der Dienstleistung sollte ein paar Dinge im Blick haben:
Erstens: Passen die Dienstleistung und die angenommenen Aufträge zu den Erwartungen und Bedürfnissen der Kunden?
Zweitens: Welche Anforderungen bezüglich Bearbeitungsgeschwindigkeit und -Menge gibt es und wie gut erfüllen wir sie?
Drittens: Wie funktioniert das Ökosystem der Dienstleistungen vor dem Hintergrund der aktuell identifizierten Erwartungen und Bedürfnisse? Wie gut erfüllen wir das? Wo muss sich gegebenenfalls etwas ändern? Wie müssen wir zusammenarbeiten, damit das passiert? Welche Auswirkungen wird das haben?
Und Viertens: Welche neuen Dinge, Risiken, welches unerwartete Verhalten haben wir wahrnehmen können? Wie wollen wir das adressieren?
Kanban bietet uns auch da eine Reihe von Archetypen von Meetings an, die genau diese Dinge behandeln. Einmal kurz paraphrasiert drehen sich die Meetings darum, wie wir die aktuell angebotenen Dienstleistungen verbessern können, aktuelle Entwicklungen integrieren können und schlussendlich die Dienstleistungen und damit das Gesamtsystem selbst verändern müssen, um Kundenerwartungen und -Bedürfnisse besser zu erfüllen.
Ich habe eben von Archetypen gesprochen. Kanban sagt also eher, dass es gut ist, etwas zu haben, was diesen Sinn erfüllt, als detailliert vorzuschreiben, wie das stattzufinden hat. Da kann man zwar auch viel Guidance aus unseren bisherigen Erfahrungen ableiten, aber im Grunde soll der Zweck erreicht werden – dafür können diese Archetypen auch in bestehende Meetings integriert werden.
Nicht erschrecken, es sind weitere vier Archetypen, die zu den drei aus dem Betrieb hinzukommen. Es sind das Operations-Review, um die Verbesserung des Gesamtsystems voranzutreiben; das Service Delivery Review für jede Teildienstleistung, um Daten für das Operations Review zu sammeln; das Risk-Review, um neue Störsignale zu identifizieren; und das Strategy-Review, um die Dienstleistung selbst darauf zu überprüfen, ob sie zu dem passt, was der Kunde benötigt.
Insgesamt sieben Meeting-Archetypen. Als das publiziert wurde, drückte Wolfgang Wiedenroth seine Frustration über die vielen Meetings mit dem Satz aus: "Kanban, die Let's-have-a-meeting-Methode!" Klar, das kam aus der ersten Frustration, weil da auf einmal Meetings waren, wo vorher explizit keine vorgesehen waren. In der Kanban-Community haben wir uns lange damit gerühmt, dass wir ja nicht so ausbordende Meetings haben wie die Scrummies. Und jetzt auf einmal waren es sogar drei mehr!
Nun, die Guidance war damals eher schlecht und heute wissen die, die's drauf haben: Ja, die brauchen wir, um eine Dienstleistung zu betreiben und zu verbessern. Aber wir müssen sie nicht zwangsläufig einzeln überall hinzufügen, sondern können die Archetypen auch in bestehende Meetings integrieren und diese für den Zweck anpassen. Es ergibt sehr viel Sinn, sich mit all diesen Dingen zu beschäftigen. Es ist aber auch nicht immer alles von Anfang an notwendig. Und noch was, was der Agile Bubble teilweise sauer aufstoßen wird: Es ist gar nicht zwingend notwendig, dass immer alle dabei sind! Wir können das also so klein wie möglich halten und so für weniger Menschen den Meeting-Overhead generieren.
Zusammenfassend: Kanban hat die beiden Modi Betrieb und Verbesserung. Im Betrieb geht es darum, Aufträge anzunehmen, zu bearbeiten und den Fluss in diesem Moment aufrecht zu halten. In der Verbesserung sehen wir uns die Leistung des Arbeitssystems gesamt an und verändern es, um den Fluss dauerhaft systematisch zu verbessern, bzw. die Dienstleistungen anzupassen, wenn diese noch nicht zu den Erwartungen und Bedürfnissen der Kunden passen.
Kommentar schreiben