Flight Levels in Action von Klaus Leopold
Der vierte Vortrag der ersten Agile100 lud zum fliegen ein. Klaus Leopold zeigte mit „Flight Levels in Action“, wie man eine Organisation auf verschiedenen Ebenen verbessern kann.
Das Modell der Flight Levels umfasst drei Ebenen, die sich um folgende Themen kümmern:
- Flight Level 1: Operative Ebene
- Fight Level 2: Koordination
- Flight Level 3: Strategisches Portfoliomanagement
Genauer erklärt es Klaus aber auf seinen Folien, die es im Mai Recap zur Agile100 gibt. Zudem zeigt der unten eingebundene Vortrag schön, wie die Flight Levels in Action wirken.
Flight Levels in Action von Klaus Leopold
Mehr über Klaus Leopold
Dr. Klaus Leopold ist Informatiker, Kanban-Pionier und Erfinder des Flight Levels Model, er verfügt über langjährige Erfahrung als Top-Management-Berater mit rund 1000 Workshop-Teilnehmern pro Jahr. Er berät Unternehmen weltweit, wie sie agil am Markt agieren können. Klaus ist Autor des Bestsellers Rethinking Agile, Practical Kanban und Co-Autor des Standardwerkes Kanban Change Leadership.
Er ist Mitbegründer der Flight Levels Academy und veröffentlicht seine aktuellen Gedanken und Erfahrungen in der Welt der Flight Levels und der Organisationsentwicklung auf seinem Blog www.LEANability.com und seinem Twitter Account: https://twitter.com/klausleopold.
„Theorie ohne Praxis ist nutzlos. Praxis ohne Theorie ist teuer.“
Flight Levels in Action (Transkript)
Falls du dir das Video nicht in voller Länge anschauen willst, haben wir hier für dich ein Transkript des gesamten Vortrags von Klaus Leopold. Viel Spaß beim Lesen!
Sohrab:
Willkommen zurück. Es ist großartig, Klaus Leopold heute bei uns zu haben. Klaus und ich haben uns eigentlich noch nie persönlich getroffen, aber wir haben eine Menge Leute, die in seinen Kursen waren und in meinen Kursen waren. Und in meinen Kursen sprachen sie immer von Kanban-Klaus, und vielleicht sprachen sie in seinen Kursen von Scrum-Sohrab, ich weiß es nicht, vielleicht kann Klaus uns ansprechen. Aber ich bin sehr, sehr froh, dass wir Klaus bei uns haben.
Er ist einer der Autoren, die ich schon eine Weile verfolge. Mir hat besonders sein letztes Buch "Rethinking Agile" gefallen, in dem er über Flight Levels spricht. Ich bin mir sicher, dass er heute einiges davon mit uns besprechen wird. Und wenn Sie daran interessiert sind, mehr zu erfahren, gehen Sie nach seinem Vortrag, nicht während seines Vortrags, zum Stand seiner Firma und tauschen Sie sich mit einigen seiner Kollegen aus, ich glaube, Catherine und Cliff werden dort sein. Klaus, die Bühne gehört Ihnen.
Klaus:
Perfekt. Cool. Vielen Dank, Sohrab, für diese freundliche Einführung. Ja, nun, "Rethinking Agile", das ist der Titel meines Buches, und das ist auch der Titel meiner heutigen Präsentation. Und ich denke, der Untertitel ist so ziemlich die Botschaft, die ich versucht habe zu vermitteln, warum agile Teams nichts mit Business Agility zu tun haben. Worum geht es also? Nun, ich würde gerne eine Geschichte erzählen. Ich möchte eine Geschichte über eine Organisation erzählen. Und diese Organisation, die hatte einige Probleme. Das Hauptproblem war, dass sie ihre Markteinführungszeit verbessern wollten. Sie sagten sich: "Okay, unsere Projekte brauchen viel zu lange, bis sie fertig sind. Wir müssen also wirklich unsere Vorlaufzeit bis zum Markt verkürzen."
Und, na ja, diese Art von Wünschen höre ich recht häufig: "Wir wollen unsere Time-to-Market verbessern." Aber aus geschäftlicher Sicht steckt viel mehr hinter dieser Verkürzung der Markteinführungszeit. In diesem speziellen Unternehmen ging es also viel darum, proaktiv auf dem Markt zu sein. Einst waren sie also Marktführer, aber jetzt versuchen sie nur noch, mit der Konkurrenz mitzuhalten. Das ist kein gutes Gefühl. Und sie sagten sich: "Okay, wir wollen wieder proaktiv sein, wir wollen die Chancen nutzen." Ich meine, sie wissen, was los ist, auf den Märkten. Und sie sagten: "Okay, das Problem ist, wenn wir versuchen, eines unserer Projekte aufzusetzen, ist die Gelegenheit schon vorbei." Also, keine gute Sache.
Und natürlich wollten sie auf den diskontinuierlichen Wandel vorbereitet sein, der gerade stattfindet, richtig? Wir kennen also alle diese neuen Geschäftsmodelle, die auftauchen, wir machen keine Projekte mehr, wir machen Produkte, wir machen keine Produkte mehr, wir machen Lösungen, wir machen Dienstleistungen, wir machen ich weiß nicht was. Da gibt es Blockchain, künstliche Intelligenz und so weiter und so fort. Und sie sagten: "Nun, die Zukunft wird höchstwahrscheinlich kommen. Aber wenn wir so weitermachen wie heute, dann höchstwahrscheinlich ohne uns." Und sie sagten: "Okay, wir müssen grundlegend ändern, was wir hier tun." Und nun, wenn Sie so etwas hören, was tun Sie dann? Die Antwort ist einfach, oder? Wir werden agil, richtig? Mit Agilität können wir all diese Themen leicht angehen. Tja, und das ist es, was sie im Grunde genommen versucht haben zu tun. Also begannen sie eine agile Transformation.
Was war Teil der agilen Transformation? Nun, wie in jedem Agile-Lehrbuch, wissen wir, dass wir die funktionalen Silos bekämpfen müssen. Silos sind schlecht und böse, also müssen wir funktionsübergreifende Teams bilden. Sie sagten: "Reorganisieren Sie funktionsübergreifende Teams." Was noch? Sie gingen sogar noch einen Schritt weiter und meinten: "Okay, wir müssen Produktteams haben. Wir wollen funktionsübergreifende Produktteams haben." Das heißt, ein Team arbeitet immer nur an einem Produkt. Eine gute Sache, wenn Sie darüber nachdenken. Was wir also tun, ist, dass wir Abhängigkeiten irgendwie reduzieren, so dass wir direkt an den Markt liefern können, und das verkürzt natürlich unsere Zeit bis zur Markteinführung. Also, mir persönlich gefällt das irgendwie.
Sie sagten: "Lasst uns nicht zu dogmatisch sein, wenn es darum geht, welche agile Methode die Teams verwenden. Sie können sich ihre agile Methode aussuchen, die bevorzugte agile Methode, es gibt nur einige Anforderungen, auf die sie achten sollten. So muss jedes Team eine Visualisierung haben, und zwar an Bord. Wir wollen sehen, was in den Teams vor sich geht." Die Idee war also, wenn ich sehe, was alle Teams machen, kann ich im Grunde einfach zu einem Team gehen, ein Gespräch über ihre Arbeit beginnen und ihre Probleme diskutieren. Jedes einzelne Team muss also das Board haben, wir wollen sehen, was in den Teams vor sich geht. Eine weitere Anforderung waren Standard-Meetings. Jedes einzelne Team braucht ein schnelles Feedback-Tool, mit dem sie sich auf Dinge einstellen können, die schnell auftauchen, also Stand-up-Meetings, jedes einzelne Team.
Jedes einzelne Team muss Retrospektiven durchführen, was im Grunde genommen eine Verbesserungsmaschine ist, was auch ziemlich viel Sinn macht, oder? Wir wollen uns also verbessern. Agil zu werden ist also nicht nur eine Verbesserung, wir wollen uns kontinuierlich verbessern. Und als letzte Sache, und das gefällt mir auch irgendwie, hieß es: "Wir wollen ein paar Messungen sehen." Wissen Sie, eine Sache ist, ob es sich gut anfühlt, die andere Sache ist, was ist das tatsächliche Ergebnis, was wir hier tun? Die Durchlaufzeit mit dem Team soll also sinken, und der Durchsatz soll steigen, richtig? Das waren also die beiden Metriken. Und nun, wenn Sie sich so etwas anschauen, und Sie haben gerade ein Agile-Lehrbuch gelesen, denken Sie jetzt wahrscheinlich: "Toll. Ich meine, die verstehen wirklich, was zu tun ist, oder? Ich meine, das ist es, was man tun muss. Da kann nichts schiefgehen."
Nun, das ist es, was sie versucht haben. Und wie sind sie diese Transformation angegangen? Nun, als allererstes haben sie ein anderthalbjähriges Transformationsprojekt ins Leben gerufen. Können Sie etwas fühlen? Das ist irgendwie meine Art von Humor, oder? Wir wollen agil werden, und das allererste, was uns in den Sinn kommt, ist die Definition der Wasserfalldarstellung, wie wir agil werden. Ich bin mir nicht sicher, ob das der beste Weg ist, das zu tun. Aber, na ja, okay, so hat man es gemacht. Also eineinhalb Jahre Projektplan, wie man agil wird. Und eines der allerersten Dinge in diesem Projektplan war, wir sprechen hier von 600 Leuten, also nicht zu groß, aber trotzdem 600 Leute, ziemlich viele Leute. Sie sagten: "All diese, nun, sie müssen eine Art grundlegendes agiles Training erhalten."
Ich denke, jeder hier hat davon gehört, Agilität, ist nicht so sehr über die Praktiken. Agilität ist viel mehr die Denkweise. Machen Sie sich Gedanken darüber? Es geht um die Denkweise. Wenn nur die Leute das richtige Mindset haben, ist alles super. Es geht also nicht um die Praktiken. Es geht um die Denkweise. Und das ist es, was sie getan haben. Also haben sie dieses eintägige agile Mindset-Programm gestartet, bei dem alle 600 Leute im Grunde durchgingen, und dann konnten sie im Grunde das Kästchen ankreuzen und den Projektplan agiles Mindset etablieren. Nun, wir können darüber nachdenken, wenn es so funktioniert, aber vielleicht braucht man ein zweitägiges Training, richtig? Also, gut, das ist ein Mindset, eine Sache. Was noch? Die Reorganisation wurde durchgeführt. Und was bedeutet das? Die Leute wurden im Grunde genommen in die Luft geworfen, sie landeten irgendwo anders in der Organisation in diesen funktionsübergreifenden Produktteams, und dann begann man im Grunde genommen, agile Teams pro Team zu implementieren.
Also die Scrum-Teams bekamen ihr Scrum-Training, ihr Product Owner Training, und die Kanban-Teams, die bauten irgendwelche Systeme auf und so weiter. Und gut, am Anfang wurde dieser ganze Prozess von 16 externen Coaches unterstützt, was cool ist, wenn man ein Beratungsunternehmen betreibt. Ich meine, da kann man ganz schön viele Tage verkaufen. Aber wenn man sich anschaut, was hier los ist, ich meine, wir reden hier von 600 Leuten. Also das ist wirklich... wenn man sich mal überlegt, wie viel Schulung und alles hier notwendig ist, dann braucht man wahrscheinlich wirklich die 16 externen Trainer.
Was noch? Irgendwie gefällt mir das hier. Sie sagten: "Wir müssen interne Kapazitäten aufbauen." Also bildeten sie 11 interne Coaches aus, und die Idee war: "Okay, wir müssen das Wissen in unserer Organisation halten", denn, ich meine, ich habe es so oft gesehen, solange die externen Berater da sind, ist alles irgendwie in Ordnung. Und wenn die externen Coaches und Berater gehen, dann denken viele Leute: "Endlich können wir wieder zur Normalität zurückkehren." Also, na ja, man will wahrscheinlich nicht zum Normalzustand zurückkehren, wenn man so viel Geld investiert, wie sie es hier tun. Also, das war der Plan, mehr oder weniger. Was war der Statusbericht? Der Statusbericht nach etwa einem Jahr, sie berichteten, dass 80 % der Teams vollständig transformiert waren. Ich mag diese Formulierung, oder? Sie waren vollständig transformiert. Was heißt das also, dass 80 % der Teams vollständig transformiert waren?
Nun, Sie könnten eine ganze Menge dieser Überprüfungen in Ihrer Projektplan-Retrospektive durchführen. Wir haben sie gesehen, ihre Unterstützung, natürlich, Standard-Meetings, Check, Check, Check. Es gab ein Kontrollkästchen namens Metriken. Und sie sagten: "Ja, die Teams machen Metriken, aber ... okay, wir checken das Kästchen, aber schauen wir uns die Metriken an. Ich meine, das ist der Grund, warum wir sie haben." So, jetzt wird es ein bisschen interessant. Dies ist also ein sogenanntes Scrum Sprint Velocity Chart. Ich zeige Ihnen also diese Velocity Charts und Lead Time Charts ein bisschen später, und was Sie hier sehen, sind Team Trends. Das ist also ein Trenddiagramm und nicht von einem Team, sondern von mehreren Teams. Und die Idee ist, dass wir generell sehen wollen, ob wir uns verbessern oder nicht. Es ist ein Maß für den Durchsatz der Philosophie. Im Grunde bedeutet es, wie viel ein Team liefert.
Wir sehen also die Zeitachse auf der X-Achse, und auf der Y-Achse sehen wir die Fantasie-Story-Punkte, ich glaube, man nennt sie so, von Scrum. Das ist die Geschwindigkeit. Und der Trend, das ist das, was sie erwartet haben zu sehen. Sie wollten sehen, dass die Velocity natürlich ansteigt. Am Anfang gibt es vielleicht nicht so viel Velocity, weil alles neu ist, wissen Sie, die Teams, sie müssen irgendwie lernen, wie das alles funktioniert, aber dann muss es definitiv nach oben gehen. Schön. Das ist das erwartete Ergebnis. Das tatsächliche Ergebnis sah so aus. Also, ja, es verbesserte sich ein bisschen, aber dann ging es wieder runter. Sie fragten sich: "Was ist hier los? Ich bin mir nicht sicher. Ich meine, das ist nicht das, was wir erwartet haben." Und nun, die ersten Stimmen, Sie konnten die ersten Stimmen in dieser Organisation hören, und sie sagten: "Nun, wissen Sie, wir haben Ihnen immer gesagt, dass Scrum nicht funktioniert. Das ist der Beweis, richtig? Kanban ist viel besser als Scrum, richtig?"
Also, gut, wenn Kanban besser ist als Scrum, dann lassen Sie uns einen Blick auf die Kanban-Diagramme werfen. Das ist das Kanban-Durchlaufzeit-Diagramm. Nun, Durchlaufzeit ist im Grunde Geschwindigkeit, wie schnell liefern wir? Es ist wieder ein Trend-Diagramm von mehreren Teams. Wir sehen den Trend auf der X-Achse, und auf der Y-Achse die Geschwindigkeit, wie schnell sie sind. Und natürlich wollten sie sehen, dass die Durchlaufzeit sinkt, richtig? Und, na ja, das erwartete Ergebnis, das tatsächliche Ergebnis sah so aus. Sie sagten: "Nun, das ist ein bisschen Fantasie. Wir können sagen, es wird nicht schlimmer. Aber, na ja, es ist ziemlich schwer zu sagen, dass, das ist viel besser." Also waren sie ein bisschen hektisch. Sie sagten sich: "Okay, wir wissen nicht, was hier los ist." Das ist das Problem mit diesen Diagrammen.
Das Problem ist, dass es ziemlich schwierig ist, ein Diagramm zu erstellen, wenn es geschrieben ist, keine Verbesserung, weil wir über Teamdiagramme sprechen und wir sprechen über Diagramme nach einer Reorganisation. Das heißt, diese Teams, die gab es vorher nicht. Also, gut, es gab diese Reorganisation, jetzt ist alles anders, im Grunde. Und ich kann nicht vergleichen, weil es die Teams vorher nicht gab. Aber es gab ein Diagramm, das im Grunde genommen existierte, bevor sie agil wurden, und nachdem sie agil wurden. Und das ist die Time-to-Market ihrer Initiativen. Erinnern Sie sich, das ist der Grund, warum sie alles gemacht haben, weil die Zeit bis zur Markteinführung gestiegen ist. Und sie haben Initiativen durchgeführt, bevor sie agil wurden. Und sie machten oder machen immer noch Initiativen, nachdem sie agil geworden sind.
Abhängigkeiten und agile Interaktionen
Die Zeit bis zur Markteinführung wurde also immer länger, und sie sagten: "Okay, wir müssen das ändern. Also müssen wir diese Linie nach unten bringen." Das war das erwartete Ergebnis. Das tatsächliche Ergebnis sah aber so aus. Und das tut jetzt wirklich weh, denn was wir hier sehen, ist nicht so, dass wir keine Verbesserung sehen. Es ist eher so, dass es schlimmer wird. Sie wurden also nicht agil, und es dauerte länger, bis sie auf dem Markt waren. Und dann haben sie sich gefragt: "Was ist das für ein Phänomen, das hier vor sich geht?" Ich meine, das ergibt für sie keinen Sinn, richtig? Und nun, sie hörten mich auf der Konferenz reden, als ich über lokale Optimierung versus globale Optimierung und solche Sachen sprach. Und sie sagten: "Nun, vielleicht hat es etwas mit dem zu tun, wovon ich spreche."
Also riefen sie mich im Grunde an und sagten: "Okay, können Sie bitte kommen und es sich ansehen? Wir sehen hier keine Verbesserungen. Vielleicht hat es etwas mit dem zu tun, worüber Sie in Ihrer Konferenzpräsentation gesprochen haben." Ich sagte: "Sicher. Ich kann es mir ansehen." Was ich also im Grunde tat, war, dass ich zu ihnen ging und ich verbrachte, ich schätze, eineinhalb Tage, fast zwei Tage mit ihnen. Und, ja, ich war irgendwie auf der Suche nach den Ursachen. Und es war irgendwie cool, weil, wissen Sie, alle Teams, sie waren agil. Und das bedeutet ... oder sie haben eine dieser zusätzlichen Methoden verwendet. Und das bedeutet, dass es eine Menge Sichtbarkeit gab. Ich bin also grundsätzlich zu den Teams gegangen, weil dort Agilität in dieser Organisation stattfand. Ich ging auf die Teams zu und begann einfach das Gespräch mit ihnen.
Und am Anfang habe ich über die Abhängigkeiten und die agilen Interaktionen gesprochen. Als ich also mit den Teams gesprochen habe, ist dies die vereinfachte oder die vereinfachte Visualisierung, die ich hier immer gesehen habe, so etwas wie Dinge, die wir tun müssen, wie das Backlog. Nächste Spalte, das Zeug, das wir bereits committed haben. Entwickeln ist, wir arbeiten gerade daran. Und dann gibt es noch die done-Spalte, eine vereinfachte Ansicht eines der Teamboards. Es gab nur eine Sache, jedes einzelne Team hatte so etwas auf seinem Board, externes Warten. Das heißt, dieses Team kann nicht mehr an diesem Workitem hier arbeiten, weil ein anderes Team in dieser Organisation daran arbeiten muss. Es ist also aus dieser Perspektive blockiert, und ein anderes Team muss es freischalten. Also, eine Abhängigkeit, richtig? Das Interessante daran ist, dass jedes einzelne Team in dieser Organisation, und zwar wirklich zu 100 %, jedes einzelne Team dieses externe Warteproblem hat. Und ich dachte mir: "Okay, was bedeutet das?"
Nehmen wir wirklich an, jedes einzelne Team in dieser Organisation hat so eine Visualisierung, das würde bedeuten, es gibt irgendwo ein zweites Board in dieser Organisation. Und wenn Team Nummer eins auf diese Abhängigkeit hier stößt, wie z.B. externes Warten, bedeutet das, dass das irgendwie eine Nachfrage bei Team Nummer zwei auslöst. Sie machen irgendeine Art von, ich weiß nicht, magischer Planung, was auch immer, und kommen zu dem Schluss: "Okay, fangen wir an, an diesem Element zu arbeiten, und wenn sie damit fertig sind, und das bedeutet, wir sind fertig und das Team da oben kann dieses Element freigeben." Das ist also im Grunde das, was vor sich geht, wenn wir dieses externe Warteproblem sehen. Ich habe also die Teams gefragt, wie oft das vorkommt. Und auf wen warten Sie? Also nicht nur einmal im Leben, sondern eher auf einer häufigen Basis.
Und was ich gemacht habe, ich habe so etwas wie ein Abhängigkeitsdiagramm gezeichnet, und das sah so aus. Es gibt also wirklich eine Menge Abhängigkeiten. Und ich dachte mir: "Das ist interessant." Und Sie sehen, es sind nur acht Teams hier. Also im wirklichen Leben, 600 Leute, Sie können sich vorstellen, dass das riesig ist, wenn man sich dieses Abhängigkeitsdiagramm anschaut. Die Frage ist, warum gibt es so viele Abhängigkeiten? Ich meine, sie haben eine ganze Menge getan, um diese Abhängigkeiten zu reduzieren. Denken Sie daran, sie bilden funktionsübergreifende Teams. Sie bauen funktionsübergreifende Teams auf, weil wir Abhängigkeiten beseitigen wollen. Die andere Sache ist, sogar Produktteams zu bekommen. Das heißt, ein Team arbeitet nur an einem Produkt. Sie haben also eine ganze Menge getan, um die Abhängigkeiten zu beseitigen, aber trotzdem landen sie in einer Situation wie dieser. Die Frage ist, warum?
Nun, es gibt mehrere Gründe, drei Gründe. Ich denke, das sind die drei wichtigsten Gründe, die ich herausgefunden habe. Grund Nummer eins ist, ja, es ist richtig. Ein Team arbeitet nur an einem Produkt. Das ist in Ordnung. Allerdings arbeiten mehrere Teams an demselben Produkt. Das heißt also zum Beispiel, dieses Team hier oben arbeitet nur an Produkt A, aber das andere Team und das andere Team, die arbeiten auch an Produkt A. Und, welche Überraschung, es gibt Abhängigkeiten, richtig? Was noch? Ein weiteres Problem ist, dass die Produkte nicht völlig unabhängig voneinander sind. Das heißt, wenn Sie etwas in Produkt A ändern, müssen Sie auch etwas in Produkt B und in Produkt C ändern. Wir haben also eine ganze Menge Abhängigkeiten innerhalb der Produkte oder zwischen den Produkten.
Und gut, am Ende reden wir über 600 Leute. Ich persönlich habe noch nie eine Organisation mit mehr als 30 Leuten ohne Abhängigkeiten in der Wissensarbeit gesehen, richtig? Es ist also völlig klar, dass wir hier Abhängigkeiten sehen. Und, na ja, immer wenn ich an Abhängigkeiten denke, taucht ein Bild in meinem Kopf auf, ein Bild von einer Tastatur. Nehmen wir an, unsere Organisation ist eine Tastatur, und wir sind gut im Schreibgeschäft. Was wir also tun, ist, wir schreiben Briefe für unsere Kunden. Organisieren wir also unsere Organisation, Team eins, zwei, drei, vier, richtig? Team eins drückt nur die Zahlentasten, Team zwei, Q, W, E, R, Team drei A, S, D, F und so weiter, und so weiter. Und jetzt nehmen wir mal an, der Kunde möchte, dass wir den Liebesbrief schreiben. Nun, wir müssen uns überlegen, wie wir diesen Liebesbrief zustellen können. Aber wenn Sie eine Organisation mit 600 Leuten sind, haben Sie nicht nur vier Teams. Ihre Organisation sieht wahrscheinlich so aus.
Für jede einzelne verfluchte Taste auf Ihrer Tastatur gibt es irgendwo ein Team, das diese Taste drückt. Wir haben ein R-Team, wir haben ein T-Team, wir haben ein G-Team, wir haben ein A-Team, jede Organisation braucht ein A-Team, natürlich. Sonst ist man im Grunde genommen aufgeschmissen. Und jetzt nehmen wir mal an, wir optimieren alle diese Teams. Und nehmen wir an, es klappt. Wir haben das beste R-Team auf diesem Planeten. Wir haben das beste V-Team und das beste S-Team. Und wenn das D-Team anfängt, die D-Taste zu drücken, kommt Rauch aus der Tastatur. Sie sind einfach fantastisch. Wir sind der internationale Benchmark, wenn es darum geht, die Tastatur zu schlagen, Tasten auf der Tastatur zu drücken. Die Frage ist, wie viel schneller können wir unseren Liebesbrief zustellen? Nun, vielleicht nicht so sehr, oder?
Das richtige Team muss zur richtigen Zeit an den richtigen Dingen arbeiten
Der Punkt ist also, wenn es um die Bedienung der Tastatur geht, ist es nicht so wichtig, dass sie jede einzelne Taste total schnell treffen, es ist viel wichtiger, dass ich dafür sorge, dass sie die richtige Taste zur richtigen Zeit drücken. Wenn ich die richtige Taste zum richtigen Zeitpunkt drücke, kann ich meinen Brief viel, viel schneller fertigstellen. Und das Gleiche gilt für Organisationen. Das Gleiche gilt für Organisationen. Es ist also nicht so wichtig, dass jedes einzelne Team sehr, sehr schnell arbeitet. Es ist viel wichtiger, dass wir dafür sorgen, dass das richtige Team zur richtigen Zeit an den richtigen Dingen arbeitet. Das richtige Team muss zur richtigen Zeit an den richtigen Dingen arbeiten. Das ist der Punkt, an dem es um organisatorische Leistung geht.
Und nun, es gibt einen Typen namens Russell Ackoff. Russell Ackoff sagte bereits, dass die Leistung eines Systems nicht die Summe seiner Teile ist. Es ist das Produkt seiner Interaktionen, das Produkt seiner Wechselwirkungen. Was bedeutet das? Nun, wenn wir das irgendwie in unsere heutige Welt transformieren, könnten wir sagen, dass es bei der Agilität einer Organisation nicht darum geht, dass sie, ich weiß nicht, viele agile Teams hat. Bei einer agilen Organisation geht es eher darum, dass es tatsächliche Interaktionen zwischen den Teams gibt. Wir müssen also die Interaktionen agilisieren und nicht so sehr die Teams, das ist der Punkt, an dem die organisatorische Agilität liegt. Wir müssen dafür sorgen, dass das richtige Team zur richtigen Zeit an den richtigen Dingen arbeitet. Und das ist etwas, was in dieser Organisation überhaupt nicht auf dem Radar war. Sie sagten: "Der heilige Gral ist die Cross-Funktionalität. Wir müssen diese funktionsübergreifenden Silos abreißen, und alles wird großartig sein."
Verstehen Sie mich nicht falsch. Ich bin ein großer Fan von funktionsübergreifenden Teams. Aber das Problem ist, dass es nicht reicht, die Silos einzureißen, die funktionalen Silos. Also, was diese Organisation im Grunde getan hat, ja, sie haben die funktionalen Silos abgerissen, aber sie haben funktionsübergreifende Silos aufgebaut. Der Punkt ist also, es ist nicht so wichtig, welche Person in welchem Team ist. Es ist viel wichtiger, dass wir irgendwie Interaktionslöcher zwischen den Wänden des Teams bohren. Wir müssen es also möglich machen, dass diese Teams auf eine agile Art und Weise interagieren. Und das wurde in dieser Organisation überhaupt nicht gemacht. Das war also der Befund, Nummer eins, es gab überhaupt keine tatsächlichen Interaktionen. Ich habe noch zwei Probleme für Sie. Und nach den Problemen werden wir zum Lösungsstand wechseln. Problem Nummer eins, keine agilen Interaktionen. Kommen wir zum, sagen wir mal, zweiten Problem, der zweiten Erkenntnis.
Wie ich bereits sagte, habe ich mit den Teams gesprochen, und ich habe auch mit den Teams über den Fluss gesprochen. Was bedeutet das? Nun, lassen Sie uns noch einmal einen Blick auf die Tastatur werfen. So sehen diese Tafeln also aus. Und ich dachte mir: "Okay, das ist interessant. Sie entwickeln also, und nach der Entwicklung sind Sie fertig. Das heißt, der Kunde ist total zufrieden, alles ist super." Sie sagten: "Na ja, so einfach ist das nicht. Nach der Entwicklung müssen wir natürlich integrieren, was wir gemacht haben." Und ich so: "Okay, cool. Warum nicht?" Also bauen wir eine weitere Säule. Ich meine, wir wollen sie ja sichtbar machen. Das ist doch der Sinn einer Visualisierung, oder? Also haben wir uns eine Spalte ausgedacht, die auf die Integration wartet. Na gut. Aber dann habe ich mir gedacht: "Okay, und wenn die Integration fertig ist, dann ist man fertig. Das heißt, der Kunde ist rundum zufrieden."
Sie sagten: "Nein, nicht ganz. Wir müssen natürlich noch ein paar Akzeptanztests machen." Ich sagte: "Okay, interessant. Also, lassen Sie uns eine andere Säule einführen. Also, wir warten auf die Akzeptanztests. Aber jetzt hat der Kunde es akzeptiert. Also ist der Kunde jetzt total zufrieden, richtig?" Sie sagten: "Nein, es gibt, wissen Sie, diese Freigabefenster, und es muss in ein Freigabefenster passen, und so weiter und so fort. Aber dann sind wir irgendwie fertig." Ich sagte: "Okay, das ist eine gute Information, oder? Wir haben jetzt ein Board mit ein paar mehr Spalten." Es geht also nicht so sehr um die Visualisierung. Es geht mehr darum, was wir aus dieser Visualisierung lernen können. Und wenn ich eine Visualisierung wie diese sehe, fange ich irgendwie an, Fragen zu stellen wie: "Okay, warten wir auf die Integration? Wie lange dauert das? Wie lange dauert das? Wie lange dauert das?"
Und, nun, in diesem speziellen Fall war die Antwort, dass die Integration monatlich durchgeführt wurde und viermal im Jahr Akzeptanztests, die das Release durchliefen. Wir wollen die Time-to-Market unserer Projekte verbessern. Ich denke, ich habe ein paar Ideen, richtig? Aber ich war hier natürlich nicht ganz glücklich, gerade in der Softwareentwicklung wissen wir ziemlich genau, was wir hier zu tun haben. Also, da gibt es Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Everything. Ich habe mir auch die Vorderseite des Boards angeschaut. Ich dachte mir: "Okay, hier ist das Backlog. Das heißt also, hier hast du deine Vision, deine Produktidee, deine tolle Feature-Idee, und du fängst an, sie zu entwickeln."
Und sie sagten: "Nein, nein, nein, so einfach ist das nicht. Wissen Sie, wenn wir hier über den Backlog sprechen, sprechen wir über den Entwicklungs-Backlog. Bevor wir mit der Entwicklung beginnen, müssen wir natürlich einige Analysen durchführen." Ich dachte mir: "Okay, warum nicht? Ich meine, das ist doch der Grund, warum wir dieses Board gebaut haben, oder?. Also lassen Sie uns eine weitere Spalte einrichten, wie Produktpakete hier oben, Analyse und dann sind wir im Entwicklungsrückstand, und dann können wir anfangen. Das heißt also, hier im Product Backlog haben wir wirklich unsere tolle Idee." Und sie sagten: "Nein, eigentlich sieht unser Prozess ziemlich genau so aus. Wir haben so etwas wie einen Pool von neuen Ideen, und wir machen eine Art Triage mit diesen Ideen, dann schreiben wir ein Grobkonzept. Dieses Grobkonzept wartet auf den Lenkungsausschuss, dann schreiben wir einen detaillierten Business Case, der wiederum auf die Genehmigung wartet. Und jetzt sind wir endlich im Product Backlog. Und wir können anfangen, zu analysieren."
Ich dachte mir: "Okay, interessant, natürlich. Und das Coole ist, wenn wir ein bisschen rauszoomen, sieht der Prozess so aus." Und ich dachte: "Okay, schön." Und wieder, wie zuvor, wenn ich so etwas sehe, ist der Punkt daran, dass wir wieder anfangen können, Fragen zu stellen. Und die Frage war die gleiche wie vorher, wie oft findet es statt? Und wie lange müssen wir warten? Und die Antwort war so, die Triage wird monatlich durchgeführt, was irgendwie sehr schnell ist. Viermal im Jahr gab es den Lenkungsausschuss, der irgendwie die groben Business Cases genehmigt. Und einmal im Jahr wurden die detaillierten Business Cases genehmigt, einmal im Jahr. Wir wollen die Time-to-Market für unsere Projekte verbessern. Ich glaube, ich habe ein paar Leaver identifiziert, die wir abziehen könnten. Nun, sie kamen auch auf eine Idee. Sie sagten: "Entwicklung, Problem entdeckt. Wir haben hier etwas agilen Feenstaub reingetan und wir sind so verdammt agil, es ist einfach fantastisch."
Nun, nein, tut mir leid, das zu sagen. Das glaube ich nicht. Ich meine, natürlich können wir das irgendwie schneller machen, aber im Endeffekt erreichen wir nicht viel, wenn es darum geht, schneller an den Markt zu liefern. Ich meine, das ist vielleicht die agile Softwareentwicklung. Schön und gut. Damit habe ich kein Problem. Aber mit Business Agility, das hat nichts mit Business Agility zu tun. Diese Firma X liegt auf dem Markt wie vorher, also da gibt es überhaupt keine Veränderung. Und genau das war das zweite Problem, das ich entdeckt habe. Es gab keine Erfassung und kein Management des Wertstroms.
Kommen wir zum dritten Problem, bevor wir uns den Lösungen zuwenden!
Also, das Problem, und ich habe noch ein Problem bevor wir zu den Lösungenwechseln: Wir können ein wenig über das Agile strategische Portfolio sprechen. Bevor wir das tun, lassen Sie uns zu den Teams zurückgehen, richtig? Das war also eine dieser Team-Tafeln. Und was ich auf diesen Tafeln sehen konnte, das war so etwas wie Zahlen darauf, Zahlen wie Peitschenlimits, schätze ich. Sie alle haben schon von Peitschen-Limits gehört, so wie Work-in-Process-Limits. Das bedeutet, dass sie hier nur zwei Elemente beginnen und eines dieser Elemente abschließen müssen, bevor sie ein neues Element beginnen. Das ist also für die Kanban-Teams, aber es gab auch Scrum-Teams, vielleicht hatten Scrum-Teams diese explizite Begrenzung nicht. Aber Scrum-Teams, sie haben ihre Arbeit begrenzt, weil sie mit Sprints arbeiten oder sie machen Sprints. Also ist Sprint im Grunde genommen ähnlich wie die Begrenzung der Arbeit im Prozess, denn was Sie tun, ist, Sie sagen einfach: "Okay, ich verpflichte mich, diese Elemente innerhalb der nächsten zwei Wochen zu liefern. Ich fange nicht mehr Elemente an, als ich diese Elemente liefere, und dann können wir mehr Elemente anfangen." Es ist also auch "stop starting start finishing".
Ich spreche also über dieses Erzeugen von Fokus, denn das Erzeugen von Fokus ist einfach großartig. Es steckt so viel Theorie dahinter. Und es gibt sogar einen mathematischen Beweis, wie das Little'sche Gesetz, dass mehr oder weniger alles, was Sie hier lesen können, wahr ist. Also, der Switching-Overhead sinkt, die Zykluszeit sinkt, die Kosten der Verzögerung sinken, Ihr System ist stabil, das heißt, Sie sind berechenbar. Es gibt also so viele großartige Dinge, wenn Sie einen Fokus in Ihrer Organisation schaffen. Und, na ja, es gibt sogar eine Sache, die Zykluszeit geht runter und die Zeit bis zur Markteinführung geht runter. Der Punkt ist also, wenn Sie einen Fokus schaffen, werden Sie schneller, die Zeit bis zur Markteinführung wird kürzer. Aber was wir jetzt in dieser Organisation gesehen haben, ist, dass die Zeit bis zur Markteinführung tatsächlich gestiegen ist. Wie ist das möglich? Ich meine, es gibt einige mathematische Beweise, dass das korrekt ist.
Also haben sie einfach das Little'sche Gesetz gefälscht? Nun, nein. Lassen Sie es mich so ausdrücken. Wenn es darum geht, einen Fokus zu schaffen, gibt es, sagen wir mal, ein Kleingedrucktes. Und ich denke, 99% der Organisationen haben dieses Kleingedruckte nie gelesen. Hier ist also das Kleingedruckte, ein bisschen größer. Der Punkt ist, es geht nicht darum, sich auf irgendeinen beliebigen Gegenstand oder eine beliebige Einheit in Ihrer Organisation zu konzentrieren. Was Sie tun müssen, ist, sich zu fokussieren, Sie müssen einen Fokus schaffen, Sie müssen diese Arbeitselemente begrenzen, wo Sie den Nutzen sehen wollen. Sie müssen diese Arbeitselemente dort begrenzen, wo Sie den Nutzen sehen wollen. Was bedeutet das? Nun, diese Organisation hat an Initiativen gearbeitet, richtig? Was sie taten, war, die Initiativen in Epen aufzuteilen. Dann haben sie die Epen in Geschichten aufgeteilt und ungeliebte Geschichten in Aufgaben. So haben sie es gemacht. Nun, wir müssen uns verbessern.
Was wir also sehen wollen, ist, dass wir die Zeit bis zur Markteinführung unserer Initiativen verbessern wollen. Was müssen wir einschränken? Worauf müssen wir uns in unserer Organisation konzentrieren? Nun, wie ich schon sagte, Initiativen, natürlich, also müssen wir sicherstellen, dass die Menge, die Anzahl der Initiativen in unserer Organisation irgendwie begrenzt ist. Das ist es, was wir tun müssen. Was haben sie getan? Nun, Agilität war eine Team-Sache. Agilität war also nur ein Team und sonst nichts. Ich als Team, in dieser Kette, was kann ich beeinflussen? Was kann ich tatsächlich begrenzen? Höchstwahrscheinlich nicht die Initiativen. Höchstwahrscheinlich nicht die Epics. Also mein Einflussbereich ist irgendwo hier, ich kann wahrscheinlich die Geschichten begrenzen, ich kann die Aufgaben begrenzen. Und ich denke, genau das ist das Problem. Und das ist genau das Problem, was wir in dieser Organisation gesehen haben.
Ordne nicht die Dinge, die du tust der Strategie zu, sondern mache nur, was die Strategie dir sagt!
Der Punkt ist also, seien Sie nicht überrascht, wenn Sie nicht die Verbesserung sehen, die Sie sehen wollen. Sie müssen sich also auf diese Arbeitselemente konzentrieren, bei denen Sie die Verbesserung sehen wollen. Und das sind eindeutig keine Geschichten. Das sind Initiativen. Und in dieser Organisation werden sie die Teams replizieren, sie haben ihre Sprint-Ziele und alles verteidigt, aber sie haben immer noch an 1000 Initiativen parallel gearbeitet. Also, Überraschung, Überraschung, keine der Initiativen wurde schneller fertig. Das ist keine gute Sache. Wo können wir diese Initiativen begrenzen? Wo können wir einen Fokus auf diese Initiativen schaffen? Ich würde sagen, irgendwo in einem strategischen Portfolio, irgendwo da oben, was auch immer da oben bedeutet, aber es ist jenseits der Teamebene, richtig? Wenn wir über die Strategie und das strategische Portfolio sprechen, gab es noch eine andere Sache, die in dieser Organisation irgendwie interessant war, nämlich der Prozess der Strategieentwicklung.
In dieser Organisation wurde die Strategie also ein wenig interessant angegangen. Lassen Sie es mich so ausdrücken. Also, lassen Sie uns eine Zeitleiste einfügen, okay? In dieser Organisation haben die Leute an etwas gearbeitet. Das ist gut so. Ich meine, das ist der Grund, warum sie bezahlt werden. Und dann gab es diese Strategieankündigung. Die Strategie wurde also irgendwie verkündet auf einer... ich weiß nicht, Stadthalle, tolles Essen, Getränke, alles. Und, ja, das ist alles Strategie. Und die Konsequenz der Strategieankündigung war, dass die Leute an den Sachen arbeiten. Also, kein großer Unterschied, richtig? Und dann, später im Jahr, sahen sie irgendwie das Zeichen über das Ende des Jahres. Und dann dachten sie sich: "Okay, da war etwas mit Strategie, irgendwo am Anfang des Jahres." Und was Sie in dieser Organisation beobachten konnten, mehr und mehr Leute begannen, neue PowerPoint-Dokumente wie strategyfulfillment.pptx zu erstellen.
Und was sie im Grunde taten, war, dass sie irgendwie versuchten, all die Dinge, an denen sie arbeiteten, im Nachhinein der Strategie zuzuordnen. Sie sagten sich also: "Okay, ich habe an diesem Projekt gearbeitet. Das passt in diesen Strategie-Eimer. Ich habe daran gearbeitet, das passt in diesen Strategiebereich." Sie versuchen also irgendwie, rückwärts zu planen und das auf der Grundlage der Strategiearbeit, die sie gemacht haben, zu rechtfertigen. Aber das ist nicht der Sinn der Strategie. Die Idee der Strategie ist, dass die Strategie bestimmt, woran wir arbeiten. Es ist keine Rechtfertigungsmethode, richtig? Das ist also eine weitere Sache, die in dieser Organisation wirklich auffiel. Und ich werde in der Lösung ein wenig später darüber sprechen, was wir diesbezüglich getan haben. Okay, das war also Problem Nummer drei, also kein wirkliches strategisches Portfolio-Management in dieser Organisation.
Wir sprachen also im Grunde über diese drei Probleme, keine tatsächlichen Interaktionen, die Strategie war gut, das Strategiemanagement war nicht verfügbar, und kein End-to-End-Management des Wertstroms. Das waren also im Grunde die drei Probleme, die ich entdeckt habe. Lassen Sie uns über Lösungen sprechen. Nun, am Ende waren die Lösungen, sie waren keine Raketenwissenschaft. Das ist die gute Nachricht. Trotzdem hat es einige Zeit gedauert, bis wir an diesem Punkt angelangt waren, an dem wir anfangen konnten, an Lösungen zu arbeiten. Aber was waren die Lösungen? Nun, als erstes die tatsächlichen Interaktionen zwischen den Teams. Erinnern Sie sich, da war dieses Diagramm, wo wir all diese Abhängigkeiten hatten. Und, ja, was haben wir getan? Nun, was wir getan haben, ist, erinnern Sie sich, die Abhängigkeiten waren da, weil die Teams an einem Produkt arbeiteten, aber mehrere Teams arbeiteten an demselben Produkt.
Wir hatten also immer noch eine ganze Menge Abhängigkeiten. Was wir also im Grunde getan haben, ist, dass wir von der Teamebene ausgegangen sind und Produktboards erstellt haben. Was bedeutet das? Wir haben im Grunde genommen identifiziert, welches Team an welchem Produkt arbeitet. Nehmen wir also an, diese drei Teams arbeiten an einem Produkt. Was wir also im Grunde genommen gemacht haben, ist, dass wir die drei Teams irgendwie in einen Raum gesperrt haben, und wir würden gerne eine Visualisierung erstellen, wie sie gemeinsam ihren Arbeitsstrom verwalten. Und das haben wir am Ende für alle Produkte gemacht. Wir haben also Produktboards gebaut. Der Punkt ist also, wir haben aufgehört, Organisationsstrukturen zu optimieren. Ein Team ist eine Organisationsstruktur, ich als Kunde, ich kümmere mich nicht darum, ob Sie Teambesetzungen haben oder was auch immer, es ist mir egal, richtig? Also haben wir aufgehört, uns darauf zu konzentrieren und die Organisationsstrukturen zu optimieren. Was wir taten, war die Optimierung der Wertlieferung.
Der Kundennutzen entsteht beim Produkt
Das Produkt ist etwas, bei dem der Kunde einen gewissen Nutzen hat, wenn es fertig ist. Und das ist es, was wir gemacht haben. Also haben wir Produktboards gebaut. Und vor den Produkttafeln, und das ist das Wichtigste, haben sich die Teams koordiniert. Wir hatten also Stand-up-Meetings und Retrospektiven zwischen den Teams vor diesem Board. Und ich denke, das ist auch eine sehr wichtige Sache. Der Punkt ist, es geht nicht so sehr um das Board. Es geht viel mehr darum, dass die Leute, die richtigen Leute die richtige Konversation vor dem Board führen. Die eigentliche Interaktion ist also das Wichtigste. Und, ja, was wir gemacht haben, sind Produkt-Standup-Meetings und Produkt-Retrospektiven. Das heißt, die Teams schickten Vertreter zum Stand-up-Meeting, zur Retrospektive, sie hatten ein Stand-up-Meeting für alle Teams, dann gingen sie zurück in ihr Team und hatten ein Stand-up-Meeting im Team. Ja, das ist eine Sache.
Wenn man so etwas macht, sinkt die Anzahl der Abhängigkeiten, richtig? Aber es blieben immer noch einige Abhängigkeiten übrig. Also werden diese Abhängigkeiten jetzt innerhalb des Produkts verwaltet. Aber denken Sie daran, es gab immer noch die Sache, dass wenn Sie etwas in Produkt zwei ändern, Sie etwas in Produkt eins ändern müssen. Wir haben also Abhängigkeiten zwischen den Produkten. Was haben wir also getan, um das zu überwinden? Nun, wir haben etwas aufgebaut, was ich heute als operatives Portfolio bezeichnen würde. Operatives Portfolio bedeutet im Grunde, dass wir irgendwie die Produkte und Dienstleistungen identifizieren, bei denen es viele Abhängigkeiten gibt. Und wir haben diese Boards zusammengenommen und ein weiteres Board erstellt, in dem wir diese Abhängigkeiten über die Produkte hinweg verwalten können.
Dies ist zum Beispiel nur eine Illustration. Das ist Produkt eins, Produkt zwei, Produkt drei, alle diese Produkte befinden sich auf demselben Board, und jetzt nehmen Vertreter der verschiedenen Produkte an unserem Stand-up-Meeting teil, nehmen an unserer Retrospektive teil, und wir können die Arbeit über die Produkte hinweg koordinieren. Also noch einmal, es geht nicht so sehr um das Board. Es geht mehr um die Interaktion, die vor dem Vorstand stattfindet. Ja, und das ist es, was wir im Grunde getan haben, um das Problem dieser Abhängigkeiten zu überwinden. Wir haben uns also von der Organisationsstruktur gelöst und uns auf das konzentriert, was für den Kunden interessant ist, nämlich die Wertschöpfung, in diesem Fall waren es Produkte und Werbetafeln, bei denen wir die Abhängigkeiten und alles über die Produkte, über die Teams hinweg verwalten konnten, Punkt Nummer eins.
Was haben wir gemacht? Was war die Lösung für Punkt Nummer zwei? Erinnern Sie sich, das war diese riesige Tafel, dieser riesige Prozess, der immer größer und größer und größer und größer wurde. Nun, die Lösung ist einfach. Wenn ich sie Ihnen einfach präsentiere. Aber am Ende sprachen wir über eineinhalb, fast zwei Jahre Veränderungsprozess, um an diesen Punkt zu gelangen. Also, die Lösung sieht am Ende so aus. Wir haben den Upstream irgendwie vereinfacht. Denken Sie daran, dass wir hier nicht so viele Schritte haben, bevor die Leute tatsächlich mit der eigentlichen Arbeit beginnen. Wir fahren also nur noch ein grobes Konzept, das auf die Freigabe wartet. Und, ja, wir können schon anfangen zu arbeiten. Und wir haben die Wirtschaft mit ins Boot geholt. Was bedeutet es, wenn ich sage, wir haben die Wirtschaft mit ins Boot geholt? Nun, das war eine ziemlich traditionelle Organisation, und sie waren wirklich wie ein Silo, wie, es gibt das Business und es gibt die IT. Und aus der Sicht des Business ist die IT nur Kosten.
Es ist also besser, mit diesen Leuten nicht zu reden. Die eigentliche Herausforderung bestand also darin, sie irgendwie zusammenzubringen, damit wir den gesamten Wertstrom verwalten konnten. Und, was wir auch taten, also erinnern Sie sich, dieser Genehmigungsprozess wurde nur einmal im Jahr ausgelöst, wir verkürzten dies auf zweiwöchentlich, jede zweite Woche, konnten wir neue Arbeit beginnen. Normalerweise ist das Starten neuer Arbeit kein großes Problem in Organisationen. Aber der Punkt ist, dass wir den Arbeitsprozess hier eingeschränkt haben. Wir konnten also nur mit neuer Arbeit beginnen, wenn die laufende Arbeit beendet war. Und auch hier haben wir tatsächliche Interaktionen etabliert, d.h. wir haben Stand-up-Meetings und Retrospektiven durchgeführt und die Unternehmen dazu eingeladen. Wir haben also keine neuen Meetings erfunden, die Meetings waren schon lieb, aber das Geschäft war Teil davon.
In Ordnung, ich habe noch eine Lösung und dann bin ich auch schon fertig. Also, was haben wir mit der Strategie gemacht? Nun, erinnern Sie sich, es war dieser seltsame, rückwärts gerichtete Mapping-Prozess. Also, der erste Schritt, den wir versucht haben zu etablieren, Vorwärts-Mapping-Prozess. Das heißt, es gab eine Strategie. Und basierend auf der Strategie, was wir taten, ist, dass wir Ergebnisse und Aktionen aus der Strategie ableiteten. Das heißt, die Strategie löste im Grunde eine Konversation aus: Was wollen wir erreichen? Und was müssen wir tun, um dorthin zu gelangen, richtig? Das wurde also aus der Strategie abgeleitet. Dann haben wir die Ergebnisse gemessen, dass wir erreicht haben, was wir erreichen wollten. Und das löste natürlich den Lernprozess aus, der die Strategie verfeinerte. Das war also die Denkweise. Und im Grunde haben wir das alles irgendwie auf einer Tafel abgebildet. Und das war unsere Strategietafel. Wir haben also diese strategischen Punkte, richtig? Wie, Sie wissen schon, drei bis fünf Jahre lang, wie, Digitalisierung und einige kulturelle Themen, und so weiter.
Und was wir gemacht haben, wir haben im Grunde Ergebnisse definiert, was wir innerhalb des Jahres erreichen wollen. Also haben wir den Trichter eingegrenzt. Dann, wenn wir diese Ergebnisse für ein Jahr haben, sind wir noch einen Schritt weiter gegangen, wie, und was bedeutet das für die nächsten 90 Tage? Wir haben also messbare Ergebnisse für die nächsten 90 Tage. Wir haben also einen Fokus über die Zeitachse geschaffen, 3 bis 5 Jahre, 1 Jahr, 90 Tage. Man muss sich also wirklich darauf konzentrieren. Es ist ziemlich schwer, Fünf-Jahres-Projekte zu priorisieren. Ist dieses Fünf-Jahres-Projekt wichtiger als das andere? Nun, ich weiß es nicht. Wir müssen sie alle nach fünf Jahren abschließen. Aber wenn man es irgendwie eingrenzt, kann man einen Fokus schaffen. Und wenn wir so etwas hätten, würden wir daraus Aktionen ableiten. Und wenn ich so etwas sehe, dann sehe ich schon das Strategieboard. Im Endeffekt ist es ganz einfach. Wir müssen nur ein paar Zeilen hinzufügen, und ein paar andere Zeilen entfernen. Und das war mehr oder weniger die Strategietafel, mit der wir angefangen haben zu arbeiten.
Wir haben hier also unsere Ergebnisse, die jährlichen Ergebnisse, und wir haben eine Skala von 0% bis 100%, auf der wir sehen können, ob wir Fortschritte machen. Und hier haben wir nur eine sehr vereinfachte Version des Boards, eines Boards, der Aktionen und das ist, was wir tun. Und der Punkt ist, wir haben hier den Fokus geschaffen. Das heißt also, wir haben den Fokus geschaffen in Bezug auf die Eingrenzung des Zeittrichters, und dann brauchen wir alle die richtigen Stück-Aktionen, die wirklich einige Ergebnisse innerhalb der nächsten 90 Tage erzielen. Das war das Strategie-Board. Und natürlich haben wir mit einem solchen Strategie-Board auch Stand-up-Meetings durchgeführt. Und wir haben auch Retrospektiven an diesem Brett durchgeführt. Das waren also im Grunde die drei Probleme und die Lösungen, die wir uns ausgedacht haben. Und wir werden irgendwie reflektieren, was wir gemacht haben. Eine Sache wurde ... eine Sache ... ich höre Stimmen, ich weiß nicht, ob das ein guter Zeitpunkt ist.
Eine Sache ist, wenn ich das Fazit ziehe, dass, na ja, Business Agility ist definitiv kein Mannschaftssport. Wenn es um Business Agility geht, dann ist es ein Unternehmenssport, man muss wirklich das ganze Unternehmen denken. Und Sohrab hat ja schon von Flight Levels gesprochen. Und ich gebe Ihnen noch eine Minute, weil ich denke, wenn wir von Betriebssport sprechen, was bedeutet das? Also wo in einer Organisation, können wir Verbesserungen machen? Wo müssen wir agil werden? Und genau darum geht es bei Flight Levels. Also für mich ist Flight Levels ein Denkmodell, das mir hilft zu verstehen, wo in einer Organisation muss ich was tun, um das zu erreichen, was ich erreichen will. Flight Levels ist also ein Begriff aus der Luftfahrt, man kann tief fliegen, oder man kann sehr hoch fliegen. Je nachdem, auf welcher Ebene man fliegt, sieht man unterschiedliche Dinge. Wir können in einer Organisation sehr niedrig fliegen.
Gleiche immer die Flughöhe an!
Wenn wir in einer Organisation niedrig fliegen, befinden wir uns auf Flight Level One und Flight Level One ist die operative Ebene. Die Teams, die Teams, die wirklich die Arbeit machen, wir können unsere Teams agil machen. Normalerweise hat eine Organisation mehr als nur ein Team, also sehen wir mehrere Flight-Level-One-Systeme in einer Organisation. Was wir auch sehr oft sehen, ist, dass ein Team allein nicht in der Lage ist, den Markt zu beliefern. Wir brauchen also eine Koordination zwischen mehreren Teams, um den Markt zu beliefern. Das bedeutet also, dass wir ein bisschen höher fliegen müssen. Wenn wir ein bisschen höher fliegen, ist das Fluglevel zwei, die End-to-End-Koordination. Das ist also die Welt der Produkte, der Dienstleistungen und so weiter. Was wir also tun werden, oder was wir hier tun, ist, wir stellen sicher, dass das richtige Team zur richtigen Zeit an den richtigen Dingen arbeitet. So können wir die Flugstufe zwei mit der Flugstufe eins verbinden. Die operative Arbeit wird auf Flug-Ebene eins erledigt. Und hier koordinieren wir nur, dass das richtige Team zur richtigen Zeit an den richtigen Dingen arbeitet.
Und das Sexy daran ist, dass es mir aus Sicht der Flugebene zwei egal ist, welche Methoden in den Teams gemacht werden. Also könnten Teams mit, ich weiß nicht, mit Scrum arbeiten oder Teams könnten mit Kanban arbeiten oder Teams könnten einfach nur arbeiten, das ist auch in Ordnung, oder? Stellen Sie also einfach sicher, dass das richtige Team zur richtigen Zeit an den richtigen Dingen arbeitet. Normalerweise hat eine Organisation mehr als nur ein Produkt oder eine Dienstleistung, also sehen wir mehrere Flight-Level-Two-Systeme in einer Organisation. Wenn wir Abhängigkeiten zwischen diesen Flight-Level-Two-Systemen haben, können wir ein operatives Portfolio aufbauen. Aber das ist immer noch ein Flight-Level-2-System, weil wir die Arbeit über mehrere Produkte oder Services hinweg koordinieren. Und wir können sogar noch eine Ebene höher fliegen, und das ist die Strategieebene.
Die Idee der Strategieebene ist, dass wir die Arbeit in unserer Organisation an der Strategie ausrichten, die wir auch hier auf der Strategieebene in den Fokus stellen. Natürlich können wir die Flugebene drei und die Flugebene zwei verbinden, und auch die Flugebene drei und die Flugebene eins. Und meistens haben wir nicht nur ein Strategieboard in einer Organisation, sondern wir haben mehrere Strategieboards in einer Organisation. Ja. Und das sind im Grunde die Flugebenen. Und eine Sache ist hier wichtig, es geht nicht um besser oder schlechter. Fluglevel drei ist also nicht dreimal besser als Fluglevel eins, sondern löst ein anderes Problem, richtig? Wenn Ihre Teams nicht liefern, können Sie hier oben die besten Entscheidungen treffen und den Fokus und alles auf Flug-Ebene drei schaffen, die Dinge werden trotzdem nicht geliefert, richtig? Es geht also nicht um besser oder schlechter, es geht darum, die richtigen Hebel zu finden, die man in seiner Organisation ziehen kann.
Und das ist im Grunde alles. Wenn Sie sich für mehr Dinge auf der Flugebene interessieren, wir haben einen Stand hier, Catherine, Cliff und ich werden etwas später dort sein. Und wir haben natürlich auch Workshops, die Sie besuchen können. Wenn Sie auf flightlevelsacademy.com gehen, sehen Sie die Auflistung aller Workshops oder die Auflistung der Workshops. Und was wir tun, ist, dass wir im Grunde genommen darüber sprechen, als ich in dieser Präsentation gesprochen habe. Das war's. Danke für's zuhören.
Sociocracy 3.0
=> James Priest & Jeff Cumps sprechen über [Sociocracy 3.0](/de/organisationsentwicklung/sociocracy-3-0-james-priest-jeff-cumps/ "Sociocracy 3.0)
Das agile Ministerium
=> Wie agil sind die deutschen Ministerien? - Ein Interview mit Sebnem Andresen.
Der Vorteil von Unternehmen, die experimentieren
=> Lerne, was passiert, wenn dein Unternehmen experimentiert!