Erkenntnisse als Newcomer in der agilen Welt

Hätte ich das vor einem Jahr gewusst …
ich würde alles noch einmal genauso machen.

Dies ist mein allererster Blogbeitrag, seit ich die Pforten zur agilen Welt geöffnet habe. Was, erst jetzt?! Ja, erst jetzt.
„Alles zu seiner Zeit.“

Marcel Lehmann, ein Wertwandler seit Juli 2024.

Mein erster Berührungspunkt mit dem Begriff Scrum

Vor ungefähr fünf Jahren sass ich mit meinem Mitbewohner am Küchentisch, und wir beschäftigten uns mit unseren Projekten. Ich schrieb ein Konzept für meine 24. Geschäftsidee, und er lernte für seine Zertifizierung als Scrum Master.

„Hä? Worum geht es da genau?“, fragte ich ihn.

Er erklärte es mir mit seinen Worten, und ich verstand es auf meine Weise. Doch meine Gedanken wanderten schnell wieder zurück zu meiner One-Million-Dollar-Business-Idee.

In den darauffolgenden vier Jahren baute ich mein Business auf, wurde reich und wanderte nach Bali aus – Quatsch. Ganz im Gegenteil.

Es begann eine Zeit, in der ich bestehende Ideale loslassen musste, um meinen inneren Antrieben und Interessen zu folgen. Keine leichten Entscheidungen.
Am Ende fand ich mich in einer Situation wieder, in der ich allein in einer befristeten Wohnung sass, in der einen Hand ein gekündigter Arbeitsvertrag, in der anderen ein Flugticket nach Vietnam.

Der Startschuss

Vier Jahre später stellte ich meinem damaligen Mitbewohner dieselbe Frage noch einmal: „Worum geht es bei Scrum – und was macht ein Scrum Master?“

Er vernetzte mich mit einer Person, die ich sinnbildlich als Pfortenwächter bezeichnen würde. Gemeinsam erkannten wir Chancen für eine Zusammenarbeit – und es passte perfekt zu meinem inneren Antrieb und meinen Interessen.

Von da an ging alles sehr schnell. Ich fand mich in einer völlig neuen Situation wieder: Diesmal mit einem unbefristeten Mietvertrag, zusammen mit Freunden. In der einen Hand ein Arbeitsvertrag, in der anderen ein Mandat als Scrum Master.

Was ich erleben durfte…

Heute, nach zehn Monaten als Scrum Master, bin ich an einem Punkt in meinem Leben angekommen, den ich mir nicht besser vorstellen könnte – er entspricht meinem Ideal.
Und es brauchte alle Etappen meines Lebens. Alles kam zu seiner Zeit. Genau deshalb ist jetzt auch der richtige Zeitpunkt für meinen allerersten Blogbeitrag.

Zu Beginn, war ich irritiert. Während Agilität in manchen Unternehmen längst ein alter Hut ist, ist sie in anderen der neueste Way to go. Für mich als Newcomer konnte das zu Unsicherheiten führen und den Blick auf die Zukunft trüben. Dazu kommen all diese agilen Methoden – Scrum, Kanban, SAFe usw. Alles klingt logisch, aber auch abstrakt.
Grund genug, meine Erfahrungen zu teilen: was ich lernen durfte und weshalb ich mich nicht wieder beim Pfortenwächter verabschiedete und alles den Wasserfall hinuntergehen ging.

Rückblickend durfte ich in meinem Mandat und in der Rolle als Scrum Master viele neue und spannende Situationen erleben.
Dabei ging es vorwiegend um die Begleitung von Teams, was mir sehr entspricht.
Die unterschiedlichen Teamdynamiken in verschiedensten Situationen zu erleben und zu begleiten, war stets herausfordernd und bereichernd.
Die Vielzahl an Retrospektiven schenkte mir die Möglichkeit, die Teams besser kennenzulernen und sie mit den agilen Prinzipien vertraut zu machen.
Ich erkannte schnell: Theorie ist nicht gleich Praxis und es erforderte von mir viel Flexibilität, mich auf neue Situationen einzulassen.

Besonders bei der Konzeption und Durchführung von Workshops auf Führungsebene durfte ich viel über mich und meine Tätigkeit lernen.
An jeder Herausforderung konnte ich ein Stück wachsen und gleichzeitig den Mehrwert im Unternehmen erkennen.
Obwohl ich vieles allein vorangetrieben habe, hatte ich stets motivierende Menschen um mich und ein starkes Team im Rücken.
Die Zusammenarbeit mit Gleichgesinnten sowie das gegenseitige Unterstützen und Herausfordern sind für mich zentrale Aspekte, um mit Freude und Begeisterung bei der Arbeit zu sein.
Genau mit dieser Motivation, Teams in diesen Flow-Zustand zu begleiten, stehe ich heute am Markt und freue mich auf alle neuen Begegnungen und Herausforderungen, um schlussendlich unsere Kunden zu begeistern.

Was ich aus meinen ersten Erfahrungen mitnehme ist, dass Agilität und agile Methoden nichts Neues sind und auch nichts, was plötzlich wieder verschwindet. Mir ist bewusst, dass Viele darüber sprechen, oft mit unterschiedlichen Begriffen, doch ähnliche Kerngedanken verfolgen.

Aus meiner Sicht erklärte es bereits Charles Darwin in seiner Evolutionstheorie:
„Es ist nicht die stärkste Spezies, die überlebt, auch nicht die intelligenteste, sondern diejenige, die sich am besten an Veränderungen anpassen kann.“

Wenn du dich, dein Team und dein Unternehmen nachhaltig weiterentwickeln möchtest, dann investiere in deine Lernbereitschaft, Offenheit für Veränderung und den Mut, neue Wege zu gehen. Agilität beginnt nicht mit Methoden – sie beginnt mit deiner Haltung.
Und vergiss nie: Alles zu seiner Zeit.

Lust auf einen Kaffee? Ja!

Ihr fühlt euch gestresst? Dann lasst es regnen!

Einleitung: Der ganz normale agile Wahnsinn (Awareness)

Wir kennen das doch alle, oder? Sprint-Deadlines jagen uns, Stakeholder fordern das Unmögliche, und das Team fühlt sich an wie ein Haufen übermüdeter Eichhörnchen auf Koffein. In der agilen Welt, in der wir eigentlich flexibel und entspannt sein sollten, herrscht oft mehr Chaos als im Strassenverkehr von Mumbai. Und was machen wir? Wir schlucken den Frust runter, arbeiten noch härter und beten zum Code-Gott, dass alles irgendwie gut geht. Aber hey, es gibt eine bessere Lösung! Eine, die so alt ist wie der Buddhismus selbst, aber erstaunlich gut zur Agilität passt.

Die RAIN-Methode: Dein Erste-Hilfe-Set für den agilen Irrsinn (Interest)

Stell dir vor, du stehst unter einer Dusche. Nicht unter einer dieser fiesen, kalten Duschen, die dich morgens aus dem Bett quälen, sondern unter einem warmen, sanften Sommerregen. Dieser Regen wäscht all den Stress, die Anspannung und die negativen Gefühle von dir ab. Klingt gut, oder? Nun, genau das macht die RAIN-Methode – nur ohne Wasser. RAIN ist ein Akronym, das dir hilft, einen kühlen Kopf zu bewahren, wenn es im agilen Dschungel mal wieder brennt:

  • R wie „Recognize“ (Erkennen): Check mal, was da los ist in deinem Kopf und Körper. Bist du gestresst? Genervt? Oder einfach nur kurz davor, deinen Laptop aus dem Fenster zu werfen?
  • A wie „Allow“ (Zulassen): Ja, du hast richtig gehört. Lass das Gefühl da sein. Es ist wie mit dem nervigen Kollegen, den du nicht loswirst: Je mehr du dich wehrst, desto schlimmer wird’s.
  • I wie „Investigate“ (Erforschen): Jetzt wird’s spannend! Frag dich, woher das Gefühl kommt. Was genau hat dich so aus der Fassung gebracht? Ist es wirklich die Deadline, oder steckt da vielleicht noch was anderes dahinter?
  • N wie „Nurture/Non-Identification“ (Nähren/Nicht-Identifizieren): Sei lieb zu dir selbst! Du bist nicht dein Stress, deine Wut oder deine Deadline-Panik. Gönn dir eine Pause, atme tief durch und mach dir bewusst, dass auch das wieder vorbeigeht.

Agilität trifft Zen: Eine himmlische Verbindung (Desire)

Du fragst dich jetzt vielleicht: Was hat dieser esoterische Kram mit meiner täglichen Arbeit zu tun? Nun, eine ganze Menge! Denn Agilität und Zen haben mehr gemeinsam, als man auf den ersten Blick denkt. Beide betonen:

  • Präsenz im Hier und Jetzt: Anstatt uns in To-Do-Listen und Zukunftsszenarien zu verlieren, sollen wir den gegenwärtigen Moment bewusst erleben.
  • Anpassungsfähigkeit: Sowohl im Zen als auch in der Agilität geht es darum, flexibel auf Veränderungen zu reagieren und sich dem Fluss des Lebens (oder des Projekts) anzupassen.
  • Selbstorganisation: Statt starrer Hierarchien setzen beide auf die Weisheit der Gruppe und die Fähigkeit jedes Einzelnen, Verantwortung zu übernehmen.
  • Kontinuierliche Verbesserung: Stillstand ist Rückschritt. Sowohl im Zen als auch in der Agilität streben wir danach, uns ständig weiterzuentwickeln und besser zu werden.

Die 4 Schritte zum agilen Erleuchtung (Action)

Also, wie kannst du jetzt konkret von der RAIN-Methode in deinem agilen Alltag profitieren? Hier sind ein paar Vorschläge:

  1. Das tägliche RAIN-Ritual: Nimm dir jeden Morgen ein paar Minuten Zeit, um in dich hineinzuhorchen. Wie fühlst du dich vor dem Sprint? Was sind deine grössten Herausforderungen? Und wie kannst du ihnen mit einer gelassenen und mitfühlenden Haltung begegnen?
  2. RAIN im Sprint-Review: Wenn der Sprint mal wieder nicht so gelaufen ist wie geplant (was ja bekanntlich öfter vorkommt), nutze RAIN, um die Enttäuschung und Frustration im Team aufzufangen. Anstatt Schuldzuweisungen zu suchen, könnt ihr gemeinsam erforschen, was schiefgelaufen ist, und überlegen, wie ihr es beim nächsten Mal besser machen könnt.
  3. Der achtsame Scrum Master: Scrum Master aufgepasst! Wendet RAIN an, um eure eigenen Reaktionen in stressigen Situationen zu reflektieren. Seid ihr wirklich die ruhige und besonnene Führungskraft, die ihr sein wollt, oder lasst ihr euch von jedem kleinen Problem aus der Fassung bringen?
  4. Agile Erleuchtung für Führungskräfte: Führungskräfte können RAIN nutzen, um eine Unternehmenskultur zu fördern, in der Fehler als Lernchancen betrachtet werden und Mitarbeiter sich trauen, offen und ehrlich zu kommunizieren.

Fazit: Lass es regnen – und zwar bewusst!

Die RAIN-Methode ist zwar kein Allheilmittel für alle agilen Probleme. Aber sie ist ein wirkungsvolles Werkzeug, um einen gesünderen, produktiveren und mitfühlenderen Umgang mit den Herausforderungen der modernen Arbeitswelt zu finden. Indem wir lernen, unsere Emotionen bewusst wahrzunehmen, sie zuzulassen, sie neugierig zu erforschen und ihnen mit Freundlichkeit zu begegnen, können wir uns von reaktiven Mustern befreien und eine neue Ebene der Souveränität und Gelassenheit erreichen.

Für Einzelpersonen:

  • Integriere RAIN in deine tägliche Routine: Nimm dir regelmässig Zeit für kurze Check-ins mit dir selbst, um deine Emotionen wahrzunehmen und mit ihnen umzugehen.
  • Nutze RAIN in schwierigen Situationen: Wende die Methode bewusst an, wenn du Stress, Frustration oder andere belastende Gefühle erlebst, sei es bei der Arbeit oder im Privatleben.
  • Übe Selbstmitgefühl: Sei geduldig und freundlich mit dir selbst, besonders wenn du Fehler machst oder Rückschläge erlebst. Betrachte diese als Gelegenheiten zum Lernen und Wachsen.

Für Teams:

  • Etabliert RAIN als Team-Praxis: Integriert die RAIN-Methode in eure Retrospektiven oder andere Team-Meetings, um gemeinsam schwierige Situationen zu reflektieren und einen konstruktiven Umgang mit ihnen zu finden.
  • Schafft eine Kultur der Offenheit: Fördert einen offenen und ehrlichen Austausch über Emotionen und Herausforderungen im Team.
  • Übt Empathie: Ermutigt die Teammitglieder, sich in die Lage anderer hineinzuversetzen und deren Perspektiven und Gefühle zu verstehen.

Für Führungskräfte:

  • Seid ein Vorbild: Demonstriert selbst einen achtsamen und mitfühlenden Umgang mit Emotionen und Herausforderungen.
  • Schafft eine unterstützende Umgebung: Fördert eine Unternehmenskultur, in der Fehler als Lernchancen betrachtet werden und Mitarbeiter sich trauen, offen und ehrlich zu kommunizieren.
  • Investiert in die emotionale Intelligenz eurer Mitarbeiter: Bietet Schulungen und Workshops an, um die emotionale Kompetenz und Resilienz der Teams zu stärken.
  • Entwickle deine Führungsqualitäten weiter: Unsere Leadership-Trainings basieren auf dem Modell von Bill Joiner und begleiten dich auf deinem Weg von der Experten- zur Achiever- bis hin zur Catalyst-Führungskraft. Die Prinzipien von RAIN können dich dabei unterstützen, die dafür notwendige Selbstreflexion, Empathie und emotionale Reife zu entwickeln und so deine Reise zum Catalyst-Leader erfolgreich zu gestalten.

Indem wir die Prinzipien der RAIN-Methode in unseren agilen Arbeitsalltag integrieren und uns an Modellen wie dem von Bill Joiner orientieren, können wir nicht nur unsere individuelle Leistungsfähigkeit steigern, sondern auch eine positive und nachhaltige Wirkung auf unsere Teams, Organisationen und die Welt um uns herum erzielen. Lass es regnen – und zwar bewusst!

OrgOps Denkrahmen: Flight Levels & unFIX wirksam verbinden

Viele Organisationen stehen heute nicht vor dem Problem, zu wenig Frameworks zu haben – sondern zu viele, die nicht miteinander sprechen. In Transformationsprojekten höre ich oft: „Wir haben Scrum, OKRs, SAFE, Team Topologies – aber wir kommen trotzdem nicht weiter.“

Was fehlt, ist kein neues Modell. Sondern ein Navigationssystem, das hilft zu entscheiden: Was ist gerade das Richtige – und warum?

Genau hier setzt der OrgOps Denkrahmen an. Er will keine weitere Methode sein, sondern ein strukturierendes Navigationssystem, das vorhandene Denkmodelle wie Flight Levels und unFIX kontextsensitiv verknüpft. Inspiration dafür kam unter anderem aus Klaus Leopolds Beitrag „Flight Levels: The Operating System for Your Organization“ – und aus der Arbeit im Flight Levels System Architect Workshop mit Markus Brandl.


Für alle mit wenig Zeit: Worum geht es in diesem Beitrag?

Flight Levels strukturiert den Wertfluss in Organisationen – und das hervorragend. Doch Organisationen benötigen mehr als Flow: Entscheidungslogik, bewusstes Strukturdesign, Lernsysteme und Entwicklungsperspektiven.

Der OrgOps Denkrahmen unterstützt Organisationsberater:innen, Agile Coaches und Transformationsexpert:innen dabei, Denkmodelle wie Flight Levels und unFIX kontextsensitiv einzusetzen. Er beschreibt sechs Steuerungsebenen, die gemeinsam die Denklogik einer lebendigen Organisation bilden.


Drei Kernaussagen

  1. Flight Levels bringt Transparenz in den Wertfluss – für Strategie, Koordination und Umsetzung.
  2. unFIX ermöglicht Dialog und bewusstes Strukturdesign für effektive Zusammenarbeit.
  3. Der OrgOps Denkrahmen hilft, Denkmodelle kontextsensitiv zu verknüpfen und im organisationalen System wirksam einzusetzen.

Der OrgOps Denkrahmen als Navigationssystem für Organisationen

Flight Levels ist ein leistungsfähiges Betriebssystem für den Wertfluss. Doch wie jedes Betriebssystem braucht es mehr als App-Koordination: Ressourcenverwaltung, Governance-Architekturen und systemische Entwicklungslogiken. Der OrgOps Denkrahmen erweitert diese Perspektive strukturell.

Er betrachtet Organisation als lebendiges System mit sechs strukturellen Perspektiven, gegliedert in zwei Hauptbereiche:

StructureOps – Die strukturelle Ebene

  • GovernanceOps: Prinzipien, Werte, Entscheidungslogiken, Strukturdesign
  • HumanOps: Menschen, Beziehungen, Führung, Kultur
  • SystemOps: Reflexion, Transformation, Co-Evolution

ImpactOps – Die Wertschöpfungsebene

  • StrategyOps: Ziele, Ausrichtung, Wirkung
  • OrchestrationOps: Koordination, Vernetzung, Schnittstellen
  • ExecutionOps: Umsetzung, operative Arbeit, Ergebnisse

Der Denkrahmen hilft zu erkennen, welche organisationalen Dimensionen betroffen sind – und welche Denkmodelle dort am wirksamsten eingesetzt werden können. Wirkung entsteht nie isoliert, sondern immer im Kontext des größeren Systems.


Flight Levels: Struktur im ImpactOps-Bereich schaffen

Flight Levels wirkt besonders dort, wo Wert entsteht – in dem, was ich als ImpactOps zusammenfasse: Strategy, Orchestration und Execution. Es:

  • bringt Sichtbarkeit in strategische Arbeit (FL3)
  • strukturiert Koordination (FL2)
  • unterstützt Teamumsetzung (FL1)

Mit Flight Levels System Architecture (FLSA) lässt sich analysieren:

  • Wo fehlt Verbindung zwischen Ebenen?
  • Wo stockt der Wertfluss?
  • Wo braucht es Steuerung oder Feedbackschleifen?

Flight Levels ist kein Strukturframework – und das ist seine Stärke: Agnostisch. Fokussiert. Wirksam. Deshalb habe ich mich entschieden, mich als Flight Levels Professional weiterzubilden.


unFIX: Strukturdesign als Dialog verstehen

unFIX ist kein starres Framework, sondern ein offenes Strukturmodell, das Organisationen über Muster wie Crews, Bases, Forums oder Turfs bewusst gestalten hilft.

Wichtiger noch: unFIX ist ein Gesprächsanlass. Es initiiert strukturierte Dialoge mit Führung, Teams oder HR:

  • Wie wollen wir zusammenarbeiten?
  • Welche Strukturen brauchen wir wofür?
  • Wo brauchen wir Flexibilität – wo Verbindlichkeit?

In OrgOps ordne ich diese Fragen dem jeweiligen strukturellen Raum zu:

  • Strukturdesign-Workshops → GovernanceOps
  • Rollenlogik & Koordination → OrchestrationOps
  • Menschen & Entwicklung → HumanOps

unFIX ist kein Pattern-Katalog, sondern ein Struktur-Dialog. Der OrgOps Denkrahmen hilft zu erkennen, wo dieser Dialog gerade geführt werden sollte.


Kontextsensitiv statt Framework-fixiert

Der OrgOps Denkrahmen verändert die Perspektive: Es geht nicht darum, ein weiteres Framework zu implementieren, sondern vorhandene Denkmodelle kontextsensitiv zu verknüpfen und systemisch nutzbar zu machen.

Die entscheidende Frage lautet: Worum geht es gerade im System – und welches Denkmodell ist hier am wirksamsten?

Beispiele:

  • Flight Levels → für Flow & Arbeitssystematik (StrategyOps, OrchestrationOps, ExecutionOps)
  • unFIX → für Strukturdialog & Zusammenarbeit (GovernanceOps, OrchestrationOps)
  • M3K → für Führung & Kultur (HumanOps, GovernanceOps)
  • Rendanheyi → für Marktdynamik & Eigenverantwortung (SystemOps, GovernanceOps, StrategyOps)

Der OrgOps Denkrahmen ist keine Methode, sondern ein strukturierendes Meta-System, das hilft, Wirkung bewusst zu gestalten.


Für wen ist der OrgOps Denkrahmen relevant?

  • Organisationsberater:innen, die verschiedene Denkmodelle integrativ nutzen wollen
  • Agile Coaches, die über Flow-Optimierung hinausdenken
  • Führungskräfte, die ein Navigationssystem für Transformation suchen
  • HR-Expert:innen, die Strukturen und Entwicklung systemisch begleiten wollen

Viele Organisationen suchen nach „dem richtigen Framework“ – und übersehen, dass wirksame Entwicklung kontextsensitiv gedacht werden muss. Keines der Denkmodelle adressiert allein alle Aspekte einer Organisation.

Der OrgOps Denkrahmen vernetzt Flight Levels, unFIX & Co. gezielt – und macht sie anschlussfähig für konkrete Kontexte.


Fazit & Einladung

Wir brauchen weniger neue Methoden. Aber mehr systemische Orientierung – für Denkmodelle, die bereits wirken könnten, wenn sie gezielt verbunden werden.

Ich entwickle den OrgOps Denkrahmen weiter: als Navigationshilfe für Kontextsensitivität, strukturelle Klarheit und nachhaltige organisationale Wirksamkeit.

Wenn du mit Flight Levels, unFIX oder anderen Denkmodellen arbeitest und ein übergreifendes System suchst, das hilft, Wirkung bewusst zu steuern:

Lass uns sprechen. linkedin.com/in/roman-wurzel

Warum dein Board nicht lügt – und was du nicht sehen willst

Die Einführung agiler Methoden ist oft wie ein Besuch beim Optiker. Man sieht plötzlich besser. Nur gefällt einem das Bild nicht, das erscheint. Die Konturen sind schärfer, die Farben echter – aber das, was man sieht, ist ernüchternd vertraut. Und das kann wehtun.

Viele Teams starten ihre agile Reise mit einem Board. Scrum oder Kanban, ganz egal. Man zeichnet Spalten, verteilt Kärtchen, klebt Post-its. Man ist motiviert. Man will loslegen. Und ist am Ende überrascht, wie bekannt das alles aussieht. Wie sehr das Neue nach dem Alten riecht.

Statt eines Flow of Value sieht man einen Flow of Excel. Die Spalten heissen wie Abteilungen. Die Arbeit folgt dem Organigramm. Die Struktur kennt man – sie ist alt. Nur eben jetzt auf einem agilen Brett. Mit Stickern. Und dem leisen Gefühl, dass etwas nicht stimmt.

Das Problem ist nicht das Board. Das Problem ist, dass es zu ehrlich ist.

Boards visualisieren nicht die Zukunft. Sie zeigen die Gegenwart. Gnadenlos. Sie zeigen, wie man denkt. Wie man arbeitet. Wie man Verantwortung versteht. Und was man lieber nicht sehen will.

Doch hinter dem, was da sichtbar wird, liegt mehr als nur aktuelle Struktur. Es liegt Geschichte darin. Gelebte Erfahrung. Gelernte Muster. Eine Vergangenheit, die nicht einfach verblasst, nur weil man neue Methoden einführt.

Wenn Teams ihr erstes Board entwerfen, tun sie das nicht auf einer weissen Leinwand. Sie tun es mit dem Pinsel ihrer Vergangenheit. Sie übertragen, was sie kennen, in das, was sie hoffen. Alte Prozesse werden in neue Spalten gegossen. Historisch gewachsene Produktlogik wird zum Massstab für Backlog-Schnitte. Bekanntes Denken wird vorsichtshalber beibehalten, während man Neues testet. Sicherheit geht vor – auch wenn es bremst.

Das ist menschlich. Es ist nachvollziehbar. Und es ist der häufigste Grund, warum Transformationen stecken bleiben.

Wir projizieren unser altes Wissen in das neue System – und sind irritiert, wenn es sich fremd anfühlt. Wir versuchen, das Neue dem Alten ähnlich zu machen – und wundern uns, dass es nicht funktioniert wie bei denen, die wir bewundern. Die Methode wird angepasst, bis sie wieder ins alte Muster passt. Und dann heisst es: Agile bringt nichts.

Doch das stimmt nicht. Was nichts bringt, ist der Versuch, Neues mit alten Werkzeugen zu bauen. Ein Board ist kein Zauberstab. Es zeigt nur, was da ist. Und manchmal zeigt es sehr deutlich, wie stark die Vergangenheit noch mitredet.

Wer ein Kanban-Board entwirft und dabei Produktarchitektur mit Prozessdenken verwechselt, bekommt kein Flowsystem. Sondern ein Abbild seiner inneren Zersplitterung. Ein visuelles Echo alter Gewohnheiten.

Man will ein Produkt liefern, aber denkt in Zuständigkeiten. Man will Kundennutzen, aber sortiert nach Skills. Man will Agilität, aber führt sie durch das Nadelöhr des Bekannten. Was bleibt, ist ein Widerspruch mit hübscher Oberfläche.

Warum ist das so?

Organisationen sind konservativ. Nicht aus Böswilligkeit. Sondern aus Gewohnheit. Man hat gelernt, dass Dinge funktionieren, wenn man sie kontrolliert. Wenn man sie plant. Wenn man sie in kleine, zuständige Einheiten zerlegt. Das hat über Jahrzehnte funktioniert. In einer Welt, die planbar war.

Agile Methoden fordern das Gegenteil. Verantwortung wandert ins Team. Wert entsteht nicht mehr am Ende, sondern unterwegs. Klarheit wird wichtiger als Kontrolle. Kommunikation schlägt Struktur. Und das macht Angst. Verständlich.

Viele Führungskräfte unterschätzen das. Sie denken, ein bisschen Training reicht. Ein Zertifikat hier, ein Taskboard da – und schon läuft es.

Tut es aber nicht.

Denn was sich ändern muss, ist nicht das Tool. Es ist das Denken. Die Logik. Die Haltung. Und oft auch der Mut, die eigene Geschichte kritisch zu betrachten.

Produktdenken ist nicht Prozessdenken. Und ein Wertstrom ist kein Abteilungsworkflow mit Hüten auf. Es geht nicht um Effizienz entlang bestehender Linien. Es geht um Wirksamkeit entlang neuer Wege.

Teams, die scheitern, scheitern oft nicht an der Methode. Sie scheitern daran, dass sie mit alten Modellen ein neues Spiel spielen wollen. Sie versuchen, neue Ergebnisse mit vertrautem Denken zu erzwingen. Und wundern sich über den Stillstand.

Und Coaches? Berater:innen?

Sie stehen oft da wie Übersetzer in einer fremden Welt. Sie zeigen auf die Widersprüche. Sie erklären, warum das Sprintziel kein Reportinginstrument ist. Warum ein Backlog kein Wunschzettel sein darf. Warum ein Kanban-System keine Projektlandkarte abbildet. Sie geben Impulse. Sie machen Angebote. Aber gehen muss das System selbst.

Denn am Ende hilft nur eines: Das System muss sich bewegen. Nicht der Berater. Nicht das Board. Sondern das Denken, das dahinter steht. Und das Denken ist nicht neutral. Es kommt aus der Vergangenheit. Es trägt Geschichte. Es trägt Kultur. Es trägt Verantwortung.

Das ist keine Frage von Technik. Sondern von Haltung. Von Mut. Von Entscheidung.

Führungskräfte müssen sich fragen: Bin ich bereit, mein System anders zu denken? Bin ich bereit, Verantwortung abzugeben? Bin ich bereit, mein Produktbild zu verändern – nicht nur die Methodik drumherum?

Denn das Board, das dein Team baut, zeigt nicht, wo ihr hinwollt. Es zeigt, wo ihr steht. Und manchmal zeigt es auch, wo ihr feststeckt. In der eigenen Geschichte.

Und das ist nicht immer angenehm.

Aber es ist ein Anfang.

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 .

  1. Bindung – Soziale Eingebundenheit gibt uns Sicherheit.
  2. 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