Agilität? Haben wir probiert! Funktioniert nicht! – Teil 7

Seit dem sechsten Teil dieser Serie ist nun wieder ein gutes halbes Jahr ins Land gegangen. Und die Welt ist seitdem nicht weniger ungewiss geworden, eher noch verrückter.

Ich möchte Ihnen heute wenigstens ein kleines Stück Gewissheit schenken: Sie lesen das Finale dieser Artikelserie! Es sind keine weiteren Fortsetzungen geplant!

Und für mich markiert dieser abschließende Artikel zugleich das Ende einer spannenden und lehrreichen beruflichen Phase und den Beginn von etwas Neuem: Ich werde etwas Neues ausprobieren, ich nenne es Workatical.

Doch zurück zum eigentlichen Thema: Im ersten Artikel meiner kleinen Serie ging es vor allem um die Frage, ob Agilität überhaupt der passende Ansatz für Organisationen ist und falls ja, welcher konkrete Ansatz auf welche Situation passen könnte. Im zweiten Teil ging es vor allem um typische Probleme bei der Einführung und Umsetzung von Agilität. In der dritten Folge lag der Fokus vor allem auf den Menschen selbst. Im vierten Artikel habe ich versucht, einige gefährliche Missverständnisse anzureißen. In Teil 5 ging es um Krisen und den Umgang damit, um Führung und Orientierung und um Veränderung. Und im sechsten Beitrag habe ich einige weitere Phänomene und Fallstricke skizziert, die ich in Veränderungsprozessen und Transformationen beobachten durfte.

Zum Abschluss erwartet Sie ein Feuerwerk an weiteren Aspekten. Ich versuche, mich kurz zu fassen. Dieses Mal wirklich! Und trotzdem ist es ein laaaaaanger Artikel geworden.

Weiterhin gilt: Auch dieses Mal werde ich weder universelle Lösungen noch Kochrezepte für erfolgreiche Agilität liefern können. Die eine oder andere aufmerksame Leserin wird vielleicht erkennen, dass sich meine Argumente teilweise sogar widersprechen. Willkommen in der Realität: Mehrdeutigkeit bzw. Ambiguität ist – ja nach Experte – eine Ausprägung oder ein Begleiter von Komplexität, auf jeden Fall: unvermeidbar. Und dennoch bin ich überzeugt, dass die geneigte Leserin mit dem einen oder anderen meiner Impulse etwas anfangen können wird.

Und bevor es losgeht, zum letzten Mal der Hinweis: Auch dieser Beitrag kann wieder Spuren von Ironie beinhalten!

Sie können einfach nicht loslassen, Teil 7: Sie maximieren weiterhin die Auslastung Ihrer “Human Resources” und zelebrieren Multitasking!

Gerne möchte ich einen Fall aufgreifen, den ich bereits in Teil 6 kurz angerissen habe, und aus einer anderen Perspektive betrachten. Gehen wir mal davon aus, dass Sie sich haben überzeugen lassen, dass Scrum ja wirklich ganz sinnvoll klingt. Drei “Rollen” (richtiger: Verantwortlichkeiten), wenige feste “Meetings” (richtiger: Ereignisse, vielleicht sogar Rituale) und “Tools” (richtiger: Artefakte und Commitments) und ein paar Regeln, sowie fünf Werte. Fast zu einfach, um wahr zu sein. Doch es scheint ja zu klappen, also in anderen Unternehmen.

Also sollen Sie nun Ihre Projekte nach Scrum durchführen.

Also gibt es weiterhin für jedes Projekt ein dediziertes Team. Mal kleiner, mal größer. Im Projektverlauf wechselt die Teamzusammensetzung, na klar – die Themen ändern sich ja auch. Und Sie wollen weiterhin die jeweils besten Leute auf die wichtigsten Themen setzen! Und wenn es gerade mal in einem Projekt stocken sollte, dann können die teuer bezahlten Expert:innen in der Zwischenzeit ja an einem anderen Projekt arbeiten.

Und dann wundern Sie sich, dass dieses System schnell kollabiert?

Schauen wir uns mal an, was das für eine beteiligte Person bedeuten kann:

Wenn ich in 15 Projekten mit ebenso vielen verschiedenen Projektteams gleichzeitig involviert bin (keine Übertreibung: Ich kenne so jemanden), wie gut werde ich mich dann mit jedem dieser Projekte und Teams identifizieren und mich darauf konzentrieren können? Ich springe also von Projekt zu Projekt und es bleibt mir gar nichts anderes übrig, als mich in der kurzen Zeitspanne auf meine Aufgaben zu konzentrieren. Das große Ganze, die Zusammenhänge, werde ich gar nicht mitdenken können. Selbstorganisation im Team? Sorry, dafür bleibt keine Zeit! Ganz davon abgesehen, dass der Kalender allein durch die multiplen Dailys schon überfüllt wäre, würden sie nicht eh größtenteils parallel stattfinden. Ich kann mir das ja eh nicht alles merken und wofür auch?

