Gehen wir für diesen Artikel davon aus, dass es unser Ziel ist, zuverlässig Wert zu liefern. Zuverlässig, weil das Versprechen „Du kriegst irgendwann Wert, aber keiner weiß, wann“ im Business Context meistens nicht fliegt. Und Wert, weil hocheffizient das Falsche tun, langfristig zum Untergang der Organisation führt. Dazu ein wunderschönes Zitat von Altmeister Russell Ackoff: The more efficient you are at doing the wrong thing, the wronger you become.

Es gibt nun verschiedene gute Gründe, anzunehmen, dass derselbe Denk- und Arbeitsansatz nicht für alle Sachlagen gleich gut geeignet ist. Das sagen uns z.B. Cynefin, Wardley Maps, die Stacey Matrix und viele Org-Modelle. Sparen wir uns die Details, klar ist: Wie man es auch dreht und wendet, immer standardisieren mit Effizienz und Uhrwerk-Metapher ist nicht das Richtige. Und immer Agile mit zusammen drüber reden und gemeinsam nachdenken und rumprobieren ist auch nicht immer das Richtige.

Ein Beispiel: Wenn auf dem Fließband eine Tür zum Reinmontieren ins Auto ranfährt, dann müssen wir nicht immer wieder neu überlegen „Ja, Mensch, was machen wir denn jetzt mit der Tür?!“ Wenn wir aber neue Produkte oder Services anbieten wollen, sollten wir von den Fließband- und Kochrezept-Ansätzen Abstand nehmen und: Gemeinsam denken, experimentieren, liefern und lernen.

Dass immer beide dieser Seiten eine Rolle spielen, sieht man auch schon im Agilen Manifest. Es heißt da ja „People and interactions over processes and tools“ und nicht „People and interactions instead of processes and tools“. Im Komplexen brauchen wir einfach ein bisschen mehr von „people and interactions“ und ein bisschen weniger von „processes and tools“.

Zusammenarbeit — komplex vs. kompliziert

Wenn wir den gerade besprochenen Denkansatz auf die Skalierung von Kanban anwenden, also das Vernetzen von mehreren (Kanban) Teams/Services, dann kommen wir zu dem Schluss:

• für komplexe Aufgaben brauchen wir Interaktion (Agile)
• für komplizierte Aufgaben brauchen wir Standards (good practices, Schnittstellen etc.)

Ein Beispiel: Wenn ich einen Demand an eine andere Abteilung (oder Team oder Service) habe, z.B. „Gib uns eine Schulung zum Thema Flight Level 2 Design„, dann schicke ich manchmal eine Mail, manchmal mache ich ein JIRA-Ticket, manchmal chatte ich sie an und manchmal schick ich eine Brieftaube. Die Kollegen dort teilen mir mit: Das ist echt unpraktisch! Kannst du nicht immer Weg X gehen? Das würde uns das Leben vereinfachen. Na klar, kann ich.

Diese Vereinbarung, für meinen Demand immer Weg X zu gehen, ist eine ganz primitive Standardisierung und Vereinfachung. Sie hat nichts mit Agile oder innovativer Kollaboration zu tun — weil Agile und innovative Kollaboration hier einfach überflüssig sind. Dieser Ansatz ist der Kern von tayloristischer „Professionalisierung“ und Effizienz, wie er im 20. Jahrhundert gepflegt und vervollkommnet wurde.

Wenn wir aber folgende Anfrage haben: Mach mal eine Schulung zum Thema Flight Levels in SAFe Release Trains — Freunde fürs Leben… Aber die Teilnehmer sind noch nicht ganz klar, da muss ich erst mal fragen, sollen wir da alle rein tun oder nur das Business? Und sind das dann eher zwei Tage oder (Business hat nie Zeit) geht es auch an einem Tag? Und brauchen wir die Design-Abteilung? Und sollte man da Grundwissen voraussetzen, wenn ja, welches? Dann hab ich eine Fragestellung, die in meinen Standardweg X nicht reinpasst. Wir kennen das, der Sachbearbeiter sagt uns: Das kann ich in meiner Maske nicht eingeben.

Aber selbst, wenn wir es eingeben könnten, wäre es nicht sinnvoll, denn was wir hier brauchen, ist: Austausch, Ping Pong, Kollaboration, zusammen nachdenken und Pläne schmieden. Klaus Leopold, Begründer des Flight-Level-Ansatzes, nennt das agile Interaktionen. Über einen standardisierten Ansatz mit einem anderen Service zu sprechen, könnte nicht alle nötigen Fragen, Ideen, Rahmenbedingungen und Seiteneffekte anmelden, die der Service wissen müsste, damit wir zusammen (!) das beste Ergebnis generieren. Das ist es u.a., was ein Flight Level System leistet.

Kanban Skalierung: Agile Interaktionen vs. Service Canvas

Wir haben also zwei Fälle, den komplizierten, den man standardisieren kann, und den komplexen, wo man agile Interaktion braucht. Kunden-Beispiel: Für die gemeinsame Arbeit an der Wertschöpfung nutzen wir ein „klassisches“ Flight-Level-2-Board, auf dem Arbeitspakete (Epics, User Stories) abgebildet sind, bei denen es Abhängigkeiten zwischen mehreren Teams gibt. Diese Pakete durchlaufen auf dem FL2-Board den ganzen Ende-zu-Ende-Wertstrom. Einmal in der Woche besprechen alle relevanten Personen aus allen Services/Teams den Stand, wie bei einem Kanban-Daily-Standup auch. Denn genau das geschieht in einem FL2-Standup: Die Abhängigkeiten werden visualisiert und Blocker, Bottlenecks und auftauchende Probleme gemeinsam thematisiert. Ziel ist: Gemeinsame zuverlässige Lieferung von Wert.

So sieht ein solches Flight Level System schematisch z.B. aus:

Aber nicht alles, was zwischen zwei Teams bzw. Services passiert, muss andauernd besprochen werden, wie schon gesagt. Für alles Standardisierbare haben wir einen einfachen Service Canvas gebaut, der pro Service folgende Dinge offenlegt:

• Welche Arten von Anfragen (Demand) nimmst du an?
• Hast du Definitions of Ready für diese Demands?
• Welche Dependencies hast du unter Umständen bei diesen Demands?
• In welcher Form lieferst du und hast du Definitions of Done für die Lieferung?
• Welche Serviceklassen bietest du an und wie sehen deine Lead-Time-Verteilungen aus? (vgl. hierzu Was bedeutet „bessere“ Lead Times?! in unserem Blog)

All diese Dinge will ich nämlich nicht immer wieder besprechen müssen, so a la „Hey Joe, wie lange brauchst du für X“ oder „Hey Joe, kann ich das Ticket hier auch bissl schneller haben?“ oder „Hey Joe, wenn ich X von dir brauche, brauchst du dann den Y dafür?!“ usw. Diese Dinge müssen geklärt und definiert sein. So bietet jeder Service den anderen eine definierte Schnittstelle zur Verfügung, so wie es Services in der Softwareentwicklung über APIs tun.

Hier die Spreadsheet-Version des Service Canvas (Lizenz CC-2.0-BY-SA-NC):