Manuel Mehring - Blog

Thoughts on project management and the agile journey.


5. Mai

Scaled Agile Frameworks – Warum die wichtigste Frage nicht die des geeigneten Frameworks ist

Post-it Zettel an einem Scrum Board

Vorwort – Agilität – Viele Motivationen, viele Frameworks

Es gibt verschiedene Gründe warum man agile Frameworks einsetzen sollte und möchte. Je nachdem ob die Entscheidung Top-Down (vom Management aus abwärts) oder bottom-up (aus den Reihen der Mitarbeiter geschieht, sind die Motivationen unterschiedlich. Mitarbeiter versprechen sich von agilen Ansätzen oft bessere Qualität, fokussierteres Arbeiten und besseres Teamwork.

Aus Management Perspektive ist oft die Beschleunigung der Prozesse, die höhere Qualität und vor allem die Steigerung der Agilität im Vordergrund, die es Firmen ermöglichen soll, schnell und unkompliziert auf Veränderungen reagieren zu können. Auch die Steigerung der Zufriedenheit der Mitarbeiter kann hier eine Rolle spielen.

Bevor wir aber über die verschiedenen Agilen Frameworks sprechen, möchte ich auf eine zentrale Sache hinweisen, die ich bei vielen agilen Projekten gesehen habe.

Agilität skalieren – Macht aus kleinen Problemen große?

Viel wichtiger als die Wahl des richtigen Frameworks ist das vollständige Verständnis von Agilität. Wenn ich etwas skalieren möchte, so muss sichergestellt sein, dass es im Kleinen bereits funktioniert, bevor ich es skaliere – sonst macht man aus kleinen Problemen große.

Damit kurz zurück zu den Erwartungshaltungen, die an Agilität (oft synonym mit „SCRUM“) gestellt werden:

Erwartungshaltungen an agile Methoden und SCRUM aus Sicht der Mitarbeiter und des Managements

Wie oben bereits beschrieben gibt es oft verschiedene Erwartungshaltungen an Agilität. Auf der einen Seite versprechen Führungskräfte sich oft gesteigerte Qualität, eine schnellere Releasezeit von der Entscheidung bis zum Produkt (time to Market), gesteigerte Effizienz und idealerweise auch zufriedenere Mitarbeiter.

Auf der anderen Seite erwarten Mitarbeiter sich oft freier arbeiten zu können, sich besser auf ihre Arbeit fokussieren zu können (anstatt sich mit Politik und Prozessen auseinandersetzen zu müssen), sowie eine angenehmere Teamarbeit.

Dabei gibt es zwei Essenzielle Erkenntnisse, die ich in Projekten gemacht habe:

Agilität als Projektionsfläche unserer Wünsche

Agilität/Scrum wird oft zur Projektionsfläche unserer Wünsche. Das bedeutet, dass sich, wie oben beschrieben, die Projektbeteiligten oft verschiedene Dinge von Agilität versprechen. Das muss nicht unbedingt schlecht sein – aber es ist von essentieller Wichtigkeit, beiden Gruppen das jeweilige andere Verständnis näher zu bringen, sodass sich beide Kreise idealerweise überlappen. Ist das nicht der Fall, verfolgen die Beteiligten verschiedene Wünsche und Ziele, was zu starken Konflikten führen kann. Angelehnt an das Johari Fenster, ist die jeweils andere Sicht oft der blinde Fleck bei den Beteiligten, den es zu reduzieren gilt.

Das Unbekannte an der Agilität

In der Mitte beider Kreise gibt es etwas, dass beiden Seiten unbekannt sein kann. Eines der Geheimnisse des Erfolges von agilen Frameworks liegt darin, dass sie typische verlangsamende Strukturen durch effiziente Abläufe und Rollen ersetzen und Probleme schnell offenlegen. Diese Veränderung muss aber nicht immer gewollt sein. Wie man sehen kann, sind die Stichpunkte in der Mitte negativ konnotiert. Dies soll unterstreichen, dass diese Dinge oft negativ wahrgenommen werden können. (Obwohl ich sie für sehr erstrebenswert halte)  Eines der obersten Credos von Scrum ist die Schaffung von Transparenz. Transparenz ist nötig um auf Probleme aufmerksam zu machen und diese zu beseitigen. Das offene Ansprechen von Problemen kann jedoch sehr schnell unbequem sein. (konfliktvermeidung, bzw. gelebte Fehlerkultur) Hier muss man sehr stark moderierend eingreifen und im Vorfeld die Erwartungshaltungen mitgestalten. Das gleiche gilt für klare Verantwortungen. Scrum regelt klar die Rolle von Product Owner, Scrum Master, dem Team und den Stakeholdern. Dazwischen gibt es kein „Wenn-und-Aber“. Das bedeutet aber auch, dass Menschen uneingeschränkte Verantwortung übernehmen müssen. Für manche mag dies befreiend sein, für andere ist es eher beängstigend. Auch das Thema „Vertrauen“ ist zentral in Framworks wie Scrum oder skalierten Framworks wir SAFe oder Nexus: Es wird erwartet, dass Führungskräfte ihren Teams vertrauen und ihnen nicht „dazwischenreden“. Plakativ ausgedrückt: Selbstbestimmung statt „Command-and-Control“. Man stellt schnell fest, dass es sich bei diesen Änderungen nicht nur um bloße Stichpunkte handelt, sondern um Dinge, die wir Menschen oft als unveränderlich zuschreiben, wie Verhaltensmuster oder Grundwerte. Diese zu verändern ist bei vielen Menschen nur sehr langsam möglich, bei manchen gar nicht.

Erwartungshaltungen an agile Methoden und SCRUM aus Sicht der Mitarbeiter und des Managements

Bevor wir den nächsten Schritt zu den skalierten agilen Framworks wagen, lautet daher mein Aufruf: Fragt euch: Leben wir Agilität wirklich und stehen wir zu den Werten von Agile/Scrum?

Wenn ihr euch nicht sicher seid empfehle ich euch ein agile-assessment durchzuführen. Entweder nur für euch selbst, oder noch besser: Mit eurem Scrum Master/Teams zusammen. Dazu gibt es viele Ansätze die sich über Google einfach unter dem Stichwort „Agile-Assessment“ finden lassen.

Wenn ihr alle Punkte voller Überzeugung in euren Teams mit „Ja“ beantworten könnt, habt ihr eine solide Basis geschaffen um euch dem nächsten Schritt der Reise zuwenden zu können: Der Auswahl des richtigen Frameworks für die agile Skalierung.

 

Schlussworte

Ursprünglich sollte der erste Artikel in diesem Blog sich mit der Auswahl der verschiedenen skalierten agilen Frameworks auseinandersetzen. Da jedoch die Schaffung der richtigen Voraussetzungen mindestens so wichtig ist wie die Wahl des richtigen Frameworks, entstand diese zweiteilige Artikelserie.

 

Teaser Photo by bonneval sebastien on Unsplash