+43-676-330-4803KontaktImpressum en de

Posts Taged Highlight

Ein Jahr Lean Business Agility Videoblog

Ein Jahr ist es her, seit das erste Video in meinem Videoblog Lean Business Agility erschienen ist. Was liegt näher, als eine Jahresbilanz zu ziehen.

Florida, Kapstadt, Johannesburg, Wien, München, Paris, London, Düsseldorf usw. Ich war an echt vielen coolen Orten und habe noch viel interessantere Leute getroffen und mit ihnen ein paar Minuten geplaudert. Ich habe eine Google Karte erstellt, in der ich die Drehorte der Episoden inklusive Link zur Episode eingetragen habe.

Charts

Ich musste feststellen, dass es gar nicht so einfach ist, objektive Charts zu erstellen. Deswegen habe ich die Charts in zwei Gruppen unterteilt:

  • Meisten Zugriffe: Die Videos mit den meisten Zugriffen in absoluten Zahlen seit Veröffentlichung des Videos. Je länger ein Video online ist, desto mehr absolute Zugriffe hat es normalerweise.
  • Zugriffe pro Woche: Gemittelte Zugriffe pro Woche seit Veröffentlichung des Videos bis heute. Die Zugriffszahlen der Videos sind nach Veröffentlichung normalerweise am höchsten und nehmen über die ersten vier bis sechs Wochen auf ein gemitteltes Maß ab.
Top 7, meisten Zugriffe
  1. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  2. DE E007: Flight Level 2 bei AutoScout24
  3. EN E004: Metrics and Dashboards
  4. DE E002: Enterprise Kanban Coach
  5. DE E012: Selbstorganisierte Unternehmen
  6. EN E020: The Spotify Model
  7. DE E011: Backlog Management bei TOP@SBB

 

Top 7, meisten Zugriffe pro Woche
  1. DE E023: Agilität mit 350+ Personen bei OTTO
  2. EN E020: The Spotify Model
  3. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  4. DE E019: Business Agility @ Rewe Digital
  5. DE E007: Flight Level 2 bei AutoScout24
  6. EN E021: Why Change is Inevitable
  7. EN E022: Managing Change in the 21st Century

 

Top 4, Englische Videos, absolute Zugriffe
  1. EN E004: Metrics and Dashboards
  2. EN E020: The Spotify Model
  3. EN E006: System Stability
  4. EN E009: Actionable Agile Metrics

 

Top 4, Englische Videos, Zugriffe pro Woche
  1. EN E020: The Spotify Model
  2. EN E021: Why Change is Inevitable
  3. EN E022: Managing Change in the 21st Century
  4. EN E004: Metrics and Dashboards

 

Top 4, Deutsche Videos, absolute Zugriffe
  1. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  2. DE E007: Flight Level 2 bei AutoScout24
  3. DE E002: Enterprise Kanban Coach
  4. DE E012: Selbstorganisierte Unternehmen

 

Top 4, Deutsche Videos, Zugriffe pro Woche
  1. DE E023: Agilität mit 350+ Personen bei OTTO
  2. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  3. DE E019: Business Agility @ Rewe Digital
  4. DE E007: Flight Level 2 bei AutoScout24

 

Und es geht munter weiter. Ich war wieder in Florida und habe dort drei interessante Videos gemacht. Mehr davon in den nächsten Tagen und Wochen. Damit ihr immer am Laufenden seid, abonniert den YouTube Kanal von Lean Business Agility oder den Podcast bei iTunes oder Overcast oder den RSS Feed.

Featured image by JESHOOTS.COM on Unsplash.

TWiG – The WiP Game – ist fertig!

Fertig! TWiG Version 1.3 hat einen Zustand erreicht, welcher der Menschheit zumutbar ist. Das Material ist druckfertig und die Simulation läßt sich als stabil bezeichnen. Eine Simulation ist natürlich nie “fertig” und ich habe auch schon viele neue Verbesserungsideen, aber TWiG ist echt gut spielbar. Was noch fehlt, ist eine Dokumentation zum Setup. Es gibt derzeit erstmal zwei Bilder. Wenn man dem Sprichwort glauben schenken mag, dass ein Bild mehr als 1000 Worte sagt, dann sollte das ja definitiv ausreichen.

Warum eine neue Simulation?

