Agile Organisation – Methoden, Prozesse und Strukturen im digitalen VUCA-Zeitalter

Beidhändigkeit bzw. situativ-adäquate Balance von klassisch und agil

Die aktuell vielerorts vorzufindenden, unterschiedlichen Organisations- und Führungsansätze in ein und demselben Unternehmen deuten darauf hin, dass es bei der Suche nach den richtigen Organisations- und Führungsprinzipien weniger um ein „entweder oder“, sondern um ein „sowohl als auch“ geht.¹³⁷ Auch sind die Übergänge von klassisch-hierarchisch zu agil teilweise fließend. Es gibt sowohl klassisch-hierarchische Grundstrukturen mit agilen Elementen (z. B. agile Einheiten und Methoden in einem traditionellen Konzern) als auch agile Grundstrukturen, die in Teilen klassisch-hierarchisch gelebt werden (z. B. Kreise in einer Holacracy-Struktur, die wiederkehrende Routineprozesse mit wenigen Unklarheiten und Veränderungen bearbeiten). Eine scharfe Trennlinie zwischen klassisch-hierarchischen und agilen Ansätzen zu ziehen, hätte folglich, wenn überhaupt, nur einen analytischen Mehrwehrt und ist lediglich theoretischer Natur. Es geht beim Organisieren nicht darum, sich als Gesamtunternehmen eindeutig und einseitig zwischen klassisch-hierarchischer und agiler Organisation zu entscheiden. Gesucht sind vielmehr situations-adäquate Organisationsansätze für ein erfolgreiches Handeln im jeweiligen, spezifischen Kontext – und dieser Kontext kann innerhalb eines Unternehmens sehr unterschiedlich sein.

Der scheinbare Konflikt zwischen Stabilität und Wandel bzw. Effizienz und Innovation ist ein schon lange existierendes Kernproblem jedweder Organisationsgestaltung. Die Diskussion um die dynamische Balance aus Stabilität und Wandel hat eine lange Historie und wird aktuell mit dem Fokus auf agile Ansätze erneut befeuert. Etliche Autoren befassen sich in empirischen Untersuchungen mit dem vermeintlichen Widerspruch zwischen Stabilität und Wandel bzw. Agilität (Agilitäts-Stabilitäts-Paradox).¹³⁸ Die Ergebnisse zeigen, dass eine dualistische, trennende Betrachtungsweise, insbesondere vor dem Hintergrund der aktuellen Umweltentwicklungen (vgl. Kapitel 1), nicht haltbar ist. „Organisieren ist diesen Überlegungen zur Folge kontinuierliches Oszillieren zwischen Verwandeln und Bewahren, zwischen Risiko und Sicherheit.“¹³⁹ Es gilt, die Balance zwischen Stabilität und Dynamik immer wieder aufs Neue auszuloten.

Einseitige Extreme sind i. d. R. zu vermeiden. Die Bekämpfung jedweder Unsicherheit und Komplexität durch den Abruf vermeintlich bewährter Muster und das Abspulen reflexhafter, tradierter Routinen und Standards kann ebenso wenig funktionieren wie exzessiver Wandel und permanenter Umbau durch ein Zuviel an Agilität.¹⁴⁰ In diesem Zusammenhang haben sich die Begriffe der „organisationalen Ambidextrie“ bzw. „Beidhändigkeit“ etabliert (engl. Ambidexterity, abgeleitet aus dem Lateinischen ambo „beide“ und dexter „rechte Hand“), die heute längst über die Grenzen der theoretischen Organisationslehre hinaus Anwendung finden und mittlerweile in den praktischen Sprachgebrauch von Organisationsentwicklern übergegangen sind.

