Autor: Ruedi

Rudolf "Ruedi" Gysi Liebt Produkte welche Kunden begeistern und Forscher zum Thema Iterative Produktentwicklung. Versucht Work-Systems und Social-Systems nachhaltig miteinander zu verbinden damit wertvolle Arbeitswelten entstehen.

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:

  1. Flow-basierte Metriken – Diese messen, wie effizient Arbeit durch das System fließt.
  2. 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.

Künstliche Intelligenz und die Parallelen zur Industrialisierung: Warum KI keine Bedrohung ist, sondern eine Chance

Einleitung

Die Angst vor dem Neuen begleitet die Menschheit seit jeher. Die Dampfmaschine im 18. Jahrhundert, die industrielle Automatisierung im 20. Jahrhundert und heute die künstliche Intelligenz (KI) – immer wieder steht die Frage im Raum: Verliert der Mensch seine Bedeutung? Doch die Geschichte zeigt, dass neue Technologien nicht das Ende, sondern eine Evolution menschlicher Möglichkeiten darstellen. In diesem Blogbeitrag untersuchen wir die historischen Parallelen zwischen der Industrialisierung und der KI-Entwicklung und zeigen, warum KI nicht als Bedrohung, sondern als Chance betrachtet werden sollte.

Ki als Chane und als Teil der menschlichen Geschichte

Die Kraftmaschine als Beginn der Industrialisierung

Im 18. und 19. Jahrhundert revolutionierte die Dampfmaschine die Wirtschaft und Gesellschaft. James Watts verbesserte Dampfmaschine ermöglichte die Mechanisierung von Produktionsprozessen und verdrängte manuelle Arbeit in vielen Bereichen. Diese Entwicklung rief grosse Sorgen hervor:

  • Weber und Handwerker befürchteten den Verlust ihrer Existenzgrundlage.
  • Ludditen zerstörten Maschinen in der Hoffnung, die alte Ordnung zu bewahren.
  • Philosophen und Schriftsteller warnten vor der Entmenschlichung der Arbeit.

Trotz dieser Befürchtungen entstanden durch die Industrialisierung neue Berufe, effizientere Produktionsprozesse und ein erhöhter Lebensstandard für viele Menschen. Der Mensch lernte, mit den Maschinen zu arbeiten, anstatt gegen sie zu kämpfen.

Automatisierung im 20. Jahrhundert

Ein weiteres Beispiel für diese Entwicklung ist die Automatisierung im 20. Jahrhundert. Mit der Einführung von Fliessbandarbeit (z.B. durch Henry Ford) und später von computergesteuerten Maschinen wurde die Effizienz der Industrie weiter gesteigert. Wieder tauchten ähnliche Sorgen auf:

  • Massenentlassungen durch Automatisierung in der Produktion.
  • Die Angst vor dem Verlust von Handwerkskunst.
  • Die Sorge, dass Maschinen den Menschen ersetzen.

Doch auch hier zeigte sich: Neue Technologien schaffen neue Möglichkeiten. Die IT-Industrie, der Dienstleistungssektor und hochqualifizierte Berufe wuchsen enorm. Automatisierung erleichterte viele Aufgaben, und Menschen konnten sich auf kreativere und strategischere Arbeiten konzentrieren.

Künstliche Intelligenz als Fortsetzung dieser Entwicklung

Heute stehen wir mit KI an einem ähnlichen Punkt wie damals mit der Dampfmaschine oder der Automatisierung. KI ist keine externe Bedrohung, sondern ein Produkt menschlichen Wissens und Schaffens. Sie ist die Summe unseres technologischen Fortschritts und spiegelt unsere Gesellschaft wider.

Parallelen zur Industrialisierung:

  • Effizienzsteigerung: KI automatisiert Wissensarbeit, so wie Maschinen einst körperliche Arbeit automatisierten.
  • Berufsveränderung: Manche Jobs werden ersetzt, aber viele neue entstehen – wie damals durch die Industrialisierung.
  • Mensch-Technik-Interaktion: Statt Maschinen nur als Werkzeuge zu nutzen, lernen wir, mit KI zusammenzuarbeiten, um bessere Ergebnisse zu erzielen.

Beispiele aus der Praxis

  1. Medizin: KI hilft Ärzten bei der Diagnose von Krankheiten, ersetzt sie aber nicht. Sie steigert die Präzision und gibt Medizinern mehr Zeit für Patienten.
  2. Industrie: KI optimiert Logistikprozesse, steigert Ressourceneffizienz und macht Fabriken nachhaltiger.
  3. Kreative Berufe: KI unterstützt Designer, Musiker und Autoren, indem sie Inspiration liefert oder repetitive Aufgaben übernimmt.