Braucht die Welt wirklich neben getKanban, FlowLab, Featureban und anderen Simulationen, die ich nicht kenne, noch eine Simulation? Ja, das sind echt super Simulationen und die Welt braucht es wahrscheinlich nicht, aber ich brauche es! Die eine Simulation dauert mir zu lange, die andere ist zu kompliziert und eine weitere zu generisch. Sorry, aber so kompliziert bin ich leider, auf meiner Mission, einfache Erklärungen für komplexe Sachverhalte zu finden.

TWiG ist ein Brettspiel, das auf einfache Art und Weise zeigt, was es bedeutet, in einem WIP-limitierten System zu arbeiten. Die Simulation dauert nur ca. 1,5 Stunden. Ich spiele TWiG meistens zum Abschluss meiner Trainings, da man damit sehr gut das theoretisch erlernte, in einem realeren Kontext simulieren kann.

Ich habe die Simulation eigentlich aus reinem Egoismus entwickelt und ich wollte sie nie veröffentlichen. Nachdem ich TWiG jedoch in den ersten Trainings eingesetzt habe, wurde mir recht rasch klar, dass “nicht veröffentlichen” Wunschdenken ist. Ich bekam laufenden Anfragen, wo man denn TWiG kaufen könnte. Nachdem wir (LEANability) nicht vorhaben, in das Brettspiel-Business einzusteigen, war es nur logisch, TWiG öffentlich verfügbar zu machen. Und genau das ist jetzt passiert. TWiG ist frei verfügbar unter der  “Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International” Lizenz.

Download

Ihr könnt euch TWiG von der Website www.LEANability.com/de/twig herunterladen. Obwohl Website ein großes Wort ist, für das was es dort zu sehen gibt. (Die Englische Version gibt es hier: www.LEANability.com/en/twig)

Hilfe und Weiterentwicklung

Wir öffnen unsere LEANability Slack-Community als TWiG-Support-Kanal. Ihr könnt euch unter www.LEANability.com/de/slack für die Community anmelden. Bitte eine kurze Notiz schreiben, dass ihr euch für TWiG interessiert. Im Slack gibt es dann die folgenden Kanäle:

  • #twig-help-en: Englischer Hilfskanal
  • #twig-help-de: Deutscher Hilfskanal
  • #twig-devleop: Kanal für die Weiterentwicklung von TWiG. Sprache ist English.
  • Es gibt auch ein Trello-Board, wo ich schon begonnen habe, die Verbesserung-Ideen zu sammeln: http://bit.ly/twig-dev-trello Die sollten im Slack diskutiert werden und im Trello kann man dann den Fortschritt der Umsetzung sehen.

Das sagt zumindest die initiale Idee. Die Realität wird zeigen, wie das funktioniert.

Danke!

Vielen Dank an Katrin Dietze für ihr kontinuierliches Feedback zur Simulation und für die Hilfe beim Material. Danke auch an Mike Freislich für die Englische Übersetzung. Danke an Joanne Perold und Mike Freislich, dass ihr als Englische Versuchskaninchen  zur Verfügung standet! Hoffe, ihr habt keine bleibenden Schäden davongetragen. Na dann, viel Spass beim TWiGen und ich freue mich über Feedback und Anregungen!!

Podcast: Stories Connecting Dots

Markus Andrezak und ich tauschen uns ja regelmäßig zu allen möglichen und unmöglichen Themen aus, meistens jedoch alleine. Manchmal aber auch öffentlich: Vorige Woche veröffentlichte ich ein Interview zum Thema “Priorisierung, Verzögerungskosten und Risikobewertung”, das ich mit Markus für mein Buch Kanban in der Praxis geführt habe. Markus hat mich aber auch schon mal öffentlich befragt und zwar in seinem sehr empfehlenswerten Podcast Stories Connecting Dots. Ich hatte die Ehre, Versuchskaninchen zu sein und war Gast in der ersten Episode. Wir sprachen über Kanban und das es im allgemeinen ganz schlau wäre, alle Methoden zu töten 🙂 Hier gibt’s den Podcast noch mal zum Nachhören.

 

Flight Levels: Die Verbesserungsebenen der Organisation

Sobald man etwas niedergeschrieben hat, kann man es sich ansehen, es weiterdenken und weiterentwickeln. Mit dem Modell der Flight Levels war das genau so: Kaum waren sie in meinem Buch „Kanban in der Praxis“ veröffentlicht und bereits davor zig Male im Beratungseinsatz bei Kunden, in Trainings und bei Vorträgen erzählt, hat sich meine Sicht darauf geändert – auch dank des Feedbacks von LeserInnen, ZuhörerInnen und TrainingsteilnehmerInnen.

