ScrumBut, ScrumAnd und Water-Scrum-Fall
Über Extreme Programming (XP) schrieb Kent Beck1, man müsse alle seine Praktiken einsetzen, weil die Nachteile der einen durch andere ausgeglichen werden. Nur vollständig angewendet könne XP funktionieren.
Scrum sieht allerdings ausdrücklich vor, dass in der Retrospektive der Arbeitsprozess an die Bedürfnisse angepasst wird. Dabei könnte das Team gemeinsam entscheiden, Praktiken wegzulassen, durch andere Praktiken zu ersetzen oder durch nicht-agile zu ergänzen. So entstehen dann Scrum-Varianten:
- ScrumBut: Wir machen Scrum, aber wir lassen diese und jene Praktik weg.
- ScrumAnd: Wir machen Scrum und ergänzen es um eine oder mehrere zusätzliche Praktiken.
- ScrumBan: Eine Mischung aus Scrum und Kanban mit Kanban Board und Prozessmanagement.
- Water-Scrum-fall: Hier wird nur die Implementierung mit Scrum durchgeführt, aufbauend auf einem BUD (Big Upfront Design), Machbarkeitsstudie und Budgetierung, und dann abgeschlossen durch eine Qualitätssicherung des Gesamtsystems und einer Big Bang-Einführung.
Die beliebtesten und unbeliebtesten Scrum-Praktiken
Scrum ohne Abweichung setzen nur 42% aller Scrum-Teams2 ein. Die folgenden Zahlen stammen aus dieser Umfrage der Agile Alliance 2015 sowie aus einer Umfrage der Firma SwissQ aus dem Jahr 2012, die leider nicht mehr online steht.
Folgende Scrum-Praktiken werden von Scrum-Teams häufig verwendet:
- 90% arbeiten iterativ.
- 82% machen ein Daily Standup.
- 81% haben ein Backlog-Management.
- 81% der Teams machen am Sprint-Ende eine Retrospektive.
- 67% verwenden ein Burndown Chart.
- 64% definieren die „definition of done“.
Gerne weggelassen werden folgende Praktiken, die allerdings, wenn man genau hinsieht, auch gar nicht im Scrum Guide stehen:
- 58% machen Refactoring.
- 36% machen Test-Driven Development.
- 28% programmieren im Paar.
- 16% messen technische Schulden.
Wie man ein ScrumAnd oder ScrumBut entwickelt
ScrumAnd sind sehr häufig. Wenn Sie den Scrum Guide3 konsultieren, lesen Sie dort beispielsweise nichts von User Stories oder Epics, Task Board, Planning Poker, Code-Reviews oder DevOps, obwohl diese Praktiken in der agilen Welt weit verbreitet sind und auch in Scrum angewendet werden. Wenn das Team entscheidet, zusätzliche Artefakte zu verwenden, kann das nicht viel schaden, höchstens etwas Zeit verschwenden.
ScrumButs jedoch sind gefährlich, weil hier Scrum-Praktiken weggelassen oder ausgetauscht werden. Gerüchten zufolge bezeichnen sich auch vollständig chaotische Gruppen gerne als Scrum-Teams. Ein ScrumBut muss darum vorsichtig entwickelt werden. Wenn Sie jedoch Scrum verwenden, um Ihr ScrumBut zu optimieren, dann entwickeln Sie damit kontrolliert Ihr eigenes Vorgehensmodell für Ihr Umfeld und Ihr Team4.
„Scrum pur“, wie es im Scrum Guide3 beschrieben steht, ist für diesen Optimierungsprozess sicher ein guter Ausgangspunkt. Vielleicht sogar der einzig sinnvolle Ausgangspunkt.
Quellangaben:
1: Kent Beck: „Extreme programming explained“, Addison-Wesley, Upper Saddle River, 2000
2: Scrum Alliance – State of Scrum (2015): https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf
3: Scrum Guide (v1, DE): https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf
4: ScrumButs are the best part of Scrum: http://noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html
Hallo Frau Dr. Herrmann,
wenn man in %-Zahlen spricht, sollte man die Grundgesamtheit kennen. Was heißt 42 % aller Scrum-Teams? Wieviel Teams wurden befragt bzw. beobachtet? Weiterhin sollten Sie angeben von welcher Domäne Sie sprechen. Handelt es sich hier nur um Software oder auch um den Einsatz in anderen Domänen z. B. bei hybriden Produkten (Hardware) ? Wie Sie sicherlich wissen, wird der Einsatz von agilen Methoden auch in Hardware-Domänen z. Zt. getestet bzw. diskutiert. Dabei entstehen sehr viele Vorschläge zu den agilen Praktiken und Methoden. Interessant sind dabei natürlich die in der Praxis veränderten Scrum-Praktiken.
Mit freundlichen Grüßen
Horst
Guten Tag,
Sie haben natürlich Recht. Allerdings sollte dieser Blog-Artikel ja nur einen kurzen Überblick geben und nicht die Studien im Detail darstellen.
Die näheren Informationen zur Studie der Scrum Alliance finden Sie hier in deren Publikation:
https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf
Befragt wurden mehr als 5000 Personen aus 108 Ländern und 14 Branchen. Nur 44% der Befragten arbeiten in der Software-Entwicklung. Die Hardware-Entwicklung wird hier nicht extra genannt. Nicht alle Befragten verwenden Scrum, sondern 82%. Von diesen verwenden 42% wiederum Scrum ohne Kombination mit anderen Vorgehensmodellen.
Zur SwissQ-Studie: Hier steht über die Grundgesamtheit nur, dass über 300 Personen aus der Schweizer IT Community teilgenommen haben. Zwischen Hardware und Software wird nicht unterschieden.
Grundsätzlich ist der Einsatz von agilen Methoden in der Hardware-Entwicklung schwieriger als in der Software, weil die Hardware an sich nicht so flexibel anpassbar ist. Es scheint aber dort gut zu klappen, wo Standard-Komponenten zu einem System zusammengesetzt werden und die Software-Steuerung agil entwickelt wird. Interessant ist sicher in der Entwicklung von Hardware und anderen physischen Produkten die Kombination von Scrum mit Rapid Prototyping-Herstellungsverfahren.
Genauso macht es natürlich auch einen Unterschied, ob das Team lokal zusammen sitzt oder über den Globus verteilt. Dann funktionieren bestimmte agilen Praktiken weniger gut bzw. müssen angepasst werden.
Viele Grüße,
Andrea Herrmann
Sehr interessanter Beitrag, vielen Dank dafür! Einiges in den ScrumAnd-Beschreibungen kommt ja aus XP. Dass insgesamt das mit dem Überblick über alle Methoden, Praktiken und Werkzeuge in der agilen Welt (und selbst die Eingrenzung dieser) keine leichte Aufgabe ist, sieht man ja derzeit auch an den Bemühungen durch das PMI und die Agile Alliance, mal ein bisschen Struktur reinzubringen.
“Gerüchten zufolge bezeichnen sich auch vollständig chaotische Gruppen gerne als Scrum-Teams” :D Der war sehr gut ;)
Noch eine Anmerkung zur Aufzählung – Refactoring soll das wahrscheinlich heißen? Ich habe zunächst einmal recherchiert, ob mir ein Begriff noch nicht bekannt war, aber Rectoring existiert, glaube ich, nicht wirklich ;)
Viele Grüße!
Guten Tag Frau Lehmann-Benz,
ja, ScrumAnds lassen sich gerne bei XP inspirieren, das in seiner Gesamtheit ja sehr streng ist. Aber auch nichtagile Praktiken schaffen es wieder ins Vorgehensmodell hinein, kommen sozusagen wieder in Mode.
Stimmt, Rectoring habe ich auch noch nie gehört. Gemeint ist natürlich Refactoring!
Viele Grüße,
Andrea Herrmann
Hallo Frau Dr. Herrmann,
Danke für Ihren Artilkel.
Auch umgekehrt sind in der klassischen Welt agile Methoden angekommen und haben Eingang in die PM-Weiterbildung gefunden. Siehe bspw.: https://www.gpm-ipma.de/zertifizierung/projektmanager/zusatzzertifikat_hybrid_gpm.html
Für meinen Teil begrüße ich es sehr, dass in beiden “Lagern” Dogmen abgebaut werden und Methoden/Praktiken quasi als Baukasten zur Auswahl angeboten werden: man nehme für die eigene Aufgabenstellung den passenden Mix.
Dies gelingt mit einiger PM-Erfahrung natürlich besser, bleibt jedenfalls nicht ohne Mühe, nicht zuletzt bedingt durch das organisatorische Umfeld.
Viele Grüße,
Holger Dietrich
Sutherland und Schwaber sagten mir , dass diese gemixten Vorgehensweisen kein SCRUM seien. Sie würden immer gerufen, wenn so ein Mix in die Hose gegangen sei. Dem kann ich nur zustimmen. Seit über 20 Jahren repariere auch ich derartige gescheiterte Vorgehensmodelle – oder nehme derartige Aufträge gar nicht erst an. wenn ich die Neukreation nur weiter verschlimmbessern statt auf Scrum rückführen soll. .
Guten Tag Herr Blass,
natürlich ist nur Scrum = Scrum, das Original. ScrumAnd ist aber auch richtiges Scrum, nur mit ein paar zusätzlichen Praktiken.
Wenn man sich ein eigenes Vorgehensmodell entwickelt, geht man natürlich ein Risiko ein. Dazu gehören dann regelmäßige Retrospektiven, ob der Prozess funktioniert, und die Praktik Inspect and Adapt.
Viele Grüße,
Andrea Herrmann