Dennis Willkomm - Roadmap durch die VUCA-Welt

Hält man die vorgeschlagenen Praktiken ein, dann stellt Kanban ein Werkzeug für die evolutionäre Veränderung in Unternehmen dar. Durch das Aufdecken von Engpässen im System und der Konzentration auf eine kontinuierliche Verbesserung wird nach und nach das Gesamtsystem immer leistungsfähiger.

Beim Einsatz von Kanban spielt das Einhalten von WIP-Limitseine sehr große Rolle. Gerade Teams, die noch unerfahren mit dieser Vorgehensweise sind, tendieren dazu, die Begrenzungen zu ignorieren. Dies kann zum einen daran liegen, dass sie noch nicht ganz verstanden haben, welch große Bedeutung die Limitierung der Arbeit für den evolutionären Veränderungsprozess in Kanban besitzt. Zum anderen ist es aber auch häufig so, dass viele traditionelle Unternehmen großen Wert darauflegen, alle zur Verfügung stehenden „Ressourcen“ optimal auszulasten. Daher fühlen sich die Mitglieder eines Arbeitsteams verpflichtet, lieber eine neue Aufgabe zu beginnen, anstatt untätig herumzusitzen. Wie die Engpasstheorie jedoch verdeutlicht, führt das dazu, dass sich die Arbeit vor dem Engpass auftürmt und somit mehr Probleme entstehen, als es Mehrwert bringt. Umso wichtiger ist es, die Arbeit entsprechend zu visualisieren. Denn es geht darum, die Arbeit zu managen und sich die Menschen darum herum selbst organisieren zu lassen. Wenn die Arbeit allerdings nicht sichtbar ist, dann könnte leicht die Tendenz entstehen, das zu managen, was die Manager sehen können: die Menschen.

Der Fokus sollte erst einmal darauf liegen, den Engpass zu entlasten und dafür zu sorgen, dass wieder Kapazitäten frei werden. Wenn hier keine Möglichkeit der Unterstützung besteht, dann kann man die entstandene Zeit für die Verbesserung des Prozesses und des Gesamtsystems zu nutzen, mit dem Ziel, den Engpass langfristig zu beheben. Diese freigewordene Zeit wird oftmals auch als Slack bezeichnet und spielt in so gut wie allen agilen Rahmenwerken eine wichtige Rolle. Slack ist wichtig und notwendig, um die Leistungsfähigkeit des Gesamtsystems kontinuierlich zu steigern.

Bisher haben wir gesehen, wie Kanban funktioniert, wenn ein Team eine Anforderung von der Aufnahme bis zur Umsetzung komplett bearbeitet. In der Praxis wird es aber in einem großen Unternehmen mehrere Teams geben, die in irgendeiner Form zusammenarbeiten müssen, um eine Aufgabe wirklich abzuschließen. Hier ergeben sich schnell Abhängigkeiten und es ist zum einen oft unübersichtlich, zum anderen kaum möglich, ein einziges Kanban-Board zu haben, das alle Arbeitsschritte in der gewünschten Granularität visualisieren kann. Viele einzelne Kanban-Teams machen daher noch nicht automatisch ein agiles Unternehmen aus. Ein anschauliches Beispiel, wie man zu echter „Business-Agilität“ gelangt liefert Klaus Leopold, der zur Orientierung verschiedene Flight-Level(Flughöhen) vorschlägt (Leopold/Kaltenecker 2018).

Auf dem obersten Flight-Level schaut man auf die Wertschöpfungsketten, die in einem Unternehmen vorhanden sind. Die meisten Unternehmen haben mehr als ein Produkt oder teilen ihre Arbeit in unterschiedliche Projekte auf. Diese stellen sehr häufig auch eigene Wertschöpfungsketten mit gewissen Besonderheiten dar. Auf der oberen Ebene interessiert man sich genau für diese unterschiedlichen Initiativen und nutzt die Kanban-Praktiken, um auf dieser Granularität den Gesamtwert für das Unternehmen zu optimieren.

Das Flight-Level darunter konzentriert sich auf eine dieser Wertschöpfungsketten und stellt die Arbeitsschritte und die Aufgaben in einer Granularität dar, die eine Koordination der verschiedenen beteiligten Teams ermöglicht. Es ist die Ebene der Koordination.

