In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ sprechen Falko, Luca und ihr Gast, der Systembiologe und Berater Peter Jetter, über die Defragmentierung von Organisationen. Sie diskutieren, wie fragmentierte Prozesse, Strukturen und Glaubenssätze die Sicht auf das Gesamtunternehmen erschweren und wie Agilität, Autonomie und eine ganzheitliche Sichtweise helfen können, diese Herausforderungen zu bewältigen. Es wird erörtert, wie verschiedene Methoden wie Scrum, Kanban und DevOps angewendet werden können, um eine effektivere und integrierte Arbeitsweise zu fördern.
Inhalt
- Einführung und Biografie des Gastes Peter Jetter
- Definition und Bedeutung von DevOps
- Die Herausforderung der Defragmentierung von Organisationen
- Autonomie und Zusammenarbeit in agilen Organisationen
- Der Einfluss der Industrialisierung und Massenfertigung auf moderne Organisationsstrukturen
- Vergleich zwischen traditionellen und innovativen Produktionsprozessen (Beispiel: Tesla)
- Bedeutung von Continuous Integration und Continuous Delivery in der Softwareentwicklung
- Die Rolle von Kommunikation und Transparenz in Organisationen
- Anwendung von agilen Praktiken auf Organisationsentwicklung
- Diskussion über verschiedene agile Frameworks und deren Anwendung
Shownotes
https://www.meetup.com/AgileMunich/
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, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Wir freuen uns heute auf das Thema Defragmentierung von Organisationen.
Zu Gast haben wir Peter Jetter.
Er ist ein ehemaliger Systembiologe, der als Berater, Trainer und Enterprise Coach
seit 20 Jahren Konzerne bei agilen Transformationen unterstützt.
Hallo Peter, schön, dass du da bist.
Hallo, danke für die Einladung.
Was ist denn deiner Biografie noch hinzuzufügen?
Was ist denn eigentlich ein Systembiologe?
Ja, es ist ein ziemlich interessanter,
disziplinäres Feld mit der schönen Abkürzung Eko, Evo, Devo.
Also Ökologie, Evolution und Entwicklungsprozesse.
Wie hängt die Entwicklung des Teils mit der Evolution des Ganzen zusammen?
Wie spielt das Ganze auf das Teil und das Teil auf das Ganze solche Wechselwirkungen?
Und das kannst du auf verschiedenen Skalen machen.
Sprich, wie wirkt eine Zelle und der Gesamtorganismus zusammen?
Oder ganz global galaktisch?
Wie hat der Alten?
Einfluss der Biosphäre auf dem gesamten Planeten, des Ökosystems, auf die einzelnen Lebewesen im
Ökosystem und andersrum, wie vom sozusagen die Teile des Ökosystems auf das Ökosystem und solche
Dinge. Und Systembiologie hat eben auch was mit Systemthinking, Systemmodellierung und
Systemtheorie zu tun. Ich habe eben dann kybernetische Modelle, sprich am Computer,
von verschiedenen komplexadaptiven Systemen gemacht, von Gehirnen, Immunsystemen, Ökosystemen,
pipapo. Und das ist auch was, was mir tatsächlich in meiner Arbeit mit Organisationen, die auch
komplexadaptive Systeme sind, hilft. Sehr spannend. Wir haben in diesem Podcast eine
Tradition, dass wir jeden Gast nach seiner persönlichen Definition von DevOps fragen.
Peter, was ist denn deine? Also aus dem Bauch raus eine Sammlung von
Prinzipien und Praktiken sowie einer Kultur der Zusammenarbeit und Shared Ownership zwischen in
der Regel Softwareproduktentwicklung und IT-Betrieb. Okay, wunderbar. Dankeschön. Und das bringt uns
vielleicht dann auch genau schon in das Thema rein, um das es heute gehen soll. Wir haben sie
genannt Defragmentierung von Organisationen. Was meinen wir denn eigentlich mit der
Fragmentierung von Organisationen? Also wir erleben gemeinsam ja gerade bei
einem Kundenprojekt, dass die Organisation in vielerlei Hinsicht fragmentiert ist. Wir haben
fragmentierte Prozesse, wir haben fragmentierte Strukturen, wir haben fragmentierte mentale Modelle,
wir haben fragmentierte Glaubenssätze und so weiter. Also es hat eine starke Verinselung auf
ganz vielen Ebenen stattgefunden und die erschweren es, eine gemeinsame Sicht des Gesamtunternehmens zu
erzeugen. Das ist eine große Herausforderung. Das ist eine große Herausforderung. Das ist eine große
Herausforderung. Das ist eine große Herausforderung. Das ist eine große Herausforderung. Das ist eine große
Herausforderung. Das ist eine große Herausforderung. Das ist eine große Herausforderung. Das ist eine große Herausforderung.
Wie wenn ich versuche, in einen Spiegel zu schauen, um mich selbst zu erkennen. Der Spiegel ist aber in tausend Teile
zerbrochen. Okay, also ihr seid beide gerade bei einem gemeinsamen Kunden aktiv. Ich bin da jetzt als
Mitco-Host hier in der Runde nicht ganz so drin. Wie lange hat sich das bei dem Kunden so entwickelt und
wo seht ihr den Grund für diese Defragmentierung? Sind das einfach eine Kultur in der Organisation,
die in die Richtung geht, jeder darf machen, was er will? Oder gibt es andere Quellen für diese
Fragmentierung, für diese Aufteilung, diese Inseln? Also ich denke, die Gründe sind vielfältig
natürlich. Aber eine davon ist ganz sicher die Management-Denke der letzten 100 Jahre, die halt
stark aus der Industrialisierung geprägt ist. Und in der Industrialisierung hat man eben stark auf
die Arbeitsheiligkeit geachtet. Und in der Industrialisierung hat man eben stark auf die
Arbeitsheiligkeit gesetzt. Und der Erfolg von Unternehmen in der industriellen Revolution oder im
industriellen Zeitalter, der Inhalt hauptsächlich davon ab, wie effizient kann ich etwas Bekanntes
wiederholen. Also Stichwort Massenfertigung. Da geht es ja nicht darum, innovativ zu sein und jedes Mal
was anderes zu machen, sondern der Geschäftserfolg hängt vornehmlich davon ab, wie gut gelingt es mir,
sehr oft genau das Gleiche zu tun.
Und das kosteneffizient zu machen. Während zum Beispiel heutzutage in einer Wissensgesellschaft
Geschäftserfolg sehr stark an Innovation hängt. Und das heißt letzten Endes jedes Mal was Neues,
anderes machen. Und das ist ein ganz anderer Prozess wie in der industriellen Massenfertigung.
Also die einen reden in der Massenfertigung von einem exploitativen, also einem ausbeutenden Prozess,
immer das Gleiche machen. Und in der Industriellen Revolution, in der Industriellen Revolution,
in der Innovationskultur, Wissensgesellschaft, explorativen Prozess. Also es geht immer um die Entdeckung und Erforschung des Neuen.
Und das sind halt zwei unterschiedliche Paar Stiefel, die auch unterschiedliche Vorgehensmodelle und Strategien benötigen.
Aber an der Stelle möchte ich jetzt ganz gerne nochmal einhaken, weil wir haben ja gerade so ein bisschen begonnen zu lamentieren,
dass eine gewisse Fragmentierung herrscht, dass eine Insularität vielleicht auch herrscht.
Die beobachten wir jetzt gerade bei unserem gemeinsamen Kunden Peter.
Aber das ist ja irgendwie jetzt nichts Außergewöhnliches, sondern das gibt es ja irgendwie eigentlich immer und überall.
Jetzt gibt es aber nur eine Sache, die mich dabei wundert, nämlich reden doch die ganzen Agilisten immer davon,
dass man Autonomie haben müsse. Insofern ist das denn nicht eigentlich genau das Gewünschte, dass man sagt,
jeder macht halt irgendwie sein Ding, solange es für ihn passt, ist doch alles schön.
Wieso ist jetzt einerseits Fragmentierung böse, aber Autonomie gut? Wie geht das zusammen?
In der Architektur haben wir auch so ein Grundprinzip, das heißt,
Loose Coupling, aber High Cohesion. Und die zwei Aspekte der gleichen Münze werden halt leider vergessen,
dass es die gleiche Münze sind und alle auf Loose Coupling gucken, aber das High Cohesion aus den Augen verlieren.
Und eben auch in diesem industriellen Zeitalter mit der Wiederholung des Bekannten ist es natürlich so,
dass zum Beispiel durch das Fließband jegliche,
jegliche Entscheidungen vorweggenommen sind und es sozusagen eigentlich keine Kommunikation mit meinem Upstream- oder Downstream-Prozess stattfinden muss.
Also konkret haben wir so beschrieben, wenn ich den linken Autospiegel hinschraube, dann muss ich nicht mit dem reden,
was macht der im Prozessschritt vor mir und was macht der im Prozessschritt nach mir.
In einer Entwicklungsumgebung wird das so nicht funktionieren.
Na gut, aber machen wir das nicht.
Das ist natürlich auch so in dem Umfeld Softwareentwicklung, wenn wir von Continuous Delivery Pipelines reden und dann halt sagen,
wir bauen alle Prozesse in ein Software-Fließband, in Continuous Delivery Pipeline und bringen das Ganze dann in genau diesen,
man muss nicht mehr miteinander reden, weil am Anfang schüttet der Entwickler ein neues Stück Quellcode in die Pipeline
und am Ende kann der Nutzer ein neues Stück Software nutzen, neue Funktionalität,
neues Feature, ohne dass man da groß drüber reden muss.
Zum Teil, also alles, was sozusagen Regression-Test ist, wo es ja um die Wiederholung des eben bereits Bekannten ist, ja,
aber am Anfang ist ja was anderes, also wenn ich Test-Driven-Development mache, schreibe ich ja jedes Mal einen anderen Test,
einen anderen Code und erst, weil der automatisierte Test dann da ist und zwar ein neuer, den es vorher nicht gab,
kann ich das dann…
…durch die Pipeline bis nach hinten durchschieben.
Also ich verändere ja sozusagen jedes Mal das Produktionsband, das Fließband, indem ich eben die neuen Tests, die den neuen Code abprüfen, hinzufüge.
Das ist auch ganz interessant, wenn man darüber nachdenkt, weil ein Fließband, um diese Metapher zu verwenden,
ist ja dann quasi das Gegenteil dessen, was wir gerne wollen, das ist High Coupling.
Alle Arbeitsstationen sind eng miteinander verknüpft durch dieses gemeinsame Fließband, aber Low Cohesion.
Ich habe keine Veranlassung.
Ich habe keine Veranlassung, auf den rechten Außenspiegelanschrauber einzuwirken, wenn ich der linke Außenspiegelanschrauber bin.
Ich habe aber auch schlicht und ergreifend gar keine Möglichkeit, das Fließband lässt das ja gar nicht zu.
Also selbst wenn ich ganz gerne mit ihm gemeinsam was verändern wollte…
Gut, wenn wir jetzt mal das Thema Fließband und Entwicklung mal ein bisschen weiter betrachten, dann haben wir ja, wenn ich mir irgendein Massenprodukt, nehmen wir mal ein Auto,
da gibt es eine Entwicklungsabteilung in der Organisation, die vielleicht auch agil arbeitet, die auch iterativ arbeitet, neue Varianten entwickelt und Co.
Und dann gibt es irgendwo dieses Fließband, was die Produktion macht, was dann die festgelegten Prozesse umsetzt und was immer mal wieder passiert, sind ja sowas wie Modellupdates, neue Versionen von einem Modell und Co.
Ich sehe aber Köpfe schütteln, die man beim Podcast nicht so wirklich sehen kann. Bin gespannt, wie ihr darauf reagiert.
Das ist für mich genau der Unterschied zwischen dem, was ein Herr macht, bei Tesla macht und was die meisten Deutschen…
Automobilhersteller machen. Das, was ich so wahrnehme und natürlich sehe ich nur einen winzigen Teil und das kann man nicht verallgemeinern, ist, dass im Großen und Ganzen es immer noch einem Wasserfallprozess folgt, im Sinne, ich analysiere alles, ich designe alles und dann entwickle ich alles.
Sprich, ich lege von vornherein fest, wie schaut das neue Auto aus, dann wähle ich mein Fertigungsband entsprechend um und dann habe ich zwar ein anderes Fertigungsband, das kann aber wieder…
Ich kann nur sozusagen 10.000 Euro mal den gleichen Typ herstellen. Also natürlich gibt es gewisse Variationsmöglichkeiten, die sind aber relativ gering. Während das, was ein Herr Maas bei Tesla macht, ist, der kann für jedes einzelne Auto einen anderen Produktionsprozess benutzen und trotzdem ist jedes Fahrzeug, das da durchläuft, auditiert und hat eine Straßenzulassung.
Der kann also bei jedem…
Durchlauf den Prozess und das Fertigungsband verändern und das sehe ich bei anderen Automobilherstellern nicht und das haben die meines Erachtens, glaube ich, so auch noch nicht gar nicht verstanden.
Ja, sehe ich auch so. Normalerweise ist der Ansatz, du hast einen Prozess, der alle bestehenden Kombinationen von Produkten umsetzen kann. Also du kannst halt im besten Fall über einen Fertigungsband den Kleinwagen des SUV in allen Farbvarianten, in allen Ausstattungsvarianten irgendwie…
100 Millionen verschiedene Ausprägungen von Fahrzeug herausbringen, aber du kannst den Prozess dabei nicht ändern. Ja, okay.
Wir sind ja bei Defos, wo es so ganz viel um CICD Continuous geht und das, was ein Herr Maas gegeben hat, ist Continuous Compliance. Das heißt, jedes Mal, wenn er seinen Prozess ändert, wird aber mit jeder Änderung auch gleich die Auditierung und Zertifizierung mit abgefrühstückt.
So dass eben hinten immer ein…
Straßen zugelassenes Auto rauskommt.
Um das auch nochmal zu sagen, ich glaube, das ist eines der großen Probleme in vielen Organisationen, dass man versucht, das gedankliche Modell eines Fließbandes anzuwenden auf Dinge, die überhaupt nicht Fließbandcharakter haben.
Zum Beispiel eine Softwareentwicklung und daraus resultieren dann viele, ich nenne es mal Missverständnisse, Missverhältnisse, Misskonstruktionen vielleicht, die dann ja auch häufig dazu führen, dass auf niedriger Ebene dann versucht wird, irgendwie daran was zu ändern.
Die Leute werden dann in ein Fließband…
Ein Schema gepresst, von dem sie intuitiv oder vielleicht sogar ausdrücklich wahrnehmen, das passt nicht zu der Art, wie ich arbeiten nicht nur möchte, sondern muss, wenn da was Vernünftiges dabei herauskommen soll.
Und dann kommt es halt, dass dann irgendwie sich auf niedriger Ebene Dinge entwickeln.
Da gibt es dann die berühmten U-Boote, irgendwelche neuen Arbeitsweisen werden informell eingeführt, irgendwelche Tools werden informell eingeführt.
Der berühmte Grassroots-Ansatz.
Genau, wir können ja sozusagen das Gegenbeispiel machen.
Also ich habe auch…
Und also stell dir vor, da kommt jetzt einer und sagt, so, ich möchte jetzt in drei Jahren ein Medikament gegen Magenkrebs auf den Markt bringen.
Analysier mir das, design mir die Lösung, mach mir einen Plan, was genau wann zu welchem Zeitpunkt stattfindet, dass ich in drei Jahren dieses Medikament auf den Markt bringen kann.
Das wird nicht funktionieren.
So funktioniert Forschung und Entwicklung.
Das funktioniert Forschung eben nicht, weil ich nicht weiß, was ich alles entdecken werde und was das für Konsequenzen dann nach sich zieht.
Darum heißt es eben genau Forschung und Entdeckung, weil eben die Informationen, die auftauchen, jetzt, heute so nicht vorhersagbar sind.
Ja, also finde ich auf jeden Fall spannend.
Ich fand es ganz nett.
Ich habe jetzt einen Fernsehfilm zum Tunnelbau in der Schweiz, Gotthard Tunnel, letztens gesehen.
Und diejenigen, die das gemacht haben, haben darauf gewettet, dass mit der bestehenden Technik hätten sie es zeitlich nicht im Rahmen des Budgets geschafft, dass die Entwicklung voranschreitet und was dann mit Dynamit auch gut funktioniert hat, dass sie den Vortrieb im Tunnel von zwei Metern am Tag auf vier und dann letztendlich auch auf sechs und mehr schaffen, um in der Zeit, in dem ursprünglichen geplanten Vorgehenszeitraum das Ganze zu schaffen, darauf zu wetten, dass die Entwicklung voranschreitet und was dann mit Dynamit auch gut funktioniert hat, dass sie den Vortrieb im Tunnel von zwei Metern am Tag auf vier und dann letztendlich auch auf sechs und mehr schaffen, um in der Zeit, in dem ursprünglichen geplanten Vorgehenszeitraum das Ganze zu schaffen, darauf zu wetten, dass die Entwicklung voranschreitet und was dann mit Dynamit auch gut funktioniert hat, dass sie den Vortrieb im Tunnel von
Das heißt, da gibt es natürlich eine ganze Menge Risiken, wenn man so vorgeht. Das kann natürlich auch nach hinten losgehen. Neue Techniken bringen halt auch neue Risiken. Wie kann man so etwas in einer Organisation anwenden?
Ich war vor vor 20 Jahren für 15 Jahre in der Telekommunikationsindustrie und die hat auch ziemliche Umbrüche hinter sich, also so vom Staatsmonopol zur Privatisierung von einem Technologiestack, der 20 oder 25 Jahre lang ziemlich stabil war.
Alles dann plötzlich All-IP über den Haufen geworfen, Business-Modelle von ich verdiene mich ziemlich gut mit Long-Distance-Calls und SMSen, fällt alles weg.
Und da war es dann auch so, da waren wir immer auf der Suche nach der nächsten Killer-Applikation, Killer-Anwendung, Killer-Telekommunikationsdienstleistung, die wieder die Cash-Cow wird.
Blöderweise konnte man aber nicht vorhersagen, welche der vielen Ansätze da ertragen kommen. Und letzten Endes ist es dann auch überhaupt keins geworden, sondern eine Mischung aus vielen verschiedenen Dingen.
Und da hat man eine sogenannte Shotgun-Schrotschuss-Strategie gefahren.
Das heißt, ich muss tatsächlich 30 verschiedene Produkte, 30 verschiedene Dienstleistungen, also was weiß ich, Location-Based-Services, Presence, Rich-Communication, blablabla, unterschiedlichste Dinge auf den Markt werfen.
Und mir sind vornherein klar, von diesen 30 Versuchen werden maximal 5 am Markt erfolgreich sein.
Und die müssen so erfolgreich sein, dass sie den Fehlschlag der anderen 25 wirtschaftlichen…
Also ähnlich wie das Venture-Capitalisten machen, die in kleine Firmen investieren, in der Hoffnung, dass halt eine von 10 die Investitionen in die anderen 10 mehr als wettmacht.
Ganz genau. Und letzten Endes ist es so, mit dieser Unsicherheit muss ich eben mit dieser Art von Experimentieren und Unsicherheit leben können.
Und mir muss eben völlig klar sein, ich kann Aussagen machen über so ein Set von Versuchen und Experimenten,
dass, wenn ich das mit 10 oder 20 mache, dass dann die Chance relativ gut ist, damit überlebensfähig zu sein.
Für das einzelne Element innerhalb diesem Set kann ich überhaupt nicht vorhersagen, wird es erfolgreich sein oder nicht.
Wir haben uns so ein bisschen, glaube ich, gedanklich entfernt von dem Aufhänger des Podcasts, nämlich diesem Thema von Defragmentierung.
Insofern würde ich ganz gerne den Podcast selber ein bisschen defragmentieren.
Und vielleicht ist das, was du gesagt hast, Peter, da auch ein ganz guter Aufhänger dafür.
Dass solche Schrott-Schüsse nur dann gut funktionieren, wenn man einerseits den verschiedenen, ich nenne es mal Schrottkugeln,
den verschiedenen Teams oder sowas, ausreichend viel Autonomie zubilligt, dass die da was hinkriegen.
Aber andererseits muss man natürlich auch die Kontrolle behalten über diese Gesamtheit von Einzelelementen, die alle ihre eigene Trajektorie verfolgen.
Und insofern würde ich ganz gerne nochmal eben die Frage stellen, wie sieht das denn in Organisationen typischerweise aus?
Welche Probleme finden wir? Welche Fragestellungen finden wir? Und welche Lösungsansätze haben wir da vielleicht?
Also mir begegnet dieses Thema Fragmentierung seit 20 Jahren bei praktisch allen Kunden.
Eben weil, wie organisiere ich ein großes Unternehmen von genau diesen Gedankenmodellen des industriellen Zeitarters mit der Arbeitsteiligkeit und Pipapo geprägt ist.
Und wenn man sozusagen jetzt auf diese Arbeitsteiligkeit nur den winzigen Teilaspekt der Agilität, Autonomie draufhängt,
dann kann das zur Folge haben, dass sozusagen jeder dieser einzelnen Teile sich losgelöst von den anderen selbstständig macht und wie du gesagt hast, in unterschiedliche Richtungen läuft.
Und das führt zum einen dazu, dass gesamtheitlich relativ wenig hinten rauskommt, obwohl jeder Teil für sich enorm belastet und vor sich hin rödelt und busy ist.
Aber eben sozusagen.
Durch die Reibungsverluste, der Unabgestimmtheit und sozusagen die meiste Wirkung schlichtweg verpufft.
Dann muss man sich eben überlegen, ja, worin besteht denn diese innere Reibung und warum passt das nicht zusammen und wie können wir es denn wieder passend machen, sodass hinten eben wieder was dabei rauskommt.
Und das hat mit allerlei Zielkonflikten, Systembrüchen, Pool-Landschaft, schlechten Interfaces.
Verlustbehafteten, Übergaben und allen möglichen Dingen zu tun.
Und das wird für jedes Unternehmen, wenn die sich das anschauen, werden die da sozusagen andere Muster sehen und die Antwort für das eine Unternehmen, hey, was ist jetzt der erste Schritt, um da ein Stück besser zu werden, wird wahrscheinlich anders ausschauen, als wenn die gleiche Frage in einem anderen Unternehmen gestellt wird.
Das heißt, was dann konkret zu tun ist, wird sich von Unternehmen.
Zu Unternehmen unterscheiden, aber letzten Endes muss es natürlich darauf rauslaufen, diese Fragmentierung so weit zu überwinden, dass wir A in der Lage sind, das Unternehmen als Ganzes, das System als Ganzes wieder sichtbar zu kriegen, weil dann können wir uns einigen, was sehen wir da denn?
Dann kann man sich einigen und was bedeutet das?
Und dann kann man sich einigen, was machen wir jetzt damit?
Also sind für mich sozusagen wieder die Rückführungen.
Auch die drei Säulen von Scrum, Transparency, Inspect and Adapt.
Ich muss erst Sichtbarkeit herstellen, dann kann ich es angucken und bewerten und dann kann ich Adapt, kann ich sagen und was mache ich jetzt damit?
Ja, da sagst du, glaube ich, auch was Wahres.
Insofern, als ich noch sehr lebhaft in Erinnerung habe, ich hatte mal einen Kunden, das war eine kleine Bude.
Also ich glaube nicht, dass die in Entwicklungsabteilung 20 Leute hatte.
Ich habe sie nie gezählt, offen gestanden.
Aber das war also.
Wirklich, die konnten sich auch alle sehen.
Das war noch in seliger Vor-Corona-Zeit.
Die saßen wirklich alle in benachbarten Büros, sogar mit Glastüren und so.
Aber nichtsdestotrotz gab es keine Transparenz und Klarheit darüber, was eigentlich gerade passiert in dieser Entwicklungsabteilung.
Für welchen Kunden machen die gerade was?
In welchem Stand ist es?
Welche Aspekte der Maschine, die dort entwickelt wurde, befinden sich in welchem Zustand?
Also insofern, ich glaube, man muss sich ganz bewusst sein, sowas passiert.
Wahrscheinlich sogar, wenn man nur zu zweit arbeitet.
Und es wird wahrscheinlich nicht besser, je größer die Organisation wird.
Genau.
Also für mich eben immer diese Metapher mit dem zerbrochenen Spiegel.
Die Unternehmen können sich nicht selber erkennen, weil der Spiegel eben zerbrochen ist.
Und dann ist sozusagen die Aufgabe, den Spiegel peu à peu wieder zusammenzusetzen und ein realistisches Selbstbild zu kriegen, um dann beurteilen zu können,
schaut das Bild denn so aus, wie es ausschauen soll?
Und nicht.
Was soll anders sein und was müsste man tun, um es anders zu machen?
Aber dann, also um zum Beispiel das Beispiel zu verwenden des Unternehmens, in dem wir jetzt gerade uns gemeinsam befinden, Peter und ich.
Die einzelnen Bereiche des Unternehmens verwenden von mir das Azure DevOps und andere verwenden bestimmt Jira und noch andere haben einfach nur gute alte Excel-Tabellen.
Auf die Weise, da stimme ich dir zu, kriegt man natürlich keine gemeinsame Sicht hin.
Aber ich stelle mir jetzt die Frage, was macht…
Was mache ich denn da jetzt konkret?
Ich meine, selbst wenn ich jetzt hingehe und sage, Excel-Tabellen sind verboten, dann muss ich ja trotzdem…
Die lösen sich nicht von alleine in Luft auf.
Ich muss eine Alternative schaffen auf Prozessebene, auf technischer Ebene, auf kultureller Ebene vielleicht gleich gar.
Also das…
So schlaue Berater wie McKinsey und so, die haben da natürlich gleich ein Wort dafür gefunden.
Reverse Conway Manoeuvre.
Also sprich, dieses Conway’s Law.
Dass Organisationen sozusagen…
Dazu verdammt sind, ihre Informationsstrukturen dann in ihren technischen Systemen abzubilden und der Weg ist dann sozusagen, das genau andersrum wieder zurückzuführen.
Also indem ich sozusagen die technischen Systeme wieder zusammenschließe zu einem einheitlichen Ganzen, folgt dann sozusagen auch die Information und das Gedankenbild der Organisation.
Und…
Ja, war es eben so, dass genau das passiert ist.
Man hat sich sozusagen auf einer relativ hohen Abstraktionsebene, aber immerhin sozusagen auf einen gemeinsamen Prozess geeinigt, auf gemeinsame…
Wie schaut denn unsere Wertschöpfungskette aus?
Hat es dann runtergebrochen in ein gemeinsames Equirement oder Arbeitsmodell?
Also sprich, ja, wir haben…
Also das ist jetzt Vira oder Ashford DevOps.
Und wir bilden verschiedene Ebenen ab.
Team, Team of Teams, irgendwie größere Einheiten und letzten Endes Gesamtportfolio.
Jeder Ebene gibt sozusagen einen Value Stream, wie Dinge von links nach rechts, von Bedarf erkannt bis zu Bedarf befriedigt, irgendwie fließen.
Und offensichtlich müssen diese Ebenen ja irgendwie zusammenhängen.
Und das ist das, was wir in der agilen Welt, eben was ich sehe, wir als Teams haben Storys als Flow.
Also Items, die fügen sich vielleicht zusammen zu Features, was dann eher so Dinge sind, die auf Teams-Ebene, wo eben mehrere Teams zusammen dran arbeiten, an dem Feature sich zusammentun.
Diese Features zahlen wieder ein auf, was weiß ich, eine Capability einer großen Solution, zahlen wieder ein auf irgendein Unternehmens-Applic.
Und sozusagen diese Kette, sich überhaupt mal darauf zu einigen, dass wir so eine Kette haben wollen, dass klar wird, ich als Mensch im Team,
mache dies, weil zahlt ein auf das, zahlt ein auf das, zahlt ein auf Unternehmens-Ziel.
Und andersrum, genau von oben, kann ich natürlich runterbrechen, hey, um dieses Unternehmens-Ziel zu erreichen, machen wir in der Solution das,
im Value Stream das, im Team das und der einzelne Mensch das.
Und daraus lässt sich dann eben dann sozusagen ein Gesamtbild aller Arbeit und wie die zu dem Gesamtbild,
das das Gesamtziel beiträgt, erzeugen.
Und das ist natürlich aufwendig, das ist viel Arbeit, das herzustellen, aber da kann man sich dann anfangen, sinnvollerweise.
Meiner Erfahrung nach da, wo Leute eben bereit sind, sich auf sowas einzulassen, also dieses Volunteering-Prinzip, die Freiwilligkeit.
Für wen macht das Sinn? Wer will das ausprobieren? Wer macht da mit?
Und dann sucht man sich eben da, versucht da Proof of Concept oder eben…
Sozusagen zu beweisen, dass das tatsächlich besser ist, als das, was man vorher hatte.
Und wenn dem so ist, dann finden sich auch immer wieder neue Menschen, die sagen, hey, ich will auch das Bessere haben, ich will das auch.
Ja, aber trotzdem, wo ich dich so habe, erzählen, hören von wegen, ja, wir haben da sehr viel konsolidiert, wir haben da ganz viele Prozesse zusammengefasst und so.
Also, Hand aufs Herz, das ging doch nicht ohne Streit, oder?
Natürlich nicht. Also dieses Einigen ist Einigungsarbeit und verschiedene Perspektiven.
Perspektiven und Sichtweisen zu einer gemeinsamen Sichtweise zusammenzuführen, ja, ist halt Arbeit.
Und das erfordert einen Diskurs und Debatten und Austausch von Argumenten und zum Beispiel auch sich einigen, wie entscheiden wir denn, wie bewerten wir, ob etwas gut oder schlecht ist.
Also, bevor man sozusagen diese Entscheidungen, das eine ist besser, wie das andere ist, muss man sich erstmal darüber anschauen.
Einigen, wie entscheiden wir denn, ob etwas gut oder schlecht ist und diese Entscheidungskriterien, auf die sich einigen.
Und das ist das, was wir zum Beispiel als Save the Economic Model sagen.
Also, wir brauchen ein gemeinsames Gedankenmodell, nach dem wir Entscheidungen treffen.
Ja, das ist interessant insofern, als ich beobachte, dass dieser erste Schritt häufig nicht gemacht wird.
Man entscheidet sich für Lösungen, ohne dass vorher klar ist, was ist denn eigentlich das Ziel dieser Lösung?
Woran kann ich denn erkennen, dass eine Lösung, die ich jetzt vorstelle, vorteilhaft oder weniger vorteilhaft ist oder inwieweit ich die gewünschten Ziele dann auch tatsächlich erreiche?
Also, ich denke, eigentlich haben wir Agilisten da seit 20 Jahren ein Modell dafür, dieses Validated Learning und genau die Idee von Test First.
Also, ich muss mir eben erst Gedanken machen, wie schaut mein Akzeptanztest aus?
Die Akzeptanzkriterien und dann kann ich was bauen, das meinen Akzeptanztest grün macht.
Das ist in der Softwareentwicklung nicht anders als mit beliebigen anderen Unternehmensentscheidungen.
Oder in der Evolutionsbiologie, wo man bestimmt erst eine Hypothese festlegt, bevor man sein Experiment designt oder durchführt.
Ja, oder anders. In der Evolution, da wird erstmal gemacht und dann geguckt, ob das neue Lebewesen in der Umwelt gut passt.
Ja, da muss ich jetzt ein bisschen gegensteuern, weil Evolution ist eben kein teleologischer Prozess, sprich, der ist nicht zielgerichtet.
Die Evolution hat ja kein Zielbild, da will ich hin, sondern die macht tatsächlich sozusagen diese Schrotstoßstrategie, erzeugt verschiedene Varianten und selektive Prozesse sorgen dann dafür, dass gut nimmt, Töpfchen die schlechten.
Na, kann man dann vernünftig überlegen?
Ja, man kann ja viele Unternehmensziele definieren, die immer sinnvoll sind, an denen man sich orientieren kann.
Immer, hast du ja vorhin das eine Beispiel bei einem Telekommunikationsunternehmen gesagt, auch das geht nicht immer.
Ja, genau. Also nicht umsonst nennt auch Google all seine Initiativen und Projekte Bets, also Wetten, um ganz klar den Charakter herauszustellen.
Ja, das ist eine Wette basierend auf den Anliegen.
Mit den Annahmen, mit den Informationen, die uns jetzt und hier und heute zur Verfügung stellen.
Die Realität wird zeigen, wie gut oder schlecht diese Annahmen waren und sich eben Dinge realisieren oder auch nicht.
Das ist das Nächste, was vielen Unternehmen schwerfällt, ist sowas wie probabilistische Planung.
Also sie kennen immer nur schwarz-weiß, ja, nein, gibt’s oder gibt’s nicht, ist wahr oder ist falsch.
Ja, und so, naja, die Wahrscheinlichkeit, dass sich das als wahre Aussage erweisen wird, ist 60 Prozent.
Damit können die meisten Unternehmen nur sehr schwer umgehen.
Ist ja auch nicht ganz einfach. Was mache ich denn da jetzt draus in Bezug auf eine Budgetentscheidung?
Gebe ich da jetzt nur 60 Prozent des Geldes dafür aus oder was wäre denn meine Reaktion auf Eintreten zur Wahrscheinlichkeit 60 Prozent?
Das ist ja noch der super einfache Fall, den Unternehmen auch seit Jahrhunderten kennen.
Das ist Risikomanagement.
Das Schöne am Risiko.
Das Schöne am Risiko ist ja, es ist ein Known-Unknown.
Und was ist Known beim Risiko? Eintrittswahrscheinlichkeit und Impact.
Und warum geht dann trotzdem so viel in die Hose?
Naja, weil es neben diesen Known-Unknown eben Unknown-Unknown gibt.
Also Dinge, die ich überhaupt nicht auf dem Radar habe, wo ich weder Eintrittswahrscheinlichkeit noch Impact kenne,
noch dass es dieses Risiko oder diese Möglichkeit überhaupt gibt.
Und wenn man sich, es gibt auch Untersuchungen dazu, anguckt, was sind denn die Gründe, warum irgendwie Projekte, Initiativen und sonst was scheitern,
dann fällt fest, ja, unser Risikomanagement hat funktioniert.
Die Risiken, die wir identifiziert haben, die hatten wir auch im großen Teil im Griff.
Was uns das Genick gebrochen hat, waren Sachen, die wir überhaupt nicht auf dem Schirm hatten.
Also diese Überraschungen.
Und dann sind wir wieder da, wo wir vorher waren.
Was sind Vorgehensmodelle oder Strategien für kompliziertes System?
Systeme, die eben ziemlich vorhersagbar sind, wo alle Informationen, die notwendig sind, um sozusagen festzustellen, welches Ergebnis kommt hinten raus,
a priori vorneweg schon bekannt sind.
Und was ist ein komplexes System, das gekennzeichnet ist durch das Phänomen Emergenz?
Also dass eben ständig neue Informationen auftauchen, die aber ziel- und damit handlungsrelevant sind.
Und die ich also fortlaufend in mein Handeln integrieren muss.
Ohne, dass ich weiß.
Was ist es denn, was ich in einem Monat, einem Jahr tun werde oder tun muss, um das Ziel zu erreichen?
Dann sind wir, glaube ich, wieder zurück bei diesem Punkt der Defragmentierung.
Weil ich unterstelle jetzt einfach mal, dass, wenn ich eine zu stark fragmentierte Sicht habe, der von dir angesprochene zerbrochene Spiegel,
dann bin ich ja gar nicht in der Lage, auf unbekannte, auf unknown unknowns zu reagieren.
Die known unknowns, das kann ich mir irgendwie zurechtlegen.
Da kann ich auch in einer hochfragmentierten Organisation, da können die dann wahrscheinlich mit großer Mühe, aber die kriegen das bestimmt hin.
Entsprechende Lösungsverfahren, Reaktionen und so weiter irgendwie mir zurechtdengeln.
Aber was passiert in einer stark fragmentierten Organisation, wenn jetzt irgendein unerwartetes Eintritt, eigenes Eintritt,
dann bin ich ja letzten Endes völlig hilflos, weil ich diese Gesamtsicht gar nicht habe.
Und dann jedes Einzelelement halt für sich irgendwie panisch versucht, was zu zeicheln.
Also ich löse sozusagen lauter lokale Lösungen aus,
die in der Regel sich eben leider nicht magisch zu einer globalen Optimierung zusammenführen,
sondern eben genau im Gegenteil in der Regel sich gegenseitig aufheben und eben massive innere Reibung erzeugen
und am Schluss sozusagen relativ wenig Gesamtwirksamkeit dabei rauskommt.
Also genau das ist das Problem.
Diese lokale Sichten führen zu lokaler Optimierung,
was in der Regel einer globalen Optimierung,
entgegenwirkt.
Also mit einer globalen Sicht bekommen, wie bekommt man die durch ein gesamtes Unternehmen?
Also es fängt an mit einem einheitlichen Denkmodell.
Und auch dieses gemeinsame Denkmodell lässt sich halt nicht mit Flick of a Swip weiter umlegen, erzeugen,
sondern das ist wieder diese Alignment-Arbeit, diese Einigungsarbeit.
Und ich muss halt anfangen, wo sind drei Leute, die sich auf ein gemeinsames Gedankenmodell einigen können,
dann fünf, dann zehn, dann hundert.
Was ist so ein Gedankenmodell?
Sind das die agilen Skalierungs-Frameworks, sind das Produkt- und…
Kann ein Orientierungsrahmen sein, aber eben zum Beispiel ganz konkret eben,
wir haben unterschiedliche Ebenen, Teams, Teams of Teams, was weiß ich, Solutions, Epics,
wir haben Storys, bla bla bla.
Das war ein Aspekt eines gemeinsamen Gedankenmodells.
Und da gibt es noch viele andere und die muss ich halt…
Reihen nach sozusagen beleuchten und beackern.
Und genau wie du sagst, ja, es gibt auch fertige Gedankenmodelle, an denen man sich orientieren kann.
Zum Beispiel agile Frameworks oder diese, auch Kanban hat ja sozusagen Grundprinzipien und Core Practices.
Das sind schon mal so Anhaltspunkte, an denen man sich entlanghandeln kann.
Und auch in Kanban ist natürlich das Erste, was ist wert?
Also die sich darüber einigen, was ist wert?
Und wie entscheiden wir, was ist wertvoller als etwas anderes?
Das ist Punkt Nummer eins.
Und das an sich ist schon ein Gedankenmodell.
Was ist unser gemeinsames Modell für Wert?
Ja, und was mir auch gerade irgendwie sehr in Erinnerung ist,
nicht nur überhaupt dieses gemeinsame Modell zu haben,
oder ja, das ist auch sehr wichtig, vielleicht sogar zentral,
aber das andere ist dann eben auch wirklich Kommunikationsflüsse durch die Organisationen,
die Organisationen sicherzustellen.
Ich hatte das jetzt gerade bei unserem gemeinsamen Kunden Peter,
dass ich mit denen so Rollenworkshops gemacht habe,
mit Leuten, die sich mit Produkt befassen, und zwar auf verschiedenen Ebenen.
Von der Portfolio-Ebene bis runter zu den Product Ownern in den einzelnen Teams.
Und wo wir gesagt haben, okay, was sind denn die Artefakte, die ihr baut?
Was sind denn die Informationen, die ihr von anderswo, in der Regel häufig von Strom auf, bekommt?
Und was sind die Informationen, die ihr nach Strom ab weiterreicht?
Und das war ganz interessant zu beobachten,
dass man dann wirklich sehen konnte, wo sind gewisse Informationsfäden abgerissen.
Die haben es dann geschafft, Ebene 1, Ebene 2, Ebene 3, pang, und dann waren sie weg.
Und in Ebene 4 haben dann die Leute auf einmal die Hände hochgehoben und haben gesagt,
wir haben gar keine Roadmap, die wir gut verwenden können.
Genau. Und das ist für mich ein wichtiger Punkt.
Also das ist immer so dieser Streitpunkt, Huhn-Ei-Diskussion.
Muss erst das Mindset da sein, oder muss sozusagen erst das Verhalten da sein?
Und da gibt es so den Spruch, es ist leichter, sich in eine neue Art des Denkens einzuarbeiten,
als sich in eine neue Art des Arbeitens einzudenken.
Also ich muss sozusagen, wenn ich Strukturen schaffe, die Umgebung verändere,
die ein neues Verhalten ermöglicht, dieses neue Verhalten führt zu neuem inneren Erleben.
Und dieses andere innere Erleben.
Das neue Erleben fängt an, meine inneren Modelle und Glaubenssätze und sonstige Dinge zu verändern.
Es ist meiner Erfahrung nach, wie eher ein Schuh draus wird,
als erst zu versuchen, hier an gemeinsame Gedankenmodelle zu appellieren
und daraus dann ein gemeinsames Verhalten abzuleiten.
Also es ist leichter sozusagen, wie kann man ein unterschiedliches Verhalten ermöglichen,
indem ich die Umgebung verändere, Strukturen.
Strukturen verändere, was zu unterschiedlichen Erleben und Erfahrungen führt
und diese wiederholt unterschiedlichen neuen Erleben und Erfahren.
Die fangen an, meine Haltung, meine Sicht auf die Welt und so weiter zu verändern.
Ja, ich glaube, das ist ganz wesentlich.
Insbesondere, wenn man jetzt wieder Bezug nimmt auf die technologische Unterfütterung vieler Prozesse,
auf Automatisierung oder sowas, die bewirkt für sich erstmal nichts.
Wenn ich jetzt einen schlechten Prozess habe, dann ist das eine gute Idee.
Wenn ich einen guten Prozess automatisiere, dann ist er halt zehnmal so schnell schlecht.
Genau. Aber der Punkt ist, wenn ich zum Beispiel eine Testautomatisierung habe
und eine Continuous Integration, um mal dieses Beispiel zu verwenden,
dann versetze ich mich in die Lage, schnell zu iterieren,
ohne dass es mir besondere Mühen abverlangen würde.
Und das wird natürlich dann auch zu einer Veränderung meines Verhaltens führen
und zu einer Veränderung meiner Denkweisen.
Dann kann ich es mir auf einmal erlauben, vielleicht viel wertorientierter,
viel nutzenorientierter zu arbeiten, weil ich mich einfach ganz schnell an so einen,
Wert vielleicht hin iterieren kann.
Und weil Experimente auf einmal weder teuer noch schmerzhaft sind,
sondern einfach nur die ganz gewöhnliche Art zu arbeiten.
Genau. Also das ist das, was ich vorwiegend funktionieren gesehen habe.
Also eben sozusagen die Möglichkeit für anderes Verhalten schaffen,
das eben dann zu anderen Erfahrungen führt.
Und das dann über die Zeit sozusagen genau wie du sagst,
hey, wenn ich leicht und schnell und billig Experimente machen kann,
dann kann ich auch einmal sozusagen ganz andere Dinge tun und andere Strategien fahren.
Erinnert mich so ein bisschen, es gibt ja von Peter Drucker ein Zitat,
Culture eats strategy for breakfast.
Und dafür gibt es eine Erweiterung von, und zwar aus dem LESS-Framework,
ich glaube Lars Border hatte da mehrere Konzepte zusammengebracht.
Und die Erweiterung lautet, Structure eats culture for breakfast.
Das heißt, wir haben Structure als Grundlage, ähnlich wie du es gerade gesagt hast,
Strukturen schaffen, Kommunikationsstrukturen.
Organisationsstrukturen, die im besten Fall nach Conway’s Law auch gut zusammenpassen.
Dann hat man eine gute Grundlage geschaffen, um die Unternehmenskultur
durch Verhaltensänderungen und Co. zusammenzubringen,
um dann eine Unternehmensstrategie umzusetzen.
Ich glaube, das ist eine ganz gute Grundlage für ein Gedankenmodell,
auch in diesem ganzen Umfeld.
Ja, genau. Jetzt kann ich ein bisschen aus dem Mäh-Täschchen plaudern.
Ich habe gesagt, ich war in der Telekommunikationsindustrie.
Das war nämlich genau da, wo dieses,
das LESS-Framework entstanden ist, NSN 2007.
Und tatsächlich ist das, was ich jetzt da gefasst habe,
in Umgebung verändern, damit sich Verhalten verändert,
dass sich Erleben und Erfahrung verändern,
dass sich dann mentale Modelle und Glaubenssätze verändern.
Das war tatsächlich genau diese praktische Erfahrung zu dieser Zeit dort,
aus der dann sozusagen das LESS-Buch und das LESS-Framework dann auch entstanden ist.
Aber jetzt mal Butter bei die Fische.
Weil wir haben jetzt irgendwie uns,
uns sehr gemütlich ausgebreitet in irgendwelchen hohen philosophischen Sphären.
Aber wie macht man das denn,
dass man eine typische Organisation,
die so eine gewisse Fragmentierung hat, wieder einfängt?
Was sind denn da Werkzeuge,
die ihr als vielleicht besonders wirkungsvoll beobachtet habt?
Das Wichtigste für mich ist,
es gibt kein One-Size-Fits-All.
Also es gibt nicht den universellen Schlüssel,
wenn ich den in das Schloss meiner, in mein Unternehmen stecke und umdrehe,
dann löst sich die Fragmentierung auf.
Also das ist schon mal der erste Zahn, den ich versuche immer zu ziehen.
Sondern ich muss mir halt, also was sind die Fragen?
Was ist eine Herausforderung in meinem Unternehmen?
Was müsste sich ändern, damit es besser wird?
Und dann?
Was muss ich an mir ändern, damit es wahrscheinlicher wird,
dass diese Änderung eintrifft?
Und es sind sozusagen immer die gleichen drei Fragen,
aber die Antwort wird immer eine andere sein in jedem Unternehmen.
Und das ist für mich das Wichtigste,
was die Unternehmen für mich lernen müssen.
Vergesst dieses Blueprints-Zeug
und es gibt die eine Lösung, die immer und überall funktioniert,
sondern was ist so sehr wichtig,
was mir sehr wohlgibt, ist sozusagen dieses Set von sinnvollen Fragen,
die ich mir stellen kann.
Und dann muss ich eben dieses Set von Fragen stellen und gucken,
was kommt bei mir in meinem spezifischen Kontext dabei raus.
Und dann kann ich daraus auch ableiten, hey, was wäre jetzt wohl der erste beste Schritt?
Und natürlich gibt es schon eine Sammlung von Practices oder Dingen,
aber die gibt es in der Agenda nicht.
Das ist eine Agilität seit 20 Jahren und dieses Toolset liegt seit 20 Jahren offen.
Oder länger, wenn man Kanban und Co. auch als Agilität versteht.
Scrum, Lean, Kanban, DevOps, OKRs, Test First,
ist ja alles ein alter Hut.
Wo findet man die Fragen, die man sich stellen muss, gut zusammengefasst?
Gibt es da eine Quelle, die du empfehlen kannst?
Ja, das ist jetzt ziemlich interessant.
Also ich habe mich ja schon geoutet.
Eigentlich komme ich aus der Less-Welt und das erste Less-Book war nichts anderes als ein Fragenkatalog.
If you see this, try that.
If you see this, try that.
Aber Less hat sich nicht durchgesetzt.
Was hat sich stattdessen durchgesetzt?
Save, die genau eben nicht diesen Ansatz gefahren sind,
sondern gesagt haben, wenn du keine Idee hast, probier es mal damit.
Und zwar nicht sozusagen runtergebrochen auf die einzelnen Dinge, die ich da alle sehen kann,
sondern die haben eben sozusagen dir die Mühe erspart,
diese 100 Fragen einzeln zu stellen
und auf 100 Mal eine einzelne kontextsensitive Antwort zu finden,
sondern haben gesagt, hey, wenn du keine Ahnung hast,
dann nimm dir ein Gedankenkonstrukt, an dem du dich orientieren kannst
und dann versuch mal, dem nahe zu kommen und bei dem Weg, dem näher zu kommen.
Da wirst du schon selber merken, dass bestimmte Fragen und Antworten auftauchen,
die dir dann helfen, dich weiterzuentwickeln.
Im besten Fall jedenfalls.
Es kann natürlich auch passieren, dass das so ein bisschen nach hinten losgeht
und dann ist das so wie bei Per Anhalter durch die Galaxis,
wo doch bekanntermaßen die Antwort auf die Frage aller Fragen ist.
Genau, ist 42.
Die Antwort ist 42.
Und in diesem Sinne, die Antwort ist safe, genau.
Egal, was dein Problem ist, wir haben die Lösung.
Das kann passieren.
Natürlich, kluge Leute werden dann dieses Safe Framework auch,
wie du sagst, als Anstoß nehmen, um auf die richtigen Fragen zu kommen
und dann sich für die eigene Organisation, für die eigene Situation,
die richtigen Antworten zu erarbeiten.
Und um das zu sagen, ich bin überzeugt davon, dass man Agilität,
das hast du ja eigentlich auch schon durchklingen lassen,
nur agil umsetzen kann.
Mit anderen Worten, auch all die Mechanismen,
die wir für die Produktentwicklung reklamieren,
die müssen wir natürlich auch auf unsere Organisationsentwicklung anwenden
und sagen, Hypothese bauen, Experiment machen, schauen, ob es funktioniert hat,
genau, und dann gehst du in den nächsten Schritt.
Und deswegen, das ist vielleicht meine Antwort auf, was funktioniert gut,
Sichtbarkeit herstellen.
Also ich bin immer noch unter dem Eindruck von der Wirkmächtigkeit dieses,
Roll Canvas Workshops, den ich eben kürzlich gemacht habe,
wo man dann wirklich quasi nachzeichnen konnte, wenn man genau hingeschaut hat,
wo Informationen versickert sind und wo es dann stromab plötzlich wehgetan hat.
Und wenn man das weiß, dann tut man sich natürlich auch leichter zu sagen,
okay, dann sorgen wir jetzt halt dafür, dass an dieser Stelle die Information durchgängig wird,
dann ist dieses Problem gelöst oder gelindert, dann wird sich natürlich das nächste auftun,
aber mit dem machen wir es dann halt gleichermaßen.
Ich meine, warum ist überhaupt Agilität entstanden?
Also weil halt, sagen wir mal, den Weg, den mir bisher gegangen ist,
schlichtweg nicht mehr funktioniert hat.
Also bei uns da in der Telekommunikationsbranche,
wir haben natürlich auch klassisches Portfolio-Projekt-Programm-Management,
bla, gemacht.
Das Problem war nur, das hat immer weniger funktioniert und zwar so wenig,
dass das existenzgefährdend war.
Und wir mussten schlichtweg lernen, Dinge anders zu machen.
Und das ist eben dieser Unterschied.
Was weiß ich, diese gute Vorhersagbarkeit, kompliziert,
Stacey-Matrix oder Canifin-Framework, komplizierte Systeme, einfache Systeme und komplex.
Und für komplex, da brauche ich eben Annäherungsverfahren.
Iterativ, inkrementell, inspect and adapt.
Und also was kann noch komplexer sein, als eine 50.000-Mann-Organisation zu verändern?
Das liegt in der Natur der Dinge, dass wir da komplex unterwegs sind
und folglich nur iterativ, inkrementell, mit Annäherungsverfahren vorwärtskommen können.
Sehr schön. Peter, vielen Dank, dass du da warst.
Und vielen Dank für die interessanten Gedanken, die du mit uns geteilt hast.
Haben wir noch irgendwas vergessen? Gibt es noch irgendwas, auf das du uns hinweisen möchtest?
Also, ich bin einer der Co-Hosts des Meetups.
Agile Munich.
Das ist ein englischsprachiges Meetup.
Wir sind so 3.000 Mitglieder, versuchen jeden Monat etwa eine Session zu machen,
bei der so 100 Leute sind.
Die Sessions sind mal remote, mal hybrid, mal vor Ort.
Wenn ihr was Spannendes zu erzählen habt, dann meldet euch bei uns
oder guckt mal unter meetup.com, Agile Munich, was da an Sessions schon lief oder ansteht.
Würde mich freuen, wenn wir uns vielleicht treffen.
Und den Link packen wir natürlich in die Show Notes.
Wunderbar. Dann Peter, Falko, vielen Dank.
Auch von mir. Bis bald.
Ja, bis bald. Ciao.
Ciao.