Fazit: KI fordert uns heraus, bessere Menschen zu werden

KI ist keine fremde Macht, sondern ein Spiegel unserer Gesellschaft und unserer Fähigkeiten. Wie jede technologische Revolution zwingt sie uns, unsere Rolle neu zu definieren. Statt uns von Angst leiten zu lassen, sollten wir uns fragen:

  • Wie können wir KI so gestalten, dass sie uns dient?
  • Welche ethischen und gesellschaftlichen Werte wollen wir mit ihr transportieren?
  • Wie können wir unser Bildungssystem anpassen, um Menschen auf die Zusammenarbeit mit KI vorzubereiten?

Doch damit KI wirklich ein positiver Begleiter der Menschheit wird, müssen wir uns aktiv beteiligen. Es reicht nicht, abzuwarten oder sich von Zukunftsängsten lähmen zu lassen. Wir sollten neugierig sein, mitgestalten und Verantwortung übernehmen. Die Geschichte zeigt: Technologien entfalten ihr volles Potenzial, wenn der Mensch sie klug nutzt. Statt uns gegen KI zu stellen, sollten wir sie als Werkzeug begreifen, das uns helfen kann, drängende Probleme zu lösen – sei es im Gesundheitswesen, in der Bildung oder im Klimaschutz.

Jeder von uns kann dazu beitragen, dass KI nicht zu einer Bedrohung wird, sondern eine Bereicherung für unsere Gesellschaft darstellt. Ob als Entwickler, Anwender oder als kritischer Denker – es liegt an uns, die KI mit menschlichen Werten zu füllen und eine Zukunft zu gestalten, in der sie uns unterstützt, inspiriert und weiterbringt.

Die Industrialisierung hat uns nicht überflüssig gemacht – und das wird auch bei der KI nicht passieren. Entscheidend ist, wie wir mit dieser neuen Technologie umgehen. Lassen wir uns also nicht von Angst beherrschen, sondern nutzen wir die Chance, durch KI eine bessere, gerechtere und innovativere Gesellschaft zu schaffen.

Die Kunst der Kanban-Board-Gestaltung: Der Breakfast Club

Die Gestaltung eines Kanban-Boards mag auf den ersten Blick einfach erscheinen, doch sie erfordert ein tiefes Verständnis des Prozesses, den es visualisieren soll. In diesem Beitrag nehme ich euch mit in eine kleine imaginäre Firma namens Breakfast Club, um euch zu zeigen, wie man ein Kanban-Board entwirft und gleichzeitig die richtigen Fragen stellt.

Die KI hat ein hübsches Bild generiert 🙂

Die Geschichte des Breakfast Club

Der Breakfast Club hat sich auf ein einfaches, aber perfektes Frühstücksmenü spezialisiert: Ein weiches Ei, zwei Stück Toast mit Butter und eine heiße Tasse Kaffee. Die Herausforderung? Jeder Gast soll sein Frühstück frisch und pünktlich serviert bekommen.

Die Teilnehmenden der Übung bekommen 5 Minuten Zeit, ein Kanban-Board für diesen Service zu erstellen. Doch wie genau sollte so ein Board aussehen, und welche Fehler gilt es zu vermeiden?

Häufige Ergebnisse der Übung

Die Übung zeigt immer wieder verschiedene Ansätze auf, wie ein Kanban-Board gestaltet werden kann. Hier sind drei typische Versionen, die entstehen:

  1. Das Detaillierte Prozess-Board Manche Teilnehmende visualisieren jeden einzelnen Schritt des Herstellungsprozesses. Zum Beispiel:
    • Eier kochen: Wasser erhitzen, Ei ins Wasser legen, Kochzeit überwachen.
    • Toast machen: Toastscheiben in den Toaster geben, Bräunungsgrad kontrollieren.
    • Kaffee kochen: Wasser aufsetzen, Kaffee brühen.
    Warum dieser Ansatz suboptimal ist: Diese Ebene gehört zur fachlichen Expertise und wird von den Mitarbeitenden beherrscht. Solche Details müssen nicht ins Kanban-Board, da sie den Fokus verwässern.
  2. Das Management-Ansatz-Board Andere gehen in die entgegengesetzte Richtung und stellen den Einkauf und die Kontextprozesse dar, z. B.:
    • Eier einkaufen.
    • Toaster beschaffen und warten.
    • Eigenschaften des Toasts definieren.
    Warum dieser Ansatz oft zu hoch gegriffen ist: Dieses Board mag für Manager:innen interessant sein, führt jedoch zu wenig Klarheit darüber, wie der eigentliche Service erbracht wird. Es verliert die Kundenzentrierung aus dem Blick.
  3. Das Kundenorientierte Service-Board Der beste Ansatz konzentriert sich auf den Service-Prozess aus Kundensicht. Ein solches Board könnte folgende Spalten und Schritte enthalten:
    • Bestellung aufnehmen: Gast bestellt das Frühstück.
    • Ei zubereiten: Das wertvollste Element des Menüs wird zuerst vorbereitet.
    • Toasten: Die Toastscheiben kommen in den Toaster.
    • Butter bereitstellen: Ein Stück Butter wird zum Toast hinzugefügt.
    • Kaffee eingiessen: Heißer Kaffee wird frisch serviert.
    • Servieren: Das komplette Frühstück wird auf einem Tablett an den Tisch gebracht.
    Warum dieser Ansatz ideal ist: Dieses Board konzentriert sich darauf, wie der Kunde den Service wahrnimmt. Es visualisiert die Abfolge der Arbeitsschritte, die direkt mit der Wertschöpfung für den Kunden verbunden sind.

