#105 SAFe enough to try? Was passiert, wenn man die Komplettlösung einkauft
27m 7s
In dieser Folge wird anhand eines Fallbeispiels aus Stefan Kühls Buch "Manage mit Moden" die Problematik standardisierter Agilitäts-Frameworks diskutiert. Ein französisches Maschinenbauunternehmen mit 10.000 Mitarbeitern kämpft mit der wachsenden Komplexität seiner Entwicklungsprozesse, da verschiedene Produktlinien um knappe Ressourcen wie Spezialisten und Testkapazitäten konkurrieren. Das Unternehmen erwägt die Einführung eines skalierten Agilitäts-Frameworks, wie SAFe, um diese Komplexität zu bewältigen. Bei der Analyse des Frameworks stellt sich heraus, dass es sich um ein "Wimmelbild" handelt, das zahlreiche Managementkonzepte der letzten 20 Jahre zusammenfasst und eher als Marketingprodukt für Beratungsfirmen dient. Es verspricht eine Lösung durch einen vorgefertigten Masterplan, was jedoch dem eigentlichen Agilitätsgedanken widerspricht, der auf inkrementelle Versuche und Anpassung setzt. Organisationen lassen sich nicht wie Autos aus Modulen zusammensetzen, da sie viel komplexer sind. Kühl identifiziert zwei sinnvolle Kernideen: die Bildung einheitlicher, örtlich zusammenarbeitender Teams und die Synchronisation von Sprints. Die Organisation zeigte sich jedoch nicht bereit, diese Empfehlungen umzusetzen, da sie sich auf die Einführung aller 40 Framework-Elemente konzentrierte, anstatt die eigentlichen Nadelöhre zu adressieren. Dies zeigt, wie schwer es ist, sich in verunsicherten Organisationen gegen solche Moden zu wehren.
Ihr hört, der ganz normale Waren sind, in dieser Staffel sprechen wir darüber, was Menschen mit Moden sind, wie sie funktionieren, welche Hoffnung mit ihnen verbunden sind und was sie eigentlich so anstellen können, wenn man sie unreflektiert umsetzt. Diese Folge gehen wir genauer ins Feld hinein. Im Buch von Stefan Kühl, "Manage mit Moden" nutzen, gibt es verschiedene Berichte direkt aus dem Leben von Organisationen und eines dieser besonderen Leben, nenne ich es mal, da wollen wir heute gerne reingehen. Und herkühl, ich schlach vorgesehen, vorgesehen. Ich hol uns gemeinsam mit den Höhren und Höhren in dieser Situation, indem ich die Szenen setz um kurz vorlese. Ein französisches Maschinen bei Unternehmen mit 10.000 Mitarbeitern leidete runter, dass die einzelnen Entwicklungsprozesse immer komplexer werden und nur noch schwer aufeinander abgestimmt werden können. Sie überlegen deswegen eines der standardisierten Agilitätzotelle einzuführen. Die zuständigen Bereichsleiter entscheiden sich vor der Einführung des Emetode durch eine kurze Analyse herausarbeiten zu lassen, ob die aufwendige und kostspielige Einführung eines solchen Modells sind ergibt. Herkühl, eine kurze Analyse, ich nehme an, beide Analyse haben sie eine Rolle gespielt, war es ein Auftrag an sie oder sind sie im Bild, was ein Leben des von ihnen. Das ist ein Projekt von mir gewesen. Das sind Sachen, die wir häufiger machen, wo einfach gefragt wird. Wir brauchen eine Einschätzung, was es da bei uns eigentlich gerade los ist. Eine Lösung, die wir uns ausgedacht haben, ist die passend oder ist sie nicht passend. Und dann benötigt man in der Regel so 25 Sondierungsgespräche, um rauszukriegen, was es eigentlich genau Sache. Und dann kann man relativ genau eine Rückmeldung geben. Das ist eine Richtung, die sinnvoll ist. Ihr werdet euch aber das und das einhandeln oder zu sagen. Die Nebenfolgen werden die und die sein, überlegt euch ob das jetzt an der Stelle vernünftig ist. Und dass dieses französische Maschinenbauunternehmen, das hatte im Entwicklungsbereich, eben die Schwierigkeit, das die mit dem größten Wachstum ihre Entwicklungsprozesse nicht mehr vernünftig getackt wird bekommen hatten. Und haben dann überlegt, die bis nicht, es gibt doch eins von diesen Frameworks, Safe oder wie die alle heißen. Das ist gerade hier der Agilitätsmodelle, die wir dir vernutzen können, macht das Sinn. Das war der Auftrag und ich muss gestehen. Ja. Ja, also sie wissen gestehen. Da bin ich gespannt drauf. Ich will nur kurz, einfach nochmal genauer verstehen. Also die Entwicklungsprozesse, die Taktung hat nicht mehr gepasst. Können wir da ins Detail gehen, uns genauer vorzustellen. Was ist das, was ist das Problem, was wir in der Organisation erlebt? Was erlebt man im Alltag als Schmerz sozusagen? Das Problem entsteht ja in der Regel nicht bei Organisationen, die ein einziges Produkt haben, was entwickelt werden muss und was relativ übersichtlich ist. Dann konzentriert sich die gesamte Entwicklungsabteilung auf diesen Einbereich. Die Schwierigkeiten entstehen in dem Moment, wo die Organisation erfolgreicher oder größer wird und man hat den ganz unterschiedliche Produkte, die entwickelt werden. Und hat man ein, was halt richtig groß ist und einfach ist ein Mittelgroß, was dann so an den einfachen Haushalt den Endabnehmer gehen kann. Und man hat den aber Fertigkeiten in den Organisationen, die in diesen verschiedenen Produktlinien, Entwicklungslinien gebraucht wird. Also man hat bestimmte Testfertigkeiten oder Testfasilitäten, die man für alle drei brauchen. Die Frage ist, wie weist man das dann an der Stelle entsprechend zu? Und dann hat man die Situation in solchen Organisationen, das ist ein ganz klassisches Problem. Man hat unterschiedliche Entwicklungsprojekte, die aber nicht völlig unabhängig von lau, von einander laufen, sondern wo man gezwungen ist, in diesen verschiedenen Entwicklungsprojekten immer wieder auf die gleiche Person zuzugreifen. Also man hat den Platz sich knappe Ressourcen, weil mehrere Entwicklungsprojekte gleichzeitig aufzugreifen. Oder man hat bestimmte Testkapazitäten, die begrenzt sind, wo verschiedene Entwicklungsprojekte, die unter Druck stehen, jeweils versuchen gerade diese Testkapazität zu gekommen. Und dann entstehen so extrem komplexe Projektmanagement, Abbildung, wo dann halt zum Beispiel einzelne Mitarbeiter auf drei verschiedenen Projekten gebucht werden und die dann eben sehr, sehr genau aufgesplittet werden, die müssen dann auch eben entsprechend verrechnet werden in den entsprechenden Entwicklungsprojekten. Und diese Komplexität, die droht in so einer Organisation, häufig zu erdrücken und dann sucht man nach Antworten, wie man das in den Griff bekommen kann, weil man hat ja diese Vorstellung, dass in diesen kleinen Bereichen funktioniert, dass doch mit der Agilität, haben wir sowas nicht vielleicht auch im Großen. Können wir das skalieren? Ich verstehe, da kommt verschiedene Griffheer. Okay. Und dann, ich habe sie unterbrochen. Ich war sehr gespannt, sie haben angefangen, sie müssen gestehen, wissen sie noch, was sie gestehen wollten. Also, das darf ich eigentlich gar nicht laut sagen, aber als diese Anfrage gekommen ist und es ist, guckt euch doch mal, diese skalierten, in diesen skalierten Rahmen an, wir haben damit angefangen, das einzuführen, muss sich erstmal, ich kurz orientieren, ich wusste zwar, dass es diese Form des skalierung von Agilität gibt, aber hatte mir das nie selbst im Detail angeschaut und ein Grund, deswegen diese Auftrag interessant gewesen ist, weil es eben eine Möglichkeit gewesen ist, sich dieses Modell mal näher vor Augen zu führen. Und was ich interessant fand, also wenn man sich das anschaut, da gibt es so grafische Darstellung, die unter den Praktikan Wimmelbilder genannt werden. Und zwar deswegen, weil die eine so hohe Eigenkomplexität haben, dass eigentlich kaum noch jemand begreifen kann, was genau dahinter steckt. Und was den gemacht wird, ist das eigentlich alle Managementkonzepte, die in irgendeiner Form gerade um Wogs sind, da zusammengemischt werden. Also da gibt es den Scrams, Kanban, Value Streams, Portfolio, Kustomer, Centricity, Design Thinking, Exploration, Iterations. Es gibt den Produkt-Owner, Epic-Owner, Scram Manager, Produktmanager, Systemarchitekt. Es wird dann von Artificial Intelligence gesprochen, Core-Velues, Vision-Objectives, Shardservice, Community of Practices. Also man hat das Gefühl, da hat sich jemand hingesetzt, hat alles, was in irgendeiner Form in den letzten 20 Jahren im Management-Diskurs-Ombog gewesen ist, genommen, dass in der KI eingespielt und gesagt, "Machen wir daraus möglichst ein wenig zu durchdringendes Bild." Und dann entsteht dieses Wimmelbild, wo eigentlich alle Managementkonzepte in irgendeiner Form zusammengefasst werden. Und damit wird der Organisation versprochen, ihr kriegt jetzt Orientierung. Und als ich mir das, bevor wir in die Organisation reingegangen sind, angeschaut, habe ich gedacht, was ist das für ein kompletter, kompletter Isen, der da etabliert wird, wo eigentlich die Lösung aller Probleme durch ein großes Rahmenwerk versprochen wird. Und was mir deutlich geworden ist, man darf das Konzept gar nicht aus dem Gesichtspunkt des Kunden nutzen, begreifen. Also der Organisation, die es einführen, sondern man muss aus der Perspektive der Berater begreifen, die das einführen. Also das ist ein Modell, was letztlich über eine Art French-Eyes-Konzept vertrieben wird, wie die meisten von diesem Rahmen werken, wo die Kern-Expertise von Beratungsfirmen darin besteht, alles das, was es in irgendeiner Form gibt, in PowerPoint-Folgen und kleinen Arbeitstools übersetzen und die in irgendeiner Form miteinander in Verbindung zu setzen. Und das kommt dann als eine Art Package da her, von der man sagt, na ja, wenn ihr dieses Package mit den 25-Subpackages bei euch in der Organisation einführt, dann habt ihr euer Komplexitätsproblem gelöst. Das ist quasi die Idee dahinter, und das lässt sich extrem gut skalieren, jetzt gar nicht für die Organisation, die damit arbeiten, sondern für die Berat, die das umsetzen, weil dann hat man irgendwelche Sub-Alleinführen. Ja, ja, ja, ja, ja. Man hat die Subunternehmer, die kaufen, denn die PowerPoint-Folgen und die entsprechenden Tools werden dann ganz kurz drin geschult und die werden dann auf die Organisation losgelassen, die dann anhand dieser fertig verpackten Sachen dieses Ready-Made-Konzept in der Organisation einführen. Immer mit dem Versprechen ihr kriegt eure Komplexität damit in den Griff. Und das fand ich, also das finde ich, finde ich eine interessante Variante, weil in meiner Wahrnehmung, dass ja dieser, dem Grundgedanken der Agedität widerspricht. Also der Grundgedanke der Agedität ist, man fängt an einer Sache an und probiert es mal aus. Also geht in so eine inkrimentale Entwicklung rein und schaut, wie sich eine bestimmte Sache entwickelt. Und das ist ja nicht nur eine Idee, die man in der Software-Entwicklung oder in der Produktentwicklung sinnvollerweise einsetzen kann, sondern das ist ja auch die Grundidewieorganisation, die Grundidewieorganisation verändert werden sollen. Also diese Vorstellung, man hat so eine Art Masterplan, von dem man weiß, wie in vier Jahren die Organisation aus sieht, die man denn darüber stülpt und sagt mit denen und dem Masterplan müsste jetzt die nächsten vier Jahre arbeiten, entspricht in gar keine Art und Weise diesem Ageditätsgedanken. Und jetzt hat man plötzlich in diesem Ageditätsdiskurs ein Instrument in diesem Rahmen, dieser Frameworks, die da eingeführt werden, die genau das machen, die letztlich irgendwie ein großes Ready-Made-Concept etablieren, was auf die Organisation übergestöbt wird, wo man gar nicht schaut, wie eine inkrimentale umgehendsweise in diesem Fändungsprozess aussieht. Und diese Widersprüchlichkeit, in dem was da gerade gemacht wird und wie sich das in der Organisation auswirkt, das fand ich spannend. Ich versuche, die Perspektive einzunehmen von. von den Beratern, die es verkaufen, was würden die jetzt wohl sagen? Und zwar die würden wir sagen, natürlich muss man das doch auf die Organisation anpassen. Also wir beraten im BuySafe, da heißt sie ja aus gründen Frameware, das ist ja der Rahmen. Und dann ist ja Teil des Versprechens oder Teil der Lösung. Natürlich braucht man kompetente Berater, die ihr Handwerk verstehen, die nicht einfach nur ein fertighaus über den Dach zusammen kloppen, was nicht so den Pass aus du möchtest, sondern natürlich muss es als Rahmen zu den Bedürfnissen der Organisation angepasst werden. Das wäre ja jetzt wahrscheinlich das, was man ihnen gegenhalten würde. Ja und die Vorstellung ist, dass Organisationen so ähnlich wie Autos funktionieren. Also wenn ich mir einen Auto kaufe, dann ist ja auch die Vorstellung, ich gehe zum Auto-Händler hin und dann setzt er mir aus verschiedenen Elementen innerhalb eines bestimmten Rames, mein Auto zusammen. Ich bin da jetzt überhaupt gar keine Experte, aber dann will ich halt irgendwo, was? Man will die Lenkradbeheizung und die Lenkradbeheizung. Ich wollte jetzt gerade die Sitzbeheizung sagen, aber die Lenkradbeheizung will man haben. Und dann geht man ja in der Regel davon aus, dass die Lenkradbeheizung in irgendeiner Form kompatibel ist zum Rest der Organisation. Also das ist da keine großen Brüche gibt. Und das gleiche ist, wenn ich jetzt auf die Lenkradbeheizung verzichte, dass das Auto trotzdem noch einigermaßen läuft. Also dass diese Elemente in einer gewissen Art und Weise sauber in Land ergreifen und ich dann aus diesen verschiedenen Modulen mir das so zusammenschlippelt, dass ich nachher am Ende was geeignetes habe. Wenn wir jetzt noch schaffen, ist gerade ein Gedanke dazu. Also ich habe es los im Kopf, aber es gab das Problem mal bei einer Vision eines BMWs, dass wenn man das komplette Paket genommen hat an allen Snickschnacks, dann hat danach die Batterie des BMWs nicht mehr gereicht, um das Auto mit allen Snickschnacks zu fahren. Das heißt, was ist dann über Trage auf die Organisation der Charite? Da ist aber, das versprechen eher ein anderes nämlich zu sagen, wenn alle Elemente, alle mutule kauft, dann funktioniert eure Organisation ganz besonders gut. Also das Werbeversprechen des BMW, der von BMW müsste an der Stelle sein, kauft alles in der fortgeschrittenen Variante, dann habt ihr quasi das High Performance Auto. Liebe Kunden, liebe Unternehmer, liebe Verwaltung, wenn ihr Safe einführt und alle Elemente kauft, dann seid ihr auf der sicheren Seite. Das Problem ist, dass Organisationen nicht wie Autos funktionieren. So einfach. Also Auto ist im Prinzip ein vergleichsweise, jetzt müssen die Ingenieure alle weghauen, weghören, ja, hauen Alab und Wäckhören. Also die Autos sind in gewisse Art und Weise niedrig komplexe Gebälde im Vergleich zu Organisationen. Und wenn man Fehler irgendwo im Auto hat, dann kann guter Ingenieure, eine gute Ingenieure finden, woran es gelegen hat und kann das an der Stelle rauskriegen, was da das Problem gewesen ist. Wenn in der Software irgendwo Probleme auftritt, dann kann man sehen, wo der Kudierfehler gewesen ist, der Kotfehlter gewesen ist. Und das ist bei Organisationen, aber den doch deutlich komplexer. Das heißt, man hat eigentlich ein Maschinenmodell der Organisation genommen und das über diese Rahmenwerke versucht im Agilitätsdiskurs in den Organisationen zu etablieren. Und ja, kann in gewisse Art und Weise nur schiefgehen. Und wo man Respekt haben muss, ist vor der Marketingmaschine, die hinter diesen Rahmenwerken steht. Also dann gibt es halt diese, ich habe mir das dann alles angeschaut, auch genau erklären lassen, es gibt dann diese Referenzlisten, wo die ganzen Organisationen aufgeführt werden und wenn man dann genauer reinschaut, was sich dahinter verbirgt, dann sind das, da hat denn mal irgendwie ein deutscher Lebensbettelkonzern, eine Schulung in Saft gekauft und wird dann sofort auf die Referenzliste raufgenommen. Also es ist sehr viel Marketing-Kompetenz bei dem Vertreiben dieser Rahmenwerke dahinter, nimmt aber natürlich, nimmt aber natürlich diese Unsicherheitsgefühle, die man in Organisationen hat, sehr gut auf. Also wer träumt nicht davon, in dem Moment, wo man das Gefühl hat, man kommt der eigenen Komplexität, die ist mir zu Recht, dass es eine Lösung gibt, die diese Komplexität für ein in eine Art und Weise reduzieren kann, dass man sich halt am Standard der jetzigen Branche interessiert. Das machen alle, alle versuchen, diese Rahmenwerke in irgendeiner Form einzuführen. Und man weiß, dass so viele und so viele Organisationen scheinen, bei der mit erfolgreich gewesen sind, wie kann man sich dem an der Stelle mit guten Argumenten wieder setzen. Also das ist extrem schwierig, wie die Welle ist ja schon wieder vorbei, aber das ist in dem Moment sehr schwierig, sich gegen diese Rahmenwerken, da geht in einer Organisation, die unter starker Verunsicherung leidet, dem zu widersetzen. Ja stimmt, dass es so diese Situation mit unserer eigenen Struktur sind wir gerade nicht zufrieden, denn wir merken, was bei uns nicht stimmt, sich dann damit anzufreuten zu sagen, okay, aber es kann niemand besser wissen als ihr selber, wie es funktioniert, ist eine frustrierende Antwort. Ja, was ist die einzige, die es sinnvollerweise geben kann und zu sagen und auch ihr könnt es nicht unbedingt wissen, sondern ihr müsst das über eigene kleine Exploration, über Versuche, über Experimente rauskriegen, wie das funktioniert und dann in dem Moment, wo ihr feststellt, da funktioniert was, das denn in gewisse Art und Weise skalieren und sagen, also da haben wir jetzt eine positive Erfahrung gemacht, können wir das ausdenen auf andere Bereiche und es nicht funktioniert stellen wir es wieder ein, das ist eigentlich die herangehensweise, die erfolgreich sein kann, aber die lässt sich häufig in der Organisation nicht so leicht vermarkten, wenn die Verunsicherung erst mal drin ist. Wir haben also die Situation, Sie haben sich die Organisation angeschaut, Sie haben sich angeschaut, was eingeführt werden soll. Ich habe die vorsichtige Vermutung wahrscheinlich waren nicht alles vom Framework nützlich für die Organisation. Also, ja, wegen der Sorge, wenn ich gesagt hätte, alles super, alle 44 jeweils gleichzeitig funktionieren und sollten von der Organisation angeschaut werden. Also, was rausgekommen ist, sind das zwei Grundideen hilfreich für die Organisation gewesen wären. Das eine ist die Idee, dass man versucht, in diesen verschiedenen Entwicklungsprojekten möglichst mit einem einheitlichen Personalstand zu arbeiten. Also statt diese komplexen Projektmatrixen zu haben, zu sagen, dass in diesen Release Trains, also in den Arbeitsgruppen, das sind dann so 80, 120 Mitarbeiter, dass die möglichst an einem Entwicklungsprojekten nur arbeiten sollen und nicht gleichzeitig auf mehrere Produktentwicklungen verteilt sein sollten und dass die möglichst auch örtlich zusammen sitzen sollen. Das sind ja unterschiedliche Spezialisten, die in dieser Organisation nach Funktionalen Bereichen aufgeteilt gewesen sind und zu sagen, wir haben jetzt doch irgendwie auf ziemlich lange Zeit angelegt, Entwicklungsprojekte ummachen, dass beeinheitliche Teams, das ist sicherlich eine sinnvolle Idee gewesen, was aber die Organisation, was gekostet hätte, weil man hätte dann zum Beispiel bestimmte Position mehrfach besetzen müssen, weil die Spezialisten, quasi, denn ja nicht mehr nur in drei Projekten arbeiten, sondern nur noch in ein und dann hätte man von gutlich noch ein, zwei weitere Spezialisten dann mit dazu einstellen müssen, damit die anderen auch die entsprechenden Sachen bekommen. Also das war die eine Idee, die interessant gewesen ist und die zweite Idee ist gewesen, dass in diesen Sprints, vier Wochen, sechs Wochen, acht Wochen, dass die zwischen den verschiedenen Entwicklungsteams getackt sind. So dass es alle vier Wochen einmal die Möglichkeit gibt, die Entwicklungsergebnisse aus den verschiedenen Produktentwicklungen vorzustellen oder zum Beispiel auch die Software-Entwicklung, die für die verschiedenen Entwicklungsprojekte tätig gewesen ist, im gleichen Zückloser arbeiten kann. Also die Idee zu sagen, wir haben ansonsten hohes Maß an heterogenität, aber wir wollen in dem gleichen Zückloser arbeiten, sodass wir immer zu den gleichen Zeitpunktentwicklung darstellen können, das ist eine sinnvolle Idee gewesen. Und auf diese beiden Bereiche hätte man sich, wenn es jetzt rein nach einer Sachorientierung gegangen wäre, konzentrieren kann, das wäre glaube ich den vorgewesen. Also viel Konjunktiv, das sind die zwei Bereiche, auf die man sich hätte konzentrieren können, wenn es um die Sachebene gegangen wäre. Das ist jetzt der Gegensieheranalyse. Ich nehme an das haben, Sie dann empfohlen, wie war die Situation dieser Empfehlung? Wir haben das aufgenommen. Sehr unterschiedlich, je nachdem, wer das gehört hat, das Problem ist gewesen, dass in den Unternehmen eigentlich nicht bei die Bereitschaft gewesen ist, diese einheitlichen Teams zu bilden. Also dafür hatte die Organisation keine Kraft und dadurch, dass man halt denn an 40 Framework-Elementen gleichzeitig gearbeitet hat, konnte man sich nicht auf die Elemente konzentrieren, die aus meiner Sicht jedenfalls eine Veränderung in der Organisation bedeutet hätten. Das heißt, also auch diese Vielfalt von Aspekten hat letztlich kessiert, wo die eigentlichen Nadelöhrer gewesen sind, durch die man als Organisation hätte durchgehen müssen. Und das sind, wie heucht bei diesen Evaluationen, wenn jemand von außen reinkommt und zwei, drei Wochen vor Ort ist und dann nachher am Ende eine Rückmeldung gibt, er zieht man häufig nicht den Effekt, die man da nicht haben kann. Also es ist frustrierenderweise so, dass die Leute ich sage, so ist das also und dann wird da sofort irgendwie eine Produktentwicklung Strategie geändert, dass es in keiner Art und Weise der Effekt gewesen ist. Es gab für mich ein Lern-Effekt, den ich interessant gewesen.
der für mich interessant gewesen ist. Und dieser Lerneffekt ist gewesen, das ist vermutlich ein versteckten Nutzen dieses Rahmenwerks für die Organisationen gegeben hat. Und zwar muss man sich das vorstellen, dass diese Organisation auch durch die eigene Komplexität und durch die verschiedenen, nicht besonders erfolgreichen Organisationveränderungsmaßnahmen der letzten Jahre, so zersplittert und auch so verunsichert gewesen ist, dass man sich eigentlich auf banalste Sachen nicht mehr einigen konnte. Also was ist zum Beispiel ein Sprint oder was ist eigentlich ein Produktentwicklungs-Team? Also so auf einer ganz banalen Ebene hatte man nicht mehr die Möglichkeit, eine Sprache zu sprechen. Und was denn deutlich gewesen ist, ist es, dass so ein hochstandardisiertes Modell mit von irgendwelchen Beratern produzierten Folien die Definition vorgeben, wenigstene Sogestion einer gemeinsamen Sprache vermitteln kann. Also man hat aufgehört, sich über bestimmte Begriffe zu streiten, weil das ja durch das Rahmenwerk vorgegeben ist. Und ich nachher am Ende in der Endbohrteilung gesagt habe, es kommt bei euch eigentlich nur auf diese beiden Punkte an. Das sind die beiden Hebel, wo sich darüber entscheidet, ob die Produktentwicklung erfolgreich ist oder nicht. Alles andere ist total erschmue, konzentriert euch nicht drauf, natürlich könnte irgendwelche KI-Riturik damit laufen lassen und irgendwelche Vision-Werkenschops machen. Aber das ist nicht das, woran sich der Erfolg entscheiden wird. Auf das könnte die eigentlich alles verzichten. Aber vielleicht macht es Sinn, das ganze Paket zu kaufen, was der mehrere Millionen in der Umsetzung kostet, das ganze Paket zu kaufen, nur deswegen, weil ja nachher am Ende das Gefühl habt, die spricht eine Sprache. Es ist ein sehr teurer Leitbel-Lure-Akshop. Ja und gleichzeitig, wenn es in gewisser Art und Weise bestimmte und produktive Diskussionen rausnimmt, ist es vielleicht gar nicht so teuer. Also ich weiß auch nachher am Ende nicht, ob diese Befriedungspunktion, die so eine Definitionsmaschinerie für so eine Organisation haben kann, ob sie nachher am Ende aufgeht oder nicht. Aber wenn man in irgendeiner formene Sinnhaftigkeit in diesem ganzen Prozess beobachten kann, dann besteht er aus meiner Sicht darin. Also nicht in dem Gedanken verschiedenste Elemente sauber aufeinander abgestimmt in der Organisation wirklich umsetzen zu können, sondern eher in einer Organisation, die über ein Höchstmaß an heterogenität und auch an Interessensgegen setzen, leidet, die über so ein von allen Mitgetragens Framework auf eine gemeinsame Sprache zu bringen. Und da sind vielleicht drei Millionen gar nicht so teuer. Ja, es geht um die Skalierung, also das wäre, es geht darum, dass es die gesamte Organisation ist. Ja, das ist vielleicht, wenn man das generalisieren möchte, ja, so die Funktion, die man auch generell beim Management-Moden beobachten kann, zu sagen, man findet sowas wie eine gemeinsame Sprache. Man hat zumindest das Gefühl, man redet über das Gleiche und hat eine gemeinsame Stoßrichtung, in die man geht. Und wenn der Organisation durch andere Sachen nicht mehr zusammengehalten wird, kann das vielleicht für einen kurzen Moment eine Sinntstiftung übernehmen. Halt das nicht für ausgeschlossen, dass da sowas wie ein versteckter Nutzen dieser Management-Konzepte drin liegt. Es ist halt, also was mich gerade daran ist, ja, was ich stört, oder irritiert vielleicht, ist ja. Dass jeder ja nachher doch wieder seinen eigenen Alltag erlebt und Alltag Begriffe prägt. Und nur dann, wenn immer wieder ein der Diskurs angeregt wird, nur dann, wenn verschiedene Rationalitäten auch miteinander treffen, wenn vorgesetzte ihre Meinung positionieren, wenn es im Meeting krachgibt und man handelt, dann benutzt man ja dieselben Worte. Aber nachher haben doch wieder alle was anderes verstanden. Aber weil wenn das Framework so abstrakt ist, dann fällt einem ja. Wo möglich erst sehr spät auf, dass alle doch was anderes meinen. Dann kauft man sich die Illusion von Frieden. Ja. Ich befürchte sie am Recht. Also, vielleicht ist das auch nur der Versuch eines Sozialogen an der Stelle über das Suchen nach versteckten Funktionen eine Sinnhaftigkeit für die Organisation raus zu interpretieren. Gewisseartenweise ist das so ähnlich wie beim Koalitionsvertrag von Parteien, also wo ja auch extrem unterschiedliche Interessen dahinter stecken. Und dann treffen wir Parteien sich um eine gemeinsame Regierung zu bilden und einen Koalitionsvertrag aufzusetzen. Und in der Koalitionsvertrag wird zwangsläufigen Abstraktionslevel gewählt, was die konkrete Gesetzgebung noch nicht abspiegeln kann. Und dann treten halt die Konflikte in dem Moment auch, wo es dann wirklich um was geht. Und so ähnlich ist es da auch. Aber man hat ja in dem Moment wo man den Koalitionsvertrag das Framework einführt. Ja, erst mal die Sogestion, dass man so was wie gemeinsam an der Stelle hat und hat dann vielleicht die Kraft in dem Detail, das gemeinsam auszuarbeiten. Angenommen, sie hätten da die Wahl gehabt oder wir stellen uns jetzt einfach mal vor. Wir hatten als Zuförerinnen und Zuhörer hier, Organisation verantwortlich, die in ähnlichen großen Organisation mit heterogen Interessen, mit Wachstumsschmerz und einer sich auszuferensierenden Produkte der Portfolie logik. Das schreit ja eigentlich nach so einer Radio-Math-Lösung. Was kann man stattdessen machen? Naja, drauf setzen, dass in diesen Organisationen sich einzelne Personen durchsetzen, die so viel Kraft und so viel Macht haben, Organisationenstrationale Lösung durchzusetzen. Also die sagen, okay, uns kosten diese abgeschlossenen Produktentwicklungs-Teams erst mal vielleicht 10 Millionen. Aber wir kriegen die notwendige Geschwindigkeit dadurch in die Produktentwicklung rein, weil die Mitarbeiterinnen und Mitarbeiterinnen dann zusammensetzen können, weil sie im alltäglichen Austausch miteinander stehen, weil sie sich einzionalein auf ein Produkt konzentrieren können, weil die Verantwortung auch klar sind. Und wir sind bereit, in dieses Risiko reinzugehen und machen das. Und das ist jetzt in dieser Organisation nicht der Fall gewesen, weil auch das Management zu häufig gewechselt hat. Die Krise war schon soweit fortgeschritten, dass das Management permanent ausgetauscht worden ist. Aber gewisse Art und Weise hätte es schon auch die Person im Hintergrund gegeben, die, wenn sie sich auf die Teilarbeit eingelassen hätten, das hätten durchsetzen können. Und jedenfalls besteht keine Lösung darin, mit diesen Zeidobifriedium in irgendeiner Form die Organisation weiter machen zu lassen. Das hätte nicht funktioniert. Dann auch hier, Stehehalköel, ganz herzlichen Dank. Bedanke ich auch.
Podcast Summary
Key Points:
Ein französisches Maschinenbauunternehmen mit 10.000 Mitarbeitern hat aufgrund wachsender Komplexität in der Produktentwicklung Probleme mit der Abstimmung und Taktung.
Das Unternehmen erwägt die Einführung eines standardisierten Agilitäts-Frameworks (z. B. SAFe), um die Komplexität zu bewältigen.
Stefan Kühl analysiert das Framework und stellt fest, dass es ein "Wimmelbild" aus vielen Managementkonzepten ist, das eher aus Beraterperspektive als aus Kundenperspektive entwickelt wurde.
Das Framework verspricht Orientierung, widerspricht aber dem eigentlichen Agilitätsgedanken, der auf inkrementelle Entwicklung und Experimente setzt, und etabliert stattdessen einen starren Masterplan.
Organisationen funktionieren nicht wie Maschinen (Autos), bei denen Module einfach zusammengefügt werden können; die Einführung solcher Rahmenwerke führt daher oft zu Problemen.
Kühl empfiehlt stattdessen, sich auf zwei Kernideen zu konzentrieren
Die Organisation war jedoch nicht bereit, diese Empfehlungen umzusetzen, da sie sich auf die vielen Elemente des Frameworks konzentrierte und die eigentlichen Nadelöhre nicht angehen konnte.
Summary:
In dieser Folge wird anhand eines Fallbeispiels aus Stefan Kühls Buch "Manage mit Moden" die Problematik standardisierter Agilitäts-Frameworks diskutiert. 000 Mitarbeitern kämpft mit der wachsenden Komplexität seiner Entwicklungsprozesse, da verschiedene Produktlinien um knappe Ressourcen wie Spezialisten und Testkapazitäten konkurrieren. Das Unternehmen erwägt die Einführung eines skalierten Agilitäts-Frameworks, wie SAFe, um diese Komplexität zu bewältigen.
Bei der Analyse des Frameworks stellt sich heraus, dass es sich um ein "Wimmelbild" handelt, das zahlreiche Managementkonzepte der letzten 20 Jahre zusammenfasst und eher als Marketingprodukt für Beratungsfirmen dient. Es verspricht eine Lösung durch einen vorgefertigten Masterplan, was jedoch dem eigentlichen Agilitätsgedanken widerspricht, der auf inkrementelle Versuche und Anpassung setzt. Organisationen lassen sich nicht wie Autos aus Modulen zusammensetzen, da sie viel komplexer sind.
Kühl identifiziert zwei sinnvolle Kernideen: die Bildung einheitlicher, örtlich zusammenarbeitender Teams und die Synchronisation von Sprints. Die Organisation zeigte sich jedoch nicht bereit, diese Empfehlungen umzusetzen, da sie sich auf die Einführung aller 40 Framework-Elemente konzentrierte, anstatt die eigentlichen Nadelöhre zu adressieren. Dies zeigt, wie schwer es ist, sich in verunsicherten Organisationen gegen solche Moden zu wehren.
FAQs
Das Hauptproblem ist die zunehmende Komplexität bei mehreren Produktentwicklungen, wo knappe Ressourcen wie Spezialisten oder Testkapazitäten auf verschiedene Projekte verteilt werden müssen, was zu überlasteten Projektmanagementstrukturen führt.
SAFE wird als ein ‚Wimmelbild‘ beschrieben, das viele Managementkonzepte vermischt und eine hohe Eigenkomplexität aufweist. Es verspricht Orientierung, erschwert aber das Verständnis und widerspricht dem agilen Grundgedanken der inkrementellen Entwicklung.
Erstens die Bildung einheitlicher Teams, die nur an einem Entwicklungsprojekt arbeiten, und zweitens die Taktung der Sprints über alle Teams hinweg, um Entwicklungsergebnisse synchron vorzustellen.
Weil sie versuchen, alle Elemente des Frameworks gleichzeitig einzuführen, anstatt sich auf die wesentlichen Nadelöhre zu konzentrieren. Zudem fehlt oft die Bereitschaft, notwendige Veränderungen wie die Bildung einheitlicher Teams umzusetzen.
Berater nutzen die Frameworks als ‚Ready-Made-Konzepte‘, die sie über PowerPoint-Folgen und Tools skalieren. Das Versprechen, Komplexität zu reduzieren, dient oft mehr der Vermarktung als der tatsächlichen Lösung.
Organisationen sind hochkomplexe Gebilde, bei denen Fehler nicht einfach lokalisierbar sind. Anders als bei Autos oder Software lassen sich Probleme nicht durch standardisierte Module beheben, sondern erfordern individuelle Exploration und Experimente.
Chat with AI
Loading...
Pro features
Go deeper with this episode
Unlock creator-grade tools that turn any transcript into show notes and subtitle files.