Wer ist schuld am Transformationsstau?

Wenn mich meine Freunde fragen, was ich beruflich mache und ich ihnen sage, dass ich Management Consultant und Agile Coach bin, ist eine typische Antwort: „Scrum haben wir auch probiert, funktioniert bei uns nicht.“ Aber ist es richtig, Scrum die Schuld für die schlechte Ausführung von Agilität oder für schleppende Transformationen zu geben? Das ist so, als würde man die Straßenverkehrsordnung für Staus verantwortlich machen. Die Regelungen für Geschwindigkeit, Vorfahrt, Überholen, Abbiegen und Parken dienen aber hauptsächlich dazu, die Sicherheit im Straßenverkehr zu gewährleisten. Wenn es sich irgendwo regelmäßig staut, verzichten wir nicht auf Sicherheit, wir arbeiten an der Infrastruktur.

Ampel vs. Kreisverkehr

ScrumMaster oder Product Owner brauchen einen Kontext, also eine Organisation, die ihre Mitarbeitenden dafür würdigt, dass sie agil arbeiten. Um zu verstehen, wie man mit Scrum-Projekten erfolgreich wird, muss man verstehen, dass die Methode selbst kein Projekt agil macht. Tatsächlich wird ein Projekt erst dann agil, wenn man sich vollkommen anders als bisher mit den Herausforderungen der Produktentwicklung auseinandersetzt.

Zu erwarten, dass man schneller entwickelt, nur weil man jetzt auf einmal auch Dailys und Reviews macht, ist schlicht ein Irrglaube. Stattdessen muss ein ganzheitlicher Wandel vor sich gehen: von der Betrachtung von Projekten (nach innen gerichtet) zum Fokus auf Produkte (nach außen gerichtet). Wenn ihr Unternehmen aber vor der Transformation bereits über Technologie, Dienstleister, Deadline und Konzept entschieden hat, haben ScrumMaster, Product Owner und das Team keine Möglichkeiten mehr, selbstorganisiert zu arbeiten. Sie können sich nur einreihen. Es ist macht keinen Unterschied, ob sie die Strukturen und Prozesse für sinnvoll halten oder ob sie bessere Ideen haben.

Daher ist es wichtig, Freiräume zu geben und von der Kontrolle abzulassen, damit Agilität eine positive Wirkung auf die Teamleistung hat. Nehmen wir hierzu das Beispiel zweier Kreuzungen: eine geregelt mit einer Ampel und die andere mit Kreisverkehr. Die Ampel ist unkompliziert und klar. Bei Grün gebe ich Gas, bei Rot stehe ich. Man muss beim Überqueren der Kreuzung kaum Rücksicht auf andere nehmen, weil die ja Rot haben. Die Ampelphasen werden von der Stadtplanung festgelegt, basierend auf alten Daten und Voraussagen. Aber in einer sich ständig ändernden Welt kann die Schaltung nicht spontan reagieren. Die Folge sind Staus.

Im Gegensatz dazu ist das Fahren im Kreisverkehr für mich als Autofahrer eine Herausforderung, weil ich auf andere Rücksicht nehmen muss, aber dafür ist es effizienter. Wenn die Kreuzung um Mitternacht leer ist, muss ich nicht warten wie an der Ampel. Das Ampelsystem basiert auf Regeln (rot-gelb-grün). Der Kreisverkehr hingegen auf Werten. Das heißt, man kann nicht einfach losfahren wie bei Grün an der Ampel, man muss auf andere achten. Die Ampel hat den Fokus auf Kontrolle und der Kreisverkehr gibt den Fahrerinnen und Fahrern Freiheiten. Weitere positive Effekte des Kreisverkehrs sind übrigens eine besser Unfallbilanz und geringerer Spritverbrauch.

Bjarte Bogsnes erklärt die Analogie von Kreisverkehr und Ampel für den Organisationskontext sehr gut:

https://youtu.be/NwqG5W9b37o?t=464

Kontrolle vs. Freiheit

Im Verkehr sehen wir schön: je reglementierter ein System, desto weniger eigenes Nachdenken und Verantwortung sind gefragt und desto ineffizienter ist die Ausführung. Durch Weglassen von Kontrollen und durch mehr Kreisverkehre bekommt man bessere Resultate auf der Straße. Was bedeutet das nun für unseren Vergleich mit agilen Methoden und Transformationen? Die agile Analogie zur StVO ist der Scrum Guide, der Leitlinien für agiles Arbeiten enthält. Der Scrum Guide lässt uns viel Freiheit. Wenn nun aber die Organisation den agil arbeitenden Teams ihre Regeln überstülpt, haben wir ein ineffizientes System.

Agilität ist mehr als nur ein Prozess oder Framework, sie ist eine Mindset-Frage. Es ist wichtig, die Prinzipien, wie Selbstorganisation, zu gewährleisten. Wenn ich auf Scrum umstelle, muss ich auch die Ampel abbauen. Ich muss den Kulturwandel, den agile Methoden mit sich bringen, verinnerlichen. Das bedeutet, ich muss Teams so schneiden, dass sie autonom liefern können, ich muss ihnen einen geeigneten Rahmen zur Verfügung stellen, damit sie ein Produkt alleine erstellen können und sie selbst Entscheidungen treffen lassen. Wenn die kulturelle Voraussetzung nicht gegeben ist, ist die Anzahl geschulter ScrumMaster und Product Owner irrelevant.

Bauen Sie das Straßennetz aus

Wenn Sie Scrum in Ihrem Unternehmen nutzen wollen, empfehle ich Ihnen, es als teambasiertes Management-Framework und Methode zur Produktentwicklung zu verstehen. Denn Scrum beginnt bereits bei der Produktidee und nicht erst wenn schon alles vorgegeben ist: das Arbeitsmodell, die Teamstruktur, die Anforderungen an das Produkt.

Scrum wurde ursprünglich für die Arbeit eines einzelnen Teams entwickelt. Das teambasierte Framework auf ein ganzes Unternehmen zu übertragen, bedeutet, dass das Management einen geeigneten Rahmen für die ScrumMaster, Product Owner und Teams schaffen muss. Dazu müssen Managerinnen und Manager wissen, wie sie eine funktionale Organisationsstruktur zu einer wertschöpfungsorientierten umgestalten können, wie Sie die Unternehmenskultur ausrichten wollen und wie sie die strategische Planung taktisch und operativ umsetzen sollen. Schauen Sie sich hierzu gerne die Trainingsreihe myScaled Agile Practitioner an. Für einen tieferen Einblick empfehle ich Ihnen auch das Buch meiner Kolleginnen und Kollegen „Agile Transformation – Der Praxisguide zum Change abseits des Happy Path“. Ich freue mich auf Ihre Kommentare.

Bild: Unsplash License, J Torres