Lernziele der Übung

Mit dieser Übung wird deutlich:

  • Ein gutes Kanban-Board stellt den Service und die Kundenerfahrung in den Mittelpunkt.
  • Zu detaillierte oder zu hoch gegriffene Boards lenken vom Wesentlichen ab.
  • Der Fokus sollte darauf liegen, wie Arbeit organisiert wird, um den Kunden schnell und effektiv zu bedienen.

Zusätzliche Überlegungen: Risiken und Wertzuwachs analysieren

Ein Kanban-Board sollte nicht nur den Prozess darstellen, sondern auch helfen, Risiken und Wertzuwachs im Blick zu behalten. Hier einige Fragen und Gedanken, die ihr in die Analyse einfließen lassen könnt:

  1. Warum starten wir mit dem Ei?
    • Das Ei hat die längste Durchlaufzeit. Es zu priorisieren, sorgt dafür, dass der gesamte Service pünktlich geliefert werden kann.
    • Würde man mit den schnelleren Elementen wie dem Kaffee oder Toast starten, wäre das Ei am Ende der Engpass.
  2. Wie entwickelt sich der Wertzuwachs?
    • Das Ei stellt den höchsten Wert für den Kunden dar. Die Visualisierung des Prozesses zeigt, wie dieser Wert Schritt für Schritt aufgebaut wird.
    • Toast und Kaffee sind wichtige Ergänzungen, aber ohne das Ei wäre das Frühstück unvollständig.
  3. Wo liegen die Risiken im Prozess?
    • Engpässe wie ein defekter Toaster oder nicht genug gekochte Eier können den gesamten Ablauf verzögern. Diese Risiken sollten im Kanban-Board sichtbar sein, um rechtzeitig Gegenmaßnahmen einzuleiten.
    • Eine Spalte wie „Blocker“ könnte helfen, solche Probleme zu identifizieren und schnell zu beheben.
  4. Wie bleibt der Fokus auf dem Kunden erhalten?
    • Jede Spalte sollte die Abfolge aus Sicht des Kunden widerspiegeln: Von der Bestellung bis zur Lieferung.
    • Das Board sollte nicht mit internen Details überfrachtet werden, sondern klar und leicht verständlich bleiben.

Schlussfolgerung

Die Erstellung eines Kanban-Boards ist mehr als nur das Skizzieren von Prozessen. Es ist ein Werkzeug, das Teams hilft, ihre Arbeit zu visualisieren, zu priorisieren und die Wertschöpfung für den Kunden zu optimieren. Der Breakfast Club zeigt auf spielerische Weise, wie wichtig es ist, den richtigen Fokus zu finden – denn nur so kann der Service wirklich effektiv gestaltet werden.

Hast du Lust, das Kanban-Board des Breakfast Clubs selbst zu entwerfen? Probier es aus und teile deine Ergebnisse!

Warum Scrum-Teams eigentlich Kanban machen

Wenn wir ehrlich sind, machen fast alle Scrum-Teams in Wirklichkeit Kanban. Ja, du hast richtig gelesen. Scrum ist nämlich nichts anderes als eine hochspezialisierte Form von Kanban, die in einem engen Rahmen operiert. Lass uns das genauer betrachten, wissenschaftlich fundiert und mit einem Augenzwinkern.

Der Kanban-Ansatz: Flow und Kontinuierliche Verbesserung

Kanban basiert auf einigen einfachen, aber wirkungsvollen Prinzipien:

  1. Visualisiere den Workflow: Alles wird transparent gemacht.
  2. Begrenze die Work in Progress (WIP): Fokus auf das, was zählt.
  3. Messung und Optimierung: Ständige Verbesserungen durch Feedback-Schleifen.

Der Fokus liegt darauf, den Flow zu optimieren – also die Geschwindigkeit und Effizienz, mit der Arbeit durch das System fließt – und die Lead Time (Zeit von der Anforderung bis zur Lieferung) zu minimieren.