Geht man noch ein Level tiefer, so ist man auf der Team-Ebene, wo die Arbeit, die von einem Team erledigt wird, visualisiert und optimiert wird. Wenn hier Arbeiten abgeschlossen werden, wird diese Aktualisierung auf das darüberliegende Level übertragen. Würde man Kanban nur auf das Teamlevel beschränken, dann würde es eventuell zu lokalen Optimierungen kommen, die – wie wir gesehen haben – das Gesamtsystem eventuell sogar verschlechtern. Durch die unterschiedlichen Flughöhen hat man aber auf unterschiedlichen Ebenen die Engpässe und auch mögliche Verbesserungen im Blick, so dass man die gesamte Wertschöpfungskette und auch das gesamte Unternehmen verbessern kann.

Im Zusammenhang mit Kanban fällt oft der Begriff Kaizen,was sich aus den japanischen Begriffen kai (Wandel) und zen (zum Besseren) ableitet. Kaizen beschreibt den kontinuierlichen Verbesserungsprozess, der sich bei Einhaltung der Kanban-Praktiken von allein einstellen sollte. Darüber hinaus gibt es aber eine Reihe von Praktiken, die von den meisten Teams geteilt werden, auch wenn es keine Regeln gibt, die sie vorschreiben. So zum Beispiel regelmäßige Statusmeetings, Reviews oder auch Retrospektiven.

Eine weitere, gern genutzte Praktik bei der Verwendung von Kanban, ist die Einführung von Service Level Agreements (SLA).Die Aufgaben werden dann bestimmten Klassen zugeordnet. So ist es möglich, bestimmte Aufgaben einem Service Level zuzuweisen, der bevorzugt behandelt wird. Sobald dann an einer Station Kapazitäten frei werden, wird eine solche Aufgabe als erstes bearbeitet. Dies führt auch zu unterschiedlichen Cycle- und Lead-Times für die verschiedenen Service Level, die auch zum Kunden kommuniziert werden können.

„Mit 85 % ist ScrumScrum die meistgenutzte agile Methode. Danach folgen Kanban, Lean und DevOps.“ Zu diesem Schluss kommt die Studie Status Quo Agile,1 die von der Hochschule Koblenz 2016/17 durchgeführt wurde.2 Scrum erfreut sich damit viele Jahre nach seiner ersten Erwähnung im „New new product development game“ sehr großer Beliebtheit.

Eine tragende Rolle bei der systematischen Umsetzung der von Takeuchi und Nonaka beschriebenen Praktiken nahmen Ken Schwaber und Jeff Sutherland ein. Jeff Sutherland griff die beschriebene Idee auf und nutzte die Erkenntnisse in ersten Projekten. Ken Schwaber veröffentlichte bereits 1995 auf der OOPSLA-Konferenz einen ersten Beitrag über Scrum. Beide Pioniere gehörten auch zu den Unterzeichnern des Agilen Manifests im Jahr 2001. Im gleichen Jahr veröffentliche Ken Schwaber auch das erste Buch zum Thema Scrum, gemeinsam mit Mike Beedle (Schwaber/Beedle 2002).

Schwaber und Sutherland taten sich zusammen und gestalteten gemeinsam den Scrumguide,Scrumguide der die Spielregeln von Scrum definiert, auf die sich alle Anwender des Frameworks berufen.3 Der Scrumguide wurde in viele Sprachen übersetzt und wird regelmäßig aktualisiert. Auch wenn Scrum sehr populär in der IT ist, wird im Scrumguide explizit darauf hingewiesen, dass Scrum in allen erdenklichen Bereichen verwendet werden kann. Von einer großen Liste strahlender Beispiele berichtet Jeff Sutherland in seinem Buch „Die Scrum Revolution“ (Sutherland 2015). Der Scrumguide beschreibt drei wichtige Rollen,die zur Ausführung von Scrum benötigt werden.

Der Product Owner(Eigentümer des Produkts) hat die Verantwortung für das Produkt. Dafür muss er sicherstellen, dass die Aufgaben erledigt werden, die am meisten Wert generieren. Dies gelingt ihm, indem er alle Arbeiten, die zu erledigen sind, um das Produkt herzustellen, in das Product Backlog einträgt und dort in eine eindeutige Reihenfolge bringt.

In der Regel gibt es eine Reihe von Leuten, die ein Interesse an dem Produkt haben. Dies können zum einen (potenzielle) Kunden sein, zum anderen aber die eigene Unternehmensführung oder auch andere Abteilungen im eigenen Unternehmen. Die Aufgabe des Product Owners besteht nun darin, die Interessen dieser Stakeholdereinzusammeln und gegeneinander zu gewichten. Dafür muss er in engem Kontakt mit den Stakeholdern stehen.