Der Begriff basiert auf einem wegweisenden Aufsatz von MARCH aus dem Jahr 1991. Darin hat er Exploration und Exploitation als zwei Formen des organisationalen Lernens unterschieden.¹⁴¹ Während Exploration für Experimente, Alternativensuche, Varianzerhöhung und Risiko steht, repräsentiert Exploitation die Aspkete Regeleinhaltung, Standardisierung, Varianzreduktion und Risikovermeidung. Organisationale Ambidextrie beschreibt die Fähigkeit, einen organisatorischen Rahmen zu bieten, der es den Organisationsmitgliedern erlaubt, gleichzeitig effizient und flexibel zu agieren. Es beschreibt eine Organisation, in der sowohl bestehendes Wissen und bewährte Routinen auf effiziente und effektive Weise genutzt und optimiert werden können, um den operativen Geschäftsbetrieb am Laufen zu halten (Exploitation), als auch neues Wissen generiert und nach neuen Technologien geforscht wird, um Innovationen hervorzubringen und das Unternehmen zukunftsfähig auszurichten (Exploration) – und das zur gleichen Zeit (vgl. Abbildung 24).¹⁴² Untersuchungen zeigen, dass Unternehmen, die über einen längeren Zeitraum erfolgreich sind, es schaffen, sich kontinuierlich an neue Marktbedingungen anzupassen und zu verändern und gleichzeitig die eigene Identität zu bewahren, indem sie sich auf bestehende Strukturen und Kulturen stützen und diese bewusst reflektieren und weiterentwickeln.¹⁴³

Vor diesem Hintergrund haben unterschiedliche organisatorische Ansätze unter einem „Dach“ also nach wie vor ihre Berechtigung. Trotz dieser Erkenntnisse wurden klassische Organisationsansätze in den letzten Jahrzehnten immer wieder abgeschrieben und stehen aktuell mehr denn je im Kreuzfeuer der Kritik.¹⁴⁴ Tatsächlich werden aber viele der zentralen Kernaspekte klassischer Organisation nach wie vor angewendet – und auch agile Ansätze bedienen sich an diesen, wie in Kapitel 4.5 aufgezeigt wurde.

Abb. 24: Organisatorische Beidhändigkeit¹⁴⁵

Die Hartnäckigkeit, mit der sich klassische Ansätze im aktuellen Kontext behaupten, liegt also nur zum Teil an der mentalen Starrheit und der fehlenden Veränderungsbereitschaft von Entscheidern. Es liegt eben auch daran, dass ein gesundes Maß an organisatorischen Regeln und Ordnung sinnvoll ist und sich auch für die Arbeitsteilung und Koordination in komplexen und unbeständigen Umfeldern bewährt. Es gilt: „There is nothing inherently virtuous in agility, or … nothing inherently evil in bureaucracy. They are only tools in the service of a strategy for achieving results.“¹⁴⁶

Arten der Beidhändigkeit

Es werden meist zwei Ansätze der organisatorischen Beidhändigkeit unterschieden – und vor dem Hintergrund der Wirkungsweise sozialer Systeme wird unten noch ein dritter ergänzt. Bei der strukturellen Ambidextrie finden Exploitation und Exploration in organisatorisch getrennten Strukturen bzw. Organisationseinheiten/ -bereichen statt, was folglich die Herausforderung mit sich bringt, mit durchaus unterschiedlichen Arbeitsweisen, Führungsstilen und Kulturen unter einem Dach umzugehen. ARNDT/METTNER erläutern in ihrem Buchbeitrag am Beispiel der R+V, wie strukturelle Ambidextrie in der Praxis aussehen kann.

Im Gegensatz zu dieser Form der beidhändigen Organisation, findet bei der kontextuellen Ambidextrie keine strukturelle Trennung von Exploitation und Exploration statt, sondern es wird je nach Kontext bzw. konkreter Aufgabe situativ aus unterschiedlichen Organisationsprinzipien gewählt und nach diesen agiert, was die Beidhändigkeit im Denken und Handeln von jedem einzelnen Organisationsmitglied erfordert. Die Beiträge von STELZMANN/REININGER (TELE HAASE) und FISCHERMANNS (IBO) zeigen, wie kontextuelle Beidhändigkeit in der Praxis funktionieren kann.

Exploitation und Exploration stehen also nicht im Widerspruch. Wie Stabilität und Wandel bedingen sie sogar einander. Sie befinden sich wie zwei Pole in einem permanenten Spannungsfeld, das es immer wieder neu auszutarieren gilt. Wenn einer von beiden wegfällt, dann gerät die dynamische Balance aus der kontinuierlichen Optimierung des Bestehenden sowie der Innovation in und am System ins Wanken – und das Unternehmen in eine gefährliche Schieflage. Dieses Verständnis ermöglicht es, dass in ein und demselben Unternehmen der Fokus auf der effizienzgetriebenen Vermeidung von Verschwendung, dem fehlerfreien Ablauf standardisierter Prozesse und der kontinuierlichen Optimierung von Prozessen liegt (Exploitation), während zur gleichen Zeit in Experimente und neue Geschäftsmodelle mit ungewissem Ausgang investiert wird und Recruiting betrieben wird, um neue Talente und Kompetenzen zu gewinnen. Diese vermeintliche Paradoxie bzw. diesen Widerspruch gilt es im unternehmerischen Alltag mitzudenken und auszuhalten.¹⁴⁷ Denn zum einen ist die Investition in Exploration im engeren Sinne nur möglich durch eine effiziente und wertschöpfende Exploitation. Zum anderen hängt die zukünftige Exploitation und damit die Aufrechterhaltung des Geschäftsbetriebs maßgeblich von der erfolgreichen Exploration ab, die in der Gegenwart betrieben wird.

