Warum agile Organisationsstrukturen bei 4 Teams oft mehr Meetings erzeugen als Output

Agile Organisationsstrukturen sollen Entscheidungen beschleunigen, Verantwortung näher an die Teams bringen und schneller Ergebnisse liefern. Doch sobald vier Teams an einem Produkt oder an miteinander verbundenen Aufgaben arbeiten, kann das Gegenteil eintreten: Abstimmungen häufen sich, Zuständigkeiten überschneiden sich und immer mehr Arbeitszeit fliesst in Meetings statt in die eigentliche Wertschöpfung. Das Problem liegt dabei nicht zwangsläufig in Scrum oder Agilität. Häufig fehlen stabile Prioritäten, eindeutige Entscheidungsbefugnisse und verbindliche Regeln für die Zusammenarbeit.

Für Bereichsleitende in Schweizer Unternehmen ist deshalb nicht die Anzahl agiler Rollen oder Meetings entscheidend, sondern die Frage, ob die Organisationsstruktur tatsächlich selbstständige Entscheidungen ermöglicht. Vier Teams brauchen nicht automatisch vier Product Owner, zusätzliche Koordinationsrollen oder ein komplexes Skalierungsframework. Sie brauchen vor allem einen gemeinsamen Arbeitsrhythmus, nachvollziehbare Prioritäten und klar abgegrenzte Verantwortlichkeiten.

Der entscheidende Perspektivenwechsel lautet: Agilität bedeutet nicht, mehr miteinander zu reden. Sie bedeutet, weniger Entscheidungen unnötig abzustimmen und mehr Verantwortung dort zu verankern, wo die Arbeit entsteht.

Warum Scrum scheitert, wenn Prioritäten alle 2 Tage wechseln

Scrum scheitert nicht automatisch an häufigen Änderungen, aber es verliert seinen Steuerungswert, wenn Führungskräfte die Prioritäten während eines Sprints ständig neu setzen. Jeder Richtungswechsel kann neue Rückfragen, eine Neubewertung des Backlogs und zusätzliche Abstimmungen auslösen. Die Teams verbringen dann zunehmend Zeit damit, herauszufinden, was gerade wichtig ist, statt vereinbarte Ergebnisse fertigzustellen.

Der Mechanismus ist einfach: Ein Team startet einen Sprint mit einem vereinbarten Ziel. Kurz darauf kommt eine neue Vertriebsanforderung, eine Managemententscheidung oder ein dringendes Projekt hinzu. Die bisherige Arbeit wird unterbrochen. Abhängigkeiten zu anderen Teams müssen neu bewertet werden. Bereits geplante Kapazitäten stimmen nicht mehr mit den Erwartungen überein. Bei vier Teams vervielfacht sich dieser Effekt, weil Änderungen auch Schnittstellen und gemeinsame Liefertermine betreffen können.

Der Scrum Guide weist dem Product Owner die Verantwortung für die Maximierung des Produktwertes und die Reihenfolge der Product-Backlog-Einträge zu. Während eines Sprints dürfen keine Änderungen vorgenommen werden, die das Sprint-Ziel gefährden. Der Umfang kann bei neuen Erkenntnissen mit dem Product Owner neu vereinbart werden. Wird das Sprint-Ziel obsolet, kann ausschliesslich der Product Owner den Sprint abbrechen. Diese Regeln sollen einen verlässlichen Arbeitsrahmen schaffen. Der offizielle Scrum Guide in deutscher Übersetzung bietet dafür die verbindliche Begriffs- und Rollenbasis.

Für die Diagnose genügt zunächst eine einfache Auswertung über zwei Sprints. Erfassen Sie jede Prioritätsänderung nach Sprint-Beginn und dokumentieren Sie, wer sie ausgelöst hat. Unterscheiden Sie dabei zwei Kategorien:

• Begründete Änderung: Ein relevantes Kundenereignis, eine neue Marktinformation oder eine veränderte geschäftliche Rahmenbedingung beeinflusst den tatsächlichen Wert der laufenden Arbeit.
• Interne Unentschlossenheit: Eine Führungskraft oder ein Stakeholder ändert seine Meinung, ohne dass sich der Geschäftswert oder die Ausgangslage wesentlich verändert hat.

Diese Unterscheidung ist wichtig. Agilität verlangt keine starre Planung unabhängig von neuen Erkenntnissen. Sie verlangt nachvollziehbare Entscheidungen. Wenn sich der Business Value einer laufenden Aufgabe messbar verändert, kann eine Anpassung sinnvoll sein. Wenn lediglich eine andere Person eine andere Meinung vertritt, sollte das nicht automatisch den Sprint neu ausrichten.

Häufige Wechsel beschädigen zudem das Commitment. Wenn Mitarbeitende erleben, dass Sprint-Ziele ohnehin nach wenigen Tagen überholt sind, sinkt die Bereitschaft, sich verbindlich auf Ergebnisse festzulegen. Das Team arbeitet dann nicht mehr auf ein gemeinsames Ziel hin, sondern reagiert auf die jeweils lauteste Anforderung.

Erst wenn sichtbar wird, wer Änderungen auslöst und ob sie geschäftlich begründet sind, lässt sich entscheiden, ob das Problem im Scrum-Prozess, in der Führung oder in der Priorisierungsstruktur liegt.

Wie starten Sie mit Agilität in 6 Wochen, ohne die Organisation umzubauen?

Ein Unternehmen kann innerhalb von sechs Wochen einen ersten agilen Pilotbetrieb aufbauen, ohne die gesamte Organisationsstruktur zu verändern. Voraussetzung ist ein klar abgegrenztes Produktvorhaben mit einem zuständigen Team, definierten Entscheidungsbefugnissen und einem überschaubaren Kreis von Beteiligten. Die sechs Wochen sind dabei eine Planungshypothese, keine allgemeingültige Garantie für eine erfolgreiche Transformation.

Für Schweizer KMU ist ein begrenzter Pilot häufig sinnvoller als eine sofortige Einführung neuer Organisationsmodelle. Die bestehenden Linienverantwortlichkeiten bleiben zunächst erhalten. Das Team erhält einen konkreten Auftrag und ausreichend Entscheidungsfreiheit innerhalb dieses Rahmens. Damit wird Agilität praktisch erprobt, statt zunächst ein neues Organigramm zu entwerfen.

Vier Regeln sollten ab der ersten Woche verbindlich sein:

• Ein gemeinsames Ziel: Das Pilotteam arbeitet auf ein nachvollziehbares Produkt- oder Geschäftsergebnis hin.
• Ein verantwortlicher Product Owner: Eine Person priorisiert das Product Backlog und besitzt die entsprechende Entscheidungskompetenz.
• Stabile Sprint-Ziele: Änderungen erfolgen nicht aus blosser Unentschlossenheit oder aufgrund informeller Einzelaufträge.
• Klare Grenzen: Umfang, beteiligte Personen, Abhängigkeiten und Eskalationswege sind dokumentiert.

Ein sinnvoller Ablauf kann in drei Etappen organisiert werden. In den ersten zwei Wochen werden Produktziel, Team, Rollen und Entscheidungsgrenzen festgelegt. In den folgenden zwei Wochen werden die vereinbarten Arbeitsabläufe praktisch getestet. In den letzten zwei Wochen werden Hindernisse ausgewertet und die Regeln angepasst. Diese Aufteilung ist ein vorgeschlagenes Pilotdesign und keine im Scrum Guide vorgeschriebene Einführungssequenz.

Die tatsächliche Dauer hängt unter anderem von der Produktkomplexität, der Zahl der Stakeholder und bestehenden technischen oder organisatorischen Abhängigkeiten ab. Ein Produkt mit mehreren beteiligten Fachbereichen kann mehr Vorbereitungszeit benötigen als ein klar abgegrenztes internes Vorhaben.

Entscheidend ist die Erfolgsmessung. Prüfen Sie nicht nur, ob das Team mit der neuen Arbeitsweise zufrieden ist. Erfassen Sie auch die Anzahl der Steuerungsgremien, die Dauer von Entscheidungswegen und den Anteil tatsächlich abgeschlossener Facharbeit pro Sprint. So wird sichtbar, ob die neue Arbeitsweise Output ermöglicht oder lediglich neue Besprechungsformate geschaffen hat.

Nach dem Pilot sollten nur jene organisatorischen Anpassungen übernommen werden, die einen erkennbaren Nutzen erzeugen. Ein Umbau der gesamten Organisation ist kein Beweis für Agilität.

Spotify-Modell oder klassische Teams: Was passt bei 1 Produkt und 3 Stakeholdern?

Bei einem Produkt und drei Stakeholdern ist ein klassisches, klar abgegrenztes Team häufig die pragmatischere Wahl. Ein komplexes Modell mit Squads, Tribes und Chapters kann zusätzliche Koordinationsrollen und Abstimmungsbedarfe schaffen, ohne dass dafür ein entsprechender organisatorischer Nutzen entsteht. Entscheidend ist nicht, welches Framework moderner wirkt, sondern wie viele unabhängige Produkte, Stakeholder und Teamabhängigkeiten tatsächlich gesteuert werden müssen.

Das sogenannte Spotify-Modell wird oft als fertige Organisationsvorlage verstanden. Diese Interpretation ist problematisch. Der ursprüngliche Erfahrungsbericht von Spotify Engineering beschreibt eine unternehmensspezifische Entwicklung, keine universelle Blaupause. Spotify weist selbst darauf hin, dass die Squads unterschiedlich arbeiten und die Organisationsentwicklung ein fortlaufender Prozess ist. Der Beitrag Spotify Engineering Culture von Henrik Kniberg sollte deshalb als historische Fallbeschreibung und nicht als verbindliches Skalierungsframework gelesen werden.

Für die Auswahl sind drei Fragen besonders hilfreich:

• Wie viele Produkte laufen parallel? Ein einzelnes Produkt benötigt meist weniger strukturelle Trennung als ein Portfolio mit mehreren unabhängigen Produktlinien.
• Wie viele Stakeholder entscheiden unabhängig voneinander? Drei Beteiligte mit klaren Zuständigkeiten benötigen nicht automatisch zusätzliche Koordinationshierarchien.
• Wie stark sind die Teams voneinander abhängig? Viele technische und fachliche Abhängigkeiten können eine zusätzliche Koordination rechtfertigen. Wenige Abhängigkeiten sprechen eher für einfache Strukturen.

In einem Schweizer KMU mit einem Produkt und drei Stakeholdern kann eine Squad- und Chapter-Logik einen zweiten, informellen Machtapparat neben der bestehenden Linienorganisation schaffen. Mitarbeitende müssen dann möglicherweise gleichzeitig mit ihrer Linienführung, einer fachlichen Chapter-Leitung und einer Produktverantwortung abstimmen. Die Zahl der Ansprechpartner steigt, ohne dass automatisch klarer wird, wer entscheiden darf.

Ein klassisches Team ist deshalb kein Rückschritt. Es kann aus einer gemeinsamen Arbeitsgruppe, einem Product Owner und einer klar definierten Zusammenarbeit mit den drei Stakeholdern bestehen. Die drei Beteiligten liefern Anforderungen und Perspektiven. Die Produktpriorisierung bleibt bei einer eindeutig verantwortlichen Person.

Auch hier gilt: Weniger Rollen bedeuten nicht weniger Professionalität. Eine Organisationsstruktur ist dann gut, wenn sie die notwendige Komplexität abbildet und alles andere bewusst weglässt.

Wenn ein überschaubares Team die notwendigen Entscheidungen selbst treffen kann, ist eine zusätzliche Organisationsebene eher eine Belastung als ein Fortschritt.

Der Rollenfehler: Wenn Product Owner und Vertrieb dasselbe entscheiden wollen

Ein Product Owner und der Vertrieb dürfen Kundenbedürfnisse unterschiedlich bewerten, sollten aber nicht dieselbe Priorisierungsentscheidung treffen. Der Vertrieb vertritt konkrete Kundeninteressen und häufig kurzfristige Umsatzchancen. Der Product Owner verantwortet den Produktwert und die Reihenfolge der Product-Backlog-Einträge. Werden beide Rollen mit gleichzeitiger Weisungsbefugnis gegenüber dem Entwicklungsteam ausgestattet, entstehen widersprüchliche Aufträge und zusätzliche Abstimmungen.

Der Konflikt beginnt oft mit einer nachvollziehbaren Kundenanfrage. Ein wichtiger Kunde wünscht eine neue Funktion. Der Vertrieb verspricht eine schnelle Umsetzung oder signalisiert intern eine hohe Dringlichkeit. Der Product Owner hat jedoch bereits andere Produktziele priorisiert. Wenn der Vertrieb direkt Aufgaben an das Team vergeben kann, entsteht eine zweite Priorisierungsebene.

Das Team muss dann entscheiden, welcher Anweisung es folgt. Es entstehen Rückfragen, Sondermeetings und informelle Eskalationen. Die Verantwortung für das Ergebnis wird verwässert, weil zwei Rollen Einfluss auf dieselbe Entscheidung beanspruchen.

Eine praktikable Lösung trennt Anforderung und Entscheidung:

1. Der Vertrieb erfasst den Kundenwunsch strukturiert.
2. Die Anfrage enthält den erwarteten Geschäftswert, den betroffenen Kunden und gegebenenfalls eine vertragliche Verpflichtung.
3. Der Product Owner bewertet den Wunsch im Verhältnis zu bestehenden Produktzielen und anderen Backlog-Einträgen.
4. Die Aufnahme in das Product Backlog und die Priorisierung erfolgen über den Product Owner.
5. Der Vertrieb erhält Transparenz über die Entscheidung und deren Begründung, aber keine direkte Weisungsbefugnis gegenüber dem Team.

Ausnahmen benötigen nachvollziehbare Kriterien. Ein Kundenwunsch kann beispielsweise eine Eskalation rechtfertigen, wenn ein messbarer Umsatzbeitrag, ein strategisch wichtiger Kunde oder eine konkrete vertragliche Zusage betroffen ist. Auch dann sollte die Entscheidung über einen definierten Prozess erfolgen und nicht durch informelle Einzelaufträge.

Der Scrum Guide definiert den Product Owner als einzelne Person und nicht als Gremium. Er weist dieser Rolle die Verantwortung für die Maximierung des Produktwertes und die Reihenfolge des Product Backlogs zu. Das schliesst den Austausch mit dem Vertrieb nicht aus. Es verhindert vielmehr, dass mehrere Personen gleichzeitig die Produktpriorisierung übernehmen.

Unklare Rollen machen agile Verantwortlichkeiten im Alltag zu einer Art Doppelhierarchie: Product Owner und Vertrieb werden als konkurrierende Vorgesetzte wahrgenommen, obwohl die Entscheidungsrechte nicht entsprechend geregelt sind.

Der Vertrieb sollte seine Kundennähe einbringen können, ohne dass jede neue Kundenanfrage automatisch die laufende Arbeit des Teams unterbricht.

Wie reduzieren Sie parallele Arbeit um 30%, ohne „Nein“ zu allem zu sagen?

Parallele Arbeit lässt sich reduzieren, indem Unternehmen die Anzahl gleichzeitig begonnener Aufgaben begrenzen und neue Arbeit erst dann aufnehmen, wenn Kapazität frei wird. Eine Reduktion um 30 Prozent kann ein internes Ziel sein, ist aber kein allgemeingültiger Produktivitätsbenchmark. Entscheidend ist, zunächst die tatsächliche Ausgangslage zu messen und daraus ein realistisches Reduktionsziel abzuleiten.

Viele Unternehmen verwechseln Auslastung mit Produktivität. Wenn Mitarbeitende an fünf Projekten gleichzeitig arbeiten, sieht das nach hoher Aktivität aus. Tatsächlich entstehen jedoch Kontextwechsel, Wartezeiten und zusätzliche Koordination. Bei vier Teams kommen Abhängigkeiten hinzu: Eine Aufgabe kann nicht abgeschlossen werden, weil ein anderes Team noch an einer Voraussetzung arbeitet.

Die Anzahl gleichzeitig begonnener, aber noch nicht abgeschlossener Arbeitselemente wird im Kanban-Kontext als Work in Progress (WIP) bezeichnet. Der Kanban Guide for Scrum Teams von Scrum.org beschreibt WIP als eine zentrale Flussmetrik. Er erläutert zudem, dass bei konstantem Durchsatz eine höhere durchschnittliche Anzahl paralleler Arbeitselemente mit längeren durchschnittlichen Durchlaufzeiten verbunden ist.

Die praktische Konsequenz: Nicht jede neue Anfrage muss abgelehnt werden. Stattdessen wird sichtbar gemacht, welche Aufgaben bereits laufen und welche Kapazität tatsächlich verfügbar ist. Ein gemeinsames Board mit expliziten WIP-Limits schafft dafür eine transparente Grundlage.

Die Regel lautet: Neues kommt erst rein, wenn Fertiges rausgeht. Dadurch verschiebt sich die Diskussion von der Frage, ob eine Anfrage wichtig ist, zur Frage, wann sie sinnvoll bearbeitet werden kann.

Bevor ein Limit festgelegt wird, sollte die Führungskraft die aktuelle Situation erfassen:

• Wie viele Projekte bearbeitet jede Person gleichzeitig?
• Wie viele Aufgaben sind pro Team begonnen, aber noch nicht abgeschlossen?
• Seit wann befinden sich diese Aufgaben im aktuellen Status?
• Welche Aufgaben warten auf Entscheidungen oder andere Teams?
• Welche Projekte würden heute erneut gestartet, wenn die Entscheidung nochmals getroffen werden müsste?

Besonders wichtig ist die letzte Frage. Parallele Arbeit wächst häufig nicht nur durch neue Projekte, sondern auch durch fehlende Abbruchentscheidungen. Eine quartalsweise Projektprüfung schafft einen festen Anlass, Vorhaben zu beenden, deren ursprünglicher Geschäftswert nicht mehr besteht.

Zu strenge WIP-Limits können allerdings kontraproduktiv werden. Wenn die Führung nur noch die Einhaltung einer Kennzahl kontrolliert, ohne Kapazität und Zielsetzung zu berücksichtigen, können Aufgaben in private Listen und informelle Aufträge ausweichen. Deshalb muss die Begrenzung gemeinsam mit den Teams eingeführt werden.

Damit diese Regeln nicht in Diskussionen über Zuständigkeiten stecken bleiben, braucht es im nächsten Schritt eine eindeutige Zuordnung der Entscheidungsrechte zwischen den beteiligten Abteilungen.

RACI oder RAPID: Welche Methode passt bei 3 Abteilungen und 1 gemeinsamen CRM?

Bei drei Abteilungen und einem gemeinsamen CRM ist RAPID besonders hilfreich, wenn geklärt werden muss, wer eine fachliche Entscheidung trifft. RACI eignet sich dagegen besser für die Verteilung von Aufgaben und Verantwortlichkeiten im laufenden Betrieb. Beide Methoden erfüllen unterschiedliche Zwecke und können deshalb kombiniert werden: RAPID für Entscheidungen über Prozesse und Datenmodelle, RACI für deren Umsetzung und Pflege.

Die Unterscheidung ist wesentlich. RACI beantwortet die Frage, wer für eine Tätigkeit verantwortlich ist, wer sie ausführt, wer konsultiert werden muss und wer informiert wird. RAPID strukturiert dagegen den Entscheidungsprozess anhand von fünf Rollen:

• Recommend: entwickelt und empfiehlt eine Entscheidung.
• Agree: muss der Entscheidung in definierten Fällen zustimmen.
• Perform: setzt die Entscheidung um.
• Input: liefert relevante Informationen und Perspektiven.
• Decide: trifft die abschliessende Entscheidung.

Die Publikation von Bain & Company beschreibt RAPID als Modell zur eindeutigen Zuweisung von Entscheidungsrollen. Besonders wichtig ist die klar benannte finale Entscheidungsverantwortung. Die Untersuchung stammt aus dem Jahr 2013 und ist eine Beratungspublikation, keine aktuelle unabhängige Studie über Schweizer KMU.

Ein hypothetisches Beispiel verdeutlicht den Unterschied: Marketing, Vertrieb und Kundenservice möchten ein gemeinsames CRM-Feld verändern. Marketing benötigt eine neue Segmentierungsinformation, der Vertrieb will die Erfassung vereinfachen und der Kundenservice möchte die Datenqualität verbessern.

Eine RACI-Matrix kann zeigen, wer die technische Änderung vorbereitet, wer sie umsetzt und wer informiert werden muss. Sie beantwortet jedoch nicht zwangsläufig eindeutig, welcher Fachbereich bei widersprüchlichen Anforderungen die letzte Entscheidung trifft.

Mit RAPID kann die Entscheidungsarchitektur für genau diese Frage festgelegt werden. Eine Abteilung empfiehlt die Änderung, die betroffenen Bereiche liefern Input und eine klar benannte Person übernimmt die finale Entscheidung. Notwendige Zustimmungen werden auf tatsächlich erforderliche Fälle beschränkt.

Ein häufiger Fehler besteht darin, in einer RACI-Matrix mehrere Personen oder Abteilungen mit einem A für Accountable einzutragen. Dadurch wird die finale Verantwortung unklar. Wenn mehrere Bereiche gleichzeitig als abschliessend verantwortlich gelten, wird jede Entscheidung erneut verhandelt.

Für die Einführung empfiehlt sich ein begrenzter Ansatz. Beginnen Sie nicht mit einer vollständigen Matrix für sämtliche CRM-Aktivitäten. Wählen Sie zunächst fünf bis zehn wiederkehrende Entscheidungen aus, beispielsweise Änderungen am Datenmodell, Pflichtfelder, Zugriffsrechte, Prozessdefinitionen oder die Einführung neuer Schnittstellen.

Halten Sie die jeweiligen Zuständigkeiten dort fest, wo die Beteiligten sie im Alltag benötigen. Eine zentrale Dokumentation im CRM oder in einem zugänglichen Prozessbereich ist hilfreicher als eine umfangreiche Matrix, die nach dem Workshop niemand mehr konsultiert.

Die beste Methode ist nicht die umfangreichste. Sie ist diejenige, die bei wiederkehrenden Konflikten eine nachvollziehbare Entscheidung ermöglicht, ohne jedes Mal ein neues Abstimmungsmeeting auszulösen.

Wie gestalten Sie Change-Management-Prozesse, wenn 30% der Mitarbeitenden skeptisch sind?

Wenn 30 Prozent der Mitarbeitenden einer Veränderung skeptisch gegenüberstehen, sollte das Unternehmen diese Haltung zunächst verstehen, statt sie als Störung zu behandeln. Entscheidend ist, welche konkreten Nachteile die Betroffenen erwarten: Verlust von Entscheidungsspielraum, neue Kontrollmechanismen, veränderte Aufgaben oder Unsicherheit über die eigene Rolle. Ein wirksamer Change-Prozess beantwortet diese Befürchtungen mit nachvollziehbaren Massnahmen.

Die angenommene Skepsis von 30 Prozent ist hier ein Szenario aus der redaktionellen Aufgabenstellung, keine empirisch belegte allgemeine Quote. Sie eignet sich dennoch als Ausgangspunkt für eine praktische Überlegung: Veränderung betrifft nicht alle Mitarbeitenden auf dieselbe Weise. Eine neue agile Organisationsstruktur kann für ein Entwicklungsteam mehr Selbstständigkeit bedeuten, während eine Führungskraft gleichzeitig befürchtet, Einfluss auf operative Entscheidungen zu verlieren.

Besonders bei der Einführung eines gemeinsamen CRM oder neuer Arbeitsprozesse entstehen unterschiedliche Befürchtungen. Mitarbeitende können beispielsweise annehmen, dass ihre Leistung künftig stärker überwacht wird, dass bisheriges Fachwissen weniger zählt oder dass zusätzliche Dokumentationspflichten entstehen.

Statt pauschal für die Vorteile der Veränderung zu werben, sollten diese Erwartungen systematisch erhoben werden. Eine anonyme Befragung vor dem eigentlichen Prozessdesign kann folgende Fragen enthalten:

• Welche bestehende Aufgabe oder Verantwortung könnte durch die Veränderung wegfallen?
• Welche neuen Kontrollen oder Berichtspflichten werden befürchtet?
• Welche Kompetenzen oder bisherigen Arbeitsroutinen könnten an Bedeutung verlieren?
• Welche Entscheidungen erscheinen nach der Umstellung weniger beeinflussbar?
• Welche konkrete Information fehlt, um die Veränderung nachvollziehen zu können?

Aus den Antworten entsteht eine Befürchtungsanalyse. Jeder wesentliche Einwand erhält eine konkrete Antwort: eine verbindliche Rollendefinition, eine Erklärung zur Datennutzung, eine Schulung oder eine Anpassung des geplanten Ablaufs. Nicht jeder Einwand muss zur Änderung des Projekts führen. Er sollte aber nachvollziehbar behandelt werden.

Eine besondere Rolle spielen mittlere Führungskräfte. Sie müssen die neuen Regeln gegenüber ihren Teams erklären und gleichzeitig die praktischen Schwierigkeiten aus dem Arbeitsalltag zurückmelden können. Werden sie erst kurz vor dem Roll-out informiert, entsteht häufig eine Lücke zwischen der zentralen Veränderungsplanung und der tatsächlichen Umsetzung.

Deshalb sollten Bereichs- und Teamleitungen bereits in Woche 1 an der Zieldefinition beteiligt sein. Sie brauchen Klarheit darüber, welche Entscheidungen künftig bei den Teams liegen, welche weiterhin auf Führungsebene getroffen werden und welche Eskalationswege bestehen.

Auch der Erfolg muss realistisch gemessen werden. Zustimmung beim Kick-off ist kein zuverlässiger Nachweis dafür, dass neue Prozesse tatsächlich funktionieren. Aussagekräftiger sind die freiwillige Nutzung der neuen Abläufe, die Anzahl ungelöster Einwände nach vier bis sechs Wochen und die Frage, ob Teams Entscheidungen ohne zusätzliche Aufforderung innerhalb des vereinbarten Rahmens treffen.

Erst wenn die Betroffenen verstehen, was sich ändert, warum es sich ändert und welche Verantwortung sie künftig übernehmen, kann aus formaler Zustimmung eine tatsächliche Veränderung des Arbeitsverhaltens werden.

Wie erstellen Sie einen Change-Plan mit 5 Zielgruppen, ohne Agentur?

Ein Change-Plan für fünf Zielgruppen benötigt keine externe Agentur, wenn für jede Gruppe drei Fragen beantwortet werden: Was verändert sich konkret? Was wird von den Betroffenen erwartet? Über welchen Kanal erreichen Sie diese Personen tatsächlich? Mit dieser schlanken Struktur lässt sich die Kommunikation gezielt organisieren, ohne ein zusätzliches Projektmanagement aufzubauen.

Der wichtigste Fehler besteht darin, allen Mitarbeitenden dieselbe Botschaft über dieselben Kanäle zu vermitteln. Eine Bereichsleitung benötigt andere Informationen als ein operatives Fachteam. Skeptische Mitarbeitende benötigen konkrete Antworten auf ihre Befürchtungen, während die Geschäftsleitung vor allem nachvollziehbare Entscheidungen und Ergebnisse erwartet.

Eine mögliche Einteilung der fünf Zielgruppen sieht so aus:

Diese Zuordnung ist ein anpassbares Arbeitsbeispiel. Die tatsächlichen Zielgruppen und Kanäle müssen aus der Organisationsstruktur abgeleitet werden. Ein Intranet ist beispielsweise nicht automatisch der richtige Kommunikationsweg, nur weil es offiziell verfügbar ist.

Beginnen Sie deshalb mit einer kurzen Bestandsaufnahme. Fragen Sie die jeweiligen Führungskräfte, welche Informationswege ihre Mitarbeitenden tatsächlich nutzen. Wählen Sie anschliessend die zwei wirksamsten Kanäle pro Zielgruppe, statt fünf Kommunikationskanäle parallel zu pflegen.

Wichtig ist ausserdem die persönliche Verantwortung. Jede Zielgruppe braucht eine namentlich oder funktional benannte zuständige Person. Ein zentraler Change-Kommunikator kann Inhalte koordinieren, aber nicht automatisch die Fragen und Entscheidungen aller Bereiche beantworten.

Der Change-Plan sollte deshalb auch festhalten, wer Rückmeldungen sammelt, wer Entscheidungen trifft und wie offene Punkte eskaliert werden. So entsteht keine zusätzliche Kommunikationshierarchie, sondern ein klarer Informations- und Entscheidungsweg.

Für ein Unternehmen mit vier agilen Teams bedeutet das: Jede Gruppe weiss, was sich für sie ändert, welche Entscheidungen sie künftig selbst treffen darf und an wen sie sich bei ungeklärten Abhängigkeiten wenden kann.

Die Veränderung ist damit nicht allein kommuniziert, sondern organisatorisch verankert. Der nächste Schritt besteht darin, die vereinbarten Regeln im Arbeitsalltag zu überprüfen und bei Bedarf gezielt nachzuschärfen.

Agile Organisationsstrukturen werden nicht durch zusätzliche Rollen, Frameworks oder Meetings leistungsfähiger. Sie funktionieren dann, wenn vier Teams wissen, worauf sie hinarbeiten, wer entscheiden darf und welche Arbeit Vorrang hat. Für Bereichsleitende bedeutet das vor allem, Prioritäten zu stabilisieren, Verantwortung eindeutig zuzuordnen und parallele Arbeit konsequent sichtbar zu machen.

Der sinnvollste nächste Schritt ist eine Bestandsaufnahme über zwei Sprints: Erfassen Sie Prioritätswechsel, offene Entscheidungen, parallele Aufgaben und unnötige Abstimmungsschleifen. Daraus lässt sich ein konkreter Verbesserungsplan entwickeln, ohne die gesamte Organisation neu aufzubauen.