Das Scrum-Schisma

Bild: Pixabay / Schach 100 - Lizenz

Es gibt Entwicklungen die so langsam vor sich gehen, dass man sie erst bemerkt wenn sie bereits eine Zeit lang existieren und sich schon verfestigt haben. Eine davon dürfte die Aufspaltung der Scrum-Bewegung in zwei Ausrichtungen sein. Nicht etwa in Scrum Alliance und Scrum.org sondern viel grundsätzlicher: die eine Ausrichtung geht davon aus, dass Scrum von ganzheitlicher, organisationsweiter Bedeutung ist, die andere reduziert es auf die Team-Ebene.

Um zu verstehen wie diese Trennung entstanden ist hilft ein Blick in die Vergangenheit. In seiner ersten schriftlichen Form ist das heutige Scrum noch als teambasiert zu erkennen. Das OOPSLA-Paper von 1995 spricht eindeutig vom "Scrum Project Team" mit Subteams für Produktmanagement und Entwicklung. Es wird zwar betont, dass zum Entwicklungsteam auch Vertreter von Marketing, Vertrieb und anderen Funktionen gehören müssen, die Zusammenarbeit mit der umgebenden Organisation ist aber noch kein Thema.

Der seitdem entwickelte "offizielle Weg", vertreten von den Gründern Schwaber und Sutherland und den Verbänden Scrum Alliance und Scrum.org, ist (zugespitzt) der, dass sich das restliche Unternehmen nach dem Scrum Team zu richten hat. Laut Scrum Guide muss die gesamte Organisation die Entscheidungen des Product Owners respektieren, das Entwicklungsteam ermächtigen seine Arbeit selbst zu managen und wird in ihrer Umstellung auf Scrum von den Scrum Mastern geführt.

Dass das eher unbekannt ist liegt wesentlich an der Abneigung von Schwaber und Sutherland gegen zu spzifische Prozessbeschreibungen, die dann im Einzelfall nicht mehr passen würden. Die Art der Umsetzung ist daher bewusst offengelassen, die quasi-offiziellen Skalierungsframeworks LeSS und Nexus stimmen aber darin überein, dass die Verantwortung des Product Owners für alle an diesem Produkt arbeitenden Teams ein wesentliches Element ist.

Wesentlich häufiger als der "offizielle Weg" ist in Unternehmen die Situation vorzufinden, dass Scrum (und ähnliche Ansätze) auf die Teamebene beschränkt werden, und auch dort häufig nur auf die Umsetzung, während Planung, Architekturentscheidungen und Kunden-/Auftraggeberkontakt an andere Gruppen ausgelagert werden. Bekannt ist in diesem Zusammenhang SAFe mit seinen zahlreichen Rollen, aber auch PMI und Prince2 haben (eingeschränktes) Scrum bei sich integriert.

Diese Formalisierung ist aber letztendlich nichts anderes als das offiziell Machen der bereits in vielen Unternehmen schon länger gelebten Praxis. Ohne Kenntnis des übergreifenden Anspruchs (oder ohne Bereitschaft ihn zu akzeptieren) ist Scrum an vielen Stellen schon seit längerem ein reiner Team-Ansatz, der damit zwar die reine Lehre nicht erfüllt, meistens aber besser funktioniert als das vorher genutzte Mikromanagement.

Zu einem Zusammenprall der beiden unterschiedlichen Scrum-Auslegungen kommt es vor allem dann wenn Angestellte oder Berater mit einem Hintergrund der einen Scrum-Variante in ein Unternehmen kommen in dem die andere gelebt wird. Ein Konflikt ist dann unvermeidbar, der aber je nach Kenntnisstand unterschiedlich ausgetragen werden kann. Da wo den Beteiligten das "Scrum-Schisma" bewusst ist kann versucht werden zu einer Lösung zu kommen, da wo davon ausgegangen wird, dass das jeweils "eigene" Scrum auch das einzige ist reden sie aneinander vorbei.