Scrumand

Wissen kompakt: Die Erweiterung des Scrum Frameworks um Elemente oder Methoden wird als Scrumand bezeichnet. Die Bezeichnung geht auf “We use Scrum and …” zurück.

Scrumand – wenn Organisationen das Scrum Framework erweitern

Der Scrum Guide definiert die “Spielregeln” von Scrum und benennt drei Verantwortlichkeiten, fünf Events und drei Artefakte. Die Verwendung von Elementen, die nicht im Scrum Guide beschrieben sind und das Framework oder dessen Anwendung erweitern, wird als Scrumand bezeichnet.

Der Begriff ist abgeleitet von “We use Scrum and …” – zu Deutsch “Wir verwenden Scrum und …” – und lehnt sich an die Formulierung “We use Scrum, but…” an, die den Verzicht auf einzelne Elemente – ein sogenanntes Scrumbut – anzeigt. Scrumand und Scrumbut sind quasi “Geschwister” im Geiste.

Die Intention eines Scrumands liegt meist in der Anpassung des Frameworks an den Kontext einer Organisation und entspricht damit dem Verständnis der beiden Scrum-Autoren¹.

Arten und Beispiele von Scrumands

Die Bandbreite möglicher Scrumands ist sehr groß, denn Erweiterungen können sich z.B. auf

  • die Verantwortlichkeiten und Aufgaben des Product Owners, des Scrum Masters und der Entwickler,
  • die Durchführung von Events (Sprints, Sprint Planning, Daily Scrum, Sprint Review oder Retrospektive),
  • die Verwendung von Artefakten (Product Backlog, Sprint Backlog und Inkremente) oder
  • die Verwendung von Commitments (Product Goal, Sprint Goal oder Definition of Done)

beziehen. Hier einige Beispiele:

  • Anstelle eines Product Owners wird in einem Projekt mit einem Product Owner Team oder einem Proxy Product Owner gearbeitet.
  • Zusätzlich zum Daily Scrum findet ein Weekly Standup Meeting zur weiteren Synchronisation der Teammitglieder oder zum Review von Zwischenständen statt.
  • Neben den Artefakten werden Lastenhefte und Pflichtenhefte, Lessons Learned Vorlagen und Protokolle genutzt.
  • Zusätzlich zu den Commitments werden eine Definition of Ready und individuelle Zielvereinbarungen verwendet.

Die Liste lässt sich leicht verlängern, insbesondere wenn man alle Hilfsmittel, die nicht explizit im Scrum Guide erwähnt sind, aber in der Unternehmensrealität eingesetzt werden, als Scrumand klassifiziert: User Storys, Akzeptanzkriterien, Velocity, Story Points sind solche Hilfsmittel.

Und zu guter Letzt können Scrumands auch aus der Kombination einiger Nicht-Scrum Praktiken mit dem Scrum Framework entstehen: “Wir machen Scrum und OKR”, “Scrum und DevOps”, “Scrum und Design Thinking” oder “Scrum mit Kanban” aka Scrumban.

Sind Scrumands gut oder schlecht?

Manche Diskussionen erwecken den Eindruck, dass es eine schlechte Idee ist, Scrum zu adaptieren. Niemand bekommt ein Sternchen im Zeugnis, wenn eine Entwicklung zu 100 % nach Scrum durchgeführt wird. Scrum ist ein Framework und liefert “nur” einen Rahmen mit Hilfsmitteln und Beschreibungen, die bei der iterativen Entwicklung von komplexen Produkten und Services hilfreich sein können. Wer also Scrum anpassen will, kann und soll dies tun. Idealerweise sollten die Anwender dabei aber wissen, was sie tun – ein Scrummerfall ist z.B. selten zielführend – und sie sollten die Erweiterungen im Laufe der Zeit auf ihre Sinnhaftigkeit überprüfen.

Sind Scrumlands also gut oder schlecht? Auf diese Frage gibt es keine allgemeingültige Antwort.

Scrumand - wenn Organisationen das Scrum Framework erweitern

Was macht t2informatik?

Was macht t2informatik? Kleiner Tipp: Es hat etwas mit Softwareentwicklung zu tun!

Impuls zum Diskutieren:

Wie wahrscheinlich ist es, dass Organisationen Scrum zu 100 % so umsetzen, wie es im Scrum Guide beschrieben ist?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Ken Schwaber und Jeff Sutherland sind die Urheber von Scrum. Sie verstehen den Scrum Guide nicht als Anleitung zur Umsetzung von Scrum, sondern lediglich als eine Beschreibung des Frameworks. Innerhalb des Frameworks können verschiedene Methoden, Prozesse oder Techniken zum Einsatz kommen. Jedes beschriebene Element im Guide dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist. Die kontextabhängige Erweiterung des Frameworks ist also naheliegend und grundsätzlich nachvollziehbar.

Hier finden Sie einen schönen Appell, der erläutert, wie Organisationen von einem Scrumbut-Gedanken zu einem Scrumand-Ansatz kommen können.

Hier finden Sie ein kostenloses Scrum Whitepaper mit allem Wichtigen über das Framework auf einen Blick.

Und hier finden Sie ergänzende Informationen aus dem t2informatik Blog:

t2informatik Blog: Agilität? Haben wir probiert! Funktioniert nicht! – Teil 1

Agilität? Haben wir probiert! Funktioniert nicht! – Teil 1

t2informatik Blog: Proxy Product Owner - ein Scrum Antipattern?

Proxy Product Owner – ein Scrum Antipattern?