Wie Ignoranz und Dummheit „agile Ideen“ zerstören

Es ist zum Heulen! Wieder mal wird ein überragendes Konzept durch oberflächliche Manager demontiert. Diesmal sind es „agile Ideen“ von selbststeuernden, flexibel agierenden Organisationen.

Vor zwei Jahren hatte ich auf die möglichen negativen Konsequenzen eines “agilen Hypes” (siehe Premium Content Vorsicht Scrum!) hingewiesen, nun mehren sich die Anzeichen, dass alles noch viel schlimmer kommt.

Zu diesem Beitrag gibt es Premium Content: Das White Paper mit dem Titel “Vorsicht Scrum!” steht Ihnen kostenlos zur Verfügung. Sie finden den Premium Content am Ende des Beitrags.

Da ist dieses große, international aufgestellte und renommierte Unternehmen mit seinen technischen Produkten. Das möchte sich in eine agile Organisation wandeln, um den Herausforderungen der Digitalisierung gewachsen zu sein. Für dieses Unternehmen eine richtig gute Entscheidung.

Eine Zentraleinheit, direkt unterm Vorstand, wird mit der Konzeption und Umsetzung des entsprechenden Transformationsprogramms betraut. Ein üblicher erster Schritt. Die Idee, den gesamten Umbau der Organisation selbst als agiles Projekt anzulegen, ist ausgezeichnet. Nach meiner Erfahrung der beste Weg, eine solche Transformation erfolgreich zu verwirklichen. Wenn man es richtig macht! Siehe hierzu den Artikel Agile Transformation: Mit dem agilen Kopf durch die hierarchische Wand.

Das Projekt soll entsprechend des Scrum Frameworks durchgeführt werden. Sehr gut! Es bietet tatsächlich geeignete Prinzipien und Praktiken für solche Projekte.

Nun aber fängt das Elend an.

Katastrophale Umsetzung

Für die Konzeptionsarbeit wird ein Verantwortlicher benannt, dem fünf Mitarbeiter zur Verfügung stehen. Diese haben zwar keine besonderen Qualifikationen für das Thema, waren aber gerade im Haus und haben freie Kapazitäten. Weil es agil ablaufen soll, wird diese Gruppe Scrum Team genannt. Der Verantwortliche fungiert darin als Product Owner. Da einige Mitglieder dieses Scrum Teams schon mal Berührung mit Themen wie Organisationsentwicklung und Trainings hatten, wird auf einen Scrum Master verzichtet.

Die Teammitglieder können für die Konzeption etwa 10% ihrer Arbeitsleistung zur Verfügung stellen, an unterschiedlichen Tagen. Weil das nicht reicht, sollen für bestimmte Themen weitere Experten aus der gesamten Organisation kurzzeitig hinzugezogen werden. Nachdem die Eckpunkte des Transformationskonzeptes stichpunktartig gesammelt wurden, wird eine To-do-Liste in Form von Karten an einer Pinnwand erstellt. Die Pinnwand wird Backlog genannt. Nun legt der Product Owner gemeinsam mit seinem Chef sechs Meilensteine fest. Der Zeitraum zwischen zwei Meilensteinen wird Sprint genannt. Der Product Owner verteilt die Aufgaben aus dem Backlog, die jetzt User Stories heißen, an seine Mitarbeiter. Man trifft sich einmal pro Woche zu einem halbtägigen Jour Fixe, das jetzt Stand-up Meeting heißt (gemeint ist eine Art Daily Scrum).

Ist ja alles ganz nett. Am Ende entscheide aber ich. (Der Leiter des Bereichs, der eine agile Transformation verwirklichen soll)

Es zeigt sich schnell, dass auch der Vorgesetzte des Product Owners klare Vorstellungen vom Ablauf des Transformationsprojekts hat und diese verwirklicht sehen will. Deshalb wird für ihn die neue Position des Chief Product Owners geschaffen. Schließlich gibt es noch den Chef der Zentraleinheit. Er ist eine sehr einflussreiche, in der Machthierarchie des Konzerns ganz hochstehende Persönlichkeit. Er verankert laufend immer neue Ideen und Vorstellungen des Vorstands in dem Projekt. Da das Top-Management in diesem Unternehmen über den profanen Strukturen und Gesetzen der Arbeitsorganisation schwebt, wird es vom Umbau nicht betroffen sein. Daher muss auch keine weitere Position für den Boss in dem agilen Projekt geschaffen werden. Er ist einfach eine graue Eminenz, die am Ende bestimmt, wo es langgeht.

Grandioses Scheitern

Ich will nicht tiefer in die Details gehen. Aber das ganze Setting hat rein gar nichts mit agilen Vorgehensweisen bzw. Scrum zu tun. Es ist nicht mal ein professionell geplantes und geführtes Projekt klassischen Zuschnitts.

Dementsprechend läuft es ab: Durch die unklaren Verantwortlichkeiten entstehen Reibungsverluste am laufenden Band. Es wird viel Energie beim Ringen um Macht und Deutungshoheit vergeudet. Das Projekt schreitet voran, macht kehrt und geht dann den Weg wieder zurück. Die Qualität der Ergebnisse ist aufgrund der Zusammensetzung und der fehlenden Zusammenarbeit im Team ohnehin schon gering. Durch das ständige hin und her und die unkoordinierte Einflussnahme Außenstehender nimmt sie im Verlauf des Projektes weiter ab. Die Kosten explodieren, da man zur Einhaltung der Termine zunehmend externe Unterstützung einkaufen muss. Die Termine werden trotzdem nicht eingehalten.

Bei ehrlicher Betrachtung wird keines der gesetzten Ziele erreicht. Es macht sich eine tiefe Enttäuschung über agile Vorgehensweisen breit. Niemand ist aber da, der auf die wahren Ursachen für das Scheitern aufmerksam macht. Stattdessen entstehen Zweifel am gesamten Transformationsvorhaben und es wird zurückgerudert. Die Organisation soll jetzt nicht mehr agil, sondern “flexibler” werden. Zu diesem Zwecke wird ein ganzes Sammelsurium an Prinzipien zeitgemäßer Arbeitsorganisationen in das Konzept aufgenommen: Flussorientierte Arbeitsorganisation, Lean Development und Agile Entwicklung. Doch keines dieser Konzepte wird gründlich vermittelt und konsequent umgesetzt.

Die negativen Beispiele häufen sich

Mit zunehmender Popularität “agiler Ideen” beobachte ich immer öfters solche Fehlzündungen. Da werden selbst von Unternehmensberatungen hanebüchene Aktivitäten entfaltet.

Wir werden agiler und verzichten daher auf die Agenda! (Der Chef eines Beratungsunternehmens)

Unter dem Motto “Wir werden agiler und verzichten daher auf die Agenda!” wird der agile Wandel durch eine “agile Neugestaltung” der vierteljährigen Treffen aller Berater eingeläutet. Der Chef ernennt sich zum Product Owner. Die sich aus Diskussionen üblicherweise ergebenden To-dos werden als Karten auf eine Pinnwand, äh, ich meine Backlog geheftet. Und – raten Sie mal – die drei Monate bis zum nächsten Treffen heißen Sprint und das Treffen Sprint Review.

Merken Sie was? Dieses Beispiel besitzt erstaunlich viele Parallelen zum ersten. Mit dem Unterschied, dass hier ein Unternehmen stümperhaft agiert, welches sich professionell mit Organisationsentwicklung befasst.

Es gibt aber auch andere Möglichkeiten, agile Ideen zu missbrauchen. So wird immer wieder davon berichtet, dass agile Ansätze zu einem vergifteten, krankmachenden Arbeitsklima führen. In allen mir bekannten Fällen werden die agilen Prinzipien pervertiert. Aus Transparenz wird Kontrolle, aus Selbstorganisation Gruppendruck usw. Interessante Gedanken zu dieser Art “Missverständnis” finden Sie hier: Agiler Burnout. Und zum Burnout allgemein hier: Burnout.

Auswirkungen auf agile Konzepte

Warum mich das so in Wallung bringt? Weil alle diese laienhaft aufgesetzten Initiativen ihre Ziele verfehlen werden. Und weil dann agile Konzepte und wirklich tolle Frameworks, wie Scrum, in den Unternehmen verbrannt sein werden.

Meine Ansprechpartner in den Unternehmen sagen mir dann vor einem Gespräch mit den Verantwortlichen: “Nehmen Sie bloß Worte wie agil, Scrum oder Selbstorganisation nicht in den Mund! Die sind hier verbrannt. Hat bei uns alles nicht funktioniert.” Meine Kollegen und ich müssen sich dann verbiegen, nach neuen Worten ringen und diese überlebenswichtigen Konzepte mühsam durch die Hintertür in die Organisation tragen.

Tiefergehender und weniger emotional diskutiere ich die Symptome einer schlechten Einführung agiler Konzepte und ihre Ursachen im Artikel Reality Check: Agile.

Ich verlange Verantwortung und Professionalität von Managern

Es stimmt schon, die Anforderungen an das Management von Unternehmen steigen. Das ist aber keine Entschuldigung dafür, sich mit existenziellen Fragen unternehmerischen Handelns nur oberflächlich und dilettantisch zu befassen. Es ist nicht zu viel verlangt, wenn sich das Top-Management Zeit nimmt, um sich mit dem Vorhaben einer Transformation der Organisation sowie den dahinterstehenden theoretischen Konzepten gründlich auseinanderzusetzen. Dann hätte es Folgendes darüber gelernt:

• Eine agile Organisation wird nicht dadurch geschaffen, dass Projekte nach Scrum durchgeführt werden oder Positionen die Namen agiler Rollen erhalten. Sondern es ist eine Änderung der Unternehmenskultur, insbesondere des Führungsverständnisses, erforderlich.
• Soll am Ende wirklich eine agile Organisation stehen, müssen alle Hierarchieebenen in den Veränderungsprozess einbezogen werden. Auch – und vor allem! – das Top-Management.
• Führungskräfte mischen sich nicht mehr in die operative Arbeit ein. Sie konzentrieren sich auf die Strategieentwicklung und sorgen für optimale Rahmenbedingungen innerhalb der Organisation.
• Dafür werden weniger Führungskräfte benötigt. Hierarchieebenen können somit abgebaut werden. Die überzähligen Führungskräfte werden für andere Aufgaben qualifiziert und andernorts nutzbringend eingesetzt.

Auf dieses neue Führungsverständnis gehe ich in den beiden Artikeln Die „ideale Führungskraft“ für selbststeuernde Organisationen und Agile Führung – Persönlichkeit und Entwicklung agiler Führungskräfte ein.

Und über Scrum hätte das Top-Management dieses erfahren:

• Nur qualifizierte Experten werden Teil eines Scrum Teams. Sie organisieren sich selbst und übernehmen die Verantwortung für das Ergebnis.
• Der Scrum Master ist kein überflüssiges Beiwerk, sondern erfolgskritisch für agile Teams. Er sorgt dafür, dass sich die Teams selbst organisieren und bestmöglich zusammenarbeiten können.
• Die Teammitglieder stehen dem Projekt mit nahezu 100% ihrer Kapazität zur Verfügung. Sie arbeiten meist am selben Ort intensiv zusammen.
• Ein Wechsel in der Besetzung wird nach Möglichkeit vermieden. Externe Zuarbeit erfolgt nur in Ausnahmefällen.
• Der Product Owner alleine ist für das Produkt verantwortlich. Er hat eine konkrete Vorstellung von dem Produkt (Produktvision). Er spricht mit relevanten Stakeholdern und entscheidet über die zukünftigen Produkteigenschaften (hier die Bestandteile des Transformationsprojektes).
• Das Backlog ist die Sammlung dieser Produkteigenschaften (Funktionen, Features o.ä.). Sie sind in Form von User Stories aus der Sicht zukünftiger Nutzer oder Kunden beschrieben.
• Hierarchische Machtstrukturen gibt es nicht. Agile Rollen, wie einen Chief Product Owner, gibt es höchstens bei großen Projekten mit vielen Scrum Teams und bestimmten Arten der Skalierung.
• Sprints dauern nur ein paar Wochen. Am Ende steht ein konkretes Teilergebnis (Produktinkrement), zu dem die relevanten Stakeholder (meist die Kunden) im Sprint Review Feedback geben.

Wenn es nicht gut läuft, zieht man Experten für agile Organisationen und Transformation hinzu. Dies werden dann aber nicht selten als “zu wenig pragmatisch” oder “zu idealistisch” bezeichnet, wenn sie auf diese Zusammenhänge hinweisen. Damit vertun die Verantwortlichen ihre letzte Chance, ihre Organisation erfolgreich agil aufzustellen.

Wie man eine agile Transformation perfekt und garantiert erfolgreich umsetzen kann, beschreibe ich im Artikel 7 Erfolgsfaktoren der agilen Transformation.

Wenn ich ein Transformationsprojekt begleite, verfolge ich einen weitergehenden Ansatz: Es wird ein agiles Team aus Führungskräften bzw. Managern gebildet. Und die Rolle des Product Owners wird vom Vorstandsvorsitzenden, dem Geschäftsführer o.ä. besetzt. Wenn das gelingt, gibt es keine derartigen “Missverständnisse” und es treten keine der diskutierten Probleme auf.

Wollen Sie etwas über den “agilen Hype” erfahren? Dann lesen Sie mein White Paper mit dem Titel “Vorsicht Scrum!” Dieses steht Ihnen als Premium Content kostenlos zur Verfügung.