In dieser Episode des DevOps-Podcasts wird das Thema Klarheit in organisatorischen und technischen Prozessen behandelt. Die Moderatoren Luca Ingianni und Falko Werner diskutieren über die Herausforderungen, denen sie in ihrer Arbeit als DevOps-Trainer und Berater begegnen, insbesondere bezüglich der Unklarheit in Kundenprojekten. Sie betonen die Wichtigkeit von klar definierten Prozessen, gemeinsamen Sprachen und Definitionen sowie die Nutzung von Werkzeugen wie Wertstromanalysen und Visualisierungen, um Klarheit zu schaffen. Die Episode betont, dass Klarheit in allen Unternehmensebenen notwendig ist und dass dies für effektive DevOps-Praktiken und agile Transformationen unerlässlich ist.
Inhalt
- Einführung und Bedeutung von Klarheit in DevOps
- Herausforderungen durch Unklarheiten bei Kundenprojekten
- Bedeutung einer gemeinsamen Sprache und Definitionen
- Rolle von Werkzeugen wie Wertstromanalysen und Visualisierungen
- Wichtigkeit von Klarheit auf allen Unternehmensebenen
- Diskussion über agile Praktiken und ihre Implementierung
- Einsatz von Planning Poker und anderen Schätzungsmethoden
- Wirkung von Klarheit auf Effizienz und Transparenz
- Beispiele aus der Praxis und Erfahrungen der Moderatoren
- Schlussfolgerungen und Handlungsempfehlungen
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und wo wir gerade über organisatorische Aspekte sprechen, ist vielleicht Aufmerksamhörern aufgefallen, dass ein Name weggefallen ist.
Nämlich Dirk Söllner, der ja vor gefühlt einem Internetjahrhundert diesen Podcast ins Leben gerufen hat,
hat sich aus seiner aktiven Rolle als Mitherausgeber zurückgezogen,
hat den Podcast Falko und mir zum Geschenk gemacht
und ist natürlich weiterhin sowohl uns als auch dem Podcast sehr eng verbunden
und wird bestimmt auch noch als Gast das ein oder andere Mal hier auftreten,
aber gehört eben nicht mehr zum Stammpersonal, sondern ist…
Ich habe den Ausdruck mal in einem anderen Podcast gehört und ich finde den schön.
Er ist ein Freund des Podcasts. Er ist ein Freund von uns.
Insofern begrüße ich jetzt den zweiten Teilnehmer an dem heutigen Podcast, nämlich den Falko.
Hallo Falko, wie geht’s dir heute?
Hallo Luca, schön, dass wir mal wieder zusammensitzen und einen Podcast…
Podcast zu zweit aufzeichnen.
Ich freue mich auf das Thema, das du schon so gut vorbereitet hast, aber das kommt gleich.
An sich, zu deiner Frage, mir geht’s gut.
Ich freue mich auf ein Wochenende demnächst und bin ganz froh, dass die Arbeitswoche so weit rum ist,
bis auf den Podcast, die Podcast-Aufzeichnung jetzt.
Ja, das ist ja keine Arbeit, das ist ja ein Vergnügen.
Sehr schön. Worüber sprechen wir überhaupt dieses Mal?
Ich habe mir da ein Thema überlegt und es ist…
Das Thema heißt einfach Klarheit.
Und dieses Thema ist jetzt natürlich so ein bisschen unscharf, ein bisschen unklar selber.
Das liegt daran, dass ich in den letzten Monaten im Rahmen meiner Arbeit,
Betreuung verschiedener Kunden, immer wieder mit diesem Thema konfrontiert wurde,
dass in verschiedener Hinsicht, aus verschiedenen Perspektiven einfach Unklarheit herrschte
und sowohl mir als Konsultant, als auch meinen Kunden vor allen Dingen,
beträchtliche Schwierigkeiten bereitet hat.
Zum Teil auch Schwierigkeiten, die sich vielleicht gar nicht so richtig bewusst…
Und deswegen habe ich mir gedacht, vielleicht ist es an der Zeit, dass wir das mal hier im Podcast erörtern.
Was fällt dir denn ein zu diesem Begriff Klarheit, Falco?
Das Erste, was mir eingefallen ist, als du den Vorschlag zum Thema gemacht hast,
ist eine Folge, die wir schon hatten, und zwar mit Peter Lange zum Thema gemeinsame Sprache finden.
Das heißt Grundlage gemeinsamer Begriffe, gemeinsames Verständnis von der Situation im Unternehmen,
um dann letztendlich darauf aufbauen zu können.
Und ich denke, das ist eine gute Vertiefung auch zu der Folge jetzt, die wir damals hatten.
Ja, das stimmt. Und es ist spannend, dass wir jetzt an der Stelle einklinken,
weil das ist ja jetzt wirklich was wahnsinnig Grundlegendes,
dass wir sagen, Worte, haben wir überhaupt gemeinsame Worte?
Jetzt mal ganz abgesehen von allem anderen.
Ja, natürlich. Aber wir haben natürlich auch unterschiedliche Sprachen, unterschiedliche Historie.
Ja, die Worte an sich ist ja das eine.
Eine gemeinsame Bedeutung für die Worte zu finden, ist ja quasi der Schritt darauf.
Klar kann man sich immer auf eine Sprache, die in irgendeiner Form definiert ist,
wie Deutsch mit dem Duden oder Englisch mit dem Oxford- oder Merriam-Webster-Dictionary,
wo dann halt viele Begriffe klar definiert sind.
Aber im Geschäftsumfeld gibt es natürlich auch andere Quellen,
die hilfreich sind, so ein gemeinsames Verständnis zu finden.
Zum Beispiel Frameworks, die bestimmte Dinge definieren.
Ich arbeite gerade mit ein paar Kollegen bei der DASA an dem DASA DevOps-Glossar,
wo wir genau das versuchen, für die DevOps-Welt ein Stück zu ermöglichen und zu definieren.
Können uns da natürlich ein bisschen auch abstützen auf bestehenden,
auch mehrsprachigen Glossaren von Save oder von Scrum,
anderen Frameworks und Richtungen.
Die in dem Umfeld IT natürlich ein Stück ergänzend sind zu den Standard-Sprach- und Wort-Definitionen.
Wie siehst du das?
Ja, da sind wir schon mitten im Thema drin eigentlich.
Es erinnert mich vor allen Dingen auch an das, was wir traditionell eingangs dieses Podcasts immer machen.
Nämlich, wenn wir Gäste haben, fragen wir ja immer nach einer persönlichen Definition von DevOps,
weil so einfach ist es halt häufig nicht.
Du kannst nicht einfach den Duden aufschlagen und nachlesen, was heißt denn da DevOps,
sondern das heißt.
Für viele Leute viele Dinge und so ist es auch mit ganz vielen anderen Themen und so ist es
nicht nur auf der Ebene von Worten, sondern
Klarheit ist etwas, was immer wichtig ist, wenn man mit anderen zusammenarbeitet, auf ganz vielen Ebenen.
Ich behaupte, es ist auch sogar wichtig, wenn man nur mit sich selbst zusammenarbeitet, dass man eigentlich weiß, was man möchte, wohin man möchte.
Und es ist mir einfach in den letzten Monaten so aufgefallen bei meinen Kunden, dass
dass ein beträchtlicher Mangel an Klarheit herrscht, der mir natürlich als jemand, der von außen neu zu einer Organisation dazukommt, immer das Leben schwer macht.
Ich muss dann irgendwie versuchen, da rauszufinden, um was es eigentlich geht.
Aber was vor allen Dingen auch für meine Kunden selber das Leben wahnsinnig schwer macht.
Also ich bin gerade irgendwie erinnert an einen Kunden zum Beispiel, den ich in den letzten Monaten hatte, wo einfach überhaupt keine Vorgaben existieren darüber,
in welche Richtung die Organisation sich entwickeln soll.
Also irgendwie so die, die, die wollen halt irgendwas mit Agile machen, so war mal so der Gedanke.
Irgendwas mit ist natürlich ein cooler Anfang, erinnert mich gerade an den Titel von einem Podcast, der jetzt ein halbes Jahr läuft, von von jemand anders im AI Umfeld.
Irgendwas mit AI.
Also letztendlich ist er offenbar neugierig genug, dass ich mir den Titel gemerkt habe und auch die eine oder andere Folge gehört habe.
Und an sich ist das halt so ein Punkt.
Ich sehe es auch, wenn ich in Projektumgebungen reinkomme, dass man dann halt viele neue Begriffe, die unternehmensspezifisch sind, irgendwie sich nahe bringen muss, die man lernen muss.
Je größer das Unternehmen, desto mehr gibt es davon und desto mehr gibt es auch spezielle Abkürzungen und produktspezifische Sichten und anderes,
die dann halt nicht klar und deutlich in einem allgemein definierten Sammelsuchium von Worten wie in Glossar doch,
teilweise schon, teilweise haben Unternehmen sogar Glossare, aber nicht halt in einer Wikipedia, in einem Duden oder in einem Webster nachzulesen sind, weil sie halt doch sehr, sehr unternehmensspezifisch sind.
Genauso ist es mit vielen anderen Aspekten, die ein Unternehmen definieren, zum Beispiel die Art und Weise der Zusammenarbeit, wo du sagst, okay, wir wollen irgendwas mit agil machen.
Und was heißt denn jetzt agil?
Wo wollt ihr hin?
Was ist der Hintergrund?
Wo kommt ihr her?
Was sind eure Werte?
Was sind eure Ziele?
Was sind die laufenden Projekte vielleicht auch?
Oder welche Produkte gibt es im Unternehmen, um einfach als Berater, als Consultant in dem Umfeld dann auch wirken zu können, braucht man halt ein Verständnis.
Und dann muss man halt teilweise recht einfache Fragen stellen und wenn man dann feststellt, es gibt dann keine vernünftigen Antworten, dann wird es natürlich schwierig.
Also ich hatte jetzt letztens eine Schulung im Umfeld von Versicherungen und da ging es um agiles Arbeiten nach Scrum.
Als Framework und Scrum hat ein paar Werte und dann haben wir halt mal gefragt, ja, wie sieht es denn mit Unternehmenswerten aktuell aus?
Gibt es da Überschneidungen?
Gibt es da zu dem Scrum Framework und den Werten vielleicht auch Konflikte, die man dann mal diskutieren musste?
Funktioniert das theoretisch, so ein Framework in dem bestehenden Unternehmensumfeld zu etablieren, schon auf der Ebene der Werte?
Und dann halt der Operator.
Und dann halt die operativen Dinge, Umsetzung der Werte im realen Leben mit, wie werden die Werte dann gelebt, die es aktuell gibt?
Dann stellt man halt fest, ja, es gibt so eine Definition und dann hat jemand drei Werte im Kopf und der Nächste noch drei andere Werte.
Aber wenn man dann fragt, ja, wie werden die gelebt? Wie ist es denn bei euch wirklich in der Realität?
Dann wird es häufig dünn.
Dann merkt man, es hat sich kaum jemand wirklich Gedanken darüber gemacht.
Und genauso mit verschiedenen anderen Dingen, die in einem Unternehmen passieren.
Die nicht so ganz transparent sind.
Also ein Aspekt für Klarheit ist halt auch, dass man darüber redet, sich die Zeit nimmt und versucht, Dinge über verschiedene Köpfe hinweg zu einem gemeinsamen Verständnis zu bringen.
Also Transparenz zu schaffen.
Weiteres Werkzeug, was aus meiner Sicht für Klarheit bricht, ist Visualisierung.
Dass man halt sagt, okay, man redet nicht nur, man nutzt nicht nur Worte, sondern man nutzt auch Bilder.
Man nimmt Zeichnungen, man nimmt Diagramme, man geht an Whiteboard.
Man versucht, auf dem Weg ein gemeinsames Verständnis zu finden.
Und das kann man für verschiedenste Zwecke einsetzen.
Software-Architektur ist ein Beispiel, wo man dann Architektur-Diagramme ableitet, die zur Klarheit beitragen.
Genauso aber auch über Arbeitsabläufe.
Wenn man über Wertstromanalysen nachdenkt, dann sind das ja meist visuell dargestellte Abläufe von Arbeitsprozessen, Prozessschritten, von Abhängigkeiten, die man dann hat, die man dann visualisiert.
Und das hilft aus meiner Sicht auch, Klarheit zu schaffen.
Genauso kann man das auf anderen Ebenen machen.
Zum Beispiel, wenn man ein Produktportfolio versucht zu visualisieren und sagt, okay, wo stehen auf einer Skala, auf einer Sichtbarkeit, auf einer Umsetzbarkeit bestimmte Produkte im Portfolio.
Also auch da hilft aus meiner Sicht Visualisierung sehr gut.
Was muss man bei Klarheit noch bedenken?
Ein lustiger Aspekt ist, dass Klarheit nicht universell ist.
Genau.
Genau.
Genau.
Genau.
Genau.
Genau.
Genau.
Völlig klar sein und dem anderen derselbe Sachverhalt vollkommen unklar sein.
Und im Übrigen auch, dass es natürlich so Dinge gibt wie scheinbare Klarheit.
Als du gesprochen hast, zum Beispiel über Architektur-Diagramme, habe ich mich erinnert an einen mehrfachen Gast dieses Podcasts, den Felix, der mal die interessante Anekdote berichtet hat.
Der war CTO, wenn ich es richtig weiß, eines irgendwie Hosting-Unternehmens.
Und er hat seine Teams mal beauftragt, ihm ein Architektur-Diagramm zu malen.
Ihres Produkts, ihrer Infrastruktur.
Und die waren alle falsch.
Kein Team hat es hingekriegt, ein vollständiges und richtiges Architektur-Diagramm zu malen.
Die hatten alle Lücken, die hatten alle Fehler.
Und insofern, immer wenn ich ein Diagramm sehe, ein Architektur-Diagramm, ein, was weiß ich,
Wettsturm-Diagramm oder sowas, dann muss ich immer an diese Episode zurückdenken und mir
überlegen, das, was ich da sehe, ist das jetzt wirklich die tatsächliche Wahrheit?
Gibt es überhaupt tatsächlich nur eine Wahrheit?
Oder haben da vielleicht zwei verschiedene Leute, wenn du die beauftragst, den Workflow
aufzumalen, malen die dann verschiedene Workflows, weil sie es halt auch echt verschieden machen?
Insofern, auch da können die Dinge nur scheinbar klar sein.
Genau, ja, aber dann hat man zumindest die Möglichkeit, mit mehreren einfacher zusammenzuarbeiten,
um gemeinsam Workflow zu finden.
Und wenn ich mir überlege, wie so ein Wettsturm-Diagramm entsteht, so ein Value-Stream-Workshop
abläuft.
Dann hat halt jemand eine erste Idee, dann bringt er die an die Wand und dann wird sie
halt zerpflückt, diskutiert, ergänzt, erweitert und dann kommen halt andere Sichten dazu.
Dann hat man darüber Klarheit, das ist das eine.
Und das andere ist, man hat die Chance, gemeinsame Sichten zu entwickeln.
Genauso sehe ich das auch, wenn ich jetzt gerade an die Schulung der letzten Woche zurückdenke,
Scrum-Grundlagen, Estimation-Poker, genau das ist Klarheit schaffen.
Klarheit zwischen Anforderung und Umsetzung.
Dass man halt diskutiert, dass man klar macht, sichtbar macht, visualisiert.
Der eine schätzt Aufwand für eine User-Story in acht Story-Punkten, der andere in 21 Story-Punkten
und dann hat man Klarheit darüber, dass man unterschiedliche Sicht auf die Anforderungen
hat und kann dann Klarheit darüber schaffen, wo diese Differenz liegt in der Sicht auf
die Anforderung.
Dann kann man darüber diskutieren, wo diese Differenz herkommt, kann sie auflösen und
im besten Fall schätzt man halt nochmal, hat eine gemeinsame Einschätzung, die gleich
ist, vielleicht ist es bei beiden dann eine 13 oder man hat sich sogar auf eine 5 geeinigt
als Story-Punktgröße für die Anforderung, weil man Klarheit darüber hat, dass bestimmte
Annahmen, die quasi da sind, von unterschiedlichen Sichten heraus vielleicht nicht der Realität
entsprechen und deswegen die Schätzung unterschiedlich ist und deswegen halt es wichtig ist, darüber
zu reden.
Also man kann Klarheit über verschiedene Sichten.
Im besten Fall über Gespräche, über Workshops, über gemeinsame Arbeit an dem Objekt schaffen.
Also zum Beispiel gemeinsame Sicht auf den Quellcode, wenn man nicht genau weiß, was
ist umgesetzt.
Gemeinsame Sicht auf eine Visualisierung, auf eine Dokumentation, die man dann vielleicht
auch noch aktualisiert, wenn man feststellt, das was dort steht, stimmt nicht mit der gemeinsamen,
mit der Sicht der Einzelnen.
Ja, das ist eine berechtigte Frage.
Ich glaube, zumindest der Umstand, dass da…
Ein und dieselbe Architektur verschieden dargestellt wurde, ist ein Signal dafür, dass irgendwo
was im Argen liegt.
Egal, ob es da ein Felixrecht hatte oder vielleicht halt auch nicht oder sowas.
Aber ein Kabel verläuft objektiv entweder da lang oder es verläuft nicht da lang.
An der Realität messen.
Wie klar, wie richtig ist das, was man dort zum Beispiel in einem Modell, in einem Diagramm,
in einer Visualisierung aufgezeichnet hat?
Wie nah ist das an dem Kabelverlauf zum Beispiel?
In dem echten Schrank?
In dem echten…
In dem echten Rechenzentrumsrandabschnitt oder so.
Und da haben wir jetzt ein paar interessante Fragen aufgeworfen.
Zum Beispiel, kann man Klarheit irgendwie messbar machen oder sowas?
Aber ich würde diese Fragen sogar ganz gerne nochmal zurückstellen und erstmal noch ein
bisschen weiter uns an diesem Thema abarbeiten, dass wir sagen, wie kann ich denn jetzt Klarheit
erreichen?
Weil du hast zwar zu Recht gesagt, man könnte zum Beispiel ein Diagramm machen oder sowas.
Man könnte sich verschiedenster Techniken bedienen.
Aber wie wir jetzt gesehen haben, Klarheit oder andersrum, ein Diagramm erzeugt dann
nicht automatisch Klarheit, weil das Diagramm kann ja verkehrt sein.
Insofern, wie können wir denn sowas erzeugen, absichern?
Wie kann man Klarheit erzeugen und wie kann man sicherstellen, dass die erzeugte Klarheit
da ist?
Komme ich zurück auf die Diskussion, auf die gemeinsame Erstellung von einer Dokumentation,
einer Visualisierung im Gespräch von den Beteiligten, die Wissen über die Situation
haben, zur Not an der physisch-realen…
Also dem Quellcode, dem Bit und Byte, das irgendwo steht und geschrieben ist, dass
man halt nachschaut, recherchiert und sich bewusst macht, wie es wirklich ist.
Messen hilft dabei, sicherlich.
Genau, wenn man einen Nachweis hat, wenn man einen physischen Beweis hat, geht da jetzt
eine Stippe lang oder geht da keine Stippe lang, dann kann man es auf diese Weise machen.
Ansonsten kann man das machen.
Was du vorhin ja auch schon angesprochen hast, zum Beispiel Planning Poker, man kann, wenn
man es will, über statistische Methoden, Planning Poker ist, etwas dramatisch gesprochen,
ja einfach nur eine statistische Methode, ich mache die Anzahl groß und schaue dann,
wie groß meine Abweichung ist.
Das heißt, ich kann dafür sorgen, dass Einigkeit besteht oder vielmehr, ich kann überprüfen,
zu welchem Grad Einigkeit besteht, so muss ich sagen.
Das ist, glaube ich, etwas, was ganz wichtig ist und was selten gemacht wird.
Ich meine, bei Planning Poker…
Das ist ziemlich verbreitet, das machen bestimmt viele Leute, auch weil es irgendwie
schön einfach ist und zugänglich ist und nicht viel Mühe macht.
Ob jetzt einer eine Karte hochhält oder zehn, das ist dann auch schon irgendwie wurscht.
Naja, bei einem oder zehn, also bei einem oder mehr als einem mache ich auf jeden Fall
einen Unterschied.
Also wenn ich jetzt für mich eine Karte hochhebe, brauche ich die Karte auch nicht hochheben,
weil ich weiß genau, dass meine Schätzung aus meiner Sicht mit meinem Wissen, mit meinem
Wissensstand…
Ja, ja, klar, aber das ist ja etwas, was ja früher oft gemacht wurde.
Dass einfach ein Chefingenieur oder sowas die Aufwände geschätzt hat.
Der hat das Gesamtwissen, der hat das perfekte Wissen und dann ist das ja auch völlig okay,
wenn man diese Annahme hat und danach arbeitet.
Wenn der Chefingenieur das alles weiß, was notwendig ist und in den Köpfen der anderen
kein zusätzliches Wissen, das notwendig ist, um eine Schätzung abzugeben, besteht,
mag das ja auch völlig okay sein.
Und da bin ich zum Beispiel auch erinnert an etwas, was ich bei einem anderen Kunden vor
nicht allzu langer Zeit gemacht habe.
Nämlich ein, wie nennt ihr das, ein Roll Canvas.
Ich glaube, da hatte ich auch schon mal in einem Podcast darüber gesprochen.
Das war, genau, mein Peter Jetter, glaube ich, der unlängst bei uns zu Gast war.
Und das war ganz interessant, da habe ich mit verschiedenen Teams auf verschiedenen Ebenen,
da ging es irgendwie immer um Antworten.
Da gab es die auf Portfolio-Ebene, die Leute, die da Epics geschrieben haben oder sowas.
Und dann gab es die Leute auf Wertstromebene, die haben vielleicht Features geschrieben.
Und dann gab es die Leute auf Team-Ebene.
Die haben User-Stories geschrieben.
Und mit all diesen Gruppen habe ich jeweils ein Roll Canvas gemacht.
Ich habe die also gefragt, wie versteht ihr eure Rolle?
Was sind eure Eingangsprodukte?
Was sind eure Ausgangsprodukte?
Womit arbeitet ihr?
Was braucht ihr?
Und dann hatte man verschiedene Antworten darüber, wie denn eigentlich dieser Arbeitsfluss aussieht,
diese Verarbeitung von Informationen aussieht.
Und da konnte man eben schon beobachten, an welcher Stelle fehlt was.
Dass die einen sagen, also wir brauchen jetzt, keine Ahnung, eine Roadmap.
Und die anderen Rollen haben aber…
Da hat man einfach keine Roadmap gebaut und da konnte man sagen, an der Stelle hakt es jetzt irgendwie.
Und plötzlich entstand dann eine Klarheit darüber, nicht was machen die einzelnen Leute
oder was sollten sie machen oder so, sondern was braucht eigentlich dieser Prozess als Ganzes.
Und das war für viele Leute eine wahnsinnig lehrreiche Erfahrung,
dass jetzt wirklich mal schwarz auf weiß und ganz deutlich zu sehen,
hier fließt Information und an der Stelle versiegt sie zum Beispiel.
Und das war natürlich eine Menge Arbeit.
Also ich meine, dieser Canvas selber,
der hat irgendwie pro Team, pro Ebene allein die Umsetzung,
ich sage jetzt mal eine Stunde, anderthalb, zwei Stunden gekostet.
Ich hatte Vorbereitungszeit, ich hatte Nachbereitungszeit,
erkleckliche sogar, weil diesen Riesenwust an Informationen dann wirklich mal übereinander zu legen
und auf sich wirken zu lassen und Dinge zu sehen,
vor allen Dingen Dinge, die nicht niedergeschrieben sind, weil sie fehlen.
Das hat schon viel Energie gebunden.
Das war teuer, aber es war, glaube ich, auch wirklich wahnsinnig wertvoll.
Also hast du letztendlich das, was ich vorhin vorgeschlagen habe,
also eine Visualisierung, eine Darstellung aus unterschiedlichen Sichten
in einem Diagramm, in einem Modell zusammengetragen
und damit ein Verständnis für verschiedene andere erhöht.
Also Klarheit geschaffen oder zumindest Klarheit erhöht.
Und deswegen war es mir irgendwie ein Anliegen,
jetzt das zum Thema des Podcasts zu machen,
weil ich das Gefühl habe,
das ist etwas, was so ein bisschen unterbleibt im Alltagsgeschäft.
Man wird immer zerrieben zwischen allen möglichen Dingen,
die fertig werden müssen und die man machen muss und Wertschöpfung und so.
Und diese notwendige Pflege unserer Prozesse,
unseres Verständnisses auf ganz vielen Ebenen kommt da halt irgendwie zu kurz.
Das, glaube ich, habe ich ganz häufig gesehen.
Ich weiß nicht, Falko, siehst du das ähnlich?
Das ist etwas, was mit der Zeit sich entwickelt.
Diese gewachsenen Strukturen in Unternehmen, die halt irgendwo sind,
irgendjemand macht was, irgendwas funktioniert gut,
es wird wiederholt, es wird vielleicht sogar als Prozess definiert,
damit es andere wiederholen können und sich an die Vorgabe halten.
Dann gibt es irgendwo einen Fehler,
dann wird eine Ausnahmeregelung hinzugenommen,
dann wächst letztendlich die Dokumentation, die man dazu braucht.
Dann muss man bestimmt jedes Mal auf diese Ausnahmen achten,
gucken, dass da nicht wieder was an Problemen wächst und entsteht.
Und irgendwann hat man halt einen relativ großen Wust an Dingen,
auf die man achten muss, die man kennen muss,
auf die man sich letztendlich wieder berufen kann und sagen kann,
okay, so haben wir gesagt, wollen wir vorgehen, um das Produkt herzustellen
oder um die Dienstleistung dem Kunden zur Verfügung zu stellen.
Und ja, da bietet es sich halt an, zu schauen, wie viel Bürokratie,
wie viel Aufwand, wie viel nicht wertschöpfende Tätigkeiten sind da dabei
und wie kann man diese vielleicht auch entschlacken, wie kann man Prozess wieder runder,
laufen lassen oder wie kann man es schaffen, dass Wert wieder fließt
und nicht an vielen verschiedenen Liegestellen blockiert ist.
Und ja, dazu, also was Prozesse angeht, denke ich, gibt es gute Werkzeuge,
das zu visualisieren, Wertstromanalyse fällt mir da als erstes ein,
zu schauen, wie wird Wert im Unternehmen geschöpft,
wie kann, was sind die beitragenden Rollen oder Personen im Rahmen der Wertstromanalyse,
die Wertschöpfung, wie arbeiten diese Personen miteinander zusammen
und welche von den Schritten sind halt wirklich für den Nutzer, für den Kunden,
für den Endkunden werthaltig und welche sind halt für das Unternehmen werthaltig,
aber nicht wirklich für den Kunden und was kann man vielleicht auch im Prozess
vereinfachen, verschlanken, vielleicht sogar automatisieren,
um die Wertschöpfung zu beschleunigen.
Genau, also insofern, man hat Werkzeuge, um Kleid herzustellen,
man muss, glaube ich, solche Kleidungskraftwerke,
halt auch verteidigen, also ich glaube, dass, wenn man nicht aktiv gegensteuert,
dann nimmt die Entropie zu, die Unschärfen nehmen zu,
die Dinge gehen irgendwie so halt ihren Gang
und dann ist man irgendwann in so einem Kuddelmuddel drin.
Genau, insofern, Visualisierung hilft, Wertstromanalysen helfen,
Retros helfen, gut gemachte Retros.
Es gibt viele Werkzeuge, wir hatten ja vorhin Planning Poker
bei Anforderungsmanagement, Retrospektiven,
klar, um die Arbeitsprozesse, die man hat, zu optimieren,
sie zu reflektieren, ja, für Retros ganz viele verschiedene Methoden,
die man einsetzen kann, sei es Kommunikationsdiagramme,
mit wem, in welcher Form, über welchen Weg kommuniziert so ein Team,
wo kommen Anforderungen her, mit wem muss man sich abstimmen,
wo gibt es Zulieferungen, sind ja auch Dinge, die man gut in der Retro
mal abfragen oder verarbeiten kann, um zu schauen,
ist es denn allen überhaupt bewusst, gemeinsames Verständnis schaffen
und dann entscheidend ist, dass man sich nicht nur auf die Anforderungen, die man hat, schafft,
und dann entscheidend ist, dass man sich nicht nur auf die Anforderungen, die man hat, schafft,
auch davon abzuleiten, gibt es ja genauso in der Wertstromanalyse,
genauso aus der Analyse der Anforderungsprozesse, die du beschrieben hast,
sind ja dann Maßnahmen abgeleitet worden, um diese Vorgehensweise zu verbessern, zu optimieren,
das kann man in kleinen Schritten iterativ machen,
oder man kann halt wirklich mal einen kompletten Bereich mit Mitarbeitern neu strukturieren,
andere Arbeitsweisen von vornherein ansetzen und dann komplett vorne starten
mit einer Neubesetzung und Zusammensetzung von Teams,
zum Beispiel bei einer agilen Transformation, wenn man von klassischen silo-orientierten Ansätzen kommt
und sagt, okay, wir restrukturieren in eine Richtung, die Agilität fördert,
weil wir irgendwas mit Agilität machen wollen und machen jetzt cross-funktionale Teams,
das heißt, bestehende Teamstrukturen werden komplett aufgelöst,
neue Teams werden durch bestimmte Prozesse zusammengesetzt,
um Ende-zu-Ende-Verantwortung für Produkte, für Wertströme, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter,
für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter,
zu etablieren und so Agilität zu fördern, auch Geschwindigkeit zu erhöhen,
Warteliegezeiten aufzulösen und vielleicht dabei dann auch eine Automatisierung zu fördern,
zumindest eine Standardisierung, dass man halt dann gemeinsam in sowas wie Communities of Practice
oder in Gilden zusammenkommt und teamübergreifend dann,
was früher halt in den Silo-Teams passiert ist, über Standardisierung nachzudenken,
welche Tools, welche Werkzeuge setzten wir teamübergreifend für bestimmte Zwecke ein?
Können wir uns auf eine gemeinsame Versionsverwaltung zum Beispiel einigen?
Können wir uns auf eine gemeinsame Art und Weise, Software zu schreiben mit einer IDI einigen,
die dann die meisten Teams einsetzen? Können wir uns auf ein Continuous-Delivery-Pipeline-Werkzeug,
das dann die Informationen aus der Versionsverwaltung aufnimmt, einigen
und dann
da auch
Klarheit schaffen?
Genau, also es ist einfach, es gibt genug Werkzeuge. Ich glaube, es ist die Zusammenfassung.
Das Wichtige ist, dass man sie auch tatsächlich einsetzt und dass man diese Klarheit verteidigt
und sich vielleicht auch ab und zu mal vergewissert, dass die wirklich noch da ist.
Ich hatte zum Beispiel einen anderen Kunden vor einer Weile, die waren gesegnet mit einer Vielzahl von Mitarbeitern,
die einfach schon ganz lange da waren. Das war, also irgendwie, es war schier keiner kürzer als acht Jahre irgendwie
in diesem Unternehmen und auch in diesem Team, was also natürlich für die spricht als Unternehmen, als Arbeitsumfeld.
Aber die Kehrseite davon war, dass so viel Wissen einfach wahnsinnig implizit war.
Und nicht nur für mich als Berater, der da irgendwie von außen reinkam, sondern auch für Leute, die sie jetzt gerade neu eingestellt hatten.
Die hatten solche Schwierigkeiten, Fuß zu fassen, obwohl alle wahnsinnig freundlich und hilfsbereit waren und einem jede erdenkliche Unterstützung haben zuteilwerden lassen.
Aber ganz viel war einfach nur institutionalisiertes Wissen und keiner konnte dir so richtig sagen, warum das jetzt so gemacht wird
oder wie das jetzt läuft oder es gab keine Liste von, keine Ahnung, von Verantwortlichen beispielsweise.
Sondern das weiß man halt, wen man da anruft.
Dann kann man es lernen und dann kann man es entweder aufschreiben oder eben auch nicht aufschreiben und sich merken.
Ja, genau. Und du hast natürlich immer eine Antwort gekriegt. Also die Leute waren da auch ganz toll.
Die haben dieselbe Frage sich auch zehnmal angehört, ohne mit der Wimper zu zucken.
Aber es war halt einfach so.
Ja, genau. Und du hast natürlich immer eine Antwort gekriegt. Also die Leute waren da auch ganz toll. Die haben dieselbe Frage sich auch zehnmal angehört, ohne mit der Wimper zu zucken. Aber es war halt einfach so.
Ja, genau. Und du hast einfach so.
Einfach echt schwierig.
Es hat so lang gedauert da Fuß zu fassen.
Und ganz ehrlich.
Ich hab da so ein bisschen an mir und meinen Fähigkeiten als Berater gezwipfert und ich hab mir gedacht, das kann doch nicht sein, dass du jetzt so lange brauchst, um da irgendwie einen Dreh daran zu kriegen.
Und erst so im Laufe der Zeit und auch im Gespräch mit eben anderen Leuten, die da neu reinkam, hab ich festgestellt, das liegt vielleicht irgendwie doch nicht an mir, sondern es lag halt extra an der Organisation,
die sich da unsichtbarerweise natürlich auch echt selber an Bein gestellt haben.
Nicht nur in Bezug auf das Onboarding von neuen Leuten, sondern vielleicht dann auch für die tägliche Arbeit.
Ich weiß nicht, wie viel da noch irgendwie schwieriger war, als es hätte sein müssen.
Und was habt ihr dann gemacht an der Stelle?
Also wie seid ihr mit dem impliziten Wissen umgegangen, das halt in den verschiedenen Köpfen verteilt war?
Je nachdem.
Also es gibt so gewisse Sachen, da habe ich einfach gesagt, diesen Kampf, den nehme ich jetzt nicht auf,
sondern das steckt einfach so tief in der Organisation drin, das würde meine Möglichkeiten übersteigen, auch meine zeitlichen Möglichkeiten.
Aber ansonsten habe ich mich halt bemüht, da einfach in dieses Dickicht mal Schneisen reinzuschlagen und zu sagen,
gut, wir fangen mal dort an, wo man vielleicht eine leichte Zugänglichkeit hat.
Zum Beispiel in meinem konkreten Fall war das, ich habe mich sehr stark mit den Anforderungen befasst,
die ja, wie gesagt, auch so ein bisschen undurchsichtig flossen und ein bisschen hemdsärmelig gehandhabt wurden oder sowas.
Und das hat halt den Charme, das hängt an einem vergleichsweise überschaubaren Kreis von Leuten.
Du weißt, du musst mit deinen Product Ownern reden, du musst mit deinen Business Ownern reden, solche Sachen.
Und dann kannst du da Klarheit reinbringen.
So wie es üblich ist, gab es da natürlich auch ein riesen Dickicht von Epics, die 2019 zuletzt aktualisiert wurden,
aber nominell irgendwie halt noch aktiv waren.
Und da bin ich halt einfach einmal durchgegangen und habe gesagt, ja, brauchen wir das noch, brauchen wir das noch, ist das noch aktuell?
Und dann…
ging halt zack, zack, zack, auch eine Menge Storys einfach zu.
Ja, und auf diese Weise konnte man die Klarheit erhöhen, könnte man den Grad an, ich nenne es mal Explizitheit, auch so ein bisschen erhöhen.
Und das hat dann auch den Effekt gehabt, dass Entscheidungsprozesse leichter wurden,
weil man sich wieder darauf verlassen konnte, dass zum Beispiel die Sachen, die im Backlog stehen, auch wirklich mit Recht da drin stehen.
Und dass nicht die wesentlichen Themen von solchen, die vielleicht mal wesentlich gewesen sind, maskiert wurden, verdrängt wurden, sonst irgendwas.
Also, lange Rede, kurzer Sinn, ganz auf den Kopf gestellt habe ich, alleiniger Hansel, diese Organisation natürlich nicht,
aber ich habe schon ein paar Breschen geschlagen, ich habe ein paar Aspekte mir gesucht, wo ich tatsächlich irgendwie wirksam werden konnte
und wo ich für mehr Klarheit gesorgt habe und wo sich dann auch Wirkungen eingestellt haben, was nicht nur mich gefreut hat,
weil natürlich ist es immer schön, Erfolg zu haben, sondern es war auch tatsächlich einfach etwas, wo dann auch die anderen gesagt haben,
ja, das hat uns jetzt echt weitergebracht.
Was sind denn die Wirkungen?
Was sind denn die Wirkungen?
Was sind denn die Wirkungen?
Die Wirkung von Klarheit.
Die Wirkung von Klarheit ist, dass die Arbeit, die man von vorne reingesteckt hat, oder das ist vielleicht das Unmittelbarste,
dass die sich hintenrum wieder auszahlt, so wie meine Mutter immer sagt, keiner hat Zeit, sein Zimmer aufzuräumen, aber jeder hat Zeit, seinen Schlüssel zu suchen.
Entweder du klärst die Anforderungen halt vorher oder du klärst sie hinterher, wenn dann ein Kunde ums Eck kommt und sagt, ja, das war jetzt Mist.
Besser ist es, das vorher zu machen, weil du steigerst die Planbarkeit, du steigerst die Verlässlichkeit, auch im Sinne dessen, dass du in der Lage bist, Zusagen einzuhalten.
Für jene, die auf deinen Arbeitsergebnissen aufbauen.
Ich glaube, das ist ein ganz wesentliches Kriterium dafür, wie viel Klarheit herrscht.
Bin ich denn in der Lage, Zusagen abzugeben und die dann auch hinterher einzuhalten?
Weil das ist ja dann häufig das Allererste, was passiert, dass die Leute sagen, also, da kann ich jetzt gar nicht mich dazu äußern, weil das check ich ja gar nicht, was da alles hintendran hängt.
Oder ich weiß gar nicht, wie unsere Auslastung ist.
Ich weiß nicht, wie viel Arbeitsleistung ich dir überhaupt zusichern kann oder sowas.
Das ist natürlich einerseits roter Alarm, aber andererseits.
Auch eigentlich ganz schön üblich, ne?
Ja, gibt es teilweise.
Ich kann nicht einschätzen, wann ich XY liefere.
Kann natürlich daran liegen, dass die Anforderung unklar ist.
Kann aber auch sein, dass es der Ablauf, der Prozess nicht klar ist.
Oder es kann halt auch sein, dass ich gar nicht weiß, wer alles daran beteiligt ist.
Insofern sind das ja alles Stufen von Klarheit, die man schaffen kann.
Die Beteiligten sichtbar machen, die Abläufe sichtbar machen, die Abhängigkeiten, die dabei entstehen.
Und die.
Nicht entstehen, sondern die halt da sind, die dann sichtbar werden.
Und ja, dann in das Aufräumen gehen.
Und das bietet auf jeden Fall eine gute Grundlage.
Kann man Klarheit dann anhand solcher Aussagen, die Häufigkeit, wie sowas auftritt, wie du gerade gesagt hattest.
Ich weiß gar nicht.
Ich muss erst mal nachfragen oder ich kann gar keine klare Zusage oder keine klare Aussage treffen oder sowas.
Sind das Messgrößen, Indikatoren für Klarheit?
Ein Indikator ist, glaube ich, das richtige Wort, weil da spielt natürlich noch mehr rein als nur Klarheit.
Aber umgekehrt, wenn du keine Klarheit hast, dann wirst du dich häufig schwer tun, deinerseits klare Aussagen zu treffen und deine Zusagen dann auch einzuhalten.
Insofern, ich glaube, zum Teil gibt es eben wirklich direkte Indikatoren, wie wir es schon ein paar Mal erwähnt haben.
Das Planning Poker.
Erstens, wie groß ist die Diskrepanz für eine gegebene Story?
Und zweitens vielleicht auch, wenn man einen Schritt zurückkriegt und sagt, wie oft kommt es eigentlich vor,
dass wir da ganz weit divergierende Schätzungen haben?
Hängt natürlich an verschiedenen Wissensständen von unterschiedlichen Mitarbeitern.
Liegt letztendlich, wie lange so ein Team in welchem Bereich schon zusammenarbeitet und so weiter.
Ist ja auch völlig okay, aber wäre natürlich eine Maßzahl oder ein Indikator für Klarheit.
Genau, oder ein Indikatorchen.
Wie du sagst, da spielen natürlich eine ganze Reihe von Faktoren rein.
Aber man sieht ja schon so.
Man kann Tendenzen ablesen, das bestimmt.
Insofern solche Vergleichswerkzeuge.
Andererseits eben auch als leider ziemlich stark nacheilenden Indikator kann man sagen,
wie verlässlich bin ich denn eigentlich?
Wie gut kann ich denn Zusagen einhalten?
Ich überlege auch gerade, ob es irgendwelche voreilenden Indikatoren gibt, die mir einfallen.
Aber da komme ich jetzt gerade auf nichts wirklich Gewichtiges.
Ja gut, man könnte natürlich all die Dinge, die wir jetzt als hilfreiche Werkzeuge zum Schaffen von Klarheit aufgeführt haben,
aufgeführt haben.
In einem Unternehmen suchen, also zu schauen, gibt es, gibt es so etwas, gibt es Verantwortlichen, gibt es Kontaktlisten, gibt es ein Glossar, gibt es also eine Checkliste, durch die man gehen kann und wird regelmäßig so etwas auch aktualisiert, wäre dann die zweite Stufe.
Also gibt es letztendlich einen aktuellen Stand von all diesen Dokumentationen?
Gibt es ein Onboarding Dokument für Mitarbeiter, das auf dem aktuellen Stand ist?
Gibt es Entwicklerrechte?
Ich denke auch, dass die DORA-Metriken ganz, ganz interessant sind, was auch Klarheit angeht.
Wenn man überlegt, wenn man im DevOps-Umfeld darüber nachdenkt, sowohl Stabilität als auch Geschwindigkeit in Veränderungen zu haben, ist ja DevOps da, Continuous Delivery da.
Und da war ja eine von den Dingen, die auf alle Output-Metriken im System von Softwareentwicklung und Co. Einfluss hatten, ist denn,
alles in der Versionsverwaltung.
Dann ein Single Point of Truth, bei dem letztendlich alle Informationen nachlesbar, schriftlich dokumentiert sind und dann vielleicht auch darauf aufbauend Automatisierungsprozesse und Co. ablaufen können.
Genau, da hast du recht. Also da gibt es eine ganze Reihe von solchen Indikatoren darüber, ob sich überhaupt jemand mal die Mühe gemacht hat.
Ob es solche Informationssammlungen gibt, dann gibt es immer noch diese sekundären Fragen, ist das denn noch alles aktuell, sind die Adresslisten noch korrekt und so weiter und so weiter.
Ja, ja, aber immerhin hat man da schon mal Zeichen.
Genau, also ich würde sagen, ähnlich zur Versionsverwaltung in der Softwareentwicklung und im IT-Betrieb sehe ich, was Wissensmanagement und Kommunikation zwischen Menschen angeht, den Einsatz von einem Wiki in einem Unternehmen.
Hat ein Unternehmen ein Wiki und wird das genutzt und ist es gepflegt. Also eine zentrale Wissensquelle. Das kann jetzt ein Sharepoint sein, wenn das gut genutzt und gepflegt wird.
Das kann ein Wiki sein.
Das kann eine Dateiablage irgendwo sein, wie auch immer es ausgeprägt ist, ist dann wieder die Frage, wie gut ist es anpassbar, editierbar, wird es gepflegt, ist es genutzt und wird es auch regelmäßig aufgeräumt.
Also das, was du gerade gesagt hattest, wo dann die externe Sicht von einem Berater hilfreich ist, zu schauen, okay, lasst uns doch mal wirklich die Zeit nehmen und investieren in, wie läuft denn der Informationsfluss bei der Anforderungserhebung über die verschiedenen Ebenen, Portfolio, Management, Produkt.
Teams und Co. genau ab, wo sind Informationsquellen, wo sind Informationssenken und wo sind zwischendrin irgendwelche Sicherstellen.
Gut und um den Bogen nochmal zurückzuschlagen zu diesem ganzen DevOps-Thema.
Wichtig ist es eben gerade, wenn man in Richtung einer Transformation geht, einer DevOps-Transformation oder sowas, dass man Klarheit hat.
Erstens, wohin man eigentlich will mit so einer Transformation und dass man zweitens sich im Vorfeld oder im Zuge dessen oder wie auch immer,
sich seine Vorgehensweisen, seine Prozesse und so weiter genau anschaut, um zu vermeiden, dass man einen unscharfen Prozess dann irgendwie versucht zu automatisieren,
was entweder ins Auge geht oder, wenn man Pech hat, gelingt es sogar und dann hat man einfach irgendwas Unscharfes in Stein gemeißelt.
Aber dann hat man es zumindest scharf aufgeschrieben. Finde ich gar nicht so schlecht.
Also wenn man es jetzt automatisiert hat, dann steht es schriftlich festgehalten in einer Continuous Delivery Pipeline irgendwo.
Ein Toolkit.
Dann werden die Daten übergeben von X nach Y, auch wenn es nicht optimal ist, dann hat man es zumindest schriftlich und kann darauf aufbauen und eine gute Analyse fahren.
Ein paar Gedanken hatten wir uns noch aufgeschrieben. Feedback. Braucht man Feedback zum Thema Klarheit? Braucht Feedback Klarheit? Braucht Klarheit Feedback?
Naja, also ich glaube, Feedback braucht Klarheit, weil sonst ist es ja unklar, wozu man Feedback gibt und braucht Klarheit.
Feedback, ja, ich glaube, das haben wir auch schon ein paar Mal besprochen im Sinne dessen, es ist möglich und es ist bestimmt auch klug,
sich zu vergegenwärtigen, inwieweit oder wie groß der Grad an Klarheit momentan ist in dem Betrachtungsgegenstand.
Habe ich aktuelle Listen von Zuständigkeiten? Mache ich einen Planning Poker bzw. was beobachte ich in meinem Planning Poker?
Und so fort, dass man rechtzeitig auch gegensteuert, wenn man merkt, dass Prozesse da so ein bisschen ins Unscharfe abgleiten und irgendwelche Diffusionsprozesse einsetzen.
Was mir als Feedback im Rahmen der…
gerade erwähnten Schulung aufkam zum Thema Klarheit und Agilität und Ziele und so weiter, dass das auf allen Ebenen stattfinden muss, also auch Klarheit nicht nur auf der Team-Ebene oder für die einzelnen Individuen, sondern dass das halt in die Abteilungsstrukturen, in der Hierarchie bis nach ganz oben in die Führungsebene des Unternehmens gilt.
Also dass Klarheit auf der Ebene von Geschäftsleitung, Abteilungsleitung notwendig ist, um dann Strukturen darzustellen.
Danach auszurichten, um dann Teams in die richtige Richtung aligned, also auf das gleiche Ziel hin arbeiten, zusammenführen kann.
Ja, da hast du vollkommen recht. Ich glaube, je weiter man nach oben geht, desto wichtiger ist es.
Das habe ich eben gesehen bei einem Kunden von mir, wo von oben runter ein Mangel an Klarheit herrscht.
Wie ich gesagt habe, die machen halt irgendwas mit Agil oder auch nicht oder weiß nicht so genau.
Und entsprechend ist jetzt die ganze Organisation so ein bisschen…
An der Kippe zum Dysfunktionalen, trotz heldenhafter Bemühungen.
Aber es gibt halt einfach keine Klarheit, was wollen wir denn machen?
Wo geht die Reise denn hin? Wer darf denn irgendwas oder auch nicht?
Und das ist eine große Gefahr.
Deswegen bin ich auch immer unglücklich darüber, dass so viele Organisationen eine ganz, ich sage jetzt mal, lieblos gemachte Vision und Mission haben.
Das braucht es halt irgendwie.
Ich möchte, dass das etwas ist, was ich bei jeder Sprintplanung vorne ans Whiteboard schreiben kann, bevor wir in die Sprintplanung reingehen.
Damit ich sagen kann, okay, das, was wir uns jetzt zurechtgelegt haben als nächste Arbeitsschritte, zahlt das auf unser großes Ziel ein.
Wenn das große Ziel natürlich Mumpitz ist, dann mache ich halt irgendwas.
Also insofern sind so eine Zielhierarchien, wie sie ja mit Tractors und Key Results aufgebaut werden, natürlich ganz hilfreich,
wenn man Unternehmensziele hat, die man runterbrechen kann auf die verschiedenen Abteilungen, Teams, Gruppen, wie auch immer das Unternehmen strukturiert ist,
um dann halt zu sehen, dass das einzahlt auf das Unternehmensziel.
Das ist letztendlich hilfreich und wertvoll, ja.
Ja, ich würde sogar noch einen Schritt weiter gehen und sagen, es ist unerlässlich.
Also wenn du da nichts hast und wenn du das nicht wirklich mit deinen Mitarbeitern durchdeklinierst.
Ich finde das immer so ein bisschen schade, wenn ich irgendwo ein Training gebe und dann frage ich die Trainingsteilnehmer,
habt ihr eine Vision oder sowas?
Und dann sagt einer, ja, warte mal, ich glaube, wir hatten da irgendwo eine Präse im Internet, lass dich mich mal raussuchen oder so.
Das muss den Leuten doch bewusst sein.
Warum gehen die denn in dieses blöde Büro?
Oder heutzutage gehen sie nicht mehr ins Büro.
Sondern nur ins Remote-Arbeitszimmer.
Ja, letztendlich kann man das machen.
Dann hat man vielleicht ein erfolgreiches Unternehmen.
Oder man lässt es sein, dann hat man vielleicht trotzdem ein Unternehmen.
Auch wenn das nicht unbedingt zu den Top-10-Unternehmen gehört, die in einer Branche irgendwo Marktführer und so weiter sind.
Für viele funktioniert es ja auch mit Unklarheit.
Ja, das ist ja immer so.
Man bemüht sich ja immer, die Sachen irgendwie möglichst gut zu machen.
Aber wie viele Organisationen gibt es, die einfach…
Die einfach wahnsinnig ungeordnet sind und deswegen überleben, weil das halt irgendwie ganz vielen Organisationen so geht.
Sagen wir mal ehrlich.
Aber nichtsdestotrotz lohnt es sich natürlich, in Richtung Verbesserung zu streben.
Selbst wenn man nur noch einen weiten Weg zurückzulegen hat und vermutlich auch nie erreichen wird.
Gut.
Aber ich glaube, das war ein gutes Wort zum Sonntag.
Wir müssen, glaube ich, schauen, dass wir diese Episode mal in den Kasten kriegen.
Ja, völlig okay.
Passt für mich auch.
Appell an alle, aufräumen.
In eurem…
Prozessen, in euren Datensammlungen, in eurem Verständnis und dann drüber reden und eine gemeinsame, klare Sicht schaffen.
Auf geht’s.
Genau.
Auf geht’s.
Es gibt viel zu tun.
Fangt schon mal an.
Ja, gilt für uns auch.
Wir haben auch ein paar offene To-dos.
Das eine oder andere.
Vielen Dank für das nette Gespräch.
Ich denke, wir haben ganz…
Interessante Beiträge.
Und natürlich auch gespannt, wie das bei unseren Hörern so ankommt, wenn ihr Feedback an uns habt.
Tipps und Tricks zu Klarheit können wir auch gerne in eine Folge aufnehmen mit Gästen oder mit neuem Input.
Weißt du, was ich mir denke, Falko?
Das wäre ein schönes Thema gewesen, auch mal für eine Live-Folge, irgendwie so eine Live-Q&A-Folge.
Das müssen wir mal ins Auge fassen.
Auch das?
Sehr gut.
Sehr schön.
Also, sehr geschätzte Zuhörerinnen und Zuhörer.
Also, vielen Dank, dass ihr auch dieses Mal wieder mit dabei wart.
Ganz vielen Dank auch lieber Falko für diese schöne Episode.
Ich wünsche euch allen eine ganz tolle Zeit.
Macht’s gut.
Ja, vielen Dank.
Ciao.