Der stetig wachsende Werkzeugkasten von Microsoft Office 365 eröffnet dem geneigten Anwender unzählige Gelegenheiten, Prozesse und Projekte besser technisch zu unterstützen – oftmals, ohne dass diese Entwicklung aktiv von der IT-Abteilung gesteuert würde. Gerade im Falle von Microsoft Planner beobachte ich häufig, dass Planner-Boards (in Microsoft Planner: „Pläne“) wie Pilze aus dem Boden schießen, Menschen und vor allem ganze Teams ihre Arbeit darin zu organisieren beginnen. „Wir machen jetzt [auch] Kanban!“ ist eine für Office-365-Nutzer geradezu typische Äußerung. So erfreulich mir derartige emergente Entwicklungen auch erscheinen: Durch die Brille des Kanban-Begeisterten bin ich naturgemäß geradezu reflexhaft geneigt, mich über den zumeist äußerst niedrigen Reifegrad des auf diese Weise entstandenen Arbeitssystems zu mokieren. Wie vermessen von mir, startet Kanban doch immer „mit dem, was jetzt getan wird“ und strebt davon ausgehend nach „Verbesserung durch evolutionäre Veränderungen“¹! Genau davon soll dieser Artikel handeln: Wie komme ich möglichst pragmatisch von „einfach so“ entstandenen Microsoft Planner-Boards zu einem sich ebenso emergent evolutionär weiterentwickelnden und verbessernden Kanban-System – und das, ohne die dynamische Selbstorganisation „abzuwürgen“, die das ursprüngliche System entstehen ließ!

Die Selbstorganisation nicht „abwürgen“

Einfluss auf emergente Entwicklungen zu nehmen, bringt meiner Erfahrung nach immer die Gefahr mit sich, Dinge kaputt zu machen, das „zarte Pflänzchen“ der Selbstorganisation durch wohlmeinende Eingriffe aus Versehen absterben zu lassen. Im Falle der ungesteuert entstandenen (Selbst‑)Organisation rund um Microsoft Planner sollte man m. E. vor allem zwei Ansätze unbedingt vermeiden:

Führen Sie keine Tool-Diskussion. Obschon es sicherlich geeignetere und funktionalere Tools gibt und Microsoft Planner und Planner als Tool auch meist nur der einfachen Verfügbarkeit (im Zweifel direkt in Microsoft Teams) wegen gar nicht bewusst ausgewählt, sondern einfach nur benutzt worden ist, gilt es nun einmal, „mit dem, was jetzt getan wird“ zu starten – und das ist zumindest in Bezug auf das Tool nun einmal Microsoft Planner. Verfügbarkeit und Einfachheit waren hier offenkundig quasi Katalysator der Emergenz, das sollte man nicht kaputt machen.

Stülpen Sie dem zarten Pflänzchen der Selbstorganisation keine Frameworks oder Reifegradmodelle über. Ein kurzer Blick auf das Kanban Maturity Model (KMM)² zeigt bereits: Mit der hemdsärmeligen Dynamik eines schnell eingerichteten und genutzten Planner-Boards wäre es wohl der Komplexität und des Umfangs dieses Modells wegen schnell vorbei. Diese Auffassung ist übrigens weder als Kritik an dem Modell zu verstehen noch würde ich grundsätzlich davon abraten, das KMM gleichsam als „Nordstern“ im Hinterkopf zu haben; ich würde nur ein Team, das gerade begonnen hat, sich um ein Planner-Board herum zu organisieren, nicht damit quasi „überfallen“. Vergleichbares gilt m. E. übrigens für STATIK³ und alle anderen mehr oder minder „großen“ Ansätze; das, „was jetzt getan wird“, ist wirklich nur ein allererster Schritt und zumeist vor allem von Pragmatik geprägt. Meines Erachtens gilt es vor allem, das zarte Pflänzchen zu hegen und zu pflegen und in seinem Wachstum zu begleiten – dementsprechend also allerhöchstens nur sehr vorsichtig Einfluss zu nehmen, nur kleine, gezielte Anstöße zu geben.