So befindet sich der gesamte Bankensektor aktuell in einem schwierigen Spannungsfeld. Gerade traditionelle Banken, dazu zählen z. B. Privathäuser sowie Sparkassen und Volksbanken, haben mit der andauernden Niedrigzinsphase und den damit verbundenen Margenrückgängen zu kämpfen. Um diese Entwicklungen zu kompensieren, werden beispielsweise Aufgaben und Zuständigkeiten gebündelt, in Beratungs- und Kundencentern zentralisiert und das Filialnetz verschlankt. Damit einher gehen umfangreiche Vorhaben zur Prozessautomatisierung und Standardisierung. Gleichzeitig müssen sich die Banken aber auch neu erfinden und den aufstrebenden Fintechs Paroli bieten, wenn sie weiterhin für Kunden attraktiv bleiben wollen. So hat z. B. die SPARKASSE DÜSSELDORF die sogenannte „netzwerkstatt“ gegründet. In eigens dafür geschaffenen Räumen wird in cross-funktionalen Teams und mithilfe agiler Arbeitsmethoden offen und kreativ an innovativen Produktlösungen und Vertriebsansätzen gearbeitet.¹⁴⁸

Eine eindeutige und trennscharfe Unterscheidung der beiden Ambidextrieformen in der Praxis fällt oft nicht leicht. Das gilt insbesondere, wenn sich Unternehmen gerade in einer Transformation befinden. So lassen sich aktuell unzählige Organisationsvarianten und Spielarten beobachten, die auch als hybride Formen der Ambidextrie bezeichnet werden können, z. B. ausgeprägte agile Einheiten neben Einheiten mit klassisch-hierarchischen Rahmenstrukturen, innerhalb derer die Organisationsmitglieder mithilfe agiler Prozess- und Projektmanagementmethoden netzwerkartig interagieren (vgl. Kapitel 8.6). Es ist aber in den kommenden Jahren zu erwarten, dass der Anteil agiler Organisationselemente weiter zunehmen wird.¹⁴⁹

Für die BMW-Group-IT gilt seit November 2016 das Motto „100 % agile“. Zu diesem konsequenten Schritt hat sich die IT-Führung um CIO KLAUS STRAUB entschieden, nachdem er den Versuch des sogenannten bimodalen Modells der zwei Geschwindigkeiten – das Nebeneinander klassischer und agiler Ansätze – für gescheitert erklärt hatte. Das Ziel war es, bis Ende 2019 alle IT-Projekte auf agil umgestellt zu haben. Eine echte Herausforderung, bedeutete es doch, dass auch die Fachbereichsseite ihre Arbeitsweise ändern musste. Die klassische Projektorganisation und das bisherige Vorgehen in Projekten wurde durch eine agile Produktstruktur mit End-to-end-Verantwortung auf Teamebene ersetzt (vgl. Kapitel 4). IT und Fachbereiche arbeiten gemeinsam an Produkten. Die Konzern-IT erweitert damit den DevOps-Ansatz – die Verschmelzung von IT-Entwicklung (Development) und IT-Betrieb (Operations)¹⁵⁰ – und bezieht auch die Fachbereiche konsequent in die agile Arbeitsweise ein (sog. BizDevOps). CIO STRAUB verfolgt damit einen agilen Ansatz, der auf alle Unternehmensbereiche ausstrahlt, mit Auswirkungen auf die gesamte Konzernorganisation und -kultur.¹⁵¹