Scrum: Eine Sonderform von Kanban

Scrum hat viele Ähnlichkeiten mit Kanban, auch wenn es oft als Gegenmodell dargestellt wird. Beide fokussieren sich auf kontinuierliche Verbesserung und die Lieferung von Wert. Scrum setzt jedoch auf strikte Time-Boxing und festgelegte Rollen wie Scrum Master und Product Owner. Hier wird es interessant:

  • Sprint-Länge als Lead Time: Scrum-Teams planen ihre Arbeit in Sprints, die höchstens vier Wochen dauern. Das bedeutet, dass sie automatisch eine maximale Lead Time von vier Wochen einhalten – genau wie es Kanban-Teams tun würden, nur eben ohne explizite Time-Box.
  • Customer Lead Time: Gute Scrum-Teams stellen sicher, dass der Kunde spätestens am Ende des Sprints Feedback erhält. Damit ähneln sie fortgeschrittenen Kanban-Teams, die kontinuierlich liefern können und kurze Customer Lead Times anstreben.

Die Überschneidungen im Detail

Schauen wir uns einige Parallelen genauer an:

ScrumKanban
Time-Boxed Sprints (bis 4 Wochen)Limitierung der Lead Time durch Flow-Optimierung
Sprint PlanningPull-Prinzip und Priorisierung im Backlog
RetrospektivenKontinuierliche Verbesserungen basierend auf Daten und Feedback
Scrum BoardKanban-Board zur Visualisierung des Workflows

In beiden Ansätzen geht es um die Frage: Wie können wir effizienter, schneller und mit weniger Verschwendung arbeiten?

Fazit: Warum diese Unterscheidung wichtig ist

Scrum mag Kanban in einem Korsett sein, aber dieses Korsett hilft vielen Teams, Struktur und Rhythmus zu finden. Sobald sie jedoch die Prinzipien von Scrum meistern, könnten sie den Schritt hin zu „reinem“ Kanban wagen – oder zumindest den Kanban-Flow adaptieren, um noch flexibler zu werden.

Wenn du also ein Scrum-Team bist, dann herzlichen Glückwunsch: Du machst bereits Kanban – mit Zeitlimits. Und das ist absolut okay, solange es deinem Team und deinen Kunden dient. Vielleicht ist es aber auch an der Zeit, sich zu fragen: Was wäre, wenn wir die Grenzen von Scrum sprengen und uns voll auf den Flow konzentrieren würden?

Denn am Ende des Tages gilt: Der Flow ist King. Egal, ob du ihn in vier Wochen oder kontinuierlich lieferst.

Verzögerungstypen die deine „agile“ Welt ruinieren.

In Scrum und in agilen Methoden allgemein können verschiedene Verzögerungstypen auftreten, die den Fluss der Arbeit behindern und die Produktivität eines Teams beeinträchtigen. Diese Verzögerungen werden oft als „Waste“ oder „Impediments“ bezeichnet, da sie den Wertfluss verlangsamen. Hier sind die acht Verzögerungstypen, die häufig in Scrum auftreten, mit einer detaillierten Erklärung:

1. Wartezeit (Waiting)

Definition: Zeit, in der Teams oder Einzelpersonen auf etwas warten müssen, um weiterarbeiten zu können.

Beispiele:

  • Ein Entwickler wartet auf die Freigabe von Anforderungen durch den Product Owner.
  • Tester warten darauf, dass Entwickler ihre Arbeit abschließen.
  • Teams warten auf externe Entscheidungen oder Ressourcen.

Lösung:

  • Fördere kontinuierliche Kommunikation zwischen Teammitgliedern.
  • Reduziere Abhängigkeiten, z. B. durch Cross-Funktionalität oder Vorplanung.
  • Verwende Kanban-Praktiken wie WIP-Limits (Work in Progress), um Engpässe sichtbar zu machen.

2. Unklare Anforderungen (Unclear Requirements)

Definition: Arbeit wird verzögert, weil Anforderungen nicht ausreichend spezifiziert oder verstanden wurden.

Beispiele:

  • User Stories im Backlog sind vage oder unvollständig.
  • Das Team versteht nicht, was die „Definition of Done“ umfasst.
  • Es fehlen Akzeptanzkriterien.

Lösung:

  • Sorge für ein gut gepflegtes Product Backlog.
  • Nutze Refinement-Sitzungen, um Anforderungen rechtzeitig zu klären.
  • Etabliere eine klare „Definition of Ready“, bevor Aufgaben in den Sprint gelangen.

3. Engpässe (Bottlenecks)

Definition: Einzelne Personen oder Ressourcen sind überlastet, wodurch die gesamte Arbeit verzögert wird.