Das zarte Pflänzchen hegen und pflegen

Gehen wir einmal klassisch ressourcenorientiert vor, schauen wir also einmal, was wir jetzt bereits haben: Das wohl grundlegendste der Kanban-Change-Management-Prinzipien – „Starte mit dem, was jetzt getan wird“ – ist offenkundig bereits inhärent erfüllt. Ebenso erfüllt bzw. genutzt ist die vergleichbar basale Praktik „Visualisiere“ – zumindest in einem gewissen (nicht zuletzt auch teilweise durch Microsoft Planner gesteckten) Rahmen:

Kanban-Prinzipien und -Praktiken (1) — Kanban-Prinzipien und ‑Praktiken (in Anlehnung an den „offiziellen Leitfaden“, a. a. O)

Den Wunsch nach Verbesserung aufnehmen

Möchten wir uns von dieser – übrigens m. E. durchaus guten – Ausgangsposition weiter in Richtung eines Kanban-Systems entwickeln, hilft meiner Erfahrung nach tatsächlich als Allererstes ein weiterer Blick auf die Kanban-Change-Management-Prinzipien: Ein Konsens, dass Verbesserung erzielt werden soll – und das kleinschrittig und evolutionär – erscheint mir geradezu offenkundig als notwendige Voraussetzung für eine Weiterentwicklung. Kann man sich tatsächlich nicht einmal darauf einigen, besser werden zu wollen, ist Verbesserung naturgemäß schwierig bis unmöglich⁴ – und ist kleinschrittig-evolutionäre Verbesserung nicht gewünscht und erscheinen den Beteiligten nur „big bang“-Verbesserungsprojekte denkbar, ist die Wahrscheinlichkeit für ein komplettes Scheitern des Prozesses erfahrungsgemäß sehr groß.

Den allgemeinen Wunsch nach Verbesserung (in erster Linie im Team und vor allem nicht ausschließlich bei den Führungskräften) abzufragen, zu explizieren und Zustimmung zu kleinschrittigen Veränderungen hin zum Besseren – evolutionär und durch gemeinsame Experimente validiert – einzuholen, dürfte also ein guter und vor allem sanfter Start in die Weiterentwicklung des Arbeitssystems sein. Nebenbei bemerkt dürfte diese Selbstverpflichtung ein wichtigerer „Nordstern“ sein als jedes Framework oder Reifegradmodell.

Kanban-Prinzipien und -Praktiken (2) — Kanban-Prinzipien und ‑Praktiken (in Anlehnung an den „offiziellen Leitfaden“, a. a. O)

Regeln? Prinzipien!

Arbeitsweisen zu verbessern, bedeutet zwangsläufig auch, Arbeitsweisen zu verändern. Gezielte Veränderung ist immer ein gesteuertes „vom Ist zum Soll“, setzt also voraus, dass ich weiß, wo ich stehe und wo ich hinmöchte – also letztlich meine bisherige und meine künftige (hoffentlich bessere) Arbeitsweise explizit beschrieben habe. Die dazugehörige Kanban-Praktik „Einige Dich auf Regeln“ beschreibt m. E. nichts anderes – wobei ich persönlich lieber von situativ-flexiblen Prinzipien als von in Stein gegossenen Regeln spreche⁵.

Initial beschreibt man also, was hier und jetzt tatsächlich getan wird. Macht man die Regeln des Arbeitssystems erstmalig explizit, erscheint es mir als extrem wichtig, das erste Change-Management-Prinzip kontinuierlich im Hinterkopf zu haben: „Starte mit dem, was jetzt getan wird“. Erfahrungsgemäß ist die Versuchung groß, das System zu beschreiben, das man gern hätte – und nicht das, was aktuell wirklich gelebt wird. Es gilt also beispielsweise, den Workflow zu visualisieren, den man wirklich lebt, und nicht etwa den, den man (oder die Führungskraft) sich wünscht. Weiß ich nicht, wo ich jetzt stehe oder verorte ich mich gar falsch, kann auch jede Wegbeschreibung zum Ziel nur falsch sein – muss Veränderung fast zwingend scheitern.