Das Flight-Level-Modell stellt eine zentrale Frage: Welche Ebenen der Organisation bieten welche Hebel für die Verbesserung? Entlang dieser Frage habe ich die Flight Levels neu organisiert, denn ob der Input geregelt oder ungeregelt passiert (das bisherige Unterscheidungsmerkmal zwischen Flight Level 1 und 2) ist eine Detailfrage, die vom Wesentlichen ablenkt. In den meisten Unternehmen gibt es Mechanismen, mit denen entschieden wird, wer was als Nächstes tun soll. Ob diese Mechanismen effizient sind oder nicht, ist genau so ein Thema der Verbesserung, für das Flight-Level-Modell selbst ist sie aber nicht wichtig. Dadurch hat sich eine neue Ordnung ergeben, die so aussieht:

>  Flight Level 1 – Operative Ebene

>  Flight Level 2 – Koordination

>  Flight Level 3 – Strategisches Portfoliomanagement

Auch wenn die Flight Levels aus der Arbeit mit Kanban entstanden sind, ist es doch ein allgemeines Modell zur Weiterentwicklung von Organisationen. In meiner Arbeit mit Kunden geht es zum Beispiel sehr oft darum, mit Maßnahmen auf Flight Level 2 und 3 die Koordination und strategische Ausrichtung zu verbessern, während auf Teamebene bzw. der operativen Ebene mit Scrum gearbeitet wird. Es ist also nicht so wichtig, mit welchen Methoden auf den einzelnen Levels gearbeitet, sondern wie Kommunikation und Kooperation zwischen den Flight Levels und zwischen verschiedenen Einheiten auf den einzelnen Levels gestaltet werden. Schafft man hier Verbesserungen, beginnt sich die gesamte Wertschöpfung zu optimieren – und das ist ja schließlich unser Ziel.

Die Bezeichnung „Flight Levels“ habe ich nicht zufällig gewählt. Das Flight Level ist die Flughöhe und so soll es auch in diesem Zusammenhang verstanden werden: Je höher man fliegt, desto mehr Überblick hat man, man sieht aber auch weniger Details. Je niedriger man fliegt, desto mehr Details sieht man, aber man überblickt nicht mehr die gesamte Landschaft.

Kommunikationsinstrument
Das Modell der Flight Levels ist ein Kommunikationsinstrument, um die Wirkung von spezifischen Verbesserungsschritten  auf unterschiedlichen Ebenen deutlich zu machen und herauszufinden, wofür eine Organisation der sinnvolle und/oder mögliche Ausgangspunkt liegt, um eine Verbesserung zu starten.

Flight Level 1: Operative Ebene

Die erste Flugebene gehört dem Team, das die tägliche Arbeit erledigt. Häufig sind die involvierten Personen hoch spezialisierte Experten, vor allem in Hightech-Umgebungen begegne ich solchen Teams immer wieder. Diese Spezialisten arbeiten ausschließlich an Teilbereichen eines riesigen Gesamtsystems, etwa an den Einspritzsystemen eines Autos oder an der grafischen Aufbereitung eines Wetterradars für Flugzeuge. Eine andere typische Erscheinungsform von Einheiten auf Flight Level 1 sind crossfunktionale Software-Entwicklungs-Teams: zum Beispiel Analysten, Designer, Entwickler und Tester, die gemeinsam an einem kleineren Produkt oder an einem Subsystem eines größeren Produkts arbeiten. Meistens gelangt ein größeres Stück Arbeit zu einem Team, wird dort in sinnvolle Teile zerlegt und schrittweise umgesetzt. Nur für sich allein betrachtet, hilft ein Arbeitssystem in diesem Fall, den Arbeitsprozess dieses einen Teams zu visualisieren, zu limitieren und stetig zu verbessern. Wenn ein Unternehmen nicht nur aus einem Team besteht, sondern aus mehreren, stößt die Optimierung an den Schnittstellen zu anderen Einheiten an ihre Grenzen und sie kann sogar zur Suboptimierung des gesamten Systems führen. Die Verbesserung reicht nur bis an die Grenzen des Teams und kann in anderen Teams sogar mehr Schwierigkeiten verursachen.