Gleiches gilt für Sprint Plannings, Reviews und Retrospektiven. Es bleibt kaum noch Zeit, um wirklich zu arbeiten! Also versuche ich möglichst viele Dinge parallel zu bearbeiten, dann habe ich immer etwas zu tun, wenn es woanders gerade nicht weiter geht. Klar passieren mir dabei auch Fehler, aber Fehler passieren nun mal, oder? Die Qualitätssicherung wird sich schon bei mir melden, aber in der Zwischenzeit kann ich im anderen Projekt schon mal weiter machen. Doch egal, in welches Projekt ich gerade springe, die anderen Projekte müssen dann halt auf mich verzichten – ich versuche das natürlich möglichst gut zu planen und zu kommunizieren, doch wenn dann doch mal etwas länger dauert als gedacht, dann zieht sich diese Verzögerung durch alle anderen Projekte, die auf mich warten müssen.

Manche fühlen sich gut dabei (“ohne mich läuft hier gar nicht”), manche stumpfen ab und machen einfach Dienst nach Vorschrift, andere reiben sich in dieser Situation auf und leiden unter dem ständigen Druck.

Wenn in einer solchen Situation das System nicht kollabiert, wenn es also doch irgendwie weiter läuft, selbst dann ist eine solche Arbeitsorganisation weder effektiv noch effizient, sie ist sogar ungesund und gefährlich. Und Agilität hat unter solchen Rahmenbedingen kaum eine Chance, von Scrum ganz zu schweigen.

Dieses Thema hätte einen eigenen ausführlichen Artikel verdient, denn wie ich vor ein paar Monaten auf LinkedIn schrieb: Wenn es genau einen Hebel gibt, der in den meisten Organisationen, in die ich Einblick hatte oder zurzeit habe, den größten Nutzen – und die Basis für alle weiteren Schritte – schafft, dann ist das: Überlastung durch Multitasking abbauen! Durch Fokus! Und Pull! Zum Flow!

In den Kommentaren auf LinkedIn finden Sie einige Links zu Videos und Artikeln, wo Sie etwas tiefer in das Thema einsteigen können und auch Hinweise auf Lösungsansätze finden.

Sie wissen es von Anfang an besser und schnappen sich nur die süßesten Kirschen. Vorsicht vor dem Zuckerschock!

Wenn ich mit Menschen spreche, die mir erzählen, dass sie Agilität oder konkret Scrum ausprobiert haben, es bei Ihnen aber nicht funktioniert oder nichts gebracht hat, dann frage ich in der Regel als erstes, ob sie eine:n Scrum Master hatten und ob sie Sprint Retrospektiven gemacht haben.

“Ich hatte mal irgendwo gelesen, dass man Scrum Master eigentlich gar nicht braucht!”

“Retrospektiven? Haben wir mal probiert und schnell wieder aufgegeben, das hat uns nichts gebracht außer schlechte Laune!”

Im letzten Fall hat man es ja wenigstens ausprobiert und nicht gleich zu Beginn gesagt, dass eine Retrospektive nach jedem Sprint ja sehr viel Zeit koste und es doch sicher alle paar Monate oder nach Projektende ausreicht.

Auch die “Rolle” Product Owner ist in vielen traditionellen Organisationen buchstäblich “unvorstellbar”:

“Das klingt super! Aber das mit dem Product Owner, der Entscheidungen ohne Lenkungsausschuss trifft, das kann bei uns so nicht funktionieren, das brauchen wir so gar nicht erst auszuprobieren!”

Ich möchte nicht behaupten, dass Agilität ohne Scrum Master oder ohne ermächtigte Product Owner nicht möglich ist – regelmäßige Retrospektiven sind meines Erachtens dagegen essenziell für Agilität! Selbstverständlich kann man auch ganz ohne Scrum (oder andere agile Frameworks) erfolgreich sein und natürlich ist der Scrum Guide kein Naturgesetz, an den man sich sklavisch halten muss (siehe dazu Teil 1). Und ganz oft bringt es tatsächlich schon einen Mehrwert, wenn man Daily Standups durchführt, auch in ansonsten traditionellen Wasserfallprojekten!

Es ist nur so, dass Frameworks wie Scrum in sich schlüssig sind und nachweislich in vielen Fällen auch so funktionieren. Das bedeutet nicht, dass es auch bei Ihnen genauso funktionieren muss. Aber meine Erfahrung zeigt, dass Anpassungen nicht trivial sind.

