Methoden-FOMO: Warum Unternehmen jedem neuen Framework hinterherlaufen

Unternehmen laufen jedem neuen Framework hinterher, weil Unsicherheit und der Blick auf Wettbewerber Nachahmung belohnen, lange bevor ein Nutzen belegt ist. Methoden-FOMO ist ein ernstes Führungsthema, denn jede Einführung bindet Kapazität und Aufmerksamkeit der Führung. Wer vor der Entscheidung sieben Fragen beantwortet, macht aus dem Druck eine begründete Wahl und entscheidet, welches Framework in den eigenen Betrieb passt und welches nicht.

Dieser Beitrag erklärt, woher der Druck kommt, was die Organisationsforschung dazu sagt, was ein Frameworkwechsel ein Unternehmen tatsächlich kostet und wie Sie eine Entscheidung treffen, die einer Nachfrage von Geschäftsführung, Gesellschaftern oder Belegschaft standhält. Der Druck ist berechtigt: Wettbewerber veröffentlichen Erfahrungsberichte, Konferenzen stellen neue Rahmenwerke vor, und Mitarbeitende bringen Begriffe aus früheren Arbeitgebern mit.

Woher kommt Methoden-FOMO?

Methoden-FOMO entsteht aus drei Quellen: Unsicherheit über den richtigen Weg, sichtbare Erfolgsgeschichten anderer Unternehmen und die Erwartung, dass Führung auf jede neue Entwicklung eine Antwort hat. Die Organisationssoziologie beschreibt das seit 1983. DiMaggio und Powell zeigen in ihrem Aufsatz „The Iron Cage Revisited“, dass Organisationen unter Unsicherheit zur Nachahmung erfolgreicher Vorbilder neigen. Sie nennen das mimetischen Isomorphismus: Wer nicht weiß, welche Lösung wirkt, kopiert die, die bei anderen zu wirken scheint. Abrahamson beschreibt 1996 im Academy of Management Review, wie Management-Moden entstehen: Berater, Management-Gurus, Verlage und Wirtschaftshochschulen erzeugen Nachfrage nach Neuem, und Führungskräfte übernehmen, was als fortschrittlich gilt.

Die Psychologie hat Fear of Missing Out als Konstrukt erforscht. Przybylski und Kollegen haben 2013 in einer Studie beschrieben, aus welchen Motiven Menschen die Angst entwickeln, etwas zu verpassen, und welche Folgen sie hat. Im Unternehmen wirkt dieselbe Dynamik: Wenn ein Wettbewerber ein Rahmenwerk einführt, entsteht in der Geschäftsführung die Sorge, etwas zu versäumen, das später Vorsprung bedeutet. Die Frage, was das Framework dort tatsächlich verändert hat, wird selten gestellt, weil die Antwort aufwendig zu beschaffen ist und die Einführung selbst schon als Erfolg zählt.

Hinzu kommt die wachsende Zahl der Methoden. Das Agile Manifest von 2001 formulierte vier Werte und zwölf Prinzipien und schrieb keine Methode vor. In den Jahren danach kamen neben Scrum und Kanban unter anderem SAFe, LeSS, Disciplined Agile und das sogenannte Spotify-Modell hinzu, später Team Topologies, Shape Up und Flight Levels. Jedes dieser Werke antwortet auf ein bestimmtes Problem. Die Vielfalt gibt der Führung eine echte Auswahl, überfordert sie aber ohne Kriterien.

Was kostet es, jedem Framework zu folgen?

Jede Einführung kostet drei Dinge: die Zeit der Beteiligten, die Verwirrung durch wechselnde Begriffe und das Vertrauen in die nächste Veränderung. Die Zeit lässt sich schätzen. Ein Framework, das Rollen, Ereignisse sowie Planungsrhythmen vorgibt, bindet in jedem betroffenen Team Wochen für Schulung, Anpassung der Werkzeuge und das Einüben der Abläufe, und in dieser Zeit sinkt die Lieferleistung. Der Wechsel von einem Rahmen zum nächsten wiederholt diese Phase, und die Teams haben das alte Vorgehen kaum verinnerlicht, wenn das neue beginnt.

Der zweite Posten ist schwerer zu beziffern. Wenn Mitarbeitende binnen drei Jahren die dritte Methode erleben, lernen sie, dass Veränderung eine Sache des Moments ist, und warten ab. Die Beiträge zu agilen Ritualen ohne Wirkung und Scrum im Mittelstand beschreiben, wie Rituale weiterlaufen, deren Zweck niemand mehr kennt. Methoden-FOMO verstärkt diesen Effekt, weil jede neue Welle das Ritual der alten überdeckt, ohne es zu klären.

Der dritte Posten betrifft die Führung. Eine Geschäftsführung, die jede Mode mitmacht, verliert die Fähigkeit, zu erklären, warum eine bestimmte Methode im Betrieb gilt. Wer sie gegenüber Gesellschaftern oder Bereichsleitern nicht begründen kann, steht beim nächsten Wechsel ohne Argument da.

Wie unterscheidet man ein passendes von einem modischen Framework?

Ein Framework passt, wenn es ein Problem löst, das der eigene Betrieb nachweisbar hat, und wenn seine Voraussetzungen im Unternehmen gegeben sind. Jedes Rahmenwerk entstand in einem Kontext. Scrum wurde für Teams entwickelt, die ein Produkt in Etappen aufbauen. Team Topologies von Skelton und Pais beschreibt, wie Unternehmen Teams nach dem Fluss der Arbeit schneiden und welche Kommunikationswege sie dafür brauchen. Shape Up von Basecamp setzt auf feste Zeitfenster von sechs Wochen für ausgearbeitete Vorhaben. Der Kontext von Basecamp, ein Produkt mit kleinem Team, unterscheidet sich vom Kontext eines Konzerns mit Hunderten Beteiligten, und Entscheider sollten das benennen, bevor sie ein Framework übertragen.

Das Spotify-Modell zeigt das Risiko der Übertragung. Kniberg und Ivarsson haben 2012 in einem Whitepaper beschrieben, wie Spotify seine Teams in Squads, Tribes, Chapters sowie Gilden organisierte, und ausdrücklich als Momentaufnahme bezeichnet. Viele Unternehmen haben es dennoch als Rezept gelesen. Der Beitrag zu Team Topologies zeigt dagegen, wie ein Rahmenwerk den Kontext der Teams ausdrücklich in die Entscheidung einbezieht.

Sieben Prüffragen vor der Einführung eines Frameworks

Sieben Fragen machen aus dem Impuls eine Entscheidung, wenn Geschäftsführung und Fachbereiche sie gemeinsam beantworten. Wer eine Frage nicht beantworten kann, hat die Entscheidung noch nicht vorbereitet.

1. Welches Problem im eigenen Betrieb soll das Framework lösen, und woran ist es heute messbar? Ein Problem wie „Lieferungen verspäten sich im Schnitt um drei Wochen“ ist prüfbar, „wir wollen agiler werden“ ist es nicht.
2. Für welchen Kontext wurde das Framework entwickelt, und wie ähnlich ist der eigene? Die Primärquelle gibt darüber Auskunft, zum Beispiel der Scrum Guide von 2020, der Kanban Guide oder das Buch zu Team Topologies.
3. Welche Voraussetzungen verlangt es, und sind sie vorhanden? Beispiele sind ein Product Owner mit Entscheidungsrecht oder Teams, die ein Ergebnis von Anfang bis Ende verantworten.
4. Was ändert sich für Rollen und Budgets sowie Berichtswege, und wer muss zustimmen? Ein Framework, das Entscheidungsrechte verschiebt, braucht die Zustimmung der Führungsebene, die sie abgibt.
5. Welche bestehende Praxis wird ersetzt, und was passiert mit ihr? Wer nur addiert, erzeugt doppelte Arbeit.
6. Wie lässt sich die Einführung begrenzt prüfen? Ein Pilot mit ein bis zwei Teams und einer Laufzeit von drei Monaten liefert Daten, bevor das Unternehmen sich festlegt.
7. Woran sehen wir nach 90 Tagen, dass es wirkt, und was ist der Abbruchpunkt? Ohne Abbruchkriterium wird jede Einführung zur Daueraufgabe.

Die Fragen verbinden die Wahl mit dem Geschäftsergebnis. Sie schützen vor der Einführung eines Frameworks, das gut klingt, und vor der Ablehnung eines Frameworks, das passt, weil es zu neu wirkt.

Wie reagiert die Geschäftsführung auf Druck von außen?

Die Geschäftsführung antwortet auf externen Druck am besten mit einem Verfahren, das jede Anfrage gleich behandelt. Ein Gesellschafter, der fragt, warum das Unternehmen kein SAFe nutzt, bekommt eine Antwort aus den sieben Prüffragen, die das Problem, den Kontext und die Voraussetzungen nennt. Die Antwort kann lauten, dass SAFe auf Programme mit 50 bis 125 Beteiligten zielt und der eigene Bereich aus vier Teams besteht. Sie kann auch lauten, dass ein Teil des Frameworks, etwa die gemeinsame Planung mehrerer Teams, einen Pilot verdient. Der Beitrag zu agilen Coaches beschreibt, wie sich externe Begleitung so einsetzen lässt, dass Wissen im Unternehmen bleibt.

Hilfreich ist ein fester Rhythmus. Das Unternehmen sammelt neue Frameworks und Anfragen über das Quartal und bewertet sie einmal gemeinsam, statt auf jede einzelne Anregung zu reagieren. Die Entscheidung wird protokolliert und mit dem Ausgangswert versehen, sodass nach einem Jahr nachvollziehbar ist, was gewählt wurde und warum.

Methodenwahl mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management und Organisationsdesign prüft er, welche Arbeitsweise zu welcher Art von Arbeit passt, und führt sie mit klaren Rollen und Entscheidungswegen ein.

Das Vorgehen folgt dem Niehues Delivery Model. Für die Frage, welches Framework ein Unternehmen braucht, zählen drei Prüffragen: Welches Geschäftsergebnis soll sich messbar verändern? Was ist der Ausgangswert, und woran messen wir den Erfolg? Welche Kennzahl zeigt nach 90 Tagen, dass die Lösung ankommt? Aus den Antworten entsteht eine Wahl, die die Geschäftsführung gegenüber Gesellschaftern und Belegschaft begründen kann. Umfang und Konditionen eines Vorhabens werden in der kostenfreien Erstberatung besprochen, die Sie über den Kontakt vereinbaren.