Die Transformationen bei BMW insgesamt lässt sich in ihren Ansätzen durchaus in den Bereich der strukturellen Ambidextrie einordnen – eine Phase, in der klassisch-hierarchische Organisationsformen und -elemente (in den meisten Bereichen der BMW Group) weiterhin neben agilen Formen der Zusammenarbeit (insb. in der BMW IT) bestehen, im weiteren Verlauf aber durchaus sukzessive in eine stärker kontextuelle Form der Ambidextrie übergehen können bzw. strukturelle und kontextuelle Beidhändigkeit mischen.¹⁵²

Das Festhalten an vermeintlich bewährten Mustern und das Verpuffen vieler mit dem Etikett der Agilität versehenen Initiativen verdeutlichen die Herausforderungen, mit denen viele Entscheider in der Praxis aktuell konfrontiert sind.¹⁵³ Die oben aufgeführten Praxisbeispiele sowie die weiteren Beispiele in Kapitel 8.6 zeigen, dass für eine synergetische und erfolgreiche Koexistenz unterschiedlicher organisatorischer Ansätze eine Beidhändigkeit vonnöten ist, die nicht nur in Form einer strukturellen oder kontextuellen Ambidextrie methodisch und organisatorisch auf Unternehmens- und Teamebene ansetzt, sondern das Individuum als kleinste organisatorische Einheit in den Mittelpunkt des Geschehens rückt, damit der bewusste Umgang mit Veränderung selbst zum Muster werden kann. Denn eine Methode, eine Organisationsform oder ein Betriebssystem ist immer nur so gut, wie es zur aktuell gelebten Kultur passt, der Summe an Interaktionen und Kommunikation, die in einem Unternehmen passieren. Es braucht also auch eine kulturelle Beidhändigkeit. Diese impliziert ein beidhändiges Mindset verinnerlicht zu haben, sich am Unternehmenserfolg auszurichten, Musterbrüche zu erkennen und undogmatisch, sowohl klassisch-hierarchisch als auch agil denken, kommunizieren und handeln zu können. Dass diese Kompetenz nicht das Privileg Einzelner bleiben oder auf sogenannte Kopfmonopole reduziert sein darf, liegt auf der Hand. Für eine erfolgreiche Beidhändigkeit im Unternehmen(sbereich) müssen viele der beteiligten Mitarbeiter beidhändig denken und handeln können. Dies ist die Voraussetzung für gelebte Ambidextrie.¹⁵⁴

Damit dies gelingt, sind der Wille und die Bereitschaft entscheidend, sich mit der eigenen Situation offen und ehrlich auseinanderzusetzen und andere auf dieser „Learning Journey“ mitzunehmen. FISCHERMANNS beschreibt in seinem Beitrag, wie eine solche Lernreise aussehen kann. Dabei kommt den Führungskräften eine wichtige Rolle zu. Zwar kann eigenverantwortliches Denken und Handeln weder delegiert noch angeordnet werden und letztlich entscheidet jeder Einzelne selbst über den Grad der Eigenverantwortung. Führungskräfte können und sollten den Mitarbeitern allerdings den Weg bereiten und sie ermutigen, mehr Verantwortung zu übernehmen, d. h. Selbstorganisation bzw. Selbstführung braucht Führung – Agile Führung (vgl. Kapitel 9 sowie die Beiträge von HARTMANN und SCHULLER/FUCKER).¹⁵⁵

Die vorgestellten Arten der Beidhändigkeit lassen sich folgendermaßen zusammenfassen:

Abb. 25: Arten der Beidhändigkeit

6 Agile Prozess- und Projektmethoden
6.1 Überblick

In den folgenden Kapitel 6 bis 8 werden verschiedene konkrete agile Prozess- und Strukturansätze vorgestellt, welche auf den in Kapitel 4 erläuterten Charakteristika agiler Organisation basieren. Wie in Kapitel 3.1 dargestellt, sollten – auf einer gegebenen Organisationsebene – i. d. R. zuerst die Prozesse und dann erst die Strukturen gestaltet werden (Primat der Prozesse), da die Prozesse die Unternehmensleistung generieren und es die Prozessergebnisse sind, die vom Kunden wirklich wahrgenommen werden. Dementsprechend starten wir in Kapitel 6 mit Methoden zur agilen Gestaltung von Prozessen bzw. – wenn sie einmaligen Charakter haben – Projekten.

