Dienstag, 5. November 2019

Welches Scrum darfs denn sein?

FS
Bilder: Flickr / Charlie / Royskeane - CC BY 2.0
"Wir machen Scrum" ist eine Aussage die man mittlerweile von sehr vielen Teams hören kann. Schaut man sich einzelne davon näher an lassen sich allerdings grosse Unterschiede erkennen, zum Teil sogar so grosse, dass praktisch keine Vergleichbarkeit mehr gegeben ist. Das hat natürlich in vielen Fällen mit der freien Wahl der optionalen Bestandteile, mit Missverständnissen und mit Cargo Cult zu tun, selbst wenn man das weglässt bleibt aber noch eine erstaunliche Vielfalt übrig. Der Grund dafür - es gibt mehrere Varianten von Scrum, die sich z.T. deutlich unterscheiden:

Ur-Scrum

Die fast vergessene initiale Variante von Takeuchi und Nonaka, bzw. von DeGrace und Stahl. Nahezu alles was heute als Erkennungszeichen von Scrum Teams gilt fehlt hier noch. Keine Scrum Master, keine Product Owner, keine Sprints, keine Backlogs, keine Dailies, keine Sprint Reviews, keine Retrospektiven. Stattdessen findet sich vieles was heute eher zu den Grundlagen von Agilität gehört: crossfunktionale, stabile Teams, enger Kundenkontakt, Experimentier- und Fehlerkultur. In der Arbeitswelt kaum noch anzutreffen, mit Ausnahme von Teams die aus historisch interessierten Methoden-Nerds bestehen.

"Historisches" Scrum

Schon näher am "aktuellen" Scrum, aber noch nicht ganz da. Da Scrum regelmässig weiterentwickelt wird (seit 2010 im Rahmen des Scrum Guide) kommt es regemässig dazu, dass Teams auf einem älteren Entwicklungsstand stehen bleiben. Bei jüngeren Entwicklungen macht das kaum einen Unterschied, bei älteren kann der Unterschied deutlich sichtbar sein. Was z.B. noch immer verbreitet ist sind die "Pig" und "Chicken"-Rollen und verpflichtende Burndown Charts, aber auch andere "Relikte" kommen immer wieder vor. Vor allem in Teams oder Firmen anzutreffen die schon seit mehreren Jahren nach Scrum arbeiten.

Scrum by the Book

Der "Idealfall". Ist zu finden bei Teams die sich an der aktuellsten Form des Scrum Guide ausrichten und ihr Vorgehen nach jeder Aktualisierung anpassen. Ein Indikator dafür ist z.B. die (aktuell noch) neue Regel, dass das Sprint Backlog auch Massnahmen zur Prozessverbesserung enthalten sollte. Voraussetzung ist, dass es mindestens ein Teammitglied gibt, dass sich über aktuelle Entwicklungen auf dem Laufenden hält und diese im Team einbringt (im Normalfall ist das der Scrum Master). Im weiteren Sinn gehören auch die Skalierungsframeworks LeSS (Large Scale Scrum) und Nexus zu dieser Kategorie, da beide Wert darauf legen kaum zusätzliche Prozesse und Strukturen einzuführen und stattdessen "Scrum auf sich selbst anzuwenden".

ScrumBut / ScrumAnd

Leider der Normalfall. Berechtigt oder unberechtigt gibt es in vielen Firmen die Überzeugung, dass Scrum by the Book dort nicht funktionieren würde. Die Folgen: Weglassungen (ScrumBut) und/oder Überfrachtungen (ScrumAnd). Zu bemängeln sind in derartigen Zusammenhängen vor allem zwei Dinge - zum Einen, dass der Begriff Scrum auch dann noch benutzt wird wenn wesentliche Voraussetzungen und Kernelemente entfernt wurden, zum Anderen, dass häufig die (irrationale) Erwartungshaltung vorherrscht trotz erheblicher Eingriffe noch immer den maximalen Umfang möglicher Verbesserungen erwarten zu können.

Verschlimmbessertes Scrum

Zum Glück ein zurückgehender Trend. Getrieben von falschem Verständnis oder von kommerziellen Interessen wurden ab ca. 2010 immer wieder scheinbare (und falsche) Widersprüche konstruiert. Scrum wäre ja toll, würde sich aber bestimmte Aspekte (z.B. Security) nicht berücksichtigen, wäre nicht geeignet für grosse Unternehmen, etc. Als Lösung wurden scheinbare Weiterentwicklungen wie Secure Scrum, Reliable Scrum, Utra Scrum [sic], Scrum 2.0 oder Scrum 3.0 angeboten, die aber fast immer nur bürokratisierte oder verwässerte Abweichungen ohne erkennbaren Mehrwert sind. In gewisser Weise eine weitere Form von ScrumAnd. Ausschliesslich bei einzelnen Beratungsunternehmen zu finden.

Kastriertes Scrum

Der grosse zunehmende Trend der letzten Jahre. Seit etwa 2013 gibt es immer wieder Versuche Scrum in stark deskriptive oder Top Down-getriebene Projektmanagement-Methoden einzubinden. Die grosse Gemeinsamkeit - Scrum wird in diesem Zusammenhang nur als Arbeitsmodus einzelner Umsetzungsteams gesehen, die gleichzeitig nur ein untergeordneter Teil von grösseren Planungs- und Kontrollstrukturen sind (bekanntestes Beispiel ist SAFe). Bedingt dadurch sind zwei der wichtigsten Eigenschaften nicht mehr gegeben: Product Ownership und Process Ownership. In gewisser Weise eine weitere Form von ScrumBut, aber mit Literatur, Zertifizierungen, Konferenzen, etc.

Scrum@Scale / Scrum the Toyota Way

Zwei relativ neue und in ihrer Entstehung eng verknüpfte Scrum-Varianten (Scrum@Scale ist ein Skalierungsframework von Scrum-Pionier Jeff Sutherland, Toyota Connected eine der ersten Firmen die es eingesetzt hat). Das Besondere an ihnen: anders als in den weiter oben genannten Skalierungsframeworks LeSS und Nexus wird das untere und mittlere Management nicht obsolet sondern organisiert sich selbst in "Meta-Scrum-Teams" (Produktmanagement) und "Scrum of Scrums-Teams" (Prozessmanagement). Für die Toyota-Kultur mit ihrem stark auf die Team-Unterstützung ausgerichteten Management-Stil sicher passend, spannend wäre ob es auch woanders funktioniert.

Und noch mehr ...

Bei weiterem Suchen würde man mit Sicherheit noch weitere Varianten von Scrum finden, gute, schlechte und viele die irgendwo in der Mitte sind. Wichtig ist es sich über die Unterschiede im Klaren zu sein, denn eines ist angesichts dieser Vielfalt sicher: "Wir machen Scrum" ist zu wenig Information um zu erkennen was genau da gemacht wird.
Powered by Blogger.