18. Mai 15

Praxistest: Mit der Scrum-Methodik neue Agilität in den Change bringen

Wie schon im letzten Dezember angekündigt (im Blogbeitrag zur Unsortiertheit moderner Organisationen), widmen wir uns in diesem Jahr verstärkt der Frage, wie das Gesamtzusammenspiel organisationaler Steuerungslogiken und ihrer Akteure in der Change Implementierung gelingen kann, ohne dass gleichzeitig die interne Komplexität "explodiert“.

Unsere Beobachtung:

Angefeuert von StartUp-Organisationsmodellen aus der E-Economy (siehe dazu exemplarisch das Spotify-Beispiel von Henrik Kniberg und Anders Ivarsson in der ZOE 1-15) suchen aktuell gerade auch sehr ausdifferenzierte Organisationen nach neuer Agilität in Themenbearbeitung und Entscheidungsfindung.

Wie lässt sich aber eine "neue Agilität“ etablieren, wenn man bereits auf allen Ebenen eine höchst differenzierte Organisation vorweisen kann (z.B. im Prozessmanagement, im Projektmanagement, in den funktionalen Rollen und deren Zusammenspiel an Schnittstellen, …)?

Oft suchen diese Organisationen ihr Heil in "Insellösungen“, d.h. es werden Innovations-Biotope geschaffen, in denen permanent die Bedarfe der vorausschauenden Selbsterneuerung abgescannt werden, um neue Lösungen zu entwickeln. Aber auch diese – häufig bewusst hierarchiefreien - Entwicklungs-Inseln müssen letztlich wieder mit den bisherigen Steuerungs- und Management-Logiken in eine intelligente Verknüpfung gebracht werden. Eine Übung, die nicht selten auch aufgrund divergierender interner politischer Interessenslagen immer wieder recht sperrig verläuft, z.B. wenn die gerade noch innovativen Geschäftsideen im Rahmen langwieriger Projektkonkretisierung nach und nach wieder in Frage gestellt werden.

Hier nun ein praktisches Beispiel, wie es auch anders gehen kann:

Im Rahmen einer kontinuierlichen Entwicklungsmaßnahme für ein Führungsteam im Qualitätsmanagement eines großen Konzerns haben wir gute Erfahrungen mit einer Adaption der Scrum-Methodik gemacht. Diese hatten wir in der osb bisher vor allem als Variante der Strategieentwicklung beschrieben, getestet und in diversen Kundenveranstaltungen vorgestellt (vorangetrieben von meinen Kollegen Walter Dietl und Reinhart Nagel).

Das "Neue“ für den Bereich Qualitätsmanagement dieses Konzerns lag darin, das Scrum-Prinizip auf die Entwicklung der eigenen Steuerungs- und Dienstleistungsprodukte zu übertragen und in diesem Rahmen überhaupt ein gemeinsames Produktverständnis in der gesamten Führungsmannschaft zu entwickeln. Vorgabe von Seiten unseres Kunden war dabei, die ganze Führungsmannschaft in die gemeinsame Arbeit zu diesen Fragen zu integrieren.

Die Ausgangslage:

Der Bereich Qualitätsmanagement als Zentralbereich eines Konzerns hat die Erfahrung gemacht, dass im Rahmen einer Neuausrichtung dieses Konzerns sowohl der Entwurf als auch die Umsetzung zukunftsorientierter Change-Themen (wie z.B. die Internationalisierung des eigenen QM-Anspruchs in einem erweiterten Konzernverbund) nur sehr schleppend voranging.

Die Verortung dieser Themen im internen Projektmanagement führte zu Kompetenzstreitigkeiten und sehr langwelligen Bearbeitungsschleifen. Auch die bereits sehr differenziert vorhandene Prozessarchitektur verhinderte tendenziell ein Denken in neuen Lösungen.

Das Format:

Es wurde beschlossen, eine Führungskräftetagung zu den aktuell wichtigsten Change-Bedarfen nach den Prinzipien des Scrum durchzuführen.

Scrum™ ist ein vor allem in der Softwareentwicklung etabliertes Projektmanagement -Rahmenwerk (siehe auch Schwaber & Sutherland) das sich an den Prinzipien agiler Entwicklung orientiert:

Funktionsübergreifende, sich selbstorganisierende Entwicklungsteams entwickeln in konzeptionellen "Sprints“ launchfähige Lösungen.
Die Anforderungen an die Lösungen sind als Listeneinträge im “Produkt-Backlog” festgehalten. Kunden und Entwicklungsteams arbeiten eng zusammen.
Ein Product-Owner ermittelt, entwickelt und priorisiert Anforderungen des Product Backlogs und gibt damit die Richtung immer wieder klar vor.
Ein ScrumMaster unterstützt als Moderator und Team Coach. Er ist verantwortlich für die Einhaltung der Scrum Regeln und die optimale Umsetzung des Scrum Prozesses.

Die Ergebnisse:

Bereits nach der ersten 2-tägigen Klausur über drei Führungsebenen hinweg, die ganz nach den Scrum-Prinzipien des agilen Vorgehens ausgerichtet war, stellte sich im Bereich eine große Verwunderung darüber ein, wie schnell man auf diese Weise zu einer gemeinsamen Ausrichtung bzgl. der anstehenden Change-Themen und zu umsetzbaren Ergebnissen gekommen war.

Folgende Erfolgsfaktoren sehen wir dabei als entscheidend an:

Die permanente Erreichbarkeit und Transparenz des Bereichsleiters in seiner Rolle als Product Owner ermöglichte den themenverantwortlichen Führungskräften der nachfolgenden Ebenen eine viel schnelle Neujustierung der Erwartungshaltungen als dieses im Projektalltag bisher der Fall gewesen war. Dieses temporäre Durchbrechen der bisherigen Projektstrukturen erlaubte einen breiteren Einbezug von Stakeholdern zur Definition der Produktvisionen sowie ein kurzzyklisches "Nachschärfen“ bei Bedarf. Dadurch wurden die Erwartungshaltungen der Bereichsleitung aber auch der internen Kunden-Bereiche wesentlicher deutlicher.
Die geteilte Verantwortung im interdisziplinären Entwicklungsteam über alle Abteilungsgrenzen hinweg transportierte eine neue Kultur der Zusammenarbeit zwischen den Führungskräften. Man begegnete sich in neuen Rollen und konnte auf diese Weise bisherige fachliche Konflikte konstruktiv aushandeln. Die Frage: Wie kommen wir gemeinsam zu passenden Lösungen? ersetzte die Frage: Wer ist zuständig und darf definieren, was eine gute Lösung ist? Unterstützt wurde diese Haltung auch durch den permanenten Zeitdruck. Die Teams arbeiteten parallel an Teilprodukten / Backlogs und mussten jeweils in 2-3 stündigen Sequenzen zu vorzeigbaren Zwischenlösungen kommen.
Der Einbezug der dritten Führungsebene erweiterte die Perspektiven in der Beschreibung neuer zukunftsfähiger Steuerungs- und Dienstleitungsprodukte und verhinderte ein einseitiges "Festhalten“ an den bewährten bisherigen Routinen, die gerade in einem zentralen Qualitätsmanagement eine hohe identitätsstiftende Bedeutung haben.

Unterm Strich konnten im "Was“ der Themenbearbeitung also echte inhaltliche Fortschritte verbucht werden, im "Wie“ entstand eine konstruktive positive Energie im neuen Miteinander. Und das alles in einem sehr verdichteten Zeitraum. Am Ende wurden klare Verabredungen getroffen, die Zukunftsthemen dieses Bereiches auch weiterhin mit Hilfe des Scrum-Vorgehens voranzutreiben.

Eine essentielle Voraussetzung für ein paralleles Scrum-Vorgehen wurde aber auch schon jetzt deutlich: Durch die vorherige Arbeit mit diesem Führungsteam war eine ausreichende Reife und Arbeitsfähigkeit in der sozialen Dimension des Miteinanders erreicht worden, ohne die die Scrum-Methodik sicher nicht so konfliktfrei und effektiv hätte implementiert werden können.

Wir werden nun weiter beobachten können, wie sich dieses Steuerungsformat neben den bisherigen Logiken auch langfristig etablieren lässt.

Quellen:

Zeitschrift für Organisationsentwicklung 1/15 “Stämme, Trupps, Verbände und Zünfte – Agiles zusammenarbeiten beim Softwareunternehmen Spotify” (Henrik Kniberg, Anders Ivarsson)
"Der Scrum-Guide™“ (Ken Schwaber & Jeff Sutherland 2013)