Wie Agile die Arbeitswelt verändert hat, ein Rückblick.

Agile ist nicht tot – es ist das neue Normal!

Die ständigen „Agile ist tot“-Posts sind meist Ausdruck von Frustration. Viele Unternehmen haben sich schwergetan, Agile wirklich zu meistern, und scheitern oft nicht an der Methode, sondern an ihrem eigenen Mindset, ihrer Organisationsstruktur und Führungskultur. Doch wenn wir die letzten 20 Jahre betrachten, zeigt sich deutlich: Agile hat die Art, wie wir arbeiten, grundlegend verändert – und das bleibt.

Wie Agile die Arbeitswelt verändert hat

1. Kontinuierliche Verbesserung als Standard

Früher: Reflexionen gab es kaum, ausser in Form von Post-Mortems am Ende eines gescheiterten Projekts. Fehler wurden dokumentiert, aber es änderte sich wenig.
Heute: Retrospektiven und regelmässige Lernschleifen sind der Standard – in Teams, Abteilungen und sogar auf Unternehmensebene. Es ist normal geworden, alle 1–2 Wochen zu hinterfragen: Was können wir besser machen?

2. Echte Kundenzentrierung statt Annahmen

Früher: Produkte wurden über Jahre entwickelt, basierend auf Annahmen und Business Cases – ohne echten Kundenkontakt.
Heute: Customer Feedback ist integraler Bestandteil der Produktentwicklung. Ob über MVPs, regelmässige Nutzerinterviews oder datengetriebenes Lernen – der Kunde ist heute mitten im Prozess.

3. Planung ist kollaborativ, nicht Top-Down

Früher: Der Chef oder das PMO legten fest, was zu tun ist – Teams mussten es umsetzen.
Heute: Agile Teams planen selbst mit. Scrum Plannings, PI-Plannings oder Flight Level Initiativen zeigen: Planung ist ein gemeinschaftlicher Prozess – die Menschen, die die Arbeit machen, sind beteiligt.

4. Messen von Leistung ist transparenter und sinnvoller

Früher: Erfolg wurde an Zeitplänen und Budgets gemessen – egal, ob das Produkt am Ende einen Mehrwert hatte oder nicht.
Heute: OKRs, Flow Metrics, Outcomes statt Outputs – Erfolg wird daran gemessen, ob wir einen echten Unterschied für Kunden und Unternehmen machen.

5. Führung ist ein Enabler, nicht ein Kontrolleur

Früher: Manager haben Arbeit delegiert und kontrolliert.
Heute: In agilen Organisationen coachen, fördern und entfernen Führungskräfte Hindernisse, statt nur zu steuern. Servant Leadership ist das neue Ideal.

6. Transparenz über den Arbeitsprozess

Früher: Niemand wusste genau, woran andere Teams arbeiteten – Silos waren normal.
Heute: Dank Kanban-Boards, Sprint Reviews, Big Room Plannings und Flight Levels ist Transparenz die Norm.

7. Time-to-Market ist dramatisch gesunken

Früher: Grosse Releases alle paar Jahre waren normal.
Heute: Continuous Delivery, DevOps und inkrementelle Releases ermöglichen es, Produkte innerhalb von Tagen oder Wochen auf den Markt zu bringen.

8. Fehlerkultur ist akzeptierter

Früher: Fehler waren etwas, das vertuscht wurde – oder schlimmer, bestraft.
Heute: Fail fast, learn fast ist Standard. Unternehmen wie Google, Amazon oder Spotify haben gezeigt: Wer schneller lernt, gewinnt den Markt.

9. Die ganze Organisation wird agiler – nicht nur IT

Früher: Agile war eine Nischenmethode für Software-Entwicklung.
Heute: HR, Marketing, Sales, Controlling – alle nutzen agile Prinzipien in irgendeiner Form. Business Agility ist der neue Wettbewerbsfaktor.

10. Agile ist überall integriert – auch in klassisches PM

Früher: Es gab eine harte Trennung zwischen klassischem PM und Agilität.
Heute: Hybride Ansätze wie SAFe, Disciplined Agile oder Flight Levels zeigen, dass agile Prinzipien überall eingebaut werden.

Die wahre Herausforderung: Kultur, Zusammenarbeit und Machtverteilung

Agile Methoden haben nicht nur Prozesse und Strukturen verändert, sondern auch die Art, wie Menschen miteinander arbeiten. Doch diese Entwicklung ist nicht völlig neu – wir haben bereits Vorreiter, die zeigen, was möglich ist:

Haier mit seinem dezentralen Unternehmensmodell, das klassische Hierarchien aufgelöst hat.
Spotify mit seinem Squad-Framework, das Teamautonomie in den Mittelpunkt stellt.
Buurtzorg in der Pflegebranche, das auf selbstorganisierte Teams setzt.
Handelsbanken, die zentrale Steuerung auf ein Minimum reduziert haben.

Doch genau hier scheitern viele Unternehmen. Sie haben zwar Scrum eingeführt, aber ihre Machtstrukturen, ihre Kommunikationsmuster und ihre Kultur sind unverändert geblieben. Sie arbeiten agil in einer nicht-agilen Organisation.

Warum?
Weil man nicht erkannt hat, dass echte Agilität nicht nur Prozesse betrifft, sondern auch das soziale System. Weil man nicht gedacht hat, dass eine Investition in Menschen und Zusammenarbeit sich auszahlen könnte. Weil es unbequem ist, bestehende Machtverhältnisse zu hinterfragen.

Doch die Zeit des Zögerns ist vorbei. Wir stehen mitten in einem disruptiven Wandel. Kanadas Premierminister Justin Trudeau formulierte es treffend:

„Die Welt verändert sich in einem Tempo, das sie nie wieder so langsam wie heute sein wird.“

Mit KI, Robotik und Automatisierung stehen wir an der Schwelle zu einer neuen Ära. Unternehmen, die ihr Schiff nicht schon seetüchtig gemacht haben, werden im kommenden Sturm erkennen, ob ihr alter Tanker noch schwimmt – oder ob sie in den Wellen untergehen.

Jetzt ist es Zeit für den nächsten Schritt:

Neue Formen der Zusammenarbeit jenseits der agilen Methoden.
Neue Kommunikationsstrukturen, die Transparenz und Offenheit fördern.
Eine bewusste Entwicklung der Organisationskultur hin zu mehr Vertrauen, Eigenverantwortung und Innovation.
Eine Neudefinition von Leadership, bei der Führungskräfte zu Begleitern und Ermöglichern des Wandels werden.

Fazit: Agile ist nicht tot – aber es braucht den nächsten Evolutionsschritt

Agilität hat sich durchgesetzt, aber sie allein reicht nicht mehr aus. Die nächste Welle der Transformation betrifft Menschen, Kultur und Machtverteilung.

Schafft Räume für echte Kollaboration – nicht nur für Prozesse.
Entwickelt eure Führungskräfte zu Ermöglichern, nicht zu Kontrolleuren.
Hinterfragt bewusst die Machtstrukturen in eurer Organisation.
Behandelt Kultur nicht als Nebensache, sondern als entscheidenden Erfolgsfaktor.

Agile hat die Art verändert, wie wir arbeiten. Jetzt ist es an der Zeit, die Art, wie wir zusammenarbeiten, weiterzuentwickeln. Wer diese Chance nutzt, wird die Zukunft mitgestalten. Wer sie ignoriert, bleibt in der Vergangenheit stecken.