Was genau nun gilt es in einem ersten Schritt zu beschreiben, zu explizieren? Auch hier hilft ein sanfter und vorsichtiger Start, das emergent entstandene System nicht durch nur scheinbar bloße Beschreibung aus Versehen zu (zer)stören. Über einige wenige Punkte sollte m. E. ein in kurzen, einfachen Sätzen formulierter Konsens erzielt werden, beispielsweise über folgende Fragen:

Welche Arbeit kommt eigentlich auf das Board?
Was bedeuten die Spalten (in Microsoft Planner: „Buckets“) des Boards? Wann darf Arbeit eine Spalte (ein „Bucket“) weiterbewegt werden?
Welche Regeln für die Visualisierung werden über die Spaltenstruktur hinaus bereits genutzt?
Wie wird ausgewählt, welche Arbeit als nächstes getan werden soll? Wie wird mit Prioritäten umgegangen?
Was bedeutet eigentlich „fertig“?

Kanban-Prinzipien und -Praktiken (3) — Kanban-Prinzipien und ‑Praktiken (in Anlehnung an den „offiziellen Leitfaden“, a. a. O)

Wo nun dokumentiere ich diese Regeln bzw. Prinzipien möglichst sichtbar und vor allem auch einfach zugänglich und veränderbar? Ein physisches Board wäre hier ja geduldig; Platz für ein paar „Regel-Karten“ – womöglich sogar an thematisch geeigneter Stelle – findet sich dort immer. Softwarebasierte Boards sind in diesem Zusammenhang zumeist deutlich unflexibler, dies gilt leider auch für den Microsoft Planner. Da die Nutzung von Planner meiner Erfahrung nach tatsächlich überwiegend aus Microsoft Teams heraus erfolgt, bietet es sich an, eine zusätzliche Kanalregisterkarte direkt neben dem Planner anzulegen und mittels eines passenden und vor allem niedrigschwelligen Tools wie bspw. OneNote oder Microsoft Word – es gilt, einfach und pragmatisch zu bleiben! – die konsensfähigen Prinzipien bzw. Regeln zu dokumentieren.

Nicht noch ein Meeting!

Verbesserung muss auch stattfinden, dafür braucht es Zeit und Raum – vor allem, wenn man gemeinsam, evolutionär und experimentell verbessern möchte. Die dafür notwendige Zeit schaffen Organisationen meist in Form eines Meetings. Nun bin ich zwar bekanntermaßen kein Freund vieler Meetings⁶, ein regelmäßiges Feedback-Meeting⁷ erscheint mir aber dennoch als eine wirklich sinnvolle Investition von Zeit⁸.

Ziel eines solchen Feedback-Meetings wäre das Etablieren einer institutionalisierten Feedback-Schleife. Entscheidend dabei ist das Wort „Schleife“: Erschöpft sich das Meeting im Äußern von Feedback, ist nicht nur die Chance auf Verbesserung vertan, sondern einfach nur ein neues Mecker-Meeting – vermutlich gleich mit Fokus auf „das große Ganze“ – entstanden. Wichtiger als das Benennen von Problemen ist das Identifizieren von Verbesserungspotentialen – und auch, wenn dieser Satz auf den einen oder anderen wie euphemistische Wortklauberei wirken mag: Jammernd im Tal der Tränen zu verharren hat noch nie etwas besser gemacht; gemeinsam Ideen zu sammeln, wie man besser werden kann, kann andererseits womöglich sogar Spaß machen. Überlegt man sich für jede dieser Ideen dann noch, wie man sie experimentell validieren – also im Kleinen umsetzen und die konkrete Verbesserung, aber auch den Effekt auf das Gesamtsystem messbar machen – kann, wird die (Feedback‑)Schleife zum echten Shewhart-Zyklus⁹.