Laut der Studie „Status Quo (Scaled) Agile 2019/20” nutzen 91 % der befragten 642 Unternehmen im deutsche Sprachraum agile Methoden.¹⁵⁶ Mit 84 % ist Scrum der meistgenutzte agile Ansatz. Ebenfalls eine große Bedeutung für die Mehrheit der Befragten hat Kanban. In der Regel erfolgt die Nutzung ergänzend zu klassischen Methoden, nur 20 % der Befragten bezeichnen sich als durchgängig agil. Die häufigsten Einsatzbereiche agiler Methoden sind Software-Entwicklung (75 %), IT-nahe Themen (52 %), Aktivitäten ohne besonderen IT-Bezug wie bspw. Marketing, Strategie- und Organisationsentwicklung (39 %) und die physische Produktentwicklung (19 %).

Die in der Studie am häufigsten genannten Ziele des Einsatzes agiler Methoden sind Optimierung der Produkteinführungszeit (56 %), Optimierung der Qualität (39 %), Reduzierung von Risiken (38 %) und Optimierung der Teammoral (35 %). 85 % der Anwender agiler Methoden berichten auch von realisierten Verbesserungen bei Ergebnissen und Effizienz. Der Zeitvergleich zu früheren Auflagen der Studie offenbart aber auch, dass die Einschätzung der Erfolgsquote agiler Ansätze in den letzten Jahren – mit der zunehmenden Verbreitung – insgesamt gesunken ist.

Im globalen „14th Annual State of Agile Report” geben 95 % der 1.000 befragten IT-Experten und Manager an, dass in ihrem Unternehmen agile Methoden genutzt werden – also ähnlich zum Befund der vorher genannten Studie für den deutschen Raum.¹⁵⁷ Auch international ist eindeutig Scrum die am häufigsten genutzte agile Methode. Auch die häufigsten Einsatzbereiche sind weltweit ähnlich. Laut der globalen Studie bescheinigen sich 16 % der befragten Unternehmen einen hohen agilen Reifegrad. Die Mehrheit nutzt zwar agile Praktiken, sieht sich diesbzgl. aber noch in einem Reifeprozess.

Im Hinblick auf die realisierten Erfolge berichten 70 % von einer erhöhten Anpassungsfähigkeit auf geänderte Prioritäten, jeweils 65 % erkennen eine höhere Projektsichtbarkeit und eine bessere Abstimmung von IT und Business. 60 % der Befragten haben die „Time to Market“ reduziert. Fast ebenso viele berichten von einer höheren Teammotivation (59 %) und Teamproduktivität (58 %). Reduzierte Kosten erkennen 26 %.

Im Folgenden werden die wichtigsten bzw. bekanntesten agilen Prozess- bzw. Projektmethoden vorgestellt.

6.2 Kanban

Eine sehr bekannte agile Prozessmethode ist Kanban.¹⁵⁸ Der Ansatz wurde ursprünglich 1947 von TAIICHI OHNO bei der TOYOTA MOTOR CORPORATION entwickelt (vgl. Kapitel 2.1 und 2.3). Ausgangspunkt der Überlegungen waren lange Durchlaufzeiten sowie hohe und damit kostenintensive Lagerbestände an Roh- und Halbfertigmaterialien. Als Ursache identifizierte OHNO den zentral an einer Stelle und bis ins kleinste Detail vorausgeplanten Materialfluss. Dieses Vorgehen passte nicht dazu, dass es in der Realität immer wieder zu Schwankungen bzw. Planabweichungen an verschiedenen Stellen im System kam. Die Fähigkeit, kurzfristig und an der Produktionsstelle „vor Ort“ auf solche Schwankungen zu reagieren, war sehr begrenzt. Dadurch kam es entweder zu zeitlichen Verzögerungen (lange Durchlaufzeiten) oder aber die mangelnde Flexibilität wurde durch Vorratshaltung kompensiert (kapitalintensive Lagerbestände).

Vor diesem Hintergrund suchte OHNO nach einem stärker dezentral gesteuerten Ansatz, der sich weniger an vorausgeplanten Mengen und mehr am tatsächlichen Verbrauch von Materialien am Bereitstell- und Verbrauchsort orientiert. Seine Kernidee bestand darin, den Materialfluss in der Produktion stärker nach dem Supermarkt-Prinzip zu organisieren. Das heißt, wenn sich eine Lücke im Regal abzeichnet, weil viele Verbraucher zugreifen, wird diese bemerkt und aufgefüllt. Im Produktionsbereich bedeutet dies, dass (erst bzw. schon) dann, wenn sich eine reale Lücke bzw. ein Engpass abzeichnet, der Auftrag zur Anlieferung bzw. Nachproduktion angestoßen wird – egal wie das ursprünglich einmal zentral angedacht und geplant war.