Navigieren im Sturm: Wie ein Scrum Master ein unglückliches Team zu neuem Kurs führt

(gilt natürlich auch für Führungskräfte!)

Der Sturm, den wir alle kennen (Awareness)

Habt ihr euch je gefühlt, als würdet ihr ein sinkendes Schiff steuern? Ich schon. Als Scrum Master hatte ich kürzlich ein Team, das unglücklich war – wirklich unglücklich. Sprint Reviews endeten in Schweigen, Retrospektiven wurden zu Beschwerdeorgien, und die Stimmung war so grau wie ein Novembertag. Es war, als wären wir eine Crew auf hoher See, gefangen in einem endlosen Sturm. Der Wind peitschte uns ins Gesicht, die Wellen schlugen über Deck, und jeder dachte: „Warum passiert das ausgerechnet uns?“
Ich konnte ihnen nicht einfach sagen: „Seid glücklich, das ist eure Wahl.“ Das hätte sie nur noch mehr genervt. Aber ich wollte sie dazu bringen, die Welt anders zu sehen – nicht als Opfer des Sturms, sondern als Navigatoren ihrer Reise. Also erzählte ich ihnen eine Geschichte. Und genau diese Geschichte teile ich heute mit euch – vielleicht hilft sie auch eurem Team, den Kurs zu ändern.

Teil 1: Ein Blick durch den Nebel (Interest)

Stellt euch ein altes Segelschiff vor, mitten im Chaos. Die Crew ist erschöpft – nasse Kleider, knurrende Mägen, und der Kompass dreht sich wie verrückt. Sie schimpfen: „Dieser Sturm wird uns umbringen!“ oder „Wer hat uns überhaupt hierher gebracht?“ Klingt vertraut, oder? In meinen Sprints hörte ich ähnliches: „Die Anforderungen sind unklar!“, „Die Stakeholder ändern ständig alles!“
Dann passiert etwas. Der Kapitän – nennen wir ihn Max – steht auf. Er sagt kein Wort, sondern greift zum Fernrohr und schaut zum Horizont. Die Crew verdreht die Augen: „Was soll das jetzt?“ Aber eine Matrosin, Lisa, wird neugierig. „Was siehst du, Max?“ fragt sie. Er antwortet ruhig: „Ich sehe, dass der Sturm nicht das Meer ist. Er ist nur ein Teil davon.“
Lisa nimmt das Fernrohr selbst – und da, durch den Nebel, erkennt sie einen schwachen Landstrich. Nicht nah, aber erreichbar. Plötzlich reden sie nicht mehr über den Sturm, sondern darüber, was jenseits davon liegt.

Als Scrum Master bin ich oft wie Max. Ich kann den Sturm – unklare Product Goals, technische Schulden, Konflikte – nicht stoppen. Aber ich kann das Fernrohr reichen. In einer Retro fragte ich: „Wann lief es bei uns mal richtig gut?“ Eine Antwort kam zögernd: „Beim letzten Release, als wir zusammengetan haben.“ Ein kleiner Funke. Interesse war geweckt.

Teil 2: Der Moment der Wahrheit (Desire)

Zurück zur Crew. Sie stehen vor einer Wahl. Weiter fluchen, die nassen Füße beklagen und auf besseres Wetter warten? Oder etwas ändern? Lisa sagt: „Wenn wir die Segel anders setzen, könnten wir das Land erreichen.“ Ein anderer, Tom, fügt hinzu: „Und wenn wir zusammen rudern, sind wir schneller.“ Ein Dritter lacht: „Dann könnten wir sogar trockene Socken finden!“
Auf einmal reden sie nicht mehr über das Problem, sondern über die Lösung. Sie merken: Der Sturm ist da, ja. Aber er entscheidet nicht, wohin sie fahren. Sie entscheiden das.

In meinem Team war es ähnlich. Nach der Retro fragte ich: „Was könnten wir tun, um wieder so einen Moment wie beim letzten Release zu haben?“ Jemand sagte: „Weniger Multitasking, mehr Fokus.“ Ein anderer: „Klarere Prioritäten vom Product Owner.“ Die Ideen sprudelten – nicht, weil ich sie anwies, sondern weil sie Lust bekamen, den Kurs zu ändern. Sie wollten nicht mehr nur überleben, sondern ankommen. Als Scrum Master musste ich nur den Raum halten – das Verlangen wuchs von selbst.

Teil 3: Land in Sicht (Action)

Die Crew im Sturm macht sich ans Werk. Sie setzen die Segel neu, rudern im Takt, und ja, sie fluchen noch über den Wind – aber mit einem Grinsen. Am Ende erreichen sie das Land. Nicht, weil der Sturm aufhörte (das tat er nicht), sondern weil sie ihn nicht mehr die Richtung bestimmen ließen. Als sie anlegen, sind sie nass, müde, aber sie lachen. Nicht, weil alles perfekt war, sondern weil sie es zusammen geschafft hatten.
Ich fragte meine Crew damals: „Was hätte unsere Mannschaft anders machen können?“ Die Antwort kam schnell: „Zusammenarbeiten, statt nur zu meckern.“ Und dann: „Vielleicht sollten wir das auch mal probieren.“

Das war der Startschuss. Im nächsten Sprint priorisierten wir eine Aufgabe, die wir gemeinsam rocken konnten – ein kleines „Land“ am Horizont. Wir definierten klare Rollen (wer rudert, wer segelt?), und ich hielt mich zurück, ließ sie navigieren. Das Ergebnis? Der Sprint endete nicht perfekt, aber mit einem Gefühl: „Wir können das steuern.“

Reflexion: Was Scrum Masters und Führungskräfte lernen können

Diese Geschichte hat mir gezeigt: Unglückliche Teams brauchen kein Glücksrezept, sondern eine neue Perspektive. Als Scrum Master kannst du kein Wetterguru sein, aber ein Navigator. Du musst sie nicht belehren – erzähl ihnen eine Geschichte, die sie abholt. Zeig ihnen den Horizont, ohne ihn zu erzwingen.

Aufmerksamkeit: Spiegle ihre Realität (den Sturm), damit sie sich verstanden fühlen.
Interesse: Biete eine Wendung (das Fernrohr), die sie neugierig macht.
Verlangen: Lass sie selbst entdecken, dass sie den Kurs ändern können.
Aktion: Gib ihnen den Raum, die Segel zu setzen – sie werden es tun, wenn sie wollen.

Dein nächster Schritt

Fühlst du dich auch wie ein Kapitän im Sturm? Dann schnapp dir dein Fernrohr. Erzähl deinem Team eine Geschichte – vielleicht diese, vielleicht eine eigene. Frag sie: „Was sehen wir am Horizont?“ Und dann lass sie rudern. Teilt eure Erfahrungen in den Kommentaren – ich bin gespannt, wohin eure Reise führt!

Theorie-Teil_

AIDA:

Awareness: Einleitung mit der Sturm-Metapher.
Interest: Die Wendung mit dem Fernrohr.
Desire: Die Crew findet Motivation.
Action: Der Schluss mit konkreter Umsetzung und Aufruf.

Scrum-Elemente: Retro, Sprint, Product Owner – für Authentizität aus der Scrum-Master-Sicht.

Mein Blogbeitrag basierend auf der Anekdote von Mario Andretti und der Parallele zu moderner Führung und Agilität:

Führung auf Höchstgeschwindigkeit: Warum Kontrolle abgeben der Schlüssel zum Erfolg ist