An eben diesem Zyklus orientiert sich meist auch die Agenda eines Feedback-Meetings – wobei es mir empfehlenswert erscheint, nicht mit den Problemen und Potentialen, sondern mit den bisherigen Ergebnissen (und idealerweise Erfolgen) zu starten:

Welche Verbesserungen probieren wir gerade aus („Welche Experimente laufen?“) und wie sind die Ergebnisse?
Welche „Nebenwirkungen“ auf das Gesamtsystem haben wir beobachtet/gemessen?
Wollen wir damit in die großflächige Umsetzung gehen?
Welche Probleme und (Verbesserungs‑)Potenziale sind uns aufgefallen?
Welche Ideen (Hypothesen) haben wir dazu?
Wie wollen wir das ausprobieren (Experiment) und …
… wie können wir die Verbesserung messen?
Wann sind Ergebnisse zu erwarten? Wann treffen wir uns wieder?

Der letzte Tagesordnungspunkt dieser Agenda beantwortet übrigens auch zumindest teilweise die Frage, wie oft ein Kanban-Feedback-Meeting sinnvollerweise durchzuführen ist: Meist nicht früher, als Ergebnisse aus den durch das letzte Meeting gestarteten Experimenten zu erwarten sind – oder aber, sofern sich ausreichend Potentiale gesammelt haben. Keinesfalls häufiger, wir alle haben genügend Meetings. Das gilt m. E. übrigens für alle Kanban-„Kadenzen“: Arbeitssysteme sind unterschiedlich dynamisch, daran sollte die Frequenz aller Kadenzen angepasst werden: Sofern keine Veränderung gegenüber dem letzten Mal zu erwarten ist, braucht es (noch) kein Folgemeeting.

Schauen wir an dieser Stelle noch einmal auf die Change-Management-Prinzipien: „Fördere Handlungen von Leadership auf allen Ebenen“ ist vermutlich eines der am wenigsten verstandenen Prinzipien – vor allem in Deutschland, ist doch „Leader“ ein ins Deutsche nur unter Schmerzen übersetzbarer Begriff. Im Team etablierte Feedback-Schleifen sind m. E. dennoch eine der größten Manifestationen dieses Prinzips: Was ist denn „Leadership auf allen Ebenen“, wenn nicht aufhören, (nur) zu jammern und gemeinsam Verantwortung übernehmen für die kontinuierliche Weiterentwicklung des Arbeitssystems, in dem wir alle stecken?

Kanban-Prinzipien und -Praktiken (4) — Kanban-Prinzipien und ‑Praktiken (in Anlehnung an den „offiziellen Leitfaden“, a. a. O)

Erste Ansätze

So fern es mir auch liegt, dem fragilen, emergent entstandenen System Patentlösungen quasi „überzustülpen“: Es gibt nun einmal klassische Themen und Ansätze, mit denen in den allermeisten Arbeitssystemen relativ schnell Verbesserung zu erzielen ist – und bei aller Demut gegenüber der Verschiedenheit der Systeme empfiehlt es sich m. E. auf jeden Fall, eben diese Themen einmal zu erwähnen – keinesfalls aber als „Blaupause“, sondern vielmehr als ein „Denk-Angebot“.

Blocker-Clustering und ‑Management

