Welches Scrum darfs denn sein?
"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 (ob man auf dem aktuellsten Stand ist kann man mit Hilfe der
Scrum Guide Revision History herausfinden). 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 Skalierungs-Frameworks 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, Ultra 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 (