„Mr. Andretti, wie schaffen Sie es, bei dieser Geschwindigkeit die Kontrolle über Ihr Auto zu behalten?“

Der Formel-1-Weltmeister Mario Andretti soll auf diese Frage eines Journalisten geantwortet haben:

„Ganz einfach – ich habe nie die Kontrolle über mein Auto. Denn wenn du so fährst, dass du die Kontrolle hast, bist du zu langsam.“

Diese Aussage ist ein Gamechanger – nicht nur für den Rennsport, sondern auch für Führungskräfte, die in der heutigen Wirtschaftswelt bestehen wollen. Denn wenn du in einem komplexen Marktumfeld versuchst, jeden Aspekt zu kontrollieren, dann bist du schlicht zu langsam.

Warum Kontrolle in der Führung oft ein Bremsklotz ist

Viele Unternehmen stehen vor der Herausforderung, schneller am Markt zu sein, bessere Geschäftszahlen zu liefern und mit hoher Geschwindigkeit zu innovieren. Führungskräfte, die versuchen, jede Entscheidung selbst zu treffen, jedes Team zu steuern und jede Aktivität zu überwachen, haben ein Problem:

Sie werden zum Flaschenhals.
Teams warten auf Anweisungen statt selbst zu handeln.
Die Organisation wird träge und verliert ihre Reaktionsfähigkeit.

Das ist so, als würdest du in einem Rennen ständig auf die Bremse treten, weil du Angst hast, die Kontrolle zu verlieren. Doch genau das macht dich langsam – und am Ende wirst du überholt.

Die neue Rolle von Führung: Richtung vorgeben, aber Kontrolle abgeben

Moderne Führung funktioniert anders. Erfolgreiche Führungskräfte agieren nicht wie Fahrlehrer, die jedem Teammitglied sagen, wann es schalten und bremsen soll. Sie agieren wie ein Rennfahrer, der dafür sorgt, dass das Team die richtige Richtung kennt und mit hoher Geschwindigkeit arbeiten kann – ohne ständig um Erlaubnis zu fragen.

Das bedeutet:

Rahmenbedingungen setzen, nicht Mikromanagement betreiben.
Autonome Teams fördern, statt jeden Schritt zu überwachen.
Klare Prinzipien und Werte etablieren, statt jede Entscheidung selbst zu treffen.

Denn Kontrolle abzugeben bedeutet nicht, Chaos zuzulassen. Es bedeutet, auf Vertrauen und Klarheit zu setzen.

Warum Agilität der einzige Weg zur Höchstgeschwindigkeit ist

Wenn Unternehmen schneller und erfolgreicher sein wollen, führen an agilen Methoden und Skalierungsmodellen kein Weg vorbei. Dabei geht es nicht nur um Scrum oder Kanban – es geht um eine neue Art der Unternehmenssteuerung.

Flight Levels, das Kanban Maturity Model und andere agile Skalierungsmodelle bieten Führungskräften genau das: Eine Möglichkeit, Teams autonom arbeiten zu lassen, ohne die Kontrolle über das große Ganze zu verlieren.

Ein Beispiel:

Unternehmen, die erfolgreich skalieren, nutzen Wertströme und Koordination, statt sich in hierarchischen Prozessen zu verlieren.
Sie arbeiten mit klaren Metriken und Feedbackschleifen, statt mit Top-down-Kommandos.
Sie setzen auf Sichtbarkeit statt Kontrolle – denn Transparenz ermöglicht schnellere Entscheidungen, ohne Mikromanagement.

Und SAFe? Nein, das gehört nicht dazu. Denn agile Führung bedeutet nicht, starre Strukturen mit neuen Namen zu versehen, sondern echte, flexible Netzwerke zu schaffen, in denen Menschen schnell und eigenverantwortlich handeln können.

Fazit: Wer immer die Kontrolle behalten will, ist zu langsam

Mario Andretti wusste, dass volle Kontrolle eine Illusion ist – und dass es der Schlüssel zum Erfolg ist, genau an der Kante zu fahren, wo man sich nicht mehr vollkommen sicher fühlt. Dort entsteht Geschwindigkeit. Dort passiert Innovation. Dort wird gewonnen.

Führungskräfte, die heute erfolgreich sein wollen, müssen genau das lernen: Nicht jeden Schritt ihrer Teams überwachen, sondern die Richtung vorgeben und den Teams zutrauen, die Geschwindigkeit selbst zu bestimmen.

Denn wenn du nur so führst, dass du die Kontrolle hast – dann bist du zu langsam. Und dann überholen dich andere.

Bist du bereit, das Gaspedal loszulassen und deine Teams auf Höchstgeschwindigkeit zu bringen?

Im Wald des Wandels: Warum Agile Coaches oft den Blick für das Ganze verlieren

Es gibt diesen Moment, wenn man als Agile Coach in ein Unternehmen kommt – voller Energie, mit einer klaren Absicht und einer Vision davon, was man tun moechte. Man hat die Methoden im Gepaeck, die Frameworks im Kopf und die Mission vor Augen. Und genau hier beginnt die Herausforderung.

Stell dir vor, du gehst in den Wald. Du hast ein Buch dabei. Deine Absicht ist klar: Du willst lesen, konzentriert, ungestört, fokussiert. Kein Telefon, kein Lärm, keine Ablenkung. Nur du und dein Buch. Auf dem Weg dorthin nimmst du noch alles wahr. Die Vögel, die Sonnenstrahlen, das Rauschen der Blätter, das Knirschen des Untergrunds unter deinen Schuhen. All das gehört zu deiner Umgebung. Es ist ein Teil des Waldes, in dem du dich bewegst.

Dann setzt du dich auf eine Bank, schlägst dein Buch auf – und die Welt um dich herum verschwindet. Dein Blick ist fixiert auf die Seiten, deine Gedanken tauchen tief ein, deine Augen sehen nur noch den Text. Du nimmst nichts mehr wahr ausser dem, was in deinem Fokus liegt. Und genau das passiert auch, wenn man als Agile Coach in eine Organisation kommt.

Wenn wir als Coaches oder Berater irgendwo hinkommen, haben wir oft schon ein „Buch“ dabei. Unsere Werkzeuge, Methoden, Hypothesen, vielleicht sogar eine vorgefasste Idee davon, was das Unternehmen braucht. Wir setzen uns metaphorisch auf unsere „Bank“ und beginnen zu arbeiten – mit vollem Fokus. Doch während wir uns auf ein Framework, eine Skalierungsstrategie oder ein Teamproblem konzentrieren, passiert um uns herum noch so viel mehr. Die Kultur, die Zwischentoene in Meetings, die Koerpersprache der Fuehrungskraefte, das unausgesprochene „Warum machen wir das eigentlich?“ – all das rauscht wie der Wind in den Blaettern an uns vorbei. Und das Problem? Wir merken es nicht einmal.

Das wir es nicht wahrnehmen heisst nicht das es nicht da ist!

Organisationen sind lebende Systeme. Sie bestehen nicht nur aus Workflows, Tools und Prozessen, sondern aus Menschen, Dynamiken und ungeschriebenen Regeln. Wenn wir nur auf unser „Buch“ – unser Framework oder unseren Auftrag – schauen, übersehen wir das Entscheidende: das eigentliche System, in dem Veränderung stattfindet. Wir sehen nicht, wer gerade zurückhaltend ist, weil er schon fuenf andere Transformationen erlebt hat und sie alle gescheitert sind. Wir hören nicht, dass sich hinter einem technischen Problem oft ein kulturelles Spannungsfeld verbirgt. Wir bemerken nicht, dass eine Methode vielleicht formal perfekt eingeführt wurde – aber niemand sie lebt.