Gerade am Anfang eines solchen Prozesses ist das Arbeitssystem ganz häufig „verstopft“, steckt oft eine erstaunlich große Menge mindestens teilweise durch externe und interne Einflüsse blockierter Arbeit im System. Initial – später aber auch kontinuierlich bzw. regelmäßig – lohnt es sich, einen genauen Blick auf diese Blockaden zu werfen: Gibt es erkennbare Strukturen, gemeinsame Ursachen, identifizierbare (häufig leider quasi personifizierte) Engpässe? Was sich durch das an der jeweiligen Ursache orientierte Clustern der Blockaden an Erkenntnissen findet, ist in aller Regel voller Potenziale¹⁰ und hervorragender „Input“ für das nächste Feedback-Meeting – oder aber muss im Falle externer Blockaden ins Außen eskaliert werden.

Ist das System kontinuierlich geprägt von internen oder womöglich gar Team-internen Blockaden, empfiehlt es sich vielleicht gar, ein „Blocker-Management“ zu implementieren. Im Falle Team-interner Blockaden hilft hier erstaunlich häufig tatsächlich ein (mit einer harten und kurzen Timebox versehenes!) tägliches „Kanban-Meeting“ zur Abstimmung; im Falle Team- oder Organisations-externer Blockaden lohnt sich sicherlich ein Blick auf alles, was andernorts im Zusammenhang mit Scrum über „Impediments“ und den Umgang damit geschrieben wurde.

Noch mehr Meetings!

Ich erwähnte es bereits als Mittel des Blocker-Managements: Ein regelmäßiges Kanban-Meeting (oft auch: „Daily [Standup]“ oder analog zum „Daily Scrum“ auch „Daily Kanban“) kann unter Umständen einen erheblichen Beitrag dazu leisten, die Dinge im Fluss zu halten. Gerade in kleinen Teams bin ich immer etwas verwundert ob der Wirksamkeit eines solchen Meetings, hätte ich doch eigentlich erwartet, dass sich die Dinge auch ohne klären lassen sollten, aber offenkundig braucht es in vielen Systemen diesen institutionalisierten Rahmen. Erwägt man die Einführung eines solchen (meist) morgendlichen „Standups“, gilt es meiner Erfahrung nach, drei Aspekte besonders zu betrachten:

Es muss m. E. keinesfalls zwingend ein Kanban-Meeting geben. Vielleicht kann man ja auch anders erfolgreich miteinander kommunizieren, um die Dinge im Fluss zu halten oder gar erst ins Fließen zu bringen.
Das Kanban-Meeting muss keinesfalls zwingend täglich stattfinden, sondern die Frequenz sollte an die Dynamik der Situation und Organisation angepasst werden: Ist nicht zu erwarten, dass sich binnen eines Tages etwas Relevantes verändert, brauche ich auch kein tägliches Meeting, sondern vielleicht nur ein oder zwei Meetings pro Woche. Oftmals ist es anfangs wirklich sinnvoll, sich täglich zu treffen, man sollte aber m. E. nicht vergessen, die Häufigkeit des Meetings regelmäßig zu überprüfen und anzupassen – und das Meeting womöglich gar auszusetzen, falls es nicht mehr nötig ist!
Ein tägliches Meeting sollte m. E. immer in eine stringent moderierte Timebox (vgl. hier) eingepasst werden, ein hartes Zeitlimit in der Größenordnung weniger Minuten haben. Themen, die in diese Timebox nicht hineinpassen, sind meist grundsätzlicherer Natur und bedürfen womöglich gar eines dedizierten Meetings – möglicherweise mit einem veränderten Teilnehmerkreis. Themen, die eher auf der Metaebene zu verorten sind, sollten eher in das Feedback-Meeting (s. o.) verlagert werden.

Worüber sollte man nun in den wenigen Minuten eines solchen Meetings sprechen? Über alles, was dem taktisch-operativen Fortkommen der aktuell anliegenden Arbeit, dem Flus der konkreten Aufgaben, dient – insbesondere natürlich über das Beseitigen oder Überwinden von Blockaden.

Die Visualisierung verbessern