Wenn Ihr Unternehmen also bspw. Scrum als hilfreiches und passendes Framework ausgesucht hat, dann empfehle ich, auch möglichst “by the book” damit zu starten, also zunächst einmal möglichst wenig an den Standards zu verändern. Auf der Basis können Sie eigene Erfahrungen sammeln und in den regelmäßigen Retrospektiven reflektieren: Was passt, was passt nicht und wieso? An manche Neuerungen muss sich das Team und der Rest der Organisation auch einfach erst einmal gewöhnen (siehe dazu Teil 2). Basierend auf Ihren eigenen, konkreten Erfahrungen können Sie dann – ganz und gar agil: inspect & adapt – kleine Veränderungen vornehmen, begrenzte Experimente starten und Ihr System so – sorry für die Wiederholung, aber das ist wichtig – basierend auf empirischen Erkenntnissen statt bloßen Vermutungen schrittweise anpassen.

Noch ein weiterer Impuls: Jede Veränderung an einer Komponente des Systems hat Risiken und Nebenwirkungen, hat Wechselwirkungen auf die anderen Komponenten. Und in einem komplexen System, in einem Scrum Team oder in einer großen Organisation, ist es nicht möglich, alle Auswirkungen einer Veränderung vorherzusagen! Das muss Sie aber nicht davon abhalten, sich trotzdem bestmöglich vorzubereiten. Es ist meiner Erfahrung nach sehr hilfreich, sich vor jeder Veränderung die Frage nach möglichen Risiken, Nebenwirkungen und Wechselwirkungen zu stellen. Grundlegend dafür ist die Frage nach dem “Wofür”! Also bspw. “Wofür ist das Sprint Review eigentlich da? Was ist der Sinn und Zweck?” wenn das Sprint Review verändert oder abgeschafft werden soll. So schaffe ich eine Grundlage, um manche Risiken und Nebenwirkungen von vornherein zu vermeiden oder zumindest im Auge zu behalten, ob sie tatsächlich eintreten, um dann gezielt reagieren zu können.

Und täglich grüßt das Murmeltier? Sie machen regelmäßige Retrospektiven und die Probleme kommen immer wieder? Weniger ist manchmal mehr!

Im Abschnitt zuvor hatte ich es schon kurz angerissen: Ich höre immer wieder von Teams, denen die regelmäßigen Retrospektiven nichts gebracht haben, sodass diese dann ausgesetzt wurden, um die Zeit sinnvoller zu verbringen.

Und ich hatte auch schon erwähnt, möchte es hier aber noch einmal unterstreichen: Regelmäßige Retrospektiven sind aus meiner Sicht essenzieller Bestandteil von Agilität. Denn wie soll die kontinuierliche Verbesserung der Arbeitsweise auf Basis empirischer Erkenntnisse sonst funktionieren? Und gerne verweise ich noch einmal auf die Erkenntnisse des wunderbaren Dr. Eberhard Huber: Des Agilen Pudels Kern.

Natürlich sind Retrospektiven nicht trivial und kein Selbstläufer, insbesondere nicht im Team. Ich werde einige der häufigsten Stolperfallen kurz skizzieren und mögliche Ansatzpunkte nennen:

In manchen Teams sprechen – nicht nur – in der Retrospektive immer dieselben Personen. Die Sichtweisen (und damit auch die Probleme und Lösungen) der Anderen werden gar nicht sichtbar und können so auch gar nicht angegangen werden. Hier hilft Moderation (zum Beispiel durch eine:n Scrum Master) und Moderationstechniken, wie bspw. Brainwriting – also: erst schreiben, dann sprechen!

In manchen Teams reden zwar alle, aber alle reden immer nur oberflächlich “um den heißen Brei herum”. Probleme sind also bekannt und werden auch “unter vier Augen” bzw. “hinter vorgehaltener Hand” besprochen, aber nicht offen in der Retrospektive angegangen. Das sind Anzeichen dafür, dass hier ein Mangel an Vertrauen bzw. Angst vor Konflikten herrscht.

Oder das andere Extrem: Alle reden, alle gehen sich gegenseitig an und machen sich gegenseitig Vorwürfe! Es wird Dampf abgelassen – das kann durchaus manchmal notwendig sein – aber das war es dann auch schon!

Wie Sie solche Dysfunktionen in Teams erkennen und angehen können, habe ich gemeinsam mit dem großartigen Ralf Kruse und vielen weiteren agilen Köpfen in einem ausführlichen Artikel zusammengetragen.