Was können wir also tun? Schlag das Buch mal zu! Nimm dir bewusst Momente, in denen du nicht an Lösungen arbeitest, sondern einfach beobachtest. Höre zu. Sieh hin. Fühle das System, bevor du es verändern willst. Frage nach dem Unausgesprochenen. Warum machen wir das? Welche Ängste, Hoffnungen oder Zweifel gibt es? Wer ist wirklich bereit fuer Veränderung? Erkenne den Kontext. Eine Methode ist nur so gut wie das System, in dem sie eingebettet ist.

Wenn die Kultur nicht bereit ist, wird keine Methode das retten.

Ein Agile Coach zu sein, heisst nicht nur, ein gutes Buch zu haben und es konzentriert zu lesen. Es heisst, den Wald wahrzunehmen, bevor man sich setzt und eintaucht. Denn Veränderung passiert nicht im Buch – sie passiert zwischen den Seiten, in den Zwischentönen, in dem, was wir hören, sehen und fühlen, wenn wir wirklich offen sind. Also: Schlag dein Buch mal zu. Höre dem Wald zu. Denn da passiert die eigentliche Magie.

Der agile Konsistenzkiller: Warum falsche Autonomie-Illusion Teams zerstören kann

Einleitung: Autonomie als Heilsbringer?

Agilität wird oft mit Selbstorganisation und Autonomie gleichgesetzt. Teams sollen eigenständig entscheiden, sich selbst steuern und Verantwortung übernehmen. Doch genau hier liegt eine der Missverständnisse .

Bindung – Soziale Eingebundenheit gibt uns Sicherheit.
Selbstwerterhöhung und -schutz – Wir brauchen das Gefühl, wertvoll und kompetent zu sein.

Ein Ungleichgewicht dieser Bedürfnisse erzeugt Inkonsistenz – also Stress, Unsicherheit und Widerstand. Genau das passiert, wenn Agilität ohne psychologische Sicherheit eingeführt wird.

➡ Wenn Teams plötzlich „autonom“ arbeiten sollen, aber keine Orientierung haben, fühlen sie sich verloren.

Die Illusion der Autonomie in agilen Transformationen

Viele Unternehmen führen Agilität mit dem Versprechen ein: „Jetzt könnt ihr endlich selbst entscheiden!“ Doch was passiert oft in der Realität?

Beispiel 1: Führungskräfte ziehen sich zu früh zurück

Plötzlich sollen Teams eigenständig Ziele setzen, Roadmaps planen und sich selbst organisieren – ohne klare Leitplanken oder Unterstützung.
Führungskräfte missverstehen ihre neue Rolle als „Hands-off-Management“ – das führt zu Unsicherheit.
Teams fühlen sich allein gelassen und beginnen, entweder chaotisch oder gar nicht zu agieren.

Beispiel 2: Kein Gleichgewicht zwischen Kontrolle und Autonomie

In traditionellen Organisationen hatten Mitarbeitende oft klare Prozesse und Strukturen.
In agilen Teams verschwinden diese plötzlich, ohne durch neue Sicherheitsmechanismen ersetzt zu werden.
Ergebnis: Statt sich empowered zu fühlen, erleben Teams Verwirrung und Überforderung.

➡ Das Problem ist nicht die Autonomie an sich – sondern das Fehlen von Orientierung und psychologischer Sicherheit.

Autonomie braucht psychologische Sicherheit – sonst scheitert sie

Psychologische Sicherheit bedeutet, dass Menschen sich frei äussern, Fehler machen und Fragen stellen können, ohne Angst vor negativen Konsequenzen. Amy Edmondson, die führende Forscherin auf diesem Gebiet, fand heraus:

Teams mit hoher psychologischer Sicherheit sind kreativer, effizienter und produktiver.
Ohne psychologische Sicherheit wird Autonomie als Unsicherheit statt als Befähigung empfunden.
Eine Balance zwischen Orientierung & Eigenverantwortung ist entscheidend für den Erfolg.

Erfolgsmodell: Autonomie mit Leitplanken

Klare Ziele statt unklare Freiheit: Teams brauchen ein gemeinsames Ziel und eine Vision, um sich zu orientieren.
Stabilität durch Routinen: Regelmässige Feedbackschleifen, Check-ins und Retrospektiven schaffen Verlässlichkeit.
Gemeinsam getragene Verantwortung: Entscheidungen sollten nicht einfach ins Team „geworfen“ werden, sondern bewusst im Team entwickelt werden.

➡ Autonomie funktioniert nur, wenn sie durch psychologische Sicherheit stabilisiert wird.

Handlungsempfehlungen: So balancierst du Autonomie und Konsistenz

Setze klare Rahmenbedingungen für Selbstorganisation

Stelle sicher, dass Teams wissen, was sie entscheiden dürfen – und was nicht.
Einführung eines Decision-Making-Frameworks (z. B. Delegation Poker nach Jurgen Appelo).

Fördere psychologische Sicherheit aktiv

Schaffe ein Umfeld, in dem Fragen & Fehler normal sind (z. B. durch regelmässige „Learning Reviews“).
Führungskräfte sollten nicht auf Distanz gehen, sondern als Coach & Moderator agieren.

Gebe Orientierung, bevor du Autonomie einforderst

Kanban Maturity Model nutzen, um den Reifegrad eines Teams zu bestimmen – und erst dann den Autonomiegrad anpassen.
Flight Levels Ansatz anwenden, um sicherzustellen, dass Teams nicht isoliert „autonom“ agieren, sondern eingebettet sind.

Schaffe Stabilität durch regelmässiges Feedback

Führung sollte nicht als Kontrolle verstanden werden, sondern als sichere Struktur, die Teams Halt gibt.
Regelmässige Retrospektiven helfen, die Balance zwischen Freiheit und Orientierung nachzujustieren.

Mehr Freiheit braucht mehr Führung – nicht weniger

Die Idee, dass Autonomie automatisch zu besseren Ergebnissen führt, ist ein Trugschluss. Ohne psychologische Sicherheit wird Agilität zu Stress, nicht zu Empowerment.

Dein nächster Schritt:

Reflektiere dein Team: Fühlen sich die Mitglieder autonom oder allein gelassen?
Baue bewusst Leitplanken für Selbstorganisation auf.
Nutze psychologische Sicherheit als Basis für echte Autonomie.

👉 Wie siehst du das? Welche Erfahrungen hast du mit falsch verstandener Autonomie gemacht? Lass es mich wissen! 😊

Mehr als Training: Uns geht’s um Ergebnisse

Falls du dich dafür interessierst, wo unsere Blogschreiber ihr Wissen und ihre Erfahrung an dich weitergeben:

Bleib flexibel bei Veränderungen, befähige deine Teams und liefere Qualität.
Mit erstklassigen Kursen, Coaching und maßgeschneiderten Lösungen
von führenden Experten in agilen Methoden.

Kanban Trainings findest du auch hier: https://www.agile-academy.com/de/kanban/#trainings-table

Wie messen wir Fortschritt mit KMM? Metriken und KPIs entlang der Reifestufen

Einleitung

Agilität bedeutet kontinuierliche Verbesserung – aber wie messen wir eigentlich, ob eine Organisation auf ihrem Weg der Reife vorankommt? Das Kanban Maturity Model (KMM) bietet eine systematische Möglichkeit, die Entwicklung einer Organisation entlang verschiedener Stufen zu verfolgen. Um diesen Fortschritt sichtbar zu machen, sind Metriken und Key Performance Indicators (KPIs) unerlässlich.

In diesem Artikel gehen wir darauf ein, wie sich Fortschritt im Rahmen des KMM messen lässt und welche KPIs je Reifestufe besonders aussagekräftig sind. Außerdem beleuchten wir, warum quantitative und qualitative Messungen kombiniert werden sollten, um eine fundierte Bewertung der Agilitätsentwicklung vorzunehmen.

1. Warum Messen? Die Bedeutung von Metriken im KMM

Messen bedeutet nicht nur, Zahlen zu sammeln, sondern den Fokus auf das zu lenken, was wirklich wichtig ist. Metriken helfen dabei:

Den aktuellen Reifegrad eines Teams oder einer Organisation im KMM einzuordnen.
Engpässe, Risiken und Potenziale sichtbar zu machen.
Verbesserungen objektiv zu bewerten und gezielt nachzusteuern.
Führungskräften datenbasierte Entscheidungen zu ermöglichen.

Dabei gibt es zwei zentrale Dimensionen:

Flow-basierte Metriken – Diese messen, wie effizient Arbeit durch das System fließt.
Reifegradindikatoren – Diese zeigen, inwiefern eine Organisation über die Zeit hinweg ihre agilen Praktiken und Strukturen verbessert.

2. Metriken und KPIs entlang der KMM-Stufen

Das KMM unterteilt die agile Reifung einer Organisation in sechs Stufen. Jede Stufe hat spezifische Herausforderungen und Potenziale – und dementsprechend auch spezifische Messgrößen.

Level 0: Oblivious (Kein bewusstes Prozessmanagement)

In dieser Stufe gibt es kaum explizite Prozesse. Alles geschieht ad-hoc, Arbeit wird unsichtbar ausgeführt, und es existieren keine definierten Metriken.

Metriken:

Anzahl paralleler Arbeiten ohne klares Management
Durchschnittliche Durchlaufzeit (oft sehr hoch und unvorhersehbar)
Work in Progress (WIP) unlimitiert

👉 Erstes Ziel: Arbeit sichtbar machen! Einführung eines Kanban-Boards und einfacher Flow-Messungen.

Level 1: Team Focused (Grundlagen von Kanban eingeführt)

Hier beginnen Teams mit der Visualisierung ihrer Arbeit und ersten einfachen Steuerungsmechanismen wie WIP-Limits.

Metriken:

Zykluszeit (Cycle Time) messen
WIP-Limits setzen und überwachen
Anteil unvorhersehbarer Arbeiten (z. B. Ad-hoc-Aufgaben vs. geplante Arbeit)

👉 Ziel: Stabile Prozesse auf Teamebene etablieren und erste Effizienzsteigerungen messen.

Level 2: Customer Driven (Service-Orientierung etabliert)

Das Team beginnt, sich an Kundenbedürfnissen zu orientieren. Serviceklassen werden eingeführt, und es gibt klare Erwartungen an Durchlaufzeiten.

Metriken:

Lead Time Variabilität: Wie stark schwanken die Durchlaufzeiten?
Service-Level-Zuverlässigkeit: Wird Arbeit innerhalb der zugesagten Fristen erledigt?
Kundenzufriedenheit (z. B. Net Promoter Score, qualitative Umfragen)

👉 Ziel: Vorhersagbarkeit verbessern und den Fokus auf kundenorientierte Ergebnisse lenken.

Level 3: Fit for Purpose (Strategische Optimierung der Workflows)

In dieser Stufe beginnt die Organisation, datenbasiert zu arbeiten und Entscheidungen systematisch zu verbessern.

Metriken:

Flow Efficiency: Wie viel Zeit verbringt Arbeit tatsächlich in Bewegung vs. in Wartezeiten?
Abhängigkeiten zwischen Teams sichtbar machen
Engpassanalysen durchführen (z. B. Bottleneck Detection)

👉 Ziel: Verschwendung minimieren und Service-Delivery verbessern.

Level 4: Risk-Hedged (Fokus auf Risikomanagement & Skalierung)

Auf diesem Level sind Organisationen in der Lage, Risiken aktiv zu managen und Prozesse zu skalieren.

Metriken:

Vorhersagegenauigkeit von Work Items (Probabilistische Forecasts)
Variabilität der Zykluszeiten reduzieren
Verfügbarkeit und Resilienz messen (z. B. Incident Response Time in IT-Teams)

👉 Ziel: Organisation stabil skalieren und Unsicherheiten minimieren.

Level 5 & 6: Market Leader & Built for Survival

Hier sind Organisationen nicht nur hochgradig agil, sondern auch marktführend in ihrer Branche. Sie passen sich flexibel an Veränderungen an und innovieren systematisch.

Metriken:

Marktreaktionszeit: Wie schnell kann die Organisation auf neue Anforderungen reagieren?
Innovation Rate: Anteil neuer Produkt-/Service-Features pro Quartal
Mitarbeiter-Engagement-Score (Zeigt an, wie stark Teams sich mit der Unternehmenskultur identifizieren)

👉 Ziel: Innovation fördern und nachhaltige Marktführerschaft sichern.

3. Kombination aus quantitativen und qualitativen Metriken

Messungen sind nur dann wertvoll, wenn sie mit qualitativen Erkenntnissen ergänzt werden. Zahlen alleine sagen nicht alles – daher sollten Organisationen folgende Fragen reflektieren:

Wie fühlt sich das Team mit den Veränderungen?
Welche Hindernisse sehen Teammitglieder selbst?
Werden Prozesse tatsächlich gelebt oder nur formal dokumentiert?

Durch regelmäßige Retrospektiven und gezielte Umfragen lassen sich diese qualitativen Aspekte erheben und mit den numerischen KPIs kombinieren.

Fazit: Messen als strategisches Werkzeug

Fortschritt zu messen bedeutet mehr als nur Zahlen zu sammeln – es bedeutet, die richtigen Fragen zu stellen und kontinuierlich zu lernen. Das Kanban Maturity Model bietet eine wertvolle Orientierung, doch erst mit den passenden Metriken können Teams und Organisationen bewerten, wo sie stehen und was der nächste sinnvolle Schritt ist.

Dein nächster Schritt:

Überlege dir: Welche Metriken nutzt deine Organisation bereits? Wo gibt es noch blinde Flecken? Und wie könntest du mit gezielten KPIs deine kontinuierliche Verbesserung unterstützen?

Wenn du Unterstützung bei der Messung deines Fortschritts und der Definition passender Metriken brauchst, dann hole dir einen erfahrenen Coach ins Boot – denn eine erfolgreiche Transformation beginnt mit den richtigen Erkenntnissen!

Selbstorganisation fördern: Wie Teams durch KMM autonomer werden

Einleitung

Die Fähigkeit eines Teams, selbstorganisiert zu arbeiten, ist ein entscheidender Faktor für dessen langfristigen Erfolg. Doch Selbstorganisation entsteht nicht von selbst. Sie benötigt unterstützende Rahmenbedingungen, klare Leitplanken und ein Umfeld psychologischer Sicherheit. Das Kanban Maturity Model (KMM) bietet eine strukturierte Herangehensweise, um Teams schrittweise in Richtung größerer Autonomie zu entwickeln. Gleichzeitig zeigt sich, dass gutes Leadership der entscheidende Faktor ist, um diesen Prozess nicht nur zu ermöglichen, sondern nachhaltig zu verankern.

In diesem Artikel untersuchen wir, wie das KMM Teams dabei unterstützt, mehr Eigenverantwortung zu übernehmen, warum psychologische Sicherheit essenziell ist und welche Rolle gutes Leadership spielt.

1. Was bedeutet Selbstorganisation im Kontext von KMM?

Selbstorganisation bedeutet, dass Teams eigenständig Entscheidungen treffen, ihre Arbeitsweise selbst regulieren und sich kontinuierlich verbessern. Doch dieses Ideal ist nicht von heute auf morgen erreichbar. Unternehmen durchlaufen verschiedene Reifestufen – genau wie im Kanban Maturity Model (KMM) beschrieben.

KMM-Level und deren Einfluss auf die Selbstorganisation:

Level 0 (Oblivious): Arbeit geschieht ad-hoc, ohne klare Strukturen. Teams haben kaum Entscheidungsfreiheit und keine Mechanismen zur Selbstorganisation.
Level 1 (Team Focused): Erste Kanban-Praktiken werden eingeführt, jedoch ohne konsequente Prozesse. Teams beginnen, sich lokal zu organisieren, doch Entscheidungen hängen stark von Führungskräften ab.
Level 2 (Customer Driven): Teams verstehen die Wertströme und arbeiten aktiv an der Verbesserung ihrer Prozesse. Sie übernehmen erste Verantwortung für ihre eigene Effizienz.
Level 3 (Fit for Purpose): Teams denken in Service-Orientierung. Sie erkennen ihre Verantwortung gegenüber Kunden und treffen datenbasierte Entscheidungen.
Level 4-6 (Risk-Hedged, Market Leader, Built for Survival): Selbstorganisation ist vollständig etabliert. Teams arbeiten hochgradig autonom und können sich selbstständig an Marktveränderungen anpassen.

2. Psychologische Sicherheit als Voraussetzung für Selbstorganisation

Viele Organisationen erwarten von ihren Teams selbstorganisiertes Arbeiten, vergessen jedoch, dass dies nur in einem Umfeld psychologischer Sicherheit möglich ist. Ohne ein Gefühl der Sicherheit werden Teams Risiken meiden, nicht offen kommunizieren und keine mutigen Entscheidungen treffen.

Die Rolle psychologischer Sicherheit in KMM-Leveln:

Niedrige KMM-Level (0-2): Fehler führen oft zu Schuldzuweisungen. Teams fühlen sich unsicher, was dazu führt, dass sie Entscheidungen vermeiden oder stets eine Bestätigung von oben suchen.
Höhere KMM-Level (3-6): Organisationen erkennen den Wert einer offenen Fehlerkultur. Teams erhalten Vertrauen, um Experimente durchzuführen und aus Fehlern zu lernen.

Wie fördert man psychologische Sicherheit?

Offene Kommunikation: Führungskräfte sollten aktiv zuhören und ehrliches Feedback geben.
Fehler als Lernchancen betrachten: Keine Schuldzuweisungen, sondern Reflexion und Verbesserung.
Transparenz schaffen: Wenn Teams wissen, was erwartet wird und wie Entscheidungen getroffen werden, steigt das Vertrauen.
Führungskräfte als Unterstützer: Führungskräfte sollten nicht als Kontrolleure auftreten, sondern als Enabler, die Teams Raum für Entwicklung geben.

3. Leadership als Schlüssel zur funktionierenden Selbstorganisation

Selbstorganisierte Teams sind nicht sich selbst überlassen. Vielmehr brauchen sie Führung, aber in einer anderen Form: als servant leadership. Die Rolle von Führungskräften verändert sich entlang der KMM-Level:

KMM-Level und die Rolle der Führungskraft:

Level 0-1: Führungskräfte treffen alle Entscheidungen. Teams haben kaum Eigenverantwortung.
Level 2-3: Führungskräfte übergeben schrittweise Verantwortung an Teams, während sie als Mentoren und Coaches agieren.
Level 4-6: Führungskräfte schaffen Strukturen, in denen Teams sich selbst organisieren und strategische Entscheidungen treffen können.

Praktiken für Leadership in selbstorganisierten Teams:

Delegation fördern: Verantwortung in klar definierten Bereichen abgeben.
Coaching statt Mikromanagement: Führungskräfte helfen Teams, Probleme eigenständig zu lösen, statt direkte Anweisungen zu geben.
Vision statt Kontrolle: Teams müssen den Sinn und Zweck ihrer Arbeit verstehen, um eigenverantwortlich handeln zu können.

4. Fazit: Der Mut zur Veränderung – und warum ein Coach helfen kann

Der Weg zur Selbstorganisation ist kein leichter. Es ist eine Reise voller Unsicherheiten, Herausforderungen und neuer Denkweisen. Vielleicht stehst du gerade an einem Punkt, an dem du merkst, dass dein Team mehr Verantwortung übernehmen könnte, aber du spürst Widerstände. Vielleicht gibt es Angst vor Fehlern oder eine Kultur, die Kontrolle über Eigenverantwortung stellt. Das ist normal – Veränderung erfordert Mut.

Doch genau hier liegt das Potenzial: Unternehmen, die das Kanban Maturity Model nutzen, haben eine klare Orientierung, wie sie ihre Teams schrittweise in Richtung mehr Autonomie entwickeln können. Dabei spielt psychologische Sicherheit eine zentrale Rolle, da ohne Vertrauen und eine offene Fehlerkultur keine echte Selbstorganisation entstehen kann.

Doch das wichtigste Puzzlestück ist und bleibt gute Führung. Leadership entscheidet darüber, ob Selbstorganisation gefördert oder ausgebremst wird. Führungskräfte, die Teams unterstützen, statt zu kontrollieren, ermöglichen eine echte Transformation.

Dein nächster Schritt:

Wenn du diesen Weg nicht alleine gehen möchtest, dann hole dir Unterstützung. Ein erfahrener Coach kann dir helfen, die richtigen Hebel zu identifizieren, Fallstricke zu vermeiden und dich auf deiner Reise zur Selbstorganisation zu begleiten. Veränderung beginnt mit einer mutigen Entscheidung – treffe deine heute!

Wetteifer vs. Wettkampf: Warum Scrum Master lieber auf Zusammenarbeit als auf Konkurrenz setzen sollten

Ein harmloser Sprint oder die Hunger Games?

Stell dir vor, du bist Scrum Master eines Teams, das gerade einen Sprint-Review vorbereitet. Die Spannung ist spürbar. Zwei Entwickler diskutieren über die beste Lösung für ein Problem. Doch plötzlich kippt die Stimmung: „Meine Lösung ist klar besser!“, ruft der eine. „Blödsinn, du hast überhaupt keine Ahnung!“, entgegnet der andere.

Was als produktiver Austausch begann, mutierte zum Showdown – ein Wettkampf mit Gewinnern und Verlierern. Aber wäre es nicht besser gewesen, wenn sich die beiden Entwickler im Wetteifer gegenseitig inspiriert hätten, um gemeinsam die beste Lösung zu finden?

Was viele nicht wissen: Schon Peter Drucker, einer der bekanntesten Management-Denker, erkannte den Unterschied zwischen Wetteifer und Wettkampf – und warum der eine Teams stärkt, während der andere sie zerstören kann.

In diesem Artikel erfährst du:

Was der Unterschied zwischen Wetteifer und Wettkampf ist
Warum Wetteifer Teams beflügelt
Welche Probleme eine Wettkampfkultur mit sich bringt
Wie du als Scrum Master oder Product Owner eine Kultur des gesunden Wetteiferns förderst

Wetteifer vs. Wettkampf: Was ist der Unterschied?

Wettkampf:

Fokus liegt auf Gewinnen und Verlieren
Andere werden als Gegner betrachtet
Oft begleitet von Neid, Angst und Statusdenken
Führt zu Silodenken und Geheimhaltung
Erfolg auf Kosten anderer

Wetteifer:

Fokus liegt auf besser werden als gestern
Andere sind Sparringspartner, keine Gegner
Fördert Motivation, Innovation und Lernkultur
Zusammenarbeit bleibt erhalten
Erfolg durch gemeinsame Weiterentwicklung

Der große Unterschied: Wetteifer motiviert Teams zu Höchstleistungen, ohne dass sie sich gegenseitig das Wasser abgraben.

Warum Wetteifer Teams beflügelt

Ein Team, das sich gegenseitig inspiriert und herausfordert, entwickelt sich schneller und nachhaltiger. Hier sind einige Vorteile einer Kultur des Wetteiferns:

💡 Mehr Innovation

In einer Umgebung, in der es nicht darum geht, Konkurrenten auszustechen, sondern die beste Lösung gemeinsam zu finden, sprühen die Ideen. Entwickler ergänzen sich, statt sich gegenseitig auszustechen.

🚀 Schnelleres Lernen

In Teams mit Wetteifer helfen sich die Mitglieder gegenseitig, weil sie wissen: Wenn das Team wächst, wachsen sie selbst auch. Eine Atmosphäre, in der Wissen offen geteilt wird, beschleunigt die Entwicklung aller Beteiligten.

💪 Höhere Eigenmotivation

Anstatt aus Angst zu handeln („Ich darf nicht schlechter sein als Kollege X!“), motivieren sich die Teammitglieder gegenseitig, sich zu verbessern. Lernen macht Spaß – wenn es nicht mit Angst verbunden ist.

Die dunkle Seite: Was passiert, wenn ein Team im Wettkampfmodus agiert?

Hier ein kleines Gedankenexperiment: Stell dir vor, dein Scrum Team wird von heute auf morgen mit individuellen Bonuszahlungen belohnt. Je mehr Code du schreibst, desto mehr verdienst du. Klingt super, oder?

Hier sind die Nebenwirkungen:

Zusammenarbeit nimmt ab, weil niemand dem anderen helfen will.
Wissen wird zurückgehalten, um sich einen Vorteil zu sichern.
Fokus auf Quantität statt Qualität – Hauptsache, man hat „mehr gemacht“ als die anderen.
Politik und Misstrauen wachsen – plötzlich sind Kollegen Konkurrenten.

Kurzum: Wettkampf killt Teamarbeit und schafft Gewinner auf Kosten vieler Verlierer.

Wie du als Scrum Master oder Product Owner eine Kultur des Wetteiferns aufbaust

🎯Setze den Fokus auf gemeinsames Lernen

Statt individuelles Ranking oder „Bester-Entwickler“-Awards zu vergeben, feiere gemeinsame Erfolge. Sprint-Reviews sollten Momente sein, in denen man voneinander lernt – nicht Showdowns, in denen Teams gegeneinander antreten.

💬Fördere konstruktives Feedback

Ein gesundes Maß an Herausforderung ist gut – solange es sich um gegenseitige Verbesserung handelt. Bringe dein Team dazu, sich wertschätzendes, aber ehrliches Feedback zu geben. Eine gute Methode dafür ist Peer-Feedback in Retrospektiven.

🛠️ Stelle Transparenz über Konkurrenz

Wenn jeder weiß, woran die anderen arbeiten, gibt es keine Geheimniskrämerei. Ein transparentes Kanban- oder Scrum-Board hilft dabei, den Fokus auf das Teamziel zu richten, anstatt dass Einzelne um Status kämpfen.

🏆Feiere Verbesserungen, nicht Siege

Erfolge sind wichtig – aber sie sollten nicht auf Kosten anderer erzielt werden. Feiere nicht den „schnellsten Entwickler“, sondern den größten Lernerfolg oder die beste gemeinsame Problemlösung.

Wetteifern statt Wettkampf – für gesunde, erfolgreiche Teams

Ein Scrum-Team ist keine Gladiatorenarena. Wenn sich Teammitglieder als Konkurrenten sehen, führt das zu Misstrauen, Silodenken und einem toxischen Arbeitsklima. Eine Kultur des Wetteiferns hingegen hilft Teams, sich gegenseitig herauszufordern, ohne sich zu bekämpfen.

Dein nächster Schritt oder eine Idee wie du aus dem Blog was für dein Team erreichst:

Reflektiere: Wie ist die Kultur in deinem Team? Gibt es gesunden Wetteifer oder gefährlichen Wettkampf?
Starte bewusst kleine Veränderungen: Fördere Transparenz, wertschätzendes Feedback und gemeinsame Ziele.
Und wenn du merkst, dass dein Team in den Wettkampfmodus abdriftet? Dann erinnere sie daran: Es geht nicht darum, besser als andere zu sein – sondern besser als gestern.

Kanban Maturity Model trifft Flight Levels: Wie beide Modelle zusammenpassen

Einleitung

Die agile Transformation von Unternehmen ist ein komplexer Prozess. Viele Organisationen setzen auf Kanban, um Transparenz zu schaffen, Prozesse zu optimieren und den Flow zu verbessern. Das Kanban Maturity Model (KMM) bietet hierbei eine strukturierte Orientierung zur Weiterentwicklung von Kanban-Praktiken. Gleichzeitig hilft das Flight Levels Modell, die gesamte Organisation besser zu koordinieren und strategisch auszurichten.

Doch wie passen diese beiden Modelle zusammen? Während das KMM die Reifegrade von Kanban-Implementierungen beschreibt, sorgt Flight Levels für ein durchgängiges Verständnis von Agilität über verschiedene Ebenen hinweg. In diesem Artikel untersuchen wir, wie Unternehmen Flight Levels als Vehikel zur Erreichung höherer KMM-Stufen nutzen können und warum die Kombination beider Modelle zu einer nachhaltig erfolgreichen Agilität führt.

In diesem Beitrag versuche ich dir einen kurzen Einstieg und eine Übersicht zu präsentieren.

1. Einführung in die Modelle

1.1 Was ist das Kanban Maturity Model (KMM)?

Das Kanban Maturity Model (KMM) ist ein leistungsstarkes Framework, das Organisationen eine klare Roadmap für die Entwicklung von Kanban-Praktiken bietet. Es hilft Unternehmen, ihre Arbeitsprozesse schrittweise zu verbessern, organisatorische Widerstände zu überwinden und eine kontinuierliche Verbesserungskultur zu etablieren. KMM ist mehr als nur eine Sammlung von Kanban-Praktiken – es ist eine systematische Anleitung zur schrittweisen Reifung der Organisation.

Die Stufen des KMM:

Level 0: Unbewusst – Arbeit wird ad-hoc und unstrukturiert erledigt, oft mit chaotischen Ergebnissen und geringer Vorhersagbarkeit. Teams haben wenig Verständnis für ihren Workflow oder die Wertströme.
Level 1: Team Fokus – Erste Kanban-Praktiken werden eingeführt, meist mit einfachen Kanban-Boards. Teams beginnen, Arbeitsprozesse sichtbarer zu machen, jedoch mit inkonsistenter Einhaltung von Prozessrichtlinien.
Level 2: Kundengetrieben – Teams beginnen, den Kunden in den Fokus zu rücken, indem sie Service-Orientierung und Workflows systematisch erfassen und verbessern. Zusätzliche Visualisierungspraktiken und Metriken helfen, Engpässe besser zu erkennen.
Level 3: Fit for Purpose – Organisationen optimieren ihre Workflows gezielt, um Geschäftsziele besser mit Kundenerwartungen in Einklang zu bringen. Teams setzen fortgeschrittene Flow-Metriken ein und arbeiten abteilungsübergreifend zusammen.
Level 4: Risikominimierend – Unternehmen integrieren fortschrittliches Risikomanagement in ihre Kanban-Systeme. Vorhersagbarkeit, Performance-Optimierung und Risiko-Reduktion stehen im Mittelpunkt.
Level 5: Marktführerschaft – Die Organisation nutzt Kanban nicht nur zur internen Optimierung, sondern als strategisches Werkzeug zur Marktführung. Die agile Kultur durchdringt das gesamte Unternehmen.
Level 6: Built for Survival – Unternehmen auf diesem Level sind extrem anpassungsfähig, innovationsfähig und widerstandsfähig gegenüber externen Disruptionen. Agilität ist tief in der Unternehmenskultur verankert.

KMM bietet Unternehmen damit eine strukturierte Möglichkeit, sich von chaotischen, ineffizienten Arbeitsweisen hin zu einer hochgradig optimierten, geschäftsorientierten Organisation zu entwickeln.

1.2 Was sind Flight Levels?

Das Flight Levels Modell wurde von Klaus Leopold entwickelt und beschreibt, wie Agilität auf verschiedenen Ebenen eines Unternehmens wirken kann. Statt sich nur auf einzelne Teams zu fokussieren, betrachtet Flight Levels das Unternehmen als gesamtes System. Es zeigt Unternehmen, dass Agilität nicht nur auf Team-Ebene stattfindet, sondern durch übergreifende Zusammenarbeit und strategische Steuerung nachhaltig verankert werden muss.

Die drei Flight Levels:

Flight Level 1 (Operative Ebene): Fokus auf Teams und deren Zusammenarbeit im täglichen Doing. Hier werden operative Arbeitsabläufe optimiert, aber ohne strategische Verknüpfung.
Flight Level 2 (Koordinationsebene): Synchronisation von Teams und Bereichen für einen reibungslosen End-to-End-Flow. Dies stellt sicher, dass verschiedene Teams nicht isoliert arbeiten, sondern sich koordinieren.
Flight Level 3 (Strategische Ebene): Ausrichtung der gesamten Organisation auf strategische Ziele und Prioritäten. Hier wird sichergestellt, dass die gesamte Organisation agil und auf Unternehmensziele ausgerichtet bleibt.

Flight Levels macht sichtbar, wo in einem Unternehmen Agilität tatsächlich wirkt – und wo nicht. Viele Unternehmen kämpfen mit isolierten agilen Initiativen, die ohne systemische Betrachtung wenig Wert bringen. Flight Levels hilft dabei, Agilität bewusst dorthin zu bringen, wo sie die grösste Wirkung entfaltet.

2. Wie Flight Levels hilft, KMM-Level zu erhöhen

Das Kanban Maturity Model beschreibt detailliert, welche Praktiken auf welcher Reifestufe einer Organisation eingesetzt werden sollten. Doch häufig scheitern Unternehmen daran, die nächsten Level zu erreichen, weil es an übergreifender Koordination fehlt. Hier setzt das Flight Levels Modell an: Es sorgt dafür, dass agile Praktiken nicht nur auf Teamebene wirken, sondern über den gesamten Wertstrom hinweg integriert werden.

Flight Levels kann als Strukturierungshilfe für Unternehmen dienen, um auf den jeweiligen KMM-Leveln gezielt Verbesserungen voranzutreiben. Es hilft Unternehmen, die isolierte Verbesserung von Teams zu überwinden und systemische Engpässe zu identifizieren.

2.1 Flight Level 1 (Teams) und KMM Level 1-2

Teams beginnen, erste Kanban-Praktiken einzusetzen (WIP-Limits, Pull-Systeme, Visualisierung von Arbeit).
Der Fokus liegt auf dem lokalen Team-Flow, ohne Berücksichtigung der Wertströme auf Unternehmensebene.
Flight Levels unterstützt hier durch gezielte Team-Coachings und operative Prozessverbesserungen.

2.2 Flight Level 2 (End-to-End-Koordination) und KMM Level 3-4

Teams beginnen, über ihre Grenzen hinauszudenken und Engpässe auf Systemebene zu analysieren.
Wertströme und Abhängigkeiten zwischen Teams werden sichtbar gemacht.
Flow-Metriken wie Lead Time und Flow Efficiency werden gezielt genutzt.
Flight Levels sorgt dafür, dass verschiedene Teams synchronisiert und übergreifende Wertströme optimiert werden.

2.3 Flight Level 3 (Strategische Ebene) und KMM Level 4-6

Unternehmen beginnen, datengetrieben zu arbeiten und Forecasting-Techniken einzusetzen.
Die Verbindung zwischen operativen Abläufen und strategischen Unternehmenszielen wird hergestellt.
Die gesamte Organisation entwickelt sich adaptiv weiter und optimiert sich kontinuierlich.
Flight Levels sorgt auf dieser Stufe für eine strategische Verzahnung von Initiativen mit der Unternehmensstrategie.

3. Fazit: Warum Flight Levels das KMM ergänzt

Überlege einmal: Wo steht dein Unternehmen aktuell? Gibt es isolierte Teams, die gut funktionieren, aber nicht miteinander abgestimmt sind? Fehlt die Verbindung zwischen operativer Arbeit und strategischer Ausrichtung? Dann könnte die Kombination aus KMM und Flight Levels genau das fehlende Puzzlestück sein.

Mache den ersten Schritt: Untersuche den aktuellen KMM-Level deiner Organisation und überlege, wie du Flight Levels gezielt einsetzen kannst, um die nächste Stufe zu erreichen. Agilität ist kein Ziel – sondern eine Reise. Die Frage ist: Bist du bereit, sie strategisch zu steuern?

Weiterführende Infos bekommst du direkt bei den KMM Seiten oder bei der Flight Level Academy oder natürlich bei einem Gespräch mit mir. 🙂

Quellen und weiterführende Literatur

David J. Anderson & Teodora Bozheva – Kanban Maturity Model: Evolving Fit-for-Purpose Organizations (kanbanmaturitymodel.com)
Klaus Leopold – Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility (flightlevels.io)
Essential Kanban Condensed – David J. Anderson & Andy Carmichael (lean-kanban.com)
Flight Levels Guide – Klaus Leopold (flightlevels.io)

Diese Quellen bieten vertiefte Einblicke in die Modelle und deren praktische Anwendung. Falls du dich weiter mit den Themen KMM und Flight Levels auseinandersetzen möchtest, lohnt es sich, diese Ressourcen zu erkunden.