Die Spielregeln definieren: Rollen, Serviceklassen und explizite Regeln

Im letzten Kapitel haben wir dein erstes Kanban-System aufgesetzt. Das Board läuft, die Arbeit fließt, und das Team synchronisiert sich täglich. Doch bald wirst du auf neue Fragen stoßen: Wer kümmert sich eigentlich darum, dass die richtigen Aufgaben im Backlog landen? Was machen wir, wenn ein super-dringender Notfall alle Pläne über den Haufen wirft? Und wann genau ist eine Aufgabe eigentlich „fertig“ konzipiert?

Um diese Fragen zu beantworten, ohne in Bürokratie zu verfallen, braucht dein Kanban-System klare Spielregeln. Diese Regeln sind keine Fesseln, sondern Leitplanken. Sie schaffen die Transparenz und das gemeinsame Verständnis, die selbstorganisierte Teams benötigen, um effektiv und ohne ständige Reibungsverluste zusammenzuarbeiten.

Wer ist wofür verantwortlich? Die zwei zentralen Rollen

Kanban kommt im Gegensatz zu Scrum bewusst ohne ein starres Set an vordefinierten Rollen aus. Es geht davon aus, dass das Team die Arbeit gemeinsam erledigt. In der Praxis haben sich jedoch zwei Verantwortlichkeiten als extrem nützlich erwiesen, um die beiden wichtigsten Perspektiven im System abzudecken: den Wert und den Fluss.

1. Der Service Request Manager (SRM): Der Hüter des „Warum“ Der SRM konzentriert sich auf die linke Seite des Boards – alles, was passiert, bevor die eigentliche Entwicklung beginnt. Man könnte ihn als den kundenorientierten Part verstehen.

• Aufgabe: Er hält engen Kontakt zu Kunden und Stakeholdern, übersetzt deren Bedürfnisse in verständliche Arbeitspakete (Stories) und sorgt dafür, dass die „Up Next“-Spalte immer die wertvollsten Aufgaben in der richtigen Reihenfolge enthält.
• Fokus: Maximaler Wert für den Kunden. Er stellt sicher, dass das Team die richtigen Dinge baut.

Diese Rolle wird oft von Personen wahrgenommen, die es im Unternehmen bereits gibt: Product Manager, Projektleiter oder Account Manager. Wichtig ist nicht der Titel, sondern dass eine Person diese Verantwortung klar innehat.

2. Der Service Delivery Manager (SDM): Der Hüter des „Wie“ Der SDM, oft auch Flow Master genannt, konzentriert sich auf die rechte Seite des Boards – den reibungslosen Fluss der Arbeit durch das System.

• Aufgabe: Er beseitigt Hindernisse (Blocker), überwacht die Einhaltung der WiP-Limits und hilft dem Team dabei, seinen Prozess kontinuierlich zu verbessern (Kaizen). Er ist der Facilitator, der das System geschmeidig hält.
• Fokus: Maximaler Flow. Er stellt sicher, dass das Team die Dinge richtig baut – und zwar effizient.

In kleinen Teams kann eine Person beide Hüte tragen. Entscheidend ist, dass die beiden Fokuspunkte – Wert und Fluss – bewusst gemanagt werden.

Wie gehen wir mit unterschiedlicher Arbeit um? Serviceklassen

Nicht alle Aufgaben sind gleich. Ein kritischer Produktionsfehler hat eine andere Dringlichkeit als ein neues Feature. Das einfache Pull-Prinzip („nimm das Nächste von oben“) stößt hier an seine Grenzen. Die Lösung dafür sind Serviceklassen (Classes of Service).

Eine Serviceklasse ist eine explizite Regel, wie mit einer bestimmten Art von Arbeit umgegangen wird. Anstatt in die oben beschriebene Prio-1-Falle zu tappen und endlos über Dringlichkeit zu diskutieren, schaffst du mit Serviceklassen klare Kategorien mit eigenen Regeln.

Typische Serviceklassen:

• Standard: Die normale Arbeit. Sie folgt dem FIFO-Prinzip („First In, First Out“) und den normalen WiP-Limits.
• Express (Expedite): Der Notfall (z.B. ein Produktionsausfall). Eine Aufgabe in dieser Klasse darf andere überholen und ignoriert oft das WiP-Limit. Sie sollte auf dem Board visuell hervorstechen (z.B. durch eine rote Farbe).
• Festes Lieferdatum (Fixed Date): Aufgaben, die zu einem bestimmten externen Termin fertig sein müssen (z.B. für eine Messe oder eine Gesetzesänderung). Sie werden nicht so schnell wie möglich, sondern so rechtzeitig wie möglich bearbeitet.

Dein Praxistipp: Fang einfach an. Führe nur zwei Klassen ein: „Standard“ und „Express“. Definiert als Team glasklare Kriterien, was ein Notfall ist und was nicht. Nutzt die Express-Klasse so selten wie möglich. Allein diese eine Regel wird eure Diskussionen über Dringlichkeit dramatisch vereinfachen.

Wie schaffen wir ein gemeinsames Verständnis? Regeln explizit machen

Viele Konflikte und Verzögerungen in Teams entstehen durch implizite, unausgesprochene Annahmen. Einer denkt, eine Aufgabe ist bereit für die Entwicklung, der andere sieht noch offene Fragen. Um das zu vermeiden, macht Kanban eine einfache, aber wirkungsvolle Vorgabe: Macht eure Regeln explizit!

Definiert für jeden Spaltenübergang auf eurem Board klare Kriterien. Diese „Policies“ müssen nicht kompliziert sein. Es sind einfache Checklisten, die für alle sichtbar sind.

Beispiel: Regeln für den Übergang von Up Next zu Concept:

• Die Story ist vom SRM priorisiert und steht ganz oben.
• Das „Warum“ und der Kundennutzen sind klar verständlich.
• Es gibt freie Kapazität im Concept-Bereich (WiP-Limit wird nicht verletzt).

Allein das Gespräch über diese Regeln ist ungemein wertvoll. Es zwingt das Team, seinen eigenen Prozess zu reflektieren und ein gemeinsames Verständnis zu schaffen. Neue Teammitglieder können sich sofort orientieren, und Diskussionen werden von Meinungen auf Fakten verlagert.

Fazit: Struktur schafft Freiheit

Rollen, Serviceklassen und explizite Regeln klingen zunächst nach Bürokratie. Aber im Kontext von Kanban sind sie das genaue Gegenteil. Sie sind keine Fesseln, sondern das Geländer, das dem Team die Sicherheit gibt, sich frei und selbstorganisiert zu bewegen.

Sie reduzieren den mentalen Overhead, minimieren Reibungsverluste und schaffen die Transparenz, die es braucht, um den Fokus auf das zu legen, was wirklich zählt: einen kontinuierlichen Fluss von Wert zum Kunden.

Mit diesem stabilen System und klaren Regeln hat dein Team nun alles, was es braucht, um den eigenen Arbeitsprozess zu meistern. Aber was passiert außerhalb des Teams? Im nächsten Kapitel zoomen wir heraus und schauen uns an, wie Kanban dabei hilft, den gesamten Wertstrom im Unternehmen zu optimieren – vom ersten Kundenwunsch bis zur finalen Auslieferung.