Gehen wir davon aus, dass die Grundlagen passen, wir also ein eingespieltes Team haben, in dem alle offen und vertrauensvoll miteinander umgehen, Verantwortung übernehmen und eine gemeinsame Mission verfolgen! Auch solche Teams überspringen in Retrospektiven manchmal den dritten Schritt: Sie identifizieren also ein konkretes Hindernis/Problem und finden direkt eine Lösung dazu und gehen sie auch aktiv an. Und wundern sich dann, dass das Problem so oder etwas anders oder an anderer Stelle immer wieder auftaucht. Das passiert, wenn man Symptome bekämpft, ohne die Ursachen gefunden zu haben.

Ein anderes Muster, das ich häufig beobachte: Teams nehmen sich zu viel vor, sie sind am Ende der Retrospektive viel zu optimistisch, wollen im nächsten Sprint tausend Sachen anders machen und verbessern und sind umso frustrierter in der nächsten Retrospektive, wenn sie feststellen, dass sie wenig oder gar nichts davon geschafft haben. Hier ist weniger mehr, hier ist “Fokus” wichtig: Nehmen Sie sich lieber nur eine Maßnahme für den nächsten Sprint vor und setzen Sie diese wirklich um! Machen Sie diese Maßnahme ganz oben im Sprint Backlog des nächsten Sprints sichtbar, auch wenn der aktuelle Scrum Guide dies inzwischen nicht mehr als Regel aufführt. Das funktioniert natürlich nur, wenn der:die Product Owner an der Retrospektive beteiligt ist.

Eine Retrospektive ohne Product Owner ist ein weiterer Fallstrick, der oft dazu führt, dass Retrospektiven nicht sehr wirkungsvoll sind. Denn der:die Product Owner ist Teil des Scrum Teams. Viele Maßnahmen zur Verbesserung der Zusammenarbeit benötigen oder betreffen (oder beides) den:die Product Owner. Retrospektiven ohne Product Owner sind also per Definition weniger effektiv oder – weil die Maßnahmen im Nachgang nochmal mit dem:der Product Owner abgestimmt werden müssen – ineffizient.

Ihre Organisation ist einfach noch nicht so weit? Woher wissen Sie das?*

Stellen Sie sich vor, Ihre Firma hat beschlossen, Agilität eine Chance zu geben und allen Führungskräften die Gelegenheit angeboten, sich zumindest einen Tag lang mit einem erfahrenen Agile Coach mit dem Thema zu beschäftigen. Stellen Sie sich vor, dass nach dem Tag alle wirklich angetan, überzeugt oder sogar begeistert sind. Und dann sagt eine Führungskraft sinngemäß: “Hach! Das klingt wirklich toll und macht absolut Sinn für uns! Aber unsere Organisation ist einfach noch nicht bereit dafür!”

Die aufmerksame Leserin wird sich jetzt bestimmt an “Sie trauen Ihren Mitarbeiter*innen Agilität (noch) gar nicht zu: Bitte fassen Sie sich erst einmal an die eigene Nase!” in Teil 3 erinnern. Und tatsächlich erscheinen mir beide Phänomene sehr ähnlich zu sein, wenn auch nicht identisch: Denn hier ist nicht die Rede von konkreten Personen, sondern von “der Organisation” als Ganzes. Und da frage ich mich: Wer, wenn nicht die Menschen in den aktuellen Führungspositionen, sind in der Lage, um Veränderungen in der Organisation anzustoßen oder zumindest die Rahmenbedingungen für Wandel zu schaffen? Wenn also alle Führungskräfte das sagen, dann ist das eine ganz besondere Ausprägung des in der oben verlinkten Passage aufgezeigten Teufelskreises.

Das erinnert mich an eine Situation, als wir uns im Transformationsteam einer Bank fragten, ob für eine bestimmte Freigabe wirklich eine physische Unterschrift von mehreren Entscheidungsrollen notwendig sei, oder ob man das nicht auch anders, vielleicht digital und vor allem schlanker und schneller regeln könnte. Wir fragten den zuständigen “Process Owner”, warum das so geregelt sei. Er wusste es nicht, hat uns aber an eine andere Ansprechpartnerin verwiesen, von der er glaubte, sie sei dafür verantwortlich. Sie war es nicht, sie brauchte die Unterschrift ebenfalls nicht. Aber sie hatte eine neue Vermutung, wer der Grund für diese Regelung sein könnte. Und so fragten wir uns durch die Organisation bis wir wieder am Ausgangspunkt, beim Process Owner ankamen. Niemand brauchte diese Regelung und niemand wusste, warum es sie gab, aber alle dachten, dass es bestimmt jemanden gibt, der bzw. dem das wichtig ist. Gab es aber nicht. Aber vor uns hatte niemand mit allen Beteiligten gesprochen.

