Scrum – Der Cultural Clash der agilen Veränderung

Scrum einzuführen ist in erster Linie ein Cultural Clash zwischen den agilen Teams und den nicht-agilen Teilen einer Organisation. Zu Beginn ist die Scrumadaption eine lokale Innovation. Gleichviel ob es sich um ein, zwei Scrumteams, oder um agile Skalierung einer ganzen Abteilung handelt. Das agile Mindset bleibt dabei auf wenige Köpfe im Unternehmen beschränkt. Agile Coaches oder Scrum Master aber müssen dieses Dilemma lösen. Der Schlüssel zum Erfolg ist die Synchronisation zwischen Linie und Scrumteam. Um den Cultural Clash abzufedern, ist die Interaktionshäufigkeit über fokussierte Kommunikationsstrukturen im Scrumsystem und der Linie als Systemumwelt eine zentrale Erfolgsgröße der agilen Veränderung.

[A major mistake is…] not preparing the organization around a Scrum project – A team embracing Scrum cannot work in isolation. It needs to interact with various other teams to be successful. [1]

Was ist das Problem?

Scrum verändert die Art und Weise wie in agilen Teams zusammengearbeitet wird nachhaltig. Aus Gruppen in hierachischen Strukturen mit einer Leaderrolle werden selbstorganisierte Scrumteams mit drei nicht hierachischen Leaderrollen. Dieser Veränderungsprozess sollte nicht intuitiv erfolgen. Im Gegenteil die Orientierung am Scrum Guide sollte die Veränderungsstruktur bestimmen. Dennoch steuert man unweigerlich in einen Cultural Clash. Zum einen „predigen“ wir das agile Mindset. Zum anderen hat jedes Unternehmen eine eigene Unternehmenskultur und jede Abteilung ihre Abteilungskultur. Diese Unternehmenskulturen sind beispielsweise durch hierachische Strukturen, Arbeitszeitmodellen oder bestimmten Führungsänsatzen geprägt.

Beispielsweise verdeutlicht die Positionsbezeichnung „Gruppenleiter“, dass dieser die Führungskraft einer Gruppe ist. Die „Teammitglieder“ haben  1…n Performanceverträge. Diese werden in 1…n   „Performancedialogen“ mit dem Gruppenleiter besprochen und festgelegt.  Jedes „Teammitglied“ möchte natürlich seine Performanceziele einhalten, wodurch sich 1…n Individualziele ergeben. Diese zahlen natürlich in die Ziele des Gruppenleiters ein und diese wiederum in die Abteilung. Selbstverständlich hat auch ein Gruppenleiter mit seinem Abteilungsleiter einen Performancevertrag im Verhältnis 1…1. Bei einer Gruppengröße von 10 sind das mit dem Gruppenleiter zusammen 11 Performanceverträgen mit 11 Performancezielen. Somit ist es nicht einfach getan, Scrum mit seinen eigenen Regeln und Prozessen einzuführen und neben die bisherige Organisationsstruktur zu stellen, um dann darauf zu hoffen, es wird sich schon alles einrenken, wenn man nur richtig agil wird. Werden die Linien nicht von Beginn an in den Scrumprozess integriert, entstehen Störungen sowohl im Scrumsystem als auch im Liniensystem. Irritationen wirken zumeist ein paar Sprints auf den Veränderungsprozess ein. In Lean gedacht, handelt es sich dabei um eine Muda Typ-2 Verschwendung, da es sich bei Irritationen um nicht wertschöpfende Aufwände im Scrumproduktionssystem handelt.

Unterschied zwischen Teams in der Organisation und  Scrumteams

The most important feature of a team is “synergy” i.e. the team can achieve much more as the members can achieve individually.  Team leadership means more than one leader. [2]

Scrumteams mit dem Product Owner, dem Scrum Master und dem Development Team teilen sich die Verantwortung einer (Software-) Produktentwicklung. Jede Rolle hat bestimmte Aufgaben. Dieses Führungsmodell hat mehr als einen Leader und ist selbstverantwortlich sowie selbstorganisierend im Projektmanagement. Dieses Verständnis ist dem hierachischen Model mit einem Leader und 1…n Teammitgliedern zuerst äußerst konträr. Die bekannte Richtgröße von 7+/-2 soll das Ziel unterstützten, ein Scrumteam mit  hoher Interaktionsfrequenz zu entwickeln. Die Interaktionshäufigkeiten werden überberechenbare Kommunikationspfade sowie den Scrummeetings strukturiert. Die Formel lautet: Anzahl der Kommunikationspfade = n(n-1)/2.

J. J. Sutherland, scruminc.@, 2017

Dieses Modell wird in Scrumteams gelebt, jedoch nicht unbedingt in der Linie. So sind die Meetings in Scrum mit ihrem jeweiligen Inhalt eindeutig festgelegt. Vorallem ihre Anzahl ist mit gutem Grund eingeschränkt. Demgegenüber stehen Meetingstrukturen der hierachischen Aufbauorganisation, die weniger iterativ bestimmt sind. Die mögliche Menge aus Scrum-, und Linienmeetings ist die erste Knautschzone. Das Verständnis darüber, dass es in Scrum drei Leadingrollen gibt, steht dem Verständnis von Führung einer Gruppe in der hierachischen Aufbauorgnisation gegenüber. Ein weiteres Spannungsfeld ist durch die Teamautonomie, den Valuezielen und der agilen Softwareentwicklung gegeben.

Root Cause Analyse

Aufgrund dieser Voraussetzungen darf der Veränderungsprozess keinesfalls intuitiv erfolgen. Im Gegenteil die Orientierung am Scrum Guide sollte die Veränderungsstruktur bestimmen. Das ist nicht dogmatisch gemeint. Wenn wir jedoch eine Root Cause Analyse anstreben, benötigen wir Differenzierungsmerkmale der beiden Systeme. Die fünf wichtigsten Fragen einer Root Cause Analyse sind: Warum? Warum? Warum? Warum? und Warum? Das Problem muss aber auch quantifizierbar sein, denn wenn das Problem nicht quantifizierbar ist, wie soll dann die Verbesserung messbar sein? Beispielsweise kann die Anzahl der Linienmeetings erhoben werden. Die Linienmeetings werden den Scrummeetings gegenübergestellt. Gemeinsam wird besprochen, welche Linienmeetings reduziert werden können. Darauf aufbauend kann eine gemeinsame Commom Collaboration Time für die Produktentwicklung festgelegt werden. Diese ist für die ersten drei, vier Sprints die Kapazität der jeweiligen Teammitglieder. So wird die Linie und Scrum synchronisiert.

 

 

[1] Vikas Hazrati, Challenges in Adopting Scrum, in InfoQ, Dec. 12 2008.

[2] Fran Ackermann, Colin Eden, Making Strategy, 2011.