Zu Gast habe ich Lukas Schmidt. Lukas ist Enterprise Kanban Coach bei der Deutschen Telekom. Wir sprechen über das Thema „Skalierung von DevOps mit Flight Levels“. Erfunden hat das Thema Klaus Leopold aus Wien. Ein wichtiger Punkt für das Verständnis der Flight Levels ist: „Ob man hoch oder tief fliegt inkludiert keine Wertung.“ Weitere interessante Erklärungen und Erfahrungen aus der Praxis sind in der Episode zu hören.
In dieser Episode spricht Dierk Söllner, ein DevOps-Coach und Trainer, mit Lukas Schmidt, einem Enterprise Kanban Coach bei der Deutschen Telekom, über die Skalierung von DevOps mit Hilfe von Flight Levels. Sie erörtern, wie Flight Levels dabei helfen, Teamanstrengungen mit dem Kundenwert zu verknüpfen, die Koordination zwischen Teams zu erleichtern und einen Rahmen für strategische Entscheidungsfindung zu bieten. Sie diskutieren den Unterschied zwischen Flight Levels und hierarchischen Ebenen und betonen die Rolle von Flight Levels bei der Verbesserung von Agilität, Transparenz und Zusammenarbeit auf verschiedenen organisatorischen Ebenen. Das Gespräch behandelt auch die praktische Anwendung von Flight Levels bei der Deutschen Telekom und illustriert deren Auswirkungen auf große IT-Organisationen.
Inhalt
- Einleitung zum Podcast und den Gästen.
- Rolle eines Enterprise Kanban Coachs bei der Deutschen Telekom.
- Bedeutung von Kommunikation und Interaktion in DevOps und Kanban.
- Definition und persönliche Perspektive auf DevOps.
- Herausforderungen im Management komplexer IT-Systeme in großen Organisationen wie der Deutschen Telekom.
- Einführung in Flight Levels und deren Rolle bei der organisatorischen Zusammenarbeit.
- Das Verhältnis zwischen Flight Levels und Kanban.
- Detaillierte Diskussion über die drei Ebenen von Flight Levels:
- Ebene 1: Wertschöpfung auf Teamebene.
- Ebene 2: Zwischenteam-Koordination und -Kollaboration.
- Ebene 3: Strategische Entscheidungsfindung und Ausrichtung auf den Kundenwert.
- Praktische Anwendung und Vorteile von Flight Levels in großen IT-Organisationen.
- Die Wichtigkeit der Visualisierung von Arbeitsprozessen auf allen Ebenen.
- Missverständnisse über Flight Levels und hierarchische Ebenen.
- Einstieg in Flight Levels in einer Organisation.
- Flight Levels als Werkzeug zum Verständnis und zur Verbesserung des organisatorischen Arbeitsflusses.
- Rolle von Coaches bei der Einführung von Flight Levels.
- Abschließende Gedanken zur Flexibilität und Anpassungsfähigkeit von Flight Levels.
Shownotes
Flight Levels kurz beschrieben
Sind die Flight Levels das Shu, Ha oder Ri der Agilität – oder ist das die falsche Frage?
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dirk Söllner.
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps. Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begleite Unternehmen auf dem Weg zu einer hochperformanten
IT-Organisation. Als Trainer und Coach mache ich Teams und Menschen erfolgreich, um die
aktuellen Herausforderungen bewältigen zu können. Ich bringe meine Tätigkeit neben
der persönlichen Coaching-Kompetenz eine breite und langjährige Fachkompetenz ein.
Ich freue mich heute auf das Thema Skalierung von DevOps mit Flight Levels. Zu Gast habe
ich Lukas Schmidt. Lukas ist Enterprise Kanban-Coach bei der Deutschen Telekom. Alles weitere dazu
später von ihm persönlich. Aus meiner Sicht ist DevOps ein teamorientierter Ansatz.
Das heißt, die DevOps-Teams sind ein wesentlicher Bestandteil des Ansatzes von DevOps. Interessant
ist dabei für mich dann auch in der Praxis häufig die Frage, wie man die Zusammenarbeit
zwischen den Teams und bei übergreifenden Fragen organisieren kann. Da ich auch ein Freund von
Kanban bin, möchte ich heute darüber sprechen, wie Kanban für diese Herausforderung genutzt
werden kann. Hallo Lukas, herzlich willkommen und vielen Dank, dass du dabei bist. Was macht
ein Enterprise Kanban-Coach bei der Telekom?
Vielen Dank für die Einladung. Unsere Frauen, die sagen immer, das, was wir da machen, das
ist eigentlich nur gesunder Menschenverstand. Aber ich würde sagen, das tut so einer Firma
wie der Telekom echt gut. Also die meiste Zeit verbringen wir mit Menschen, die irgendwie
Verantwortung für irgendeinen Service für unsere Kunden tragen. Die wollen mehr Verständnis
dafür bekommen, wie wir Mehrwert für die Kunden liefern können. Das hat eigentlich
viel mit individuellem Coaching zu tun, aber auch mit der Vermittlung von Wissen, zum Beispiel
in Trainings.
Okay. Du hast davon gesprochen, individuelles Coaching. Das klingt für mich so, als ob
es da gar nicht um Fachkompetenzen geht. Ist das richtig?
Naja, also Fachkompetenzen sind schon sehr wichtig. Aber es geht auch darum, wie Menschen
miteinander zusammenarbeiten, also Interaktion und Kommunikation. Und das ist heutzutage
extrem wichtig.
Okay. Das hast du vom gesunden Menschenverstand gesprochen. Das Wort, Abkürzung GMZ, habe
ich auch schon häufiger benutzt. Habe ich auch in einem Buch mal erwähnt, ein Artikel
dazu, der gesunde Menschenverstand hilft. Darauf wollte ich so ein bisschen nochmal
eingehen, wenn du sagst gesunder Menschenverstand. Also letzten Endes, natürlich ist die Fachkompetenz
wichtig. Wie würdest du aber den Anteil beziffern, wenn man das kann?
Wie viel Anteil deiner Arbeit gesunder Menschenverstand ist? Also einfach nur mit den Leuten reden,
ihnen zuhören und ihnen Tipps geben, Anregungen geben?
Also es ist schon ein großer Anteil. Also die Schwierigkeit, die wir haben, ist viel
von dem, was wir empfinden. Das ist so ein Bauchgefühl. Also wir müssen relativ schnell
entscheiden. Das sind die meisten Entscheidungen, die wir treffen im Leben. Und das Problem
ist, würden wir uns mehr Zeit dafür nehmen, würden wir ganz anders.
Entscheiden. Und da ist es ganz, ganz wichtig, von außen eine Position zu haben,
die doch darauf hinweisen kann, dass solche Entscheidungen
ganz, ganz wichtig sind. Okay, also außen quasi der
externe Blick auf das Team dann jeweils oder auf die Menschen, die du unterstützt. Genau. Also wir
machen sehr viel individuelles Coaching. Der Coachee sucht sich bei uns den Coach aus. Also wir müssen
von vornherein ein gutes Verhältnis zueinander haben, was ich grundsätzlich ablehnen würde,
ist, wenn mir jemand sagen würde, da ist jetzt jemand, da gehst du hin, da musst du
helfen. Ich glaube, das ist eine Situation, die ist schwierig, die wird nicht funktionieren.
Ja, ja. Coach den mal, der muss besser werden. Genau. Also ja. Auftragsklärung ist dann
schon geregelt, weil das wird so nicht funktionieren. Richtig. Ja, das stimme ich dir zu. Ja, ja.
Okay. Jetzt haben wir eben schon so über das Menschenbild gesprochen, über die Tätigkeiten
eines Enterprise. Kann man das? Ja, das kann man. Ja, das kann man. Ja, das kann man. Ja, das kann man.
Jetzt haben wir ja hier den DevOps-Podcast. Und da frage ich meine Gäste immer, wie sie persönlich
DevOps definieren können. Wie würdest du DevOps definieren? Also als ich damals mal zur Schule
gegangen bin, das ist schon eine Weile her, da habe ich mal so einen ganz dämlichen Satz gehört und
musste den auch so irgendwie verinnerlichen. Und der hieß Never Touch a Running System. Meistens
war es so, dass wir im Computerkabinett die Computer nicht anfassen durften, auf dem so
die wichtigen Sachen waren. Und da habe ich dann auch so einen ganz dämlichen Satz gehört. Und da
heute weiß ich, dass das Gegenteil sinnvoll ist. Also Always Run a Changing System. Deswegen für
mich bedeutet DevOps eigentlich die Zusammenarbeit von der Entwicklung von den Produkten bis zum Ende
ihrer Anwendung bei den Kunden direkt. Und dabei ist aus meiner Sicht wichtig, durch kleine
Verbesserungen schnell Feedback zu bekommen und das Risiko für Ausfälle zu verringern. Und wenn
ich dann ein System habe, was so hart ist, dass egal, was ich da draufwerfe, ich dann auch so ein
System habe, das geht halt nicht kaputt, dann kann ich auch den Praktikanten ranlassen. Da gibt es
genug Firmen, die das mittlerweile schon so machen. Wenn ich Angst haben muss, dass, wenn ich nur ein
bisschen antippe, das System komplett zusammenbricht, dann habe ich grundsätzlich was falsch gemacht.
Okay, nun weiß ich aus meinen Schulungen bei der Telekom, das wird aber nicht nur bei der Telekom
so sein, dass es ja auch noch einen Haufen Systeme gibt, die genau aber noch so komplex oder
kompliziert sind, so viele Systeme, die man nicht so gut kann, die man nicht so gut kann, die man nicht so
gut kann, die man nicht so gut kann, die man nicht so gut kann, die man nicht so gut kann, die man nicht so gut kann.
Und wenn wir dann so viele Verwebungen in andere Systeme haben, dass das wahrscheinlich da technisch
gesehen eine Herausforderung ist, das umzusetzen, was du eben gesagt hast.
Selbstverständlich. Also wir haben einige tausend IT-Systeme bei uns in der Telekom und das ist eine
riesengroße Herausforderung. Insbesondere deswegen ist es ganz wichtig, dass wir schaffen, dass die
Menschen, die die Verantwortung dafür tragen, gut miteinander zusammenarbeiten können und
gemeinschaftlich Entscheidungen treffen können, dass wir eben in solche Probleme nicht reinlaufen.
Mhm.
Ja, okay. Insofern ist natürlich Fachkompetenz als Coach wichtig, aber auch die entsprechende Empathie.
Ganz richtig.
Sehr schön. Wir haben heute das Thema Skalierung von DevOps mit Flight Levels. Was sind Flight Levels?
Kannst du da vielleicht mal ganz kurz zum Einstieg einen Überblick geben?
Ja. Also Flight Levels sind eine Form der Darstellung von, ich würde sagen, Zusammenarbeit in einem
Unternehmen. Sie helfen den Menschen, ein gemeinsames Verständnis dafür zu bekommen, wie wertvoll
Kunden geschaffen wird. Erfunden hat das der Klaus Leopold aus Wien.
Ja, der Klaus Leopold ist ja bekannt für seine vielen Bücher und für seine Arbeit an dem Thema
Kanban. Wie sind denn dann die Flight Levels entstanden? Also ist das jetzt dann wieder ein
neues Framework, eine neue Methode, die wir quasi auf Kanban aufsetzen oder die Klaus Leopold auf
Kanban aufgesetzt hat?
Also der Klaus hat über Jahre Kanban, ich würde sagen, in Europa so eine richtig
tolle Sache gemacht. Und ich selbst habe an Kanban-Trainings vom Klaus teilgenommen und das waren
unfassbare Erlebnisse. Und irgendwann ist der Klaus zu der Erkenntnis gekommen, dass Kanban sowohl auf
Team-Ebene als auch teamübergreifend funktioniert. Und da versuchte der, dieses Learning irgendwie zu
formalisieren. Und er hat in ganz vielen Firmen angefangen, genau sowas schon einzubringen. Und so
sind die Flight Levels entstanden. Je nachdem, wie hoch man fliegt, sieht man verschiedene
Dinge. Fliegt man tief, sieht man viele Details, aber dafür
nicht sehr weit. Fliegt man jetzt hoch, hat man einen guten Rundumblick,
aber die Details gehen verloren. Der wichtige Punkt für das Verständnis von
Flight Levels ist aber, ob man hoch oder tief fliegt, inkludiert
keine Wertung. Also nicht, weil ich jetzt ein großes oder hohes
Flight Level habe, ist es besser als ein mittleres oder kleines. Jedes ist
wichtig für sich genommen.
Okay. Wenn ich daran mal kurz einhabe,
Hake, das heißt also, jetzt mal ganz banal gesprochen, der Vorstand eines Unternehmens
könnte dann auch mit einem sehr hohen Flight Level Kanban nutzen. Habt ihr das richtig
verstanden? Flight Level Modell ist grundsätzlich methodenagnostisch. Das ist mal aus den
Kanban-Gedanken entstanden. Aber mittlerweile ist es so, dass jeder grundsätzlich eingeladen
ist, seinen Kopf einzuschalten und damit sinnvolle Dinge zu entwickeln. Also Denken ist grundsätzlich
und ausdrücklich erlaubt. Man kann ganz viele Dinge mit
Flight Levels umsetzen.
Okay, aber wenn ich jetzt diesen Rundumblick
sehe oder mir das so vorstelle, das ist jemand, der in einer
Organisationshierarchie quasi weiter oben steht. Das ist auch keine Wertung,
da stimme ich euch zu von der Einschätzung her. Es ist aber
eben quasi in der Hierarchie weiter oben angesiedelt. Was ich
feststelle ist, bei vielen Unternehmen,
deswegen finde ich ja diese Idee, dass der
Flight Level so interessant,
dass quasi um Teams
herum alles
bleibt, wie es ist. Ich habe Prozesse,
ich habe Hierarchien, ich habe
lange Entscheidungswege und dann sage
ich immer nur, im Team, ihr müsst
agiler oder schneller werden. Also da fällt
nochmal die Frage,
wäre es denn denkbar oder habe ich es richtig verstanden,
dass ich mit den Flight Levels wirklich auch
auf einer ganz oberen Ebene
mit Kanban-Prinzipien
arbeite?
Ein echt weit verbreitetes Anti-Pattern
ist die Meinung, das höchste Flight Level
ist das Senior Management,
auf dem mittleren Flight Level hat man so das
Mittelmanagement und ganz unten so die Teams
und Indianer. Das kann
so sein, wenn es die derzeitige
Organisationskultur so vorschreibt.
Flight Levels sagen aber eigentlich nicht
so viel darüber,
dass das so ist.
Es ist eher so,
dass das untere Level das obere
baut und wir bauen
jetzt nicht Boards für die Leute,
sondern mit den Leuten. Und das ist ganz,
ganz wichtig. Also ohne, dass
die Menschen da
involviert werden und dass sie sich einbringen,
wird es grundsätzlich nicht funktionieren.
Okay.
Kann ich mir so ein bisschen
vorstellen, wenn wir jetzt
mal auf Flight Levels gucken,
da würde ich jetzt ja verschiedene Level erwarten,
das hast du ja eben auch gerade gesagt.
Level 1 wird dann
wahrscheinlich quasi unten sein, aber
bitte unten in Anführungsstrichen. Das hört man
jetzt nicht, aber ich würde es in Anführungsstriche setzen.
Okay. Was passiert auf dem Level
1? Auf Flight Level 1, da wird
Wert geschaffen. Die Experten auf
dieser Ebene entscheiden gemeinsam, wie etwas
Wertvolles für den Kunden geschaffen wird.
Okay, das heißt
in meinem Verständnis, das wären die
DevOps-Teams zum Beispiel.
Zum Beispiel, ob die jetzt DevOps machen,
ob die Scrum machen, ob die Kanban machen
oder XP oder einfach arbeiten,
das ist mir persönlich völlig egal.
Die schaffen Wert
und die sind erwachsen und
soweit die wissen,
was wir,
was wir wollen, dann können die sich
auch selbst organisieren.
Okay. Ah, du hast
einen guten Satz gesagt. Sie machen Scrum, Kanban
oder sie arbeiten einfach nur. Ich glaube, das
wird sich manch einer rausziehen
als Zitat aus diesem Podcast.
Wir machen
Scrum, Kanban oder wir arbeiten einfach nur.
Das können sie gerne machen, da stehe
ich voll dahinter. Ja, klar.
Wir werden sehen, warum das so ist.
Ja, ich glaube auch, dass
die Aussage dahinter,
da würde ich auch zustimmen. Also letzten Endes,
genau diese Ebene
eins ist die Ebene, wo eben, wie du das
sagst, wo Wert geschaffen wird, wo
quasi operativ gearbeitet wird
und egal, wie sich dann, also
wenn ich Teams habe, egal, wie sich diese Teams,
Gruppen oder Abteilungen organisieren,
das ist der Flight Level, auf dem
dort eben der Wert geschaffen wird.
Mhm.
Wenn dann, da kommt
der Level zwei wahrscheinlich, ganz logisch
und von der Sortierung her.
Was passiert dann auf der Ebene zwei, auf dem
Flight Level zwei? Also auf Flight Level
zwei geht es darum, dass die richtigen
Leute zur richtigen Zeit an den richtigen
Dingen arbeiten. Der
Russell Eckhoff, der hat uns
gelehrt, a system is never a sum of
its parts, it’s a product
of the interaction of its parts.
Das heißt, es bringt uns überhaupt
nichts, so ganz viele kleine, agile
Inselchen zu haben. Was wir
brauchen, sind agile Interaktionen in
einem Unternehmen und genau dafür
ist das Flight Level zwei gedacht.
Okay,
das heißt, Flight Level eins, eben
da, wo die Arbeit getan wird, da, wo
Wert geschafft wird und
das wäre ja an sich jetzt noch nichts Besonderes
wahrscheinlich, aber durch diesen Level
zwei komme ich quasi jetzt eine Ebene höher
und wie du vorhin auch sagtest, ich baue ja von
unten nach oben auf, also von Ebene eins
auf Ebene zwei.
Wie ist denn
da quasi so eine Übergabe, also
dass die Ebene eins
macht irgendwas mit Flight Leveln und
sagt irgendwie, ja, jetzt brauchen wir
Flight Level zwei darüber. Wie kann ich mir
das vorstellen?
Also das Flight Level drei,
was da drüber folgt,
das ist der Weg, wenn wir von oben
gehen, von der Vision über die
Strategie hin zur Priorisierung
von konkreten Aktionen.
Also wir setzen bei der Strategie an
und machen den zeitlichen Trichter zu.
Würden wir immer in fünf Jahresinitiativen
denken, wäre alles wichtig grundsätzlich.
Wir hatten einen Riesenhaufen von Dingen
und ja, das ist
unfassbar schwierig, sich da wirklich zu
fokussieren. Die Frage auf Flight Level
drei ist nun, was können wir im
nächsten Jahr erreichen? Und da geht es wirklich um
Outcome und nicht Output. Weil nur,
weil wir irgendwas am Ende auf die Straße
bringen, heißt es noch nicht, dass wir davon
irgendwas haben. Und
was davon eigentlich wirklich in den
nächsten drei Monaten? Und was wir dann
machen wollen, ist, dass wir jetzt nicht
irgendwie drei Monate warten und dann gucken,
was ist passiert, sondern wir treffen uns wirklich
vielleicht alle zwei, drei Wochen mal
und gucken uns die Strategie an. Das ist
ja total irre. Und
um mal ein Beispiel zu bringen,
wie man das Ganze miteinander verbindet,
also Flight Level drei nimmt die Strategie
auf und die bricht die
Ziele runter und die sind dann wirklich
greifbar. Ich habe dann was in der Hand
und da geht es wirklich ums
Begreifen. Das heißt, für mich ist es auch ganz
wichtig, dass wir wirklich etwas
nehmen können und miteinander vergleichen
können. Und wenn ich bei unseren Trainings
das mal veranschaulichen
möchte, dann nehme ich zwei unterschiedlich
farbige Post-its, nehme die in die Hand
und sage, grün oder
blau, grün oder blau, grün oder blau,
was ist es jetzt? Und dann
muss man sich wirklich aktiv entscheiden.
Also was wir dann machen, ist, wir
nageln so faktisch den
wackeligen Pudding der Unklarheit an die Wand
und wollen uns jetzt
gemeinschaftlich entscheiden,
was wir tun.
Und diese Ziele, die werden dann auf Flight Level zwei
aufgenommen und in operative
Teile übersetzt und so weit
runtergebrochen, dass ein Team
auf Flight Level eins irgendwas in der Hand hat,
was verstanden wird. Zum Beispiel
kann das ein Epic sein. Das wird
natürlich nicht für die Teams heruntergebrochen,
sondern hoffentlich mit den Teams.
Ein weitverbreitetes Anti-Pattern,
wie ich schon sagte, ist,
es gibt irgendwo die
ranghohen Manager
in der Vorstandsebene,
die überlegen sich was und das
muss dann ganz genau gemacht werden.
Ganz genau das Gegenteil ist der Fall.
Ich muss schon mit den Menschen arbeiten
zusammen, die das
am Ende wirklich entwickeln. Wenn ich einfach
etwas vor die Nase setze, dann wird das
grundsätzlich nicht funktionieren.
Okay.
Flight Level drei, gibt es noch irgendwas
darüber oder ist da jetzt Schluss?
Also was wir schon haben können, ist,
dass wir in einem Unternehmen
mehrere strategische Portfolios
haben. Also wenn ich eine Firma habe, wie
die Deutsche Telekom,
die hat mehrere strategische Portfolios,
weil sie auch unterschiedliche
Kundengruppen bedient.
Was ich auch haben kann in Flight Level
zwei ist Hierarchie. Also es kann sein,
dass mehrere Flight Level Systeme miteinander
interagieren. Grundsätzlich Flight Level
zwei ist so,
da geht es um Koordination und
ich kann aber auch unterschiedliche miteinander
koordinierte Systeme miteinander
verbinden, je nachdem, ob das so sinnvoll
ist und wie der Kontext
das verlangt.
Okay. Das heißt, wenn ich mir
das jetzt so vorstelle,
Flight Level drei, also die
Ebene mit dem weitesten
Blick und den wenigsten Details,
da gibt es verschiedene
Gruppen, du hast es auch gesagt,
Telekom, viele Kundengruppen, deswegen dort
auch wahrscheinlich verschiedene
Bereiche, in denen
auf dem Flight Level drei gearbeitet wird.
Das wird dann quasi auf das
Flight Level zwei gegeben, um das
dann zu übersetzen, um das ein bisschen
konkreter
zu fassen, wobei übergeben ist ja Quatsch,
du hast ja gesagt, einbeziehen, also da muss
ich ja dann die Schnittstelle dann
definieren. Ganz richtig.
Okay, gut. So und dann
ist die Ebene zwei immer auch
vielfältig und
ich stelle mir das jetzt gerade so vor,
und das, was
für mich ja wichtig war und wichtig ist,
ist die Erkenntnis oder
der Anti-Pattern, was du sagst,
dass man diese Flight Levels eben nicht
mit Hierarchie-Ebenen
gleichsetzen muss. Das kann man,
muss man aber nicht. Also es geht darum ja wirklich,
sich das virtuell
quasi vorzustellen. Das heißt also
verschiedene Flight Level zwei
Bereiche arbeiten dann zusammen,
aus verschiedenen Flight Level drei etwas
runterzubrechen.
Wenn ich mir das
jetzt für die Telekom mal
vorstelle,
ist wahrscheinlich eine sehr
anspruchsvolle Tätigkeit auf der Ebene
zwei, vielleicht aus verschiedenen
Level drei Vorgaben
oder Informationen, was zu
bauen, richtig?
Also je nachdem, wie
das implementiert ist, kann es
natürlich so sein, dass eine
Koordinationsebene aus mehreren
strategischen Portfolios
Arbeit bekommt.
Und was ich bisher
gesehen habe, ist, dass es
eine
Ebene mit einem strategischen
Portfolio gibt und dass dann das
Ganze auf Level zwei
operationalisiert wird.
Also wir haben uns entschieden, was wir tun wollen.
Wir haben auch das soweit
qualifiziert, dass wir auch sagen können,
okay, wir können grundsätzlich mit der Arbeit
beginnen und auf Flight Level zwei
ist es dann so, dass wir uns überlegen müssen,
wer arbeitet jetzt gemeinsam
daran, dass wir diesen Wert schaffen
können. Und da wollen wir uns gemeinschaftlich
koordinieren, um das hinzubekommen.
Und was wir dann
grundsätzlich immer wieder gemacht
haben, ist, dass wir mit Menschen
zusammengearbeitet haben, die genau das
tun. Also ich habe
irgendjemanden, der eine Verantwortung
hat für ein größeres Portfolio
und jetzt muss entschieden werden, okay,
was mache ich jetzt damit?
Also wie entscheide ich, was ist das
wirklich Wichtigste zu tun als nächstes
und wie schaffe ich es, dass die wirklich
ausführenden
Menschen, die den Wert schaffen,
sich so koordinieren können, dass es
am Ende sinnvoll ist und
dass wir schnellstmöglich davon lernen
können, was wir da eingebracht
haben. Okay,
das heißt aber, wenn ich das richtig verstanden habe,
ist es so, dass auf dem Level drei
auch kurzfristig
gearbeitet wird und die Strategie
eben immer wieder kurzfristig überprüft
wird. Also ich habe nicht einmal im Jahr ein Strategie-Meeting,
wo ein Papier erzeugt wird,
was einem ja wieder angeschaut wird, sondern
ich fange auf der Ebene
schon an, also quasi ganz oben
auf Flight Level drei mit dem weitesten
Blick, deswegen ja auch Strategie,
diese Strategie so zu operationalisieren,
dass ich sie
alle zwei, drei Wochen, manchmal auch alle
vier Wochen überprüfen und anpassen kann.
Zumindest ermöglicht es das,
ja. Je nachdem, wie sich das
entwickelt, habe ich die Chance,
darauf Einfluss zu nehmen und mir
zu überlegen, okay, wie richte ich mich aus?
Wenn ich auf einem See unterwegs bin
und ich habe relativ,
relativ wenig Sicht nach vorn,
dann muss ich auf Sicht fahren und gucken, wo die Steine
kommen. Und dann muss ich
mich relativ schnell entscheiden können, in welche
Richtung ich mich entwickle
und in welche Richtung ich mich
bewege. Und das ermöglicht das
auf jeden Fall. Und wir nutzen
Flight Levels jetzt seit Jahren für unsere
Common-Implementierung, also insbesondere
zwischen Flight Level eins und
Flight Level zwei und haben
jetzt seit einiger Zeit damit begonnen,
ganze Flight Level
System-Architekturen zu entwickeln und
sehen, das Angebot wird sehr gut angenommen
und die Nachfrage danach
sehen wir steigen.
Ja, okay. Aber wenn ich das richtig
verstanden habe, dieses Auf-Sicht-Fahren,
das ist ja das, was ich mit meiner,
mit meinen,
ich bin ja auf dem Flight Level eins
unterwegs in den Teams und dann
ist da ein anderer Punkt, ich sage, Auf-Sicht-Fahren,
Auf-Sicht-Entscheidungen treffen,
aber wenn ich das richtig verstanden habe, geht man
mit den Flight Levels,
ich sag mal, skaliert man das,
ist ja unser Thema auch, quasi auch nach
oben. Das heißt also, ich fahre auch bei der
Strategie Auf-Sicht.
Genau. Es wird ermöglicht,
wie ich mich dann entscheide,
das liegt natürlich noch in der Verantwortung
der Menschen.
Okay.
Das heißt, du hast eben schon gesagt,
dass ihr Flight Level
bei euch bei der Telekom nutzt.
Ich stelle mir das
sehr, sehr schwierig vor,
einen Tanker,
egal ob Telekom oder andere Unternehmen,
quasi zufällig,
zu flexibilisieren, zu agilisieren
und mit diesen Flight Levels zu arbeiten,
also Auf-Sicht zu fahren.
Wie sind so da deine Erfahrungen?
Also es hilft ganz
viel schon den Menschen
erstmal, ihr System besser zu
verstehen und das gemeinschaftlich
zu verstehen. Also was wir
oft gesehen haben, ist, dass die
Menschen ihre individuelle Wahrnehmung
haben und was
dann sehr hilft, ist, dass sie eine
gemeinschaftliche Wahrnehmung anfangen zu
entwickeln.
Das heißt, wir haben Menschen, die sind
in Arbeitssystemen,
die arbeiten seit vielen Jahren
zusammen und haben sich gemeinschaftlich
entwickelt und was wir
dann sehen ist,
dass die, wenn die ihre Systeme
anfangen zu visualisieren,
auch völlig unterschiedliches
Verständnis einbringen und das
das erste Mal schaffen teilweise,
wirklich
detailliert ihr System
gemeinschaftlich zu begreifen
und dafür glaube ich,
hilft es, dass man wirklich
haptisch Dinge erfasst und
dafür nutzen wir ganz viele Mittel
wie Post-its oder Stifte
oder Klebeband,
mit denen man dann
seine Arbeitssysteme wirklich mal an der Wand
darstellen kann und
ich habe das vorher nie geglaubt, dass das so viel bringt,
aber dieses gemeinschaftliche
Verständnis zu bekommen, das ist ganz wichtig
und das ist extrem hilfreich
und wenn ich einmal einen gemeinschaftlichen
Blick auf so ein System habe,
dann kann ich eben diese
meaningful Conversations
pflegen, also diese bedeutungsvollen
Konversationen und da
rede ich dann jetzt nicht mal mehr über die Menschen
und der ist jetzt doof oder was,
was vielleicht passieren könnte,
sondern es geht darum, über die Arbeit zu sprechen
und sich darauf zu fokussieren.
Es ist ein riesengroßer Unterschied, ob ich
jetzt so ein Post-it
in der Hand habe, was Arbeit
symbolisiert oder, weil
ich nicht anders kann,
über die Arbeit eines Menschen
sprechen muss.
Ja, also das Thema
Visualisierung ist natürlich
ein ganz wichtiger Punkt.
Jetzt bei der Aufnahme von diesem Podcast haben wir ja
beide auch Bilder im Kopf, wie wir uns
das vorstellen, aber wir wissen ja nicht,
ob das die gleichen Bilder sind, die wir uns
jeweils entsprechend vorstellen.
Du hast eben gesagt, die Visualisierung,
wenn ich das
dann richtig verstehe,
das System der Flight Levels visualisiert
das dann auch auf allen drei Ebenen.
Also ich fange auch an, auf der Ebene 3
die Arbeit zu visualisieren.
Genau, richtig.
Und was ich dann schaffen kann, ist, dass ich nicht nur
die einzelnen Ebenen für sich visualisiere,
sondern auch die Verbindung zwischen den einzelnen
Ebenen visualisiere und
zeigen kann, wie sie ineinander übergehen
und wie Arbeit quasi durch
das gesamte
Unternehmen durchfließt.
Also der Fluss der Arbeit ist uns ganz wichtig,
dass wir dafür ein gutes Verständnis bekommen,
weil am Ende geht es ja auch darum,
das gemeinschaftlich zu verbessern.
Ja.
Wenn wir jetzt über das Thema
Skalierung reden und wie man die Flight Levels
dafür nutzen kann, der Fluss der Arbeit,
also mal idealerweise
habe ich ein Team, was
Ende-to-Ende-Verantwortung hat,
da fließt die Arbeit nur durch das Team durch.
Das ist ja ein hehres Ziel,
aber wahrscheinlich nicht nur bei der Telekom
praktisch erstmal unmöglich.
Also würde ich dann
den Flight Level 2 nutzen,
um den Fluss der Arbeit
an sich darzustellen,
um daraus einzelne
Flight Level 1 Teams
zu steuern?
Also grundsätzlich ist es so,
ich habe mal gehört, so ab 50 Menschen
in einem Unternehmen ist es fast
unmöglich, ohne Arbeitsteilung
zu arbeiten.
Und deswegen ist es so,
wir haben im Unternehmen
über
200.000 Mitarbeiter
und da ist es völlig normal,
dass es Arbeitsteilung gibt. Es gibt einfach
Bereiche, die haben
eine Verantwortung und es gibt ganz
viele IT-Systeme, die in Verantwortung
sind und da ist
Interaktion, Kommunikation
extrem wichtig und
in dem Moment, wo ich mir überlege,
dass ich etwas tun möchte, Wert schaffen möchte,
dann habe ich immer
bestimmte Gruppen oder bestimmte Menschen,
die irgendwie involviert sind
und das Flight Level 2,
das schafft es schon, dass ich da
gucken kann, okay, wie
koordinieren wir uns zusammen, dass wir
gemeinschaftlich den besten Wert schaffen
pro Kunde.
Okay, das heißt, kann ich mir das so vorstellen,
dass auf dem Flight Level 2 eben auch
die Arbeit dieses Flight Levels
visualisiert wird und damit kann ich
das ja auch dem Flight Level 1 erklären
und damit, denke ich, auch für viel
mehr Verständnis sorgen, was
auf dem Flight Level 2 passiert.
Also ich glaube nicht, dass ich das erkläre.
Was da passiert ist, dass die Menschen
von Flight Level 1 zusammenkommen
und das gemeinschaftlich tun.
Also es gibt niemanden, der
da in dieser Position ist,
aus meinem Verständnis heraus,
der das pflegt, sondern es sind die Menschen
aus den Teams, die gemeinschaftlich
sich über ein Flight Level 2
zusammen
koordinieren und da geht es wirklich
darum von, ich habe grundsätzlich verstanden,
was der Kunde will oder glaube es
verstanden zu haben, ist ja erstmal eine Hypothese,
bis ich kann prüfen, ob der Kunde
lächelt oder nicht, diese
gemeinschaftliche Koordination hinzubekommen.
Also Ende zu Ende.
Ja, also
was ich gerade
merke oder
lerne, ist, dass die
Flight Levels
sicherlich ein super Ansatz sind,
aber vielleicht nicht im ersten Schritt
einfach zu verstehen sind, wenn man
versucht, eine Organisation
darauf immer abzubilden. Also ich habe ja
als Titel haben wir ja
Skalierung von DevOps, das ist ja für mich
so die Idee gewesen oder
immer noch die Idee, ich nutze Flight Levels, um
Teams zu koordinieren.
Wenn ich aber das verstehe oder richtig
verstehe, was du sagst, geht es eigentlich
nicht darum, einzelnen Gruppen,
einzelnen Ebenen, ein
Flight Level zuzuordnen, sondern
eben Ende zu Ende zu gucken, aha,
das sind die Anforderungen des Kunden, wie
laufen diese Anforderungen durch unser
Unternehmen? Das mache
ich vielleicht auf dem Flight Level
3 oder 2,
aber ich arbeite eben gemeinsam
diesen Weg aus
von Mitgliedern
aus der Ebene 1. Also Ebene
1 setzt sich quasi zusammen
und baut den
Fluss durch die Ebene 2. Ist das
so ein richtiges Verständnis?
Ja, das geht
auf jeden Fall schon in die richtige Richtung.
Also grundsätzlich geht es mir nicht um die
Aufbauorganisation. Die Aufbauorganisation
ist eh so, dass sie sich über
Jahre immer wieder ändert und ich habe
kaum gesehen, dass dadurch
wirklicher Einfluss auf den Wert vor Kunde
genommen wurde. Hier geht es
um die Ablauforganisation. Also
wirklich, wie Arbeit
dazu beiträgt, gemeinschaftlich
Wert zu schaffen. Und natürlich
gibt es Menschen auf unterschiedlichen
Hierarchie-Ebenen, die daran mitarbeiten
wollen, dass wir Wert vor Kunde schaffen.
Aber manchmal ist
so eine Hierarchie-Ebene
und das, was wir am Ende an Wert schaffen
und so, wie wir uns
gerade organisiert haben,
das ist halt
vielleicht auch, naja,
das ist halt
unterschiedlich voneinander.
Am Ende geht es doch
darum, dass ich es irgendwie schaffe,
dass die richtigen Leute zur richtigen Zeit
die richtigen Dinge tun.
Also wer am Ende genau
das ausführt, das ist
auch nicht so wichtig.
Also wenn ich jetzt ein Buch bei Amazon bestelle,
dann ist
grundsätzlich meine Erwartung, dass ich das Buch
haben möchte. Wer bei Amazon
am Ende dafür sorgt, dass ich das Buch bekomme,
ist mir als Kunde vollkommen egal. Hauptsache,
die kriegen das irgendwie hin, dass ich
am Ende mein Buch auf dem Tisch liegen
habe zu Hause. Und das in der
angemessenen Zeit und die Qualität
und der Preis sollten stimmen.
Der Rest ist dem Kunden doch vollkommen egal.
Das heißt, wir müssen das schaffen,
dass wir genau eben diese Kundenerwartung
treffen. Und wer das dann am Ende
macht, ja, das sollten schon die richtigen
Leute sein. Und
ich vertraue darauf, dass die sich gut
organisieren können, wenn man ihnen
die richtigen Mittel in die Hand
gibt.
Okay. Und das
heißt, das, was du eben sagtest,
dass sich die Organisation
organisiert,
dem Kunden, dass der Kunde das Buch auf den
Tisch bekommt, das ist letzten Endes
eine Aufgabe der
Flight Levels. Also die Flight
Levels in ihren drei Ausprägungen
helfen genau diese
Organisation, die interne
Ablauforganisationen so zu gestalten, dass
das funktioniert. Also die Flight Levels sind
erstmal ein Denkmodell. Also die
helfen uns oder die laden uns ein,
dass wir diese ganzen Wertentstehungsinseln,
die wir in der Organisation haben, irgendwie
miteinander verbinden.
Und sobald die Leute
verstanden haben, was man damit machen kann,
haben sie auch die Möglichkeit, es zu nutzen,
um am Ende
für sich Mehrwert zu bekommen. Also
aus meiner Sicht ist das in keinster Weise
etwas, was ich
einbringen sollte, nur um Flight Level
zu tun, sondern wenn ich
eine Herausforderung habe,
dann kann ich das nutzen,
um für mich einen Vorteil zu haben.
Und wer das nutzen
möchte und für wen das einen Vorteil
bringt, der kann das machen
in dem Moment, wo er das verstanden hat.
Selbstverständlich.
Okay. Wenn ich mir jetzt
eine IT-Organisation vorstelle,
vielleicht nicht so groß wie die Telekom, aber eine
IT-Organisation, die sagt,
hey, das klingt gut, das möchten
wir machen. Also wie würde ich mir
jetzt sozusagen den Start vorstellen?
Wie startet man in die Arbeit mit
Flight Levels?
Also ich sage immer, man sollte die Hacke so hoch
wie möglich einschlagen.
Das heißt, nur so kleine
Implementierungen auf Flight
Level 1 sind für mich
lokale Optimierungen und die führen in den
allermeisten Fällen zu globaler
Suboptimierung. Von daher glaube ich,
dass es ein guter Weg ist, irgendwo
zwischen Flight Level 2 und 3
einzusteigen. Das heißt,
die Menschen zu involvieren, die
eine große Wirkbreite haben
mit dem, was sie tun
und mir genauso
zumindest einen von diesen größeren
Wertströmen mal rauszunehmen,
um daran mal zu schauen,
okay, wie können wir gemeinsam besser
vor Kunden arbeiten. Das heißt,
zu überlegen, okay, wie passiert
Arbeit derzeit bei uns
und wie können
wir am Ende dafür sorgen, dass wir mehrwertlich
Arbeit liefern. Und die Flight Levels, die setzen
auf ganz typische Kernpraktiken agilen
Arbeitens. Also Visualisierung,
Fokus setzen, agile Interaktion
und den Erfolg von dem
messen, was ich da tue.
Also Feedback Loops implementieren.
Und wenn wir das auf allen Ebenen tun und
konditionelle Verbesserungen anstreben,
dann sind wir schon echt weit vorne dabei.
Da geht es erst mal um Verständnis schaffen
und wenn ich das Verständnis habe,
habe ich eine Sprache, mit der ich zusammen
überlegen kann, okay,
wie setze ich das um.
Ja, okay. Das heißt, wenn du sagst,
auf Ebene, zwischen Ebene 2 und 3
quasi starten,
dann muss ich mir ja sehr gut Gedanken
machen, wen ich in diesen Start mit
hineinnehme, richtig? Genau.
Kannst du da so eine typische
Anzahl von Leuten
mal nennen, die da involviert
sind? Also das kann ich jetzt für mich, ich kann mir
das jetzt gar nicht so konkret vorstellen. Sind das 5,
sind das 10?
Gibt es da so Erfahrungswerte
aus deiner Arbeit? Ja, das ist natürlich
kontextabhängig, aber
wir hatten letztens einen Workshop
gemacht, zwei Tage,
neun Teilnehmer, da waren Menschen
in Verantwortung für das Arbeitssystem
drin, aber auch so
ein paar Leute
aus Fachbereichen, die
immer wieder Interaktionspartner
sind. Also die irgendwie
Abhängigkeiten zu den eigenen
Arbeitssystem haben, in dem Wert geschaffen
wird. Weil das Auflösen von
Abhängigkeiten und das
Arbeiten mit diesen Abhängigkeiten
ist sehr, sehr wichtig. Das heißt,
irgendwas in der Größenordnung so
naja, so irgendwas zwischen acht bis
zwölf Menschen ist das,
glaube ich, was man da
haben könnte an der Größenordnung.
Ja,
ich denke auch, dass das eine vernünftige Größe
ist und dann stelle ich vielleicht in so einem Workshop
fest, da habe ich noch ein paar
Abhängigkeiten, die ich vorher nicht beachtet habe,
die mir gar nicht bewusst waren. Da müsste
ich entweder kurzfristig jemanden dazu holen
oder das erstmal quasi
ausklammern und dann später nochmal
bearbeiten. Also genau
in so einem Workshop merkt man erstmal,
wie wenig man weiß
und worauf man aufsetzen
kann. Also am Anfang ist es
ja grundsätzlich so, dass wenn ich anfange
irgendetwas mir anzugucken,
dann ist das Bild, was ich habe, grundsätzlich falsch.
Und je näher ich mich
dem Nähere, was
wir an gemeinschaftlichem
Verständnis vielleicht aufbauen können,
je richtiger könnte das werden.
Und wenn wir da
zusätzliche Informationen bekommen, dann
sehen wir auch immer
klarer, wer
weitere Informationen reinbringen kann.
Und das hilft auf jeden Fall
besseres
Verständnis aufzubauen und
baut auch mögliche Spannungen ab.
Also wenn ich Verständnis habe
für etwas, ist es auch grundsätzlich so,
dass ich
gewisse
Schwierigkeiten, die
entstehen könnten, vermeiden kann.
Also je mehr ich darüber weiß,
je besser ist das
grundsätzlich für alle gemeinschaftlich.
Das stimmt. Und dann kommen wir
wieder zu dem Eingangspunkt, den wir hatten.
Dann ist man als Coach
nicht nur Methoden-Coach
und erklärt, wie die Methode funktioniert,
sondern man muss die Menschen
natürlich auch bei den Schwierigkeiten abholen,
weil das, was du jetzt so sagst,
klingt ja wunderschön. Also ich merke,
was ich alles nicht weiß und stelle fest,
wie schwierig das alles ist.
Das führt ja nicht bei den
wenigsten Leuten zu Begeisterung.
Also muss man da ja die Leute auch begleiten
und sagen, okay, das ist jetzt erstmal so
und daran müssen wir arbeiten. Und da kann man
die Realität ja nicht negieren.
Das ist da. Und das zu erkennen
und die Leute dabei zu begleiten,
das ist dann wahrscheinlich die Aufgabe, die du auch
als deine Coaching-Aufgabe siehst.
Genau. Also die Menschen zu
begleiten, viel zu erklären
und ja auch
so eine Brücke zu liefern, das ist
definitiv unsere Aufgabe.
Nur,
also wenn ich vorher die Probleme nicht gesehen
habe, habe ich keine Chance, etwas zu tun.
Wenn ich die Probleme sehe, habe ich
zumindest die Chance, etwas zu tun.
Lösen muss ich sie dann auch alleine,
natürlich. Vielleicht kann
ich das mit anderen gemeinschaftlich tun,
dann ist es einfacher, aber
grundsätzlich ist es doch erstmal gut zu
wissen, was habe ich auf dem Tisch.
Ja, also
ich stimme dir zu,
da sind wir ja in dem gleichen Umfeld unterwegs,
aber ich sehe eben dann auch immer wieder Leute,
die das
vielleicht nicht sofort für positiv
befinden, also die
eben sagen, das ist alles gar nicht so
kompliziert, lasst mich mal entscheiden,
also jetzt mal ganz banal und ganz
platt, alte Verhaltensmuster,
Entscheidungen treffen und die dann
durchdrücken. Das, was du ja sagst,
auch der Bezug zur Agilität ist ja,
miteinander reden, gemeinsam
erstmal Transparenz schaffen und dann zu Lösungen
kommen. Das ist ja eine ganz andere Art
von Arbeiten für viele
Menschen.
Also natürlich muss man erstmal lange
Schritt für Schritt in diese Art
der Zusammenarbeit reinkommen.
Manche sind da schon
etwas geübter, manche haben mehr Erfahrung
da drin, manche haben auch schon viele
Erfahrungen, die sehr positiv sind, die sie weiter
geben können. Ich habe die Erfahrung
gemacht, dass es ganz viele Menschen im
Unternehmen gibt, die haben sich schon damit
beschäftigt, die haben schon
mit Teams und Teams von Teams
zusammengearbeitet, haben schon viele
Erfolge da drin und haben das
ja ein bisschen zu ihrem
eigenen Lebenssinn mitgemacht.
Also ich zähle mich jetzt auch selber dazu,
dass ich davon grundsätzlich begeistert
bin. Also nicht so, weil ich das wie
eine Art Religion pflege, sondern
grundsätzlich, weil ich gemerkt habe, wie
es anders sein kann,
wie es jetzt ist und ich einfach
mit Menschen zusammengearbeitet habe, die mir
das unfassbar viel gebracht hat.
Mhm, okay.
Du hast ja eben schon gesagt, wie
diese Flight Levels mit Agilität
zusammenhängen und das, was du eben sagtest,
hat ja all das auch was mit Agilität
zu tun. Also würde ich
jetzt mal sagen,
ihr nutzt, oder die Flight Levels
nutzen eben das Thema Agilität,
das, was in Agilität mit
Kernpraktiken da ist, nutzen die Flight
Levels genauso. Also insofern gibt’s
da auch gar keine Abgrenzung. Wir
machen Flight Levels und ihr seid Agile,
sondern es ist einfach das Arbeiten
an diesen Wertströmen,
das Zusammenbringen von
einzelnen Wertstrominseln,
Wertentstehungsinseln,
das ist das, was ihr tut. Und dann nutzt ihr eben
das, was normal ist. Das habt ihr vorhin auch gesagt.
Gesunder Menschenverstand
und das bringt ihr zusammen auf den Flight Levels.
Genau. Ich würde sagen,
das ist so ein bisschen die Essenz davon.
Also, dass man sich wirklich auf das
fokussiert, was ja
wichtig ist, wenn man Wert für Kunde schaffen
möchte. Und ich kann’s gerne mal wiederholen,
das ist für mich Visualisierung, Fokus
setzen, Interaktion
zwischen den Menschen und zu schauen,
okay, wie
erfolgreich bin ich mit dem, was ich tue.
Und dafür sind halt eben
genau diese Rückschleifen
sehr wichtig, dass ich davon lernen kann,
was ich an Informationen
zurückbekomme vom Kunden, um noch
erfolgreicher zu sein.
Sehr schön.
Also, ich hab bis jetzt
schon ein sehr viel besseres
Bild bekommen von den Flight Levels.
Der Besuch von
Kursen oder das Lesen von Büchern steht
auf der Liste dann für mich jetzt oben drauf
an der Stelle.
Aber ich glaube oder hoffe,
dass der eine oder andere, der jetzt diesen Podcast
hört, sagt, hey, da will ich mehr
davon erfahren. Natürlich kommen in die
Shownotes ein paar Links rein,
über den Blog oder über
Blog-Einträge, so man was nachlesen kann.
Gibt’s denn noch die Chance, da
ein bisschen mehr zu erfahren? Gibt’s außer
Blog-Beiträgen auch Bücher oder andere
Themen? Also, kurze Frage, wo kann man da
mehr über Flight Levels erfahren?
Also, aktuell
gibt’s die Flight Level Academy.
Und die ist noch im Aufbau.
Das heißt, es entwickelt sich langsam
und wir haben schon
einige Möglichkeiten,
wo man mehr erfahren kann.
Aber die Flight Level Academy
soll auf jeden Fall
bewusst nicht etwas sein, wie
eine Zertifikatsdruckmaschine
oder ähnliches, sondern
es ist eher eine Lern-Community.
Und das Ziel ist, gemeinschaftlich
mehr über Business-Abilität
zu erfahren. Und
die Hauptanwendungsgruppe
oder die Zielgruppe, das sind
wirklich die Anwender und jetzt nicht
die Consultants oder Coaches. Also, wir wollen
wirklich die Leute, die es im täglichen
Leben
anwenden können, die es gebrauchen
können, um es wirklich jetzt schon
umzusetzen.
Daneben gibt’s noch
neben der Academy
sogenannte Flight Level Guides.
Das sind so Experten, die kennen wir seit Jahren,
die kennen sich persönlich.
Und von denen wissen wir,
das, was die tun, da
vertrauen wir darauf, dass die das Modell
gut verstanden haben, anderen gut vermitteln
können und dass sie das in Organisation
auch gut etablieren können.
Die Flight Level Guides, sie sind
so eine gute Mischung aus Trainern,
Coaches, Consultants,
aber auch Leute, die wissen, wie man
das Thema in Unternehmen adressieren kann.
Okay. Das heißt, die Flight Level Academy
spricht Anwender an,
die ihr Nutzer, also
die Leute, die wirklich damit arbeiten
wollen, die mit ihren Fragen kommen, die mit ihren
Problemen oder Herausforderungen kommen
und eben die Flight Level Guide
Experten, die die
man eben nutzen kann, wenn man es nicht
alleine umsetzen kann, wenn man Gesprächspartner
braucht, wenn man Erfahrung braucht,
wenn man die mit dazu nimmt.
Gut. Das heißt aber, wenn wir
in den
Shownotes da die beiden Links
reinbringen zu diesen
zu der Academy
und zu den Flight Level Guides, dann
kann man sich darüber informieren und kann schauen,
wie es weitergeht und wie man das
Interesse, was man aus dem Podcast gewonnen
hat, wie man das vielleicht dann wirklich
für sich konkret beantworten kann.
Und weiter lernen kann.
Genau. Richtig.
Und man kann uns auch gerne persönlich
ansprechen oder anschreiben.
Es gibt auch auf Twitter die Flight Levels
Academy.
Ja.
Gut. Dann machen wir das auch noch mit in die Shownotes
rein. Einfach ein paar Links.
Dann
kann man sich da weiter informieren.
Es klingt für mich sehr, sehr
interessant. Ich
finde es auch schön, dass es keine Zertifikatsdruckmaschine
werden soll. Das
finde ich sehr, sehr positiv,
dass es darum geht, eben
Wert zu schaffen, indem man
Arbeit transparent macht und Leuten
hilft, vielleicht besser miteinander
zu arbeiten, kundenorientierter.
Das finde ich
ein super Ansatz.
Lukas, hast du noch irgendetwas,
was du zu dem Thema sagen willst,
was wir noch nicht so besprochen haben?
Mir grundsätzlich ist das Thema sehr wichtig.
Also ich habe gemerkt,
dass es wirklich hilft, mal fernzusehen,
jeglicher Modelle oder Frameworks,
das Unternehmen besser zu verstehen
und am Ende
wirklich was draus zu machen, was dem
entspricht, was das Unternehmen wirklich ist.
Also ich
vergleiche das immer gern mit
Playmobil oder Lego.
Wenn ich Playmobil kaufe, dann habe ich
einen komplett fertigen Bausatz.
Den stelle ich hin. Den kann ich
exakt so haben, wie ich ihn will.
Bei Lego ist das auch so. Da habe ich auch
eine Bauanleitung. Aber ich kann es auch
komplett weglassen. Ich nehme die Teile und baue es mir so,
wie ich will.
Und wie es dem entspricht, wie meine Vorstellung ist.
Und genau dabei,
glaube ich, hilft
das Flight Levels Modell extrem.
Dass ich wirklich sowas habe, ähnlich
wie Lego. Ich kann mir, wenn ich
das gemeinschaftlich verstanden habe, was ich damit
erreichen kann, selber was
zusammenbauen. Und das ist halt genau das,
was dem entspricht,
was das Richtige für mein Unternehmen ist
und was für die Kunden am Ende den größten
Wert erliefert.
Sehr schön. Ja, unterschiedliche
Ideen zwischen Playmobil und Lego finde ich
ein sehr eingängiges Beispiel.
Sehr schön. Gut.
Ich habe auch keine Fragen mehr
und würde sagen, herzlichen Dank
für den Podcast, für die Aufnahme.
Und dann wünsche ich dir weiterhin
viel Erfolg bei deiner
Arbeit als Enterprise Kanban Coach
bei der Telekom. Vielen Dank, Lukas.
Danke dir. Auch dir viel Erfolg.
Danke dir.