Sie ahnen es: Es braucht zunächst einmal Gelegenheiten, um miteinander statt übereinander über solche Themen zu reden, um jenseits des operativen Stresses über Strategie, Strukturen und Normen zu sprechen, um “die Axt zu schärfen” statt mit einer immer stumpfer werdenden Axt stumpf Bäume zu fällen. Und wenn man dann gemeinsam erkennt, dass eigentlich nichts und niemand gegen eine Veränderung sprechen und alle mitmachen wollen, dann besteht zumindest die Chance, dass wirklich etwas in Bewegung kommt. In agilen Teams sind das die regelmäßigen Retrospektiven – warum nicht auch regelmäßige Retrospektiven im Führungskräftekreis oder in der Abteilungsleitungsrunde oder …? Ich durfte solche Retrospektiven schon einige Mal moderieren und kann sagen: Es kann wirken!

Wer da etwas tiefer und weiter einsteigen möchte, findet sicher Inspiration rund um den Ansatz Open Space Agility!

*) Zwischenzeitlich lautete der Titel “Ihre Organisation ist einfach noch nicht so weit? Wirklich? Oder ist das nur eine Ausrede, um selber nicht ins Tun kommen zu müssen?”, aber das war mir dann doch etwas zu provokant. Und zugleich zu wichtig, um nicht wenigstens als Anmerkung und Denkimpuls erwähnt zu werden.

Sie setzen sofort auf komplizierte Skalierungsmodelle? Super, so lassen sich Probleme leicht kaschieren!

Ich wundere mich selbst gerade, dass ich diesen und den nächsten Aspekt so explizit noch gar nicht in meiner Artikelserie verarbeitet hatte. Immerhin hatte ich die grundsätzliche Problematik, dass es für die Organisation komplexer Systeme nicht die eine universelle Lösung geben kann – oder nur auf abstrakter Ebene grundlegender Prinzipien –, schon im ersten Teil unter “Agilität ist mehr als Scrum!” angesprochen. Und der vorletzte Satz dieses Abschnitts wird sogar konkret: “Wenn man allerdings Lösungen, die in anderen Unternehmen gut funktionieren (wie bspw. das sogenannte Spotify-Modell), einfach kopiert, darf man sich nicht wundern, wenn es in der eigenen Organisation quietscht und knarzt und schlimmeres.”

Ein Wort noch zum sogenannten Spotify-Modell: Ich finde den Artikel und die Videos (Teil 1 und Teil 2) vom fantastischen Henrik Kniberg großartig! Doch ich habe deren Inhalt nie als universell einsetzbares Skalierungsmodell, als Blaupause für andere Unternehmen, sondern als Inspirationsquelle, als Beschreibung verstanden, wie sich Spotify zum damaligen Zeitpunkt organisiert hat und warum. Henrik teilte eine faszinierende Momentaufnahme mit uns, die natürlich nur einen Ausschnitt und eine vereinfachte – in manchen Aspekten vielleicht auch idealisierte – Sicht zeigen konnte, nicht die gesamte reale Vielfalt. Und die Inhalte waren schon wieder veraltet, noch bevor die fertigen Videos auf YouTube hochgeladen waren – jedenfalls wenn ich eines der agilen Prinzipien ernst nehme: Reagieren auf Veränderungen! Also kontinuierliches Lernen und Optimieren, basierend auf empirischen Erkenntnissen:

• Organisationsstrukturen,
• Rollen,
• Prozesse,
• Regeln und
• Praktiken

ändern sich in agilen Organisationen fortlaufend, um sich den veränderten Rahmenbedingungen anzupassen und um stetig besser zu werden. Genau diese Anpassungsfähigkeit ist ein wesentlicher Erfolgsfaktor.

Natürlich verstehe ich, dass es verlockend und nach einer Art Abkürzung klingt, einfach etwas zu nehmen, was (in der Außendarstellung) woanders gut funktioniert, also bspw. bei Spotify oder ING (Video). Das kann man durchaus machen, das kann auch klappen – mal besser, mal weniger gut – das kann aber auch richtig wehtun!

Doch nun zu den Skalierungsmodellen, die ja tatsächlich – die einen mehr, die anderen weniger – den Anspruch erheben, universell einsetzbar zu sein. Also kann es ja gar nicht so verkehrt sein, diese als Blaupause zu übernehmen, oder?

Und auch hier gibt es mehrere Aspekte zu beachten und auch dann keine eindeutige Antwort. Ich möchte hier nur auf einen spezifischen Fall eingehen:

Manche Organisationen wollen gar nicht wirklich agil werden. Die Veränderung wäre viel zu schmerzhaft (mehr dazu u. a. im fünften Teil), vielleicht sogar existenzbedrohend. Es reicht ihnen, wenn sie ein bisschen agiler werden, entweder um gut genug auf die Veränderungen am Absatzmarkt reagieren zu können (siehe Teil 2) oder um weiter attraktiv genug für Bewerber:innen zu sein (siehe Teil 3). In solchen Fällen kann die Übernahme eines komplizierten Skalierungsmodells wie bspw. SAFe durchaus attraktiv sein.

Böse Zungen behaupten, man müsse eigentlich gar nichts verändern, nur umbenennen, um eine traditionelle Organisation auf SAFe umzustellen. So weit gehe ich nicht, dazu habe ich nicht genügend Einblick und Erfahrung.

Doch eine Hypothese wage ich: je ähnlicher der Grad der Kompliziertheit zweier Organisationsmodelle (hier: die bisherige primär funktionsorientierte Matrixorganisation und das künftige agile Skalierungsmodell), desto weniger schmerzhaft die Umstellung. Allein dadurch, dass sich bisherige Rollen und Positionen leicht auf neue dedizierte Rollen und Positionen übertragen lassen, entstehen weniger Veränderungsschmerzen bei den Mitarbeitenden, insbesondere beim mittleren Management.

Und damit ist es leicht, eine bewährte Taktik fortzuführen: auf auftretende Probleme mit neuen Regeln, Organisationsstrukturen und zuständigen Rollen zu reagieren. Also Probleme zu verwalten und damit zu kaschieren. Also Symptome zu lindern, anstatt die Ursachen anzugehen.

Ein vereinfachtes Beispiel zur Verdeutlichung: Ein Unternehmen entwickelt ein Software-Produkt und ist damit sehr erfolgreich. So erfolgreich, dass das Produkt immer größer wird, immer mehr Funktionen erhält. So erfolgreich, dass es für unterschiedliche Branchen adaptiert wird. Irgendwann kann das ein Scrum Team nicht mehr allein stemmen. Also teilt man die Arbeit auf mehrere Teams auf, die alle am selben Produkt, auf derselben Codebasis arbeiten. Dabei kommt es natürlich zu Problemen, weil es Abhängigkeiten zwischen den Teams gibt: Wenn das eine Team etwas verändert, dann hat das Auswirkungen auf das, woran andere Teams gerade arbeiten oder gearbeitet haben.

Was also tun? Erst einmal: Sich freuen, statt ärgern! Das iterative Vorgehen in Sprints hat dazu geführt, dass schon sehr früh die ersten Probleme sichtbar und spürbar wurden, nicht erst nach mehrmonatiger Entwicklungsarbeit.

Und dann gibt es im Grunde genommen zwei grundlegende Strategien:

• die Abhängigkeiten reduzieren, bspw. durch eine Microservices-Architektur oder
• die Abhängigkeiten managen, um die Symptome abzumildern, bspw. durch Regeln, Prozesse, dedizierte Rollen und Gremien.

Die erste Strategie bedeutet eine Investition in die Zukunft. Das ist anstrengend und man wird es wahrscheinlich nie schaffen, alle Abhängigkeiten zu beseitigen, doch für den Rest reichen in der Regel sehr schlanke Strukturen.

Bei der zweiten Strategie muss man am Status Quo erst einmal nichts ändern. Man baut ja nur zusätzliche Strukturen auf. Man kann die Verantwortung an den Problemen an jemanden abgeben, der sich nun darum kümmert, dass es künftig nicht mehr so stark schmerzt – und wenn doch, dann hat man wenigstens jemanden, den man dafür verantwortlich machen kann. Das kann man so machen, sofern bzw. solange man sich das so leisten kann (siehe Teil 2).

Sie setzen auch bei Agilität auf die gleichen Beratungen, die erst kürzlich Ihre Strukturen und Prozesse auf Kosteneffizienz getrimmt haben?

Da dieser Aspekt manchmal recht eng mit dem Thema des vorherigen Abschnitts zusammenhängt, möchte ich nur noch einen Satz anführen, der zumeist Albert Einstein zugeschrieben wird:

“Die Definition von Wahnsinn ist, immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten.”

Neue Besen kehren besser! Wenn Scrum nicht reicht, dann gibt’s ja noch Design Thinking! Und OKR! Oder?

Ja! Wie schon im ersten Teil unter “Agilität ist mehr als Scrum!” aufgezeigt ist Scrum nicht alles und vor allem nicht die eine universelle Lösung für alles. Also kann es selbstverständlich Sinn ergeben, Scrum durch passende Ansätze zu ergänzen.