Der größte Nachteil daran ist, dass trotz guter Intentionen eines Teams die Wünsche der Kunden nicht unbedingt besser erfüllt werden. Ich erkläre das gerne am Beispiel einer Tastatur. Nehmen wir an, ein Kunde wünscht sich einen Brief. Nehmen wir dazu weiter an, dass jedes Team unseres Unternehmens für eine Reihe der Tastatur zuständig ist. Jedes Team ist Meister seiner Reihe, aber Raum für Verbesserungen gibt es immer. Nun kann sich zum Beispiel Team 3 so lange optimieren, bis es einen neuen Weltrekord im Anschlagen des A aufstellt. Wunderbar! Allerdings wird der Brief dadurch kein bisschen schneller fertig. Beim Schreiben eines Briefs geht es nicht darum, dass man einen bestimmten Buchstaben besonders schnell anschlagen kann. Wichtiger ist es, den richtigen Buchstaben zur richtigen Zeit anzuschlagen, um eine wirkliche Leistungssteigerung zu erreichen. Daher sollte der Fokus einer Verbesserung am gesamten System liegen. Das Gesamtsystem ist es, das sich schrittweise auf den Kunden ausrichten soll: Was muss getan werden, um für den Kunden einen optimalen Wert zu generieren? Gibt es auf der operativen Ebene mehr als ein Team, ist es daher wichtig, die Arbeit zu koordinieren. Egal, in welcher Branche und in welchem Bereich: Auf dem Weg „from concept to cash“ bestehen zwischen den involvierten Teams in der Regel Abhängigkeiten. Jedes Team bzw. jede Einheit erledigt nur einen Teil der Wertgenerierung für den Kunden. Für eine sinnvolle Koordination müssen zunächst also die Wertschöpfungsketten von Produkten oder Projekten identifiziert werden. Ob eine Organisation agil ist, hat nichts damit zu tun, ob sie aus vielen agilen Teams besteht. Die Interaktionen zwischen den Teams müssen agil sein.

Flight Level 2: Koordination

Übersetzen wir es auf eine alltäglichere Situation in der Geschäftswelt. Das folgende Bild zeigt eine Situation, die ich in größeren Unternehmen (40 bis 40.000 MitarbeiterInnen) immer wieder sehe: Es braucht mehrere Teams, um einen Kundenwert zu generieren. In den meisten Fällen hat es für den Kunden keinen Wert, wenn er nur getesteten Code geliefert bekommt. Der Wert entsteht erst, wenn der Code in ein größeres (Live-)System integriert wird, das den Betrieb aufnimmt. Andererseits spezifizieren Kunden ihre Wünsche selten so kristallklar, dass sie sofort umgesetzt werden können. Ganz im Gegenteil: In der Regel ist vor der eigentlichen Entwicklungsarbeit noch viel anderes zu tun. Es müssen Leads generiert und Projektteams aufgesetzt werden, das Team muss verstehen, was der Kunde will, Verträge müssen geschlossen werden usw. In so einem Kontext kann die Devise nur lauten: Einen Wert für den Kunden zu schaffen, ist sehr viel wichtiger als ein hyperproduktives Team. Genau hier setzt Flight Level 2 an.

Auf Flight Level 2 wird die Interaktion der Teams optimiert. Um in der Metapher der Tastatur zu bleiben, wird auf Flight Level 2 sichergestellt, dass das richtige Team zur richtigen Zeit die richtige Taste drückt, also an der richtigen Arbeit zur richtigen Zeit arbeitet. Ein Flight Level 2 System koordiniert somit die Arbeit mehrerer Teams, die gemeinsam daran beteiligt sind, Kundenwünsche zu erfüllen und dazu bestimmte Leistungen in der Wertschöpfungskette erbringen. Ziel ist es, den Arbeitsfluss über die Teamgrenzen hinweg zu optimieren. Arbeitssysteme auf Flight Level 2 bringen massive Performance-Steigerungen, hauptsächlich aus zwei Gründen:

1.   Die Mitarbeiter arbeiten an den richtigen Dingen zum richtigen Zeitpunkt, denn der Arbeitsfluss wird teamübergreifend koordiniert.

2.   Die Anzahl der Arbeiten wird durchgehend limitiert und somit kann das Arbeitssystem insgesamt optimiert werden.

Da der Arbeitsfluss über den gesamten Wertstrom optimiert wird, verringern sich die Wartezeiten an den Schnittstellen und besonders wichtig: Engpässe werden deutlich sichtbar. Wer Organisationen auf diesem Flight Level erlebt hat, kann nur mehr lächeln, wenn High-Performance-Teams als Erfolgsgeheimnis verkauft werden. Je größer ein Unternehmen ist, desto mehr verschiedene Wertschöpfungsketten gibt es auch. Dementsprechend sind auch mehrere Koordinationsboards im Einsatz, die auch hierarchisch aufgebaut sein können.