Auf Basis dieser Überlegung baute OHNO die Produktionsprozesssteuerung tiefgreifend um. An die Stelle einer sehr komplexen, verschachtelten und aufwendigen Zentralsteuerung treten dezentrale, selbstregelnde, autonome Regelkreise. Die primäre Steuerung wandert von der zentralen Planungseinheit zum letzten Glied der Produktionsprozesskette. Wenn dort der Lagerbestand eines bestimmten Materials einen definierten Mindestwert bzw. Meldebestand unterschreitet, wird dies an das vorgelagerte Glied der Produktionskette bzw. das zuständige Lager gemeldet. Hierfür werden Melde- bzw. Signalkarten verwendet, die dem Ansatz den Namen gegeben haben, denn „Kan“ bedeutet im Japanischen Signal und „Ban“ Karte. Bei Erhalt einer Signalkarte (Kanban) stellt das jeweilige Glied der Produktionskette entweder das Material bereit und/oder meldet seinerseits einen Bedarf an die vorgelagerte Prozessstufe. Dadurch wird ein regelmäßiger Fluss (Flow) im Prozess hergestellt und die Anpassungsfähigkeit wird erhöht. Durchlaufzeiten werden kürzer und Lagerbestände geringer.

Weil in diesem Ansatz die Materialien quasi vom Ende der Kette gezogen (pull) und nicht von einer Zentraleinheit durch den Produktionsprozess durchgedrückt (push) werden, wird von einem Pull-System bzw. einem Pull-Prinzip gesprochen (vgl. Kapitel 4.2). Dieses Prinzip ist letztlich der zentrale Kern von Kanban.

Ein wichtiges Element, damit dieses dezentrale Pull-System funktioniert, ist Transparenz. Die Prozessbeteiligten benötigen transparente Informationen über den aktuellen Stand, insb. mögliche Engpässe. Dies wird insbesondere über verschiedene Tafeln bzw. Kanban-Boards gewährleistet.

In der IT hat sich im Laufe der Zeit ein spezieller Kanban-Ansatz entwickelt, der meistens gemeint ist, wenn im agilen Umfeld von Kanban gesprochen wird. Wesentlicher Treiber der Entwicklung von Software-Kanban (bzw. Kanban für die IT) war DAVID ANDERSON.¹⁵⁹ Er benutzt Kanban-Boards, um den bestehenden Softwareentwicklungsprozess zu visualisieren. Auf den Tafeln wird dargestellt, wie die Aufgaben die verschiedenen Prozessschritte bzw. -phasen durchlaufen. Häufig werden dafür einfache Whiteboards mit verschiedenen Spalten für die Prozessschritte/ -phasen sowie Haftnotizen (Post-its) für die Aufgaben verwendet. Es gibt aber natürlich auch elektronische Varianten (wie z. B. Trello, Asana).

Im einfachsten Modell besteht ein Kanban-Board aus lediglich drei Spalten:

To Do/Zu erledigen: In der linken bzw. ersten Spalte stehen die noch nicht begonnenen, aber zu erledigenden Aufgaben.

In Progress/In Bearbeitung: Aufgaben, die sich in der Bearbeitung befinden, stehen in der mittleren Spalte.

Done/Fertig: Fertiggestellte Aufgaben stehen in der rechten bzw. letzten Spalte.

Diese einfachste Variante eines Kanban-Boards ist in vielen Bereichen ausreichend und wird in unterschiedlichen Anwendungsfeldern (z. B. im Rahmen von Scrum) benutzt. Bei komplexeren Prozessen ist es aber auch oft nötig bzw. sinnvoll, den „In Progress“-Bereich noch weiter aufzuspalten. Wie dies im Rahmen der Softwareentwicklung aussehen kann, zeigt Abbildung 26. Grundsätzlich sind Teams aber frei, die Prozessphasen bzw. Kanban-Spalten passend zum konkreten Prozess zu gestalten.

Abb. 26: Kanban-Board (beispielhaft)¹⁶⁰