Was ich aber immer wieder beobachte: Eine Organisation, in der Scrum bereits etabliert ist, möchte nun auch Design Thinking nutzen, um “näher am Kunden zu sein”, also die Kundenzentrierung zu stärken. (Oder OKR, um die Ausrichtung der Organisation über alle Ebenen hinweg zu verbessern. Oder …) Auf den ersten Blick einleuchtend und sinnvoll. Wenn ich dann – beim Beispiel Design Thinking bleibend – meinen zweiten Blick auf die Sprint Reviews der Scrum Teams werfe und dort keinen einzigen echten Kunden bzw. Nutzer finde, sondern ausschließlich interne Stakeholder (wenn überhaupt), dann lässt mich das oft kopfschüttelnd zurück.

Auch hier gilt: Wenn man ein Problem erkennt, könnte man zunächst die Ursachen ergründen und dann selbst passende Lösungsansätze finden, statt gleich eine fertige Lösung aus dem Hut zu zaubern, und sich dann nach einigen Monaten zu wundern, dass das wieder nur ein Strohfeuer war und sich im Kern nichts verändert hat.

Vielleicht kann Design Thinking das Repertoire der Scrum Teams sinnvoll erweitern, vielleicht können dedizierte Design Sprints dazu führen, dass die Scrum Teams weniger Scheu haben, echte Nutzer zum Sprint Review einzuladen und dort miteinander ins Gespräch zu kommen. Vielleicht liegen die Ursachen aber auch an ganz anderer Stelle und brauchen andere Lösungsansätze.

Methodenkompetenz ist hilfreich, Methoden sind aber nie ein Selbstzweck. Und zu viele Methoden/Frameworks parallel können auch verwirren und überfordern. Ich kann es sehr gut nachvollziehen, wenn manche Teams nicht mehr genau wissen, ob sie ein mittelfristiges Thema nun eher als Epic in das Product Backlog eintragen oder besser im OKR-Framework abbilden sollten, oder beides?

Auch hier ist weniger manchmal mehr.

Wenn Sie aber einem echten Team, das eine gemeinsame Mission verfolgt und die Verantwortung für den eigenen Erfolg trägt und angenommen hat, neue Methoden anbieten, dann wird sich ein solches Team aus dem vielfältigen Angebot an Methoden bedienen und jene Teile verwenden, die ihm helfen, noch erfolgreicher zu werden. Ein solches Team muss man nicht überzeugen oder erziehen. Es wird sich aus dem Angebot bedienen, wenn es etwas braucht.

Sie lassen Ihre Teams im sicheren Sandkasten spielen und wundern sich, dass Ihre Teams nur spielen?

Auf einem dieser damals noch hippen New Work Meetups vor ein paar Jahren berichtete mir eine Führungskraft, dass er einfach nicht mehr weiter wisse: In seinem Team klappe das mit der Selbstorganisation einfach nicht. Dabei lasse er ihnen doch alle Freiheiten, sie können alle Irrtümer und sogar Fehler begehen, er stelle sich dann immer vor das Team und fange allen Druck durch Kunden und Stakeholder ab …

Ich wünschte, ich würde nicht lügen, wenn ich jetzt schreibe, dass es ihm selbst klar wurde, als er es aussprach …

Menschen passen ihr Verhalten nun einmal an die Rahmenbedingungen an (siehe dazu den Abschnitt zum Menschenbild in Teil 3).

Geben Sie also einem Team den Auftrag, sich mit Scrum vertraut zu machen, dann wird es sich wahrscheinlich mit Theorie und Praktiken beschäftigen, ganz nach Lehrbuch. Natürlich an einem realen, praktischen Beispiel, also an einem echten Produkt.

Doch wenn es kein echtes Feedback gibt, wenn die Führungskraft jedes Feedback von Kunden und Nutzern abfängt, filtert und abfedert, wie soll das Team dann lernen? Es trägt ja tatsächlich keinerlei Verantwortung, die trägt in diesem Fall weiterhin allein der Chef. Das Team spürt ja nie eine direkte Konsequenz des eigenen Handelns, ob Erfolg oder Fehler.

Und selbst wenn der Chef das Feedback an das Team weitergibt, dann ist es immer gefiltert und abgewandelt (“Stille Post”) und der Boss wird sich schon wieder abregen, wie immer.

Das schlimme ist: Der Chef macht das ja mit guten Absichten. Er möchte das Team nicht gleich ins kalte Wasser, in den stürmischen Ozean mit gefährlichen Haien (hier: Kunden) werfen, sondern erst einmal im Nichtschwimmerbecken in Ruhe üben lassen. Und die Praktiken lassen sich so auch üben, aber das ist kein Selbstzweck.

Wenn Sie also wollen, dass ein Team den Sandkasten bzw. das Nichtschwimmerbecken verlässt und selbst Verantwortung übernimmt, dann braucht es ein “echtes” Problem, einen realen Marktbezug, am besten direktes und ungefiltertes Feedback von echten Kunden und Nutzern. Das tut vielleicht erst einmal weh, ermöglicht aber echte Entwicklung und Wachstum.

Es hätt noch immer jot jejange – die Teams reißen es ja doch immer noch irgendwie raus … Aber zu welchem Preis?

Zum Abschluss noch ein wirklich schmerzhafter und trauriger Aspekt, für den ich leider auch keine einfache Lösung parat habe:

Stellen Sie sich vor, Ihr Unternehmen hat nun also die Produktentwicklung “erfolgreich” auf Scrum umgestellt. Das war ein echter Kraftakt, funktioniert jetzt aber richtig gut. Jedenfalls aus Sicht der Geschäftsführung: Die Zahlen stimmen jedenfalls.

Doch in den Teams quietscht und rumpelt es eher mehr als zuvor. Na klar, der Rest der Organisation denkt und agiert ja noch immer wie gehabt. Und durch die Sprints mit regelmäßigen Retrospektiven fallen die Probleme in den Teams viel früher und öfter auf. Gerade zu Beginn der Transformation gab es genügend Probleme, die die Teams selbst lösen konnten. Doch inzwischen treten immer mehr jene Probleme in den Fokus, die außerhalb der Gestaltungsspielräume der Teams liegen und sie Unterstützung benötigen. Also schaffen sich die Teams Gehör, sie gehen nach außen und machen die Probleme sichtbar und bitten um Hilfe.

Zurück zur Perspektive der Geschäftsführung: Was wollen die denn eigentlich? Läuft doch. Und genau das war ja auch der Sinn und Zweck dieser Umstellung; dass die Teams ihr Probleme selbstständig lösen, oder?

Und solange die Teams die Probleme und Störungen von außen abfangen, ausgleichen und abfedern, den Schmerz also auf sich nehmen, solange dadurch die Ergebnisse passen und die Zahlen stimmen, solange wird manch eine Geschäftsführerin geneigt sein, “das Gemecker” zu ignorieren. Das gehört wohl dazu. Aber solange alles läuft, kann es ja nicht so schlimm sein, wie sie sagen.

Ich bin immer wieder erstaunt, wie lange das gut geht, wie leidensfähig Menschen und Teams sein können.

Im besten Falle arrangieren sich die Teams irgendwann mit der Situation. Das ist zwar dann immer noch suboptimal, weil viel Potenzial verschenkt wird, aber – ich wiederhole mich – sofern bzw. solange man sich das so leisten kann (siehe Teil 2), ist das zumindest nicht schlimm.

Manche Teams fallen auseinander, die Fluktuation steigt und die Ergebnisse werden schlechter. Im Zweifel sind dann die Führungskräfte daran schuld, dass sie die Mitarbeiter nicht motivieren und halten konnten.

Im schlimmsten Fall leiden Mitarbeitende gesundheitlich unter der Situation.

Wie gesagt: Ich habe keine einfache Lösung dafür, nur den Hinweis, dass die Teams sich in solchen Situationen die Frage stellen sollten, wie sie den Schmerz dorthin umleiten können, wo er eigentlich hingehört, nämlich dorthin, wo er verursacht wird und abgestellt werden könnte. Denn im Grunde genommen handelt es sich hier um dasselbe Muster wie im Abschnitt zuvor. Nur sind es in diesem Fall die Teams, die den Rest der Organisation vor den Auswirkungen der Probleme schützen, indem sie trotz der widrigen Umstände immer wieder Mittel und Wege finden, gute Ergebnisse zu erzielen. Warum sollte der Rest der Organisation denn etwas verändern, wenn sie gar nicht unmittelbar betroffen sind, wenn sie selbst keinen Schmerz spüren?

Ausblick

Diese Artikelserie ist hiermit abgeschlossen. Vielen Dank für Ihre Aufmerksamkeit!

Ich hoffe, Sie hatten Freude und konnten aus den hier geschilderten Phänomenen und Fallstricken im Wandel von Bewährtem zu Neuem den einen oder anderen Impuls für Ihre Realität entnehmen. Ich habe keine Pläne für eine Fortsetzung. Ob es irgendwann einmal ein Spin-off, ein Sequel oder gar ein Prequel zu dieser Serie geben wird, das steht in den Sternen. Ich verabschiede mich jedenfalls erst einmal in mein Workatical und bin gespannt, wohin mich das führen wird.

Bleibt agil, bleibt neugierig, bleibt gesund!

Hinweise:

Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Hier finden Sie weitere Teile der Beitragsserie Agilität? Haben wir probiert! Funktioniert nicht!

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.