Betrachten wir Flight Level 2 aus der Sicht des Change Management, sind Initiativen auf dieser Flughöhe – auch wenn damit mehrere Hundert Menschen koordiniert werden können – meistens einfacher einzuführen als auf Flight Level 1. Die Entscheidung, eine teamübergreifende Optimierung durchzuführen, fällt hier nämlich im höheren Management. Das bedeutet auch, dass das Management mit gutem Beispiel vorangeht und die gewünschte Veränderung vorlebt. Gleichzeitig muss nicht zwingend in jedem einzelnen Team auf der operativen Ebene die Arbeitsweise geändert werden. Ob ein Team nun Kanban oder Scrum macht oder einfach „nur arbeitet“, ist völlig irrelevant. Die einzige Veränderung, wenn man es so nennen will, ist, dass sich Vertreter aus den Teams in eigenen Meetings – meistens in regelmäßigen Standups – koordinieren.

Ist das ein Wasserfall?
Wenn man sich das Bild ansieht, kann man zur Auffassung kommen, dass Flight Level 2 die Manifestation einer wasserfallartigen Umsetzung ist. Was bedeutet Wasserfallentwicklung aber? Nur weil Dinge hintereinander abgearbeitet werden, bedeutet das nicht, dass man sich automatisch in einem Wasserfallentwicklungsprozess befindet (übrigens hat selbst Winston Royce das Wasserfallmodell als iterativen Prozess beschrieben). Es ist zum Beispiel ein gutes Muster, die Funktionalität einer Software zuerst zu programmieren, bevor man sie ausliefert.

Tatsächlich nach dem Wasserfallprinzip zu arbeiten, bedeutet, dass die Arbeitseinheiten, die durch den Arbeitsfluss gezogen werden, sehr groß sind, zum Beispiel ein komplettes Projekt. Es ist nicht zielführend, ein komplettes Projekt zuerst zu analysieren, dann zu entwickeln und schließlich zu implementieren. Davon spreche ich hier aber nicht. Die Arbeitseinheiten sollen möglichst klein sein, damit man so schnell wie möglich verifizieren kann, ob ein Ansatz richtig ist. Dazu gehört, so schnell wie möglich Feedback zu bekommen, um daraus lernen zu können.

Flight Level 3: Strategisches Portfoliomanagement

Üblicherweise arbeiten Organisationen nicht nur an einem einzigen Projekt oder einem einzigen Produkt. Das Portfolio eines Unternehmens setzt sich aus einer Vielzahl von Projekten und Produkten sowie strategischen Initiativen zusammen, die das Unternehmen fit für die Zukunft machen. Genau dieser Mix wird auf Flight Level 3 gemanagt. Man will den Überblick über das Geschehen im Unternehmen gewinnen, man will wissen, welche Projekte und strategischen Initiativen sich auf welche Art und Weise beeinflussen und wie weit die Umsetzung gediehen ist. Kann ein neues Projekt schon gestartet werden oder muss noch gewartet werden, bis ein anderes abgeschlossen ist? Welche Investments sollten getätigt werden? Soll ein neuer Markt erobert oder sollen Marktanteile gesteigert werden? Welche Change-Initiativen laufen derzeit im Unternehmen?

Vor allem diese letzte Frage – wo läuft gerade was in der Organisation und mit welchem Zweck – ist hervorragend für die Visualisierung an einem Strategieboard geeignet. So kann das Top-Management nämlich erkennen, ob widersprüchliche Signale ausgegeben wurden und sich Initiativen gegenseitig behindern. Vor allem wenn sich Unternehmen agilisieren wollen und mehrere Berater mit unterschiedlichen Ansichten im Haus unterwegs sind, treten solche Widersprüche oft auf: Während an einem Tag die Selbstorganisation gefeiert wird, werden am nächsten Tag Reportings der alten Schule gefordert. Auf dieser Flughöhe geht es also um die strategische Steuerung der gesamten Organisation und nicht um Mikromanagement in der operativen Umsetzung. Größere Unternehmen mit global verteilten Niederlassungen haben durch die unterschiedlichen lokalen Marktvoraussetzungen auch mehrere Strategien, daher trifft man dort meist auf mehrere Strategieboards, während es im Headquarter wiederum ein Koordinationsboard für alle Standorte gibt.

Grundsätzlich ist es ein gutes Problem, mehr Nachfrage als Möglichkeiten zur Umsetzung zu haben, denn sonst muss ein Unternehmen Mitarbeiter abbauen. Dadurch entsteht auf Portfolio-Ebene allerdings eine Konkurrenzsituation zwischen den Optionen. Dieses Missverhältnis zwischen Optionen und Umsetzungsmöglichkeiten muss explizit gemacht werden, da sonst der Eindruck entsteht, es stünden unendlich viele Ressourcen zur Verfügung. Dem ist aber nicht so und genau darum geht es bei Arbeitssystemen auf Flight Level 3: Um die kluge Auswahl und Kombination von Projekten, zu entwickelnden Produkten und strategischen Initiativen, um Abhängigkeiten zu erkennen und den Fluss durch die Wertschöpfungskette angesichts der tatsächlich verfügbaren Ressourcen zu optimieren.

Bei den Aufgabentypen handelt es sich auf Flight Level 3 um große Arbeitseinheiten, zum Beispiel „Markteintritt in Ungarn“ oder „weniger Automotive-, mehr Aviation-Business“. Auf dieser Flughöhe konkurrieren diese großen Funktionalitäten und Initiativen miteinander, also ist die Organisation gezwungen, überlegte und bewusste Entscheidungen darüber zu treffen, was als Nächstes abgeschlossen werden soll. Im Mittelpunkt stehen dabei nicht mehr die Ziele der einzelnen Projekte, sondern das Gesamtergebnis der Organisation. Bedarf und Möglichkeiten müssen genau abgewogen werden

Zusammenfassung

Das folgende Bild fasst die Flight Levels auf einen Blick zusammen:

Flight Level 3 ist das strategische Herz der Organisation. Hier laufen die Projekte und Initiativen des Unternehmens zusammen und hier findet auch das strategische Management statt. Flight Level 3 ist mit mehreren Systemen auf Flight Level 2 und Flight Level 1 verknüpft, wo die Arbeit operativ gemanagt wird. Das Beispiel „Markteintritt in Ungarn“ besteht auf Flight Level 3 vielleicht nur aus den zwei Tickets „Produktgruppe X bereitstellen“ und „Produktgruppe Y bereitstellen“, auf Flight Level 2 werden diese groben Arbeitseinheiten feiner zerlegt und für die Teams auf Flight Level 1 zur Verfügung gestellt.

Es ist auch häufig der Fall, dass Arbeit von Flight Level 3 direkt zu einem Team auf Flight Level 1 fließt. Nehmen wir an, bei unserem Unternehmen handelt es sich um einen Autoteilezulieferer und die Strategie auf Flight Level 3 lautet „mehr Aviation-Business“. Es gibt ein Produkt, das derzeit für den Automotive-Markt entwickelt wird, und es steht die Hypothese im Raum, dass dieses Produkt mit leichten Modifikationen auch für den Aviation-Markt interessant sein kann. Ein Spezialistenteam kümmert sich darum, diese Hypothese zu überprüfen, die Arbeitseinheit fließt also von Flight Level 3 direkt auf Flight Level 1 zum Spezialistenteam.

Die Flight Levels sind kein Maturitäts- oder Beurteilungsmodell. Ein Teamproblem wird man schlecht mit einem Strategieboard lösen können und umgekehrt lässt sich eine Strategie nicht mit einer versprengten Teaminitiative umsetzen. Trotzdem sehe ich eine ähnliche Denkweise bei agilen Initiativen: Es gibt ein strategisches Problem – nämlich die Ungewissheit darüber, wie sich der Markt in Zukunft entwickeln wird. Und obwohl niemand weiß, wo der Zug hinfährt, werden schon einmal vorsorglich alle Teams agilisiert. Agilität ist ein strategisches Thema und kann nicht primär auf der operativen Ebene gelöst werden – schon gar nicht durch die Agilisierung von Bereichen, in denen es gar nicht nötig ist. Wenn man in einer Organisation eine Verbesserung erzielen will, muss man sich zuerst darüber im Klaren sein, auf welcher Ebene der beste Hebel dafür angesiedelt ist. Die Flight Levels sollen dabei helfen, die passende Ebene zu identifizieren. Generell lässt sich sagen: Je höher das Flight Level, desto größer die Hebelwirkung. Wenn es die Möglichkeit gibt, mit einer Verbesserungsinitiative auf Flight Level 3 zu starten, sollte man das auch tun. Daher ist das einzige agile Team, das man am Anfang für eine agile Organisation unbedingt braucht, ein agiles Top-Management-Team, das agiles strategisches Portfoliomanagement betreibt. Daraus entsteht alles andere – lead by example.