ScrumBut, ScrumAnd und Water-Scrum-Fall

von | 04.09.2017 | Requirements Engineering

Über Extreme Programming (XP) schrieb Kent Beck [1], 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-Teams [2] 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 Guide [3] 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 Team [4].

„Scrum pur“, wie es im Scrum Guide 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