#AusDerAgilenMethodenkiste | Serviceklassen (Typen von Arbeit) visualisieren oder was Scrum-Teams von Kanban lernen können

Arbeit ist nicht gleich Arbeit. Es gibt verschiedene Arten von Arbeit, die in ihrem Entstehungsprozess unterschiedliche Arbeitsschritte durchlaufen. Hier kommt eine Idee aus dem Kanban-Kontext ins Spiel, die sich auch im Scrum-Kontext gut einsetzen lässt: die Kategorisierung von Arbeit nach Serviceklassen.

Serviceklassen aus Kanban – Unterscheidung nach Arbeitstypen

Serviceklassen stellen Kategorien von Arbeit dar, die sich durch gemeinsame Merkmale auszeichnen. Meist lassen sich diese über den Wertstrom, den Arbeitsfluss von der „Annahme des Arbeitsauftrags“ bis zur „Lieferung des Ergebnisses“, den die Arbeit durchläuft, zusammenfassen. Aber auch die Unterscheidung zwischen Routineaufgaben und Forschungsaufgaben hilft bei einer ersten Kategorisierung. Man erkennt hier schon, dass die Arbeit unterschiedlich durch unser Arbeitssystem fließt. Bei Routinetätigkeiten und Aufgaben, die wir aufgrund unserer Erfahrung bereits kennen, können wir sehr genau definieren, wie der Arbeitsablauf aussehen muss. Anders sieht es bei Aufgaben aus, die in die Kategorie komplex fallen. Die jeweiligen Aufgabenkategorien erfordern jeweils einen anderen Arbeitsablauf in unserem Arbeitssystem in Form des Arbeitsflusses.

Die Herausforderung in einem agilen Team besteht nun darin, diese unterschiedlichen Arbeitstypen mit ihren teilweise unterschiedlichen Workflows in einem Kanban-Board (mit den Workflow-Schritten) so zu visualisieren, dass wir erkennen können, wie die Arbeit durch unser Arbeitssystem fließt und wo es zu möglichen Blockaden kommen kann.

Nehmen wir ein neutrales Beispiel. Ein Café mit Bistro. Es gibt warme Getränke, kalte Getränke, kleine Speisen. Die Bereitstellung dieser Dienstleistungen erfordert unterschiedliche Arbeitsabläufe. Wamgetränke wie Kaffee oder Tee erfordern mehr Arbeitsschritte als Kaltgetränke und Speisen wieder andere. Wollen wir diese in unserem Kanban-System abbilden, visualisieren wir zunächst die jeweiligen Arbeitsabläufe mit einer einfachen Prozesslandkarte für jede der drei Arbeitskategorien und legen diese übereinander. Dabei wird deutlich, dass sich die Arbeitstypen in den Arbeitsschritten überschneiden, aber auch unterschiedliche Arbeitsschritte von der Bestellung bis zur Ausgabe und Bezahlung durchlaufen.

Wie die Unterscheidung nach Arbeitstypen – nicht nur -Scrum-Teams hilft

Ähnlich verhält es sich in einem Scrum-Team, das häufig eben nicht nur einen Typus Arbeit aufweist, sondern mit unterschiedlichen Arbeitstypen konfrontiert sein kann.

Auf der einen Seite z.B. die klassische Entwicklung, auf der anderen Seite Routinetätigkeiten wie zum Beispiel Gremienarbeit und Öffentlichkeitsarbeit. Alle Arbeitstypen haben unterschiedliche Anforderungen an den Workflow, die wir im Kanbanboard abbilden können. Anforderungen, die zu Lösungen entwickelt werden, haben einen anderen Workflow als Routineaufgaben wie die monatliche Abrechnung mit den Zentralen Diensten oder die regelmäßige Information der politischen Gremien usw. Das ist Arbeit, die gemacht werden muss und die deshalb auch abgebildet werden sollte. Hinzu kommen ggf. dringende Aufgaben, die nicht bis zur nächsten Iteration warten können, sondern sofort erledigt werden müssen und den üblichen Workflow nicht durchlaufen.

Dies kann man übrigens sehr gut über sogenannte Swimlanes, wie in der folgenden Darstellung abbilden. Damit haben wir die jeweiligen Arbeitstypen direkt im Fokus und können das „Verhalten“ im Arbeitsfluss besser beobachten und daraus lernen. Wir erkennen besser, wie sich bestimmte Arbeitstypen durch unser System bewegen und können leichter reflektieren, was wir tun können, um unser Arbeitssystem weiterzuentwickeln.

Die Visualisierung hilft uns zu erkennen, wie die Arbeit durch unser System fließt und wo Herausforderungen durch Blockaden etc. entstehen können. Die Unterscheidung nach Arbeitskategorien hilft uns auch abzuschätzen, wie viel Arbeit wir in einer Iteration (Sprint) erledigen können. Routinetätigkeiten und Tätigkeiten, die wir aufgrund unserer Erfahrung bereits kennen, können wir aufgrund historischer Daten sehr gut einschätzen, wie viel Zeit wir dafür benötigen. Wir wissen aus der Vergangenheit sehr gut, wie lange es wahrscheinlich dauern wird, diese Art von Arbeit zu erledigen. Anders sieht es bei komplexen Anforderungen aus, mit denen wir noch keine Erfahrung haben. Das erleichtert uns die Kapazitätsplanung und entlastet uns bei Aufgaben mit hoher Komplexität, bei denen wir dieses Erfahrungswissen nicht haben. Wir wissen nun, wie viel Kapazität uns für komplexe Aufgaben zur Verfügung steht, wenn wir eine bestimmte Menge an Arbeit, deren Umfang wir bereits kennen, innerhalb unserer Iteration zugesagt haben.

Kanban ist mehr als nur WiP-Limit

Ich hoffe, mit diesem Beispiel gezeigt zu haben, dass Kanban viel mehr ist als die Darstellung eines Workflows auf einer Tafel mit der Limitierung paralleler Arbeit. Kanban als Methode ist ein wertvolles Werkzeug, um das Arbeitssystem visuell darzustellen, geht aber weit über die Visualisierung hinaus.

Kanban lässt sich auch gut mit Scrum kombinieren und unterstützt Scrum-Teams in vielerlei Hinsicht bei der Entwicklung und Gestaltung ihres Arbeitssystems. Ein Beispiel für die Möglichkeiten ist die hier dargestellte Unterscheidung von Arbeitstypen, die das kollaborative Arbeitssystem durchläuft.