Gemäß dem Pull-Prinzip ziehen sich die Teams bzw. die Teammitglieder aktiv neue Aufgaben aus der To-do-Spalte bzw. der vorgelagerten Prozessphase, wenn ihre vorherige Aufgabe abgeschlossen ist. Das heißt, die Aufgaben werden nicht von links nach rechts gedrückt, sondern von den für die Aufgabenerfüllung zuständigen Mitarbeitern „vor Ort“ immer eine Spalte weiter nach rechts gezogen.

Solche Kanban-Boards schaffen Transparenz über den Prozess und machen mögliche Probleme deutlich, die den Prozessfluss (Flow) behindern (könnten). Durch den Einsatz von Kanban-Boards wird der Prozess kontinuierlich beobachtet und wenn nötig optimiert. Zum Beispiel entstehen oft Flaschenhälse, an denen sich die Arbeit aufstaut. Dort muss dann eingegriffen werden, was beispielsweise durch das Umschichten von Ressourcen oder eine andere Aufteilung der Arbeit passieren kann. Auch kommt es immer mal wieder vor, dass einzelne Aufgaben aufgrund besonderer Umstände oder fehlender Ressourcen blockiert sind. Dies sollte im Kanban-Board visualisiert und damit transparent gemacht werden (vgl. Abbildung 26), was den Druck für eine zeitnahe Problemlösung erhöht. Somit ist ein Kanban-Board ein Prozessvisualisierungs-, -analyse- und -steuerungsinstrument. Die zentrale Steuerungsgröße ist die Vor- und Durchlaufzeit.

Ein wichtiges Element zur Steuerung sind dabei Work-in-Progress-Limits (WIP-Limits). Zur Unterstützung der Fokussierung (vgl. Kapitel 4.2) und zur Vermeidung bzw. frühzeitigen Erkennung von Engpässen sollte die Anzahl von Aufgaben in den einzelnen „In Bearbeitung“-Prozessphasen beschränkt werden. Im Beispiel in Abbildung 26 dürfen sich bspw. nur 4 Aufgaben in der Entwicklungs- und 3 Aufgaben in der Testphase befinden.

Ein Kanban-Board sollte möglichst an einem zentralen Ort stehen, der jederzeit für alle Teammitglieder zugänglich ist. Dadurch wird erreicht, dass immer alle Teammitglieder einen Überblick über den Prozessstatus haben. Dies regt dazu an, im Gesamtzusammenhang zu denken und fördert die Selbstorganisation.¹⁶¹

Bei der Arbeit mit den Kanban-Boards haben sich folgende drei Meetingformen etabliert:

Tägliche Status-Meetings: In kurzen (ca. 15 min) Meetings werden der Projektfortschritt, (mögliche) Probleme und Lösungswege besprochen. Längere Diskussionen werden bewusst ausgelagert.

Ursachenanalyse-Meetings: Bei größeren bzw. regelmäßigen Problemen (z. B. gestaute Aufgaben, unausgelastete Prozessteile, lange Warte- oder Durchlaufzeiten) wird diesen in Analysemeetings auf den Grund gegangen (Root Cause Analysis). Es geht darum, Fehlerursachen zu finden und zu beseitigen.

Operations Review Meetings: Unregelmäßige Treffen, um aus den gemachten Erfahrungen im Umgang mit dem Board, im Prozess und in der Zusammenarbeit zu lernen (vergleichbar zu Retrospektiven in anderen agilen Methoden).

Kanban eignet sich in Situationen, in denen es einen standardisierten, aber nicht voll automatisierten Prozess gibt, den unterschiedliche Aufgaben durchlaufen. Hier hilft der Ansatz dabei, Transparenz herzustellen, Selbstorganisation zu ermöglichen, Probleme frühzeitig zu erkennen und den Prozess kontinuierlich zu verbessern. In diesem Buch beschreibt KALNIK anhand ihres Beitrags, wie wichtig der tägliche Abgleich und die Visualisierung der Themen ist, um als Team zusammenzuarbeiten. Die kontinuierliche Verbesserung ist in der wöchentlichen Team-Runde fest verankert.

Die Kanban-Methode setzt tendenziell an gegebenen Prozessen an, die mehrmals durchlaufen werden, und versucht diese (immer weiter) zu optimieren (im Sinne einer kontinuierlichen Verbesserung). Bei projektartigen Einzelprozessen bzw. der Entwicklung von Neuem passen andere agile Ansätze besser – bspw. Scrum.