Die Visualisierung zu verbessern, ist sicherlich meist einer der ersten und ein im wahrsten Sinne des Wortes offensichtlicher Verbesserungsschritt. Die Visualisierung am Board ist allerdings kein Selbstzweck, muss nicht „hübsch“ sein, sondern sollte der Arbeit mit dem Board dienen, beispielsweise Blocker geeignet kennzeichnen oder Prioritäten visualisieren, Struktur schaffen und Sachverhalte auf den ersten Blick offenkundig machen – kurz: die kontinuierliche tägliche Arbeit am Fluss oder z. B. auch das Team-Kanban-Meeting (s. o.) erleichtern. Ganz einfache Mittel wie farbige Planner-Tags („Etiketten“) mit einer einheitlichen, gemeinsam verabredeten Semantik – in der Art von „intern blockierte Arbeit: rot, extern blockierte: pink“ – können hier Wunder wirken.

Die Anzahl der Board reduzieren

Ich erwähnte es ja eingangs: Microsoft Planner-Boards neigen dazu, wie Pilze aus dem Boden zu schießen. Es startet ein neues Projekt – es wird ein neues Board angelegt. Für wirklich klug halte ich das beim Blick durch die „Kanban-Brille“ nicht: Meist geht es ja eigentlich darum, die Arbeit zu managen – und nicht viele kleine Projekte. Aus Sicht des jeweiligen Projektverantwortlichen ist es natürlich vollkommen naheliegend, pro Projekt ein Microsoft Planner-Board anzulegen. Aus Sicht derjenigen, die die Arbeit tun müssen – und nicht zuletzt auch aus Sicht der Führungskräfte, die für diese Menschen und deren Arbeit[spensum] verantwortlich sind – ist dieses Vorgehen wenig sinnvoll: Die Arbeit eines einzelnen Menschen „versteckt“ sich auf einmal in dutzenden Boards, ein ganzheitlicher Überblick über Aus- und Belastung ist kaum möglich – und ohne Blick auf die Auslastung fehlt mir als Projektverantwortlicher jedwede Vorhersagbarkeit, als Führungskraft der Überblick über die Arbeitslast auf den Schultern der Mitarbeiter.

Mir erscheinen Team-Boards deutlich sinnvoller als Projekt-Boards. In Bezug auf die beteiligten Menschen (die ja nun einmal die Arbeit tun müssen) disjunkte (vgl. hier) Boards verbessern oder ermöglichen überhaupt erst die Übersicht am Engpass – dem Menschen. „Manage die Arbeit, lass die Menschen sich um die Arbeit herum selbst organisieren“ mag eines der Kern-Prinzipien von Kanban sein, aber unabhängig davon ist der arbeitende Mensch in seinen Fähigkeiten begrenzt und vor allem auch schützenswert – und ganz nebenbei meist der entscheidende Engpass im System. Projekt-Boards verstellen mir m. E. den Blick auf den Einzelnen – und ein Arbeitssystem zu managen heißt eben am Ende doch immer den Engpass „Mensch“ im Blick zu haben. Aus diesem Grund versuche ich (leider in meinem Übereifer häufig zu früh in der Entwicklung) emergent entstandene personell überlappende Projekt-Board-Strukturen möglichst schnell in personell disjunkte Team-Board-Strukturen umzustellen. Merke: Microsoft Planner sollte nicht nur technisch in Teams eingebettet sein ;‑)!

Kein Kanban ohne WiP-Limits?

Eingefleischte „Kanbanista“ sind sich sicher: Kein Kanban ohne WiP-Limits, keine Kanban-Software ohne eine Möglichkeit, WiP-Limits technisch zu forcieren – Microsoft Planner ist also mangels dieser Möglichkeit sowieso per se ungeeignet als Kanban-Tool. Wie gehen wir jetzt damit um, da wir aber ja nun einmal mit Planner gestartet sind und die Einfachheit und Zugänglichkeit (vorerst?) nicht missen möchten? Mir persönlich erscheint es sowieso wenig hilfreich, in einem komplett verstopften Arbeitssystem über die Limitierung von WiP zu reden (mehr dazu hier und hier). Viel sinnvoller erscheint es mir, in einem ersten Schritt wieder in den Fluss zu kommen – und sich dann erst einmal auf das vielzitierte „Stop starting, start finishing“ wirklich einzulassen, nicht mehr neue Arbeit zu beginnen, als man am anderen Ende des Systems auch wirklich abgeschlossen hat. Bis dahin ist aber zumeist sehr viel Arbeit durch das System geflossen. Ansonsten gilt natürlich: Kein Kanban ohne WiP-Limits.

Ausblick

An diesem Punkt ist das Team rund ums Planner-Board schon einen weiten Weg gemeinsam gegangen, hat Verbesserungen auf den Weg gebracht, gemeinsame spürbare Erfolge und ein gemeinsames Ziel – und hoffentlich den Drang zur dynamischen Selbstorganisation, der initial die Nutzung von Microsoft Planner prägte, behalten.

Die Frage ist, ob das Team jetzt nicht reif wäre für etwas mehr Theorie, gar ein gemeinsames Kanban-Training. Auf geht’s – so weit man in Sachen „Kanban Maturity“ denn kommen möchte und soweit es für die Organisation wirklich sinnvoll ist! Ob man dann irgendwann einmal ein neues Tool braucht, finde ich persönlich gar nicht die wichtigste Frage – der wahre Werkzeugkasten, das wirkliche „Tool“, sind die getroffenen Vereinbarungen, die gemeinsam genutzten Methoden und vor allem anderen der gemeinsame Wille zur kontinuierlichen Verbesserung!

Fußnoten:

↑ Der offizielle Leitfaden zur Kanban Methode v.1. (2023). Kanban University. https://kanban.university/wp-content/uploads/2023/11/The-Official-Kanban-Guide_German.pdf. Archiviert am 31.03.2025 unter <https://web.archive.org/web/20250331105424/https://kanban.university/wp-content/uploads/2023/11/The-Official-Kanban-Guide_German.pdf>. Alle weiteren Zitate zur Kanban-Methode stammen – sofern nicht anders gekennzeichnet – aus dieser Quelle.
↑ Vgl. bspw. <https://djaa.com/kanban-maturity-model/> (01.11.2025) archiviert am 13.08.2025 unter <https://web.archive.org/web/20250813004743/https://djaa.com/kanban-maturity-model/>.
↑ Vgl. bspw. <https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/> (01.11.2025) archiviert am 23.11.2024 unter <https://web.archive.org/web/20241123235155/https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/>.
↑ Und auch STATIK (s. o.) würde vermutlich ob des zugrundeliegenden Mangels an als relevant wahrgenommenen „sources of dissatisfaction“ scheitern.
↑ Zum Unterschied zwischen Regeln und Prinzipien vgl. bspw. <https://www.hinz-wirkt.de/lotsenblog/artikel/3444-prinzipien-statt-regeln/> (13.11.2025), archiviert am 13.05.2025 unter <https://web.archive.org/web/20250513184734/https://www.hinz-wirkt.de/lotsenblog/artikel/3444-prinzipien-statt-regeln/>.
↑ Vgl. bspw. „Nicht noch ein Meeting!“ und „Mehr zum Meeting-Teufelskreis“ hier im Blog.
↑ Um ausdrücklich nicht den Namen einer der etablierten Kanban-Kadenzen zu verwenden, insbesondere nicht von einer „Kanban-Retrospektive“ zu sprechen.
↑ Im Sinn von „return on time invested“.
↑ Auch „Deming-Zyklus“ oder „-Kreis“, „PDCA (plan-do-check-act)“, „OPDCA (observe-plan-do-check-act)“.
↑ Vgl. <https://www.infoq.com/articles/blockers-defects-process-improvement/> (20.03.2026).

Microsoft Planner – Selbstorganisation fördern und weiterentwickeln