Beispiele:

  • Nur ein Teammitglied verfügt über spezielles Fachwissen, das für eine Aufgabe erforderlich ist.
  • Bestimmte technische Ressourcen oder Umgebungen stehen nicht zur Verfügung.

Lösung:

  • Fördere Wissensweitergabe und Pair Programming.
  • Investiere in Automatisierung, z. B. CI/CD (Continuous Integration/Continuous Deployment).
  • Nutze Team-Swarming (mehrere Personen arbeiten an einer Aufgabe), um Engpässe zu minimieren.

4. Abhängigkeiten (Dependencies)

Definition: Verzögerungen entstehen, weil Arbeit von anderen Teams oder externen Parteien abhängig ist.

Beispiele:

  • Warten auf Feedback von einem anderen Team.
  • Externe Anbieter liefern verspätet Ergebnisse.
  • Abhängigkeiten zwischen Modulen oder Komponenten.

Lösung:

  • Identifiziere Abhängigkeiten frühzeitig und plane entsprechend.
  • Implementiere Scrum-of-Scrum-Meetings für teamübergreifende Koordination.
  • Strebe nach möglichst unabhängigen, modularen Arbeitsaufgaben.

5. Multitasking (Task Switching)

Definition: Teammitglieder arbeiten an mehreren Aufgaben gleichzeitig, was zu ineffizientem Kontextwechsel führt.

Beispiele:

  • Ein Entwickler arbeitet gleichzeitig an zwei Sprints.
  • Teammitglieder sind in mehrere Projekte eingebunden.

Lösung:

  • Reduziere parallele Arbeiten durch WIP-Limits.
  • Priorisiere klar, welche Aufgaben im Fokus stehen sollen.
  • Stelle sicher, dass Teammitglieder dediziert auf ein Projekt oder einen Sprint konzentriert sind.

6. Fehlende Kommunikation (Communication Gaps)

Definition: Mangelnde oder ineffiziente Kommunikation führt zu Missverständnissen und Verzögerungen.

Beispiele:

  • Ein Teammitglied versteht eine Aufgabe falsch.
  • Informationen werden nicht rechtzeitig oder vollständig geteilt.
  • Stakeholder sind nicht ausreichend eingebunden.

Lösung:

  • Fördere offene Kommunikation in Daily Scrums und Reviews.
  • Nutze transparente Tools wie Jira oder Trello, um den Fortschritt sichtbar zu machen.
  • Stelle sicher, dass die richtigen Stakeholder regelmäßig informiert werden.

7. Ungeplante Arbeit (Unplanned Work)

Definition: Aufgaben, die nicht Teil des Sprints oder Backlogs sind, stören den geplanten Arbeitsfluss.

Beispiele:

  • Produktionsprobleme, die Ad-hoc-Lösungen erfordern.
  • Plötzlich auftretende Anforderungen von Stakeholdern.

Lösung:

  • Nutze einen festen Puffer für ungeplante Arbeit.
  • Halte die Sprint-Planung diszipliniert ein und weise Ad-hoc-Aufgaben klar zu.
  • Überwache den Anteil ungeplanter Arbeit und optimiere Prozesse, um sie zu reduzieren.

8. Qualitätsprobleme (Defects)

Definition: Verzögerungen durch die Notwendigkeit, Fehler zu beheben oder Arbeit erneut auszuführen.

Beispiele:

  • Fehlgeschlagene Tests, die Nachbesserungen erfordern.
  • Mängel, die erst spät im Prozess entdeckt werden.

Lösung:

  • Implementiere Testautomatisierung und kontinuierliche Integration.
  • Fördere eine starke Qualitätssicherung, z. B. durch Peer Reviews und TDD (Test-Driven Development).
  • Stelle sicher, dass die „Definition of Done“ umfassend ist und Qualität sicherstellt.

Fazit

Diese Verzögerungstypen treten häufig auf und können in Scrum durch klare Prozesse, gute Kommunikation und agile Prinzipien adressiert werden. Ein regelmäßiges Retrospektiv-Meeting ist ein wichtiger Ansatzpunkt, um diese Hindernisse zu identifizieren und kontinuierlich Verbesserungen umzusetzen.

Vom systemischen Coach zum Sportcoach: Ein neuer Blick auf Agile Coaching

In der Beratungsbranche, insbesondere im Kontext von Agile Coaching, herrscht häufig ein Missverständnis darüber, was ein Coach leisten sollte. In Europa wird Coaching oft mit einem systemischen Ansatz gleichgesetzt, bei dem Coaches darauf abzielen, Selbstreflexion zu fördern und Menschen in die Selbstorganisation zu schubsen. Das Ziel ist, die Lösungen aus den Coachees selbst herauszukitzeln. Doch dieser Ansatz stößt in vielen Organisationen auf Unzufriedenheit, insbesondere wenn es um agile Transformationen geht. Teams und Führungskräfte fühlen sich oft allein gelassen, und Agile Coaches werden als wenig hilfreich oder sogar als „Baumumarmer“ wahrgenommen.

Ein neuer Blickwinkel könnte hier Abhilfe schaffen: Was, wenn wir Agile Coaches mehr wie Sportcoaches betrachten? Welche Unterschiede ergeben sich zum systemischen Coaching, und welches Verhalten würde ein solcher Ansatz von dir als Coach verlangen?

Systemisches Coaching vs. Sportcoaching

1. Zielsetzung und Ansatz

  • Systemisches Coaching:
    • Ziel: Coachees sollen ihre eigenen Antworten finden.
    • Ansatz: Fragen stellen, Reflexion fördern, kein direktes Eingreifen in die Arbeit der Coachees.
    • Stärken: Fördert Selbstreflexion und Eigenverantwortung.
    • Schwächen: Kann in komplexen und dynamischen Situationen als passiv empfunden werden.
  • Sportcoaching:
    • Ziel: Leistung steigern, klare Ergebnisse erzielen.
    • Ansatz: Direkte Anleitung, Feedback und Training auf Basis von Stärken und Schwächen.
    • Stärken: Bietet Struktur, klare Anleitung und unmittelbare Unterstützung.
    • Schwächen: Kann bei zu starker Dominanz Eigeninitiative ersticken.

2. Rolle des Coaches

  • Systemischer Coach: Begleiter, der durch Fragestellungen neue Perspektiven eröffnet.
  • Sportcoach: Anführer, der sowohl motiviert als auch fordert, während er klare Anweisungen gibt.

3. Intervention und Unterstützung

  • Systemischer Coach: Minimal invasive Intervention, Fragen statt Antworten.
  • Sportcoach: Proaktive Intervention, Anleitung, oft auch Hands-on-Unterstützung.

Was ein Sportcoach-Ansatz für Agile Coaching bedeutet

Wenn Agile Coaches die Haltung eines Sportcoaches einnehmen, bedeutet das nicht, dass sie die Autonomie der Teams untergraben. Vielmehr geht es darum, Teams gezielt auf ihrem Weg zu unterstützen, ihre Leistung zu verbessern und Hindernisse aus dem Weg zu räumen.

1. Klare Anleitung statt reiner Fragen

Ein Sportcoach gibt klare Anweisungen und zeigt, wie etwas gemacht werden kann. Im Agile Coaching könnte das bedeuten:

  • Best Practices zeigen: Agile Coaches sollten konkrete Techniken und Methoden vermitteln, z. B. effektive Retrospektiven durchführen oder Backlogs priorisieren.
  • Training und Simulationen: Wie ein Fußballtrainer Spielzüge übt, sollte ein Agile Coach Workshops und Simulationen durchführen, um neue Arbeitsweisen einzuüben.

2. Situative Anpassung

Ein Sportcoach erkennt, wann ein Spieler Führung braucht und wann er sich zurückziehen kann, um Eigenverantwortung zu fördern. Ähnlich sollten Agile Coaches:

  • Situativ handeln: In neuen oder schwierigen Situationen stärker eingreifen und Anleitung geben, während sie in stabilen Phasen die Selbstorganisation fördern.
  • Direkt unterstützen: Teams bei der Lösung spezifischer Probleme aktiv helfen, anstatt nur Fragen zu stellen.

3. Klarheit und Struktur schaffen

Sportcoaches arbeiten mit klaren Zielen und Spielplänen. Agile Coaches könnten:

  • Spielregeln definieren: Klare Erwartungen setzen, was von Teams und Führungskräften in der agilen Transformation erwartet wird.
  • Ergebnisse messen: Fortschritte anhand von Metriken oder Zielen (z. B. Time-to-Market-Verbesserungen) messen.

4. Feedback und Motivation

Ein Sportcoach gibt kontinuierlich Feedback, sowohl positiv als auch konstruktiv. Agile Coaches sollten:

  • Offenes Feedback geben: Direkt ansprechen, wenn Dinge nicht funktionieren, und Verbesserungsvorschläge machen.
  • Motivation fördern: Erfolge feiern und Teams motivieren, weiterzumachen, auch wenn es schwierig wird.

Praktische Beispiele für Sportcoaching im Agile Coaching

Beispiel 1: Sprintplanung

  • Systemischer Coach: Fragt das Team, welche Prioritäten sie setzen wollen, und lässt sie ihren Weg finden.
  • Sportcoach-Ansatz: Unterstützt das Team aktiv, zeigt eine Priorisierungsmethode wie WSJF (Weighted Shortest Job First) und moderiert die Diskussion.

Beispiel 2: Konfliktlösung

  • Systemischer Coach: Stellt Fragen, um die Konfliktparteien zur Selbstreflexion zu bringen.
  • Sportcoach-Ansatz: Moderiert den Konflikt aktiv, schlägt konkrete Lösungen vor und sorgt dafür, dass sich alle auf eine gemeinsame Vorgehensweise einigen.

Beispiel 3: Retrospektive

  • Systemischer Coach: Stellt offene Fragen und lässt das Team selbst Lösungen erarbeiten.
  • Sportcoach-Ansatz: Zeigt Muster oder blinde Flecken auf, schlägt Techniken wie „5 Whys“ vor und leitet das Team zur Problemlösung an.

Warum dieser Ansatz effektiver sein könnte

  1. Schnellere Ergebnisse: Teams, die aktiv unterstützt werden, kommen schneller voran, da sie nicht in endloser Reflexion verharren.
  2. Klarheit für alle Beteiligten: Ein Sportcoach-Ansatz schafft klare Rollen, Erwartungen und Strukturen.
  3. Stärkung der Kompetenz: Durch gezieltes Training und Anleitung werden Teams befähigt, eigenständiger zu arbeiten.
  4. Höhere Akzeptanz: Teams und Führungskräfte sehen den Mehrwert eines Agile Coaches, der aktiv Probleme löst und Ergebnisse liefert.

Fazit: Ein Hybridansatz für Agile Coaching

Agile Coaches müssen sich nicht vollständig vom systemischen Ansatz verabschieden, aber sie könnten von einem Sportcoach-Ansatz lernen. Die richtige Mischung aus Reflexion und proaktiver Unterstützung könnte der Schlüssel sein, um die Unzufriedenheit mit Agile Coaching zu beseitigen und nachhaltige Ergebnisse zu erzielen.

Frage an dich: Wie könnte ein Sportcoach-Ansatz dein Coaching verbessern? Teile deine Erfahrungen und Gedanken!

P.S. Für Coaches und Führungskräfte, die ihre Toolbox erweitern und lernen möchten, wie sie ihre Teams gezielt unterstützen können, ist ein Certified Agile Leadership Coaching eine großartige Gelegenheit. Hier kannst du nicht nur solche Werkzeuge kennenlernen, sondern dich auch mit anderen Teilnehmenden über deine Erfahrungen austauschen. Die neuen Termine für die Schweiz findest du bald auf unserer Webseite: Certified Agile Leadership.

PPS: Schreibt mir auf LinkedIn wenn ihr mehr wissen möchtet: https://www.linkedin.com/in/rudolf-gysi/

Von der 3C-Methode zur 5C-Methode: Warum Kontext und Commitment im Requirements Engineering unverzichtbar sind

Im Requirements Engineering ist die 3C-Methode (Card, Conversation, Confirmation), eingeführt von Ron Jeffries, ein bewährtes Framework, das vor allem im agilen Umfeld eine zentrale Rolle spielt. Diese Methode stellt sicher, dass Anforderungen klar dokumentiert (Card), in der Zusammenarbeit geklärt (Conversation) und durch Akzeptanzkriterien abgesichert (Confirmation) werden. Doch wie viele bewährte Ansätze aus der agilen Welt stammt die 3C-Methode aus einer Zeit, in der die Komplexität moderner Projekte und die Dynamik globaler, verteilter Teams noch nicht in diesem Maße existierte.

In diesem Blog möchte ich die These aufstellen, dass die 3C-Methode um zwei weitere Dimensionen erweitert werden sollte: Kontext und Commitment. Diese zusätzlichen Cs können sicherstellen, dass Anforderungen nicht nur präziser und realistischer formuliert, sondern auch nachhaltig verfolgt und umgesetzt werden.

Die ursprüngliche 3C-Methode: Ein kurzer Überblick

Die 3C-Methode wurde von Ron Jeffries, einem der Mitbegründer des Extreme Programming (XP), entwickelt. Sie dient dazu, User Stories und Anforderungen strukturiert und effektiv zu gestalten. Hier eine kurze Zusammenfassung der drei ursprünglichen Cs:

  1. Card – Anforderungen werden auf Karten (physisch oder digital) knapp formuliert, um den Kern der Anforderung zu beschreiben.
  2. Conversation – Die Anforderung wird in Gesprächen zwischen Team und Stakeholdern weiterentwickelt und geklärt.
  3. Confirmation – Durch Akzeptanzkriterien wird definiert, wann die Anforderung als erfüllt gilt.

Diese Methode hat sich in der Praxis bewährt, da sie Kommunikation und Kollaboration in den Vordergrund stellt und klare Prüfkriterien liefert.

Warum die 3C-Methode heute nicht mehr ausreicht

Die Arbeitsrealität in agilen Projekten hat sich verändert. Teams arbeiten zunehmend in globalen, verteilten Umgebungen, Anforderungen sind oft komplexer, und der Erfolg hängt von der Fähigkeit ab, Anforderungen nicht nur zu klären, sondern sie in einen übergreifenden Kontext einzubetten und alle Beteiligten zu einem Commitment zu führen.

Hier kommen die zusätzlichen Cs ins Spiel: Kontext und Commitment.

Das vierte C: Kontext

Warum ist Kontext wichtig?

Der Kontext ist die Grundlage, auf der Anforderungen überhaupt erst verstanden und bewertet werden können. Ohne den Kontext ist eine Anforderung isoliert und kann missverstanden oder fehlinterpretiert werden. Ein Feature, das in einem bestimmten Projektumfeld sinnvoll erscheint, könnte in einem anderen überflüssig sein.

Wie Kontext die Methode ergänzt:

  • Einbettung der Anforderung: Anforderungen sollten nicht nur auf das „Was“ (Card) und „Wie“ (Conversation, Confirmation) fokussiert sein, sondern auch auf das „Warum“.
  • Systemgrenzen und Abhängigkeiten: Der Kontext klärt, welche Systeme, Prozesse oder Stakeholder von der Anforderung betroffen sind.
  • Geschäftsziele: Der Zusammenhang zwischen der Anforderung und den übergeordneten Geschäftszielen wird explizit gemacht.

Beispiel:
Eine User Story wie „Als Kunde möchte ich meine Bestellung speichern können“ hat eine andere Priorität, wenn der Kontext ein neues MVP ist, das schnell auf den Markt gebracht werden soll, im Vergleich zu einem etablierten System, bei dem die Stabilität wichtiger ist.

Das fünfte C: Commitment

Warum ist Commitment entscheidend?

Selbst die besten Anforderungen sind wertlos, wenn die Beteiligten sich nicht dazu verpflichten, diese umzusetzen. Commitment bedeutet, dass alle Stakeholder – von Teammitgliedern bis zu Führungskräften – hinter der Anforderung stehen und sich verpflichten, die notwendigen Ressourcen bereitzustellen.

Wie Commitment die Methode ergänzt:

  • Team-Verantwortung: Das Team verpflichtet sich, die Anforderungen in der gewünschten Qualität und Zeit umzusetzen.
  • Stakeholder-Zustimmung: Stakeholder erklären sich bereit, Ressourcen, Budget und Unterstützung bereitzustellen.
  • Nachhaltigkeit: Commitment verhindert, dass Anforderungen verworfen oder ignoriert werden, sobald Hindernisse auftreten.

Beispiel:
Eine Anforderung wird erst in das Backlog aufgenommen, wenn alle Stakeholder sich darüber einig sind, dass sie notwendig, machbar und mit den Ressourcen umsetzbar ist.

Von 3C zu 5C: Ein integrierter Ansatz

Die erweiterte 5C-Methode bietet eine strukturiertere und umfassendere Herangehensweise für modernes Requirements Engineering:

  1. Card: Prägnante Formulierung der Anforderung.
  2. Conversation: Klärung und Diskussion der Details durch Team und Stakeholder.
  3. Confirmation: Festlegen von Akzeptanzkriterien, um die Erfüllung zu überprüfen.
  4. Context: Einbettung der Anforderung in den größeren Rahmen, einschließlich Geschäftsziele und Systemgrenzen.
  5. Commitment: Sicherstellung, dass alle Beteiligten sich zur Umsetzung der Anforderung verpflichten.

Vorteile der erweiterten 5C-Methode

  • Klarheit: Kontext verhindert Missverständnisse und sorgt dafür, dass Anforderungen sinnvoll priorisiert werden.
  • Nachhaltigkeit: Commitment stellt sicher, dass Anforderungen nicht nur diskutiert, sondern auch konsequent umgesetzt werden.
  • Flexibilität: Die Methode bleibt agil, da sie Kommunikation und Anpassung fördert, ohne starre Prozesse vorzugeben.

Fazit: Die 5C-Methode als neuer Standard?

Die 3C-Methode hat sich bewährt, aber sie stammt aus einer Zeit, in der Anforderungen oft weniger komplex waren und Teams enger zusammenarbeiteten. Mit den zusätzlichen Cs Kontext und Commitment wird die Methode robuster und besser an die Realität moderner agiler Projekte angepasst.

Was denkst du? Sind Kontext und Commitment notwendige Ergänzungen, oder reichen die ursprünglichen drei Cs aus? Teile deine Meinung und Erfahrungen in den Kommentaren!