Scrumbut

Inhaltsverzeichnis: Definition – Intention – Syntax – Gründe – Arten und Beispiele – Der bewusste Umgang – Download – Hinweise

Wissen kompakt: Der Verzicht auf einzelne Scrum Elemente wird als ScrumBut bezeichnet. Die Bezeichnung geht auf “We use Scrum, but …” zurück.

Scrumbut Definition

Der Verzicht auf einzelne Elemente in Scrum (Events, Verantwortlichkeiten oder Artefakte), und damit die Abweichung vom Standard wie dieser im Scrum Guide beschrieben ist, wird als Scrumbut bezeichnet. Der Ausdruck geht auf “We use Scrum, but …” zurück, auf Deutsch also “Wir nutzen Scrum, aber …”.

Grundsätzlich sieht Scrum vor, dass im Zuge einer Retrospektive der Prozess der Entwicklung an die Organisation oder die Situation, in der sich die Organisation befindet, angepasst werden kann. Aus diesem Grund gehen auch die Meinungen auseinander, ob ein Scrumbut in jedem Fall schlecht ist oder eher als sinnvoll erachtet werden sollte.

Die Intention von Scrumbuts

Die Intention eines Scrumbuts liegt meist in der Optimierung bzw. Adaption der Arbeit nach Scrum in einer und für eine konkrete Organisation. Der Verzicht auf Teile von Scrum kann sich auf

Verantwortlichkeiten und die 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 der Artefakte (Product Backlog, Sprint Backlog und Inkremente) oder
die Nutzung von Commitments (Product Goal, Sprint Goal oder Definition of Done)

beziehen.

Die Bandbreite für mögliche Scrumbuts ist sehr groß, sie reicht damit von der Interpretation der Veranwortlichkeiten („Für uns ist der Product Owner nicht so wichtig.“) über die Dauer und Frequenz einzelner Events („Wir führen einmal zu Beginn des Projekts ein Sprint Planning durch.“) bis hin zu den Artefakten („Anstelle von Product oder Sprint Backlogs verwenden wir unsere internen Projektdokumente.“).

In der Praxis kommt es auch zu Scrumbuts, die keiner positiven Intention entsprechen. Die Durchführung von Workshops zur Ermittlung von Anforderungen wird in Scrum nicht definiert, auch wenn solche Workshops sinnvoll sein können. Etwas nicht zu tun, obwohl es positiv für die Entwicklung einer Lösung wäre, ist nicht im Sinne von Scrum, so dass auch hier von einem Scrumbut gesprochen werden kann.

Scrumbut Syntax

Scrumbut erkennt man meist an einer typischen Syntax:

Scrumbut,
Grund,
Workaround.

Beispiel:

ScrumBut Syntax - Wir nutzen Scrum, aber ...

In manchen Publikationen werden alternative Beispiele verwendet: “Wir sprinten 6 bis 12 Wochen, denn so vermeiden wir Probleme”. Auch dies ist ein Scrumbut, also eine Abweichung der empfohlenen Sprintlänge von einer bis vier Wochen. Der Satz könnte auch “Wir nutzen Scrum, aber oft tun wir uns mit Aufwandsschätzungen schwer, also verwenden wir Sprints mit einer Dauer von 12 Wochen” lauten.

Gründe für Scrumbuts

Es gibt verschiedene Gründe für die Verwendung von Scrumbuts. Manche Teams nutzen sie, um kurzfristig Probleme zu lösen. Oft stehen sie unter Zeitdruck und eine Modifizierung hilft scheinbar, ein Problem zu beseitigen. Der 2017 State of Scrum Report der Scrum Alliance stellt fest, dass 86 % der Teams ein Daily Scrum durchführen, 11 % führen es mehrmals pro Woche aber nicht täglich, 2 % nach Bedarf und 1 % überhaupt nicht durch. Dieses Beispiel zeigt, dass 14 % mit Scrumbuts arbeiten. Bei Scrumbuts werden je nach individueller Situation eine oder mehrere Praktiken weggelassen oder adaptiert. Scrumand hingegen ergänzt Scrum um die eine oder andere Praktik, also “We use Scrum and …”.

Scrumands lassen sich relativ häufig in Organisationen finden. Der Scrum Guide sagt bspw. nichts von User Storys, Epics oder Taskboards, obwohl diese Elemente in der agilen Welt weit verbreitet sind. Die Verwendung dieser Aspekte verursacht zwar etwas Aufwand, aber sie gelten allgemein als sehr nützlich und werden durchweg positiv beurteilt. Scrumbuts hingegen können gefährlich sein, weil hier etablierte Praktiken bewusst oder unbewusst weggelassen werden. Es empfiehlt sich daher, Scrumbuts vorsichtig zu entwickeln, konkrete Erfahrungen – wie bei der Verwendung von Scrum – zu sammeln und gegebenenfalls weitere Anpassungen vorzunehmen.

Ein häufig genannter Grund zur Anpassung der Vorgehensweise ist das Umfeld einer Organisation: in manchen Branchen gelten besondere Nachweispflichten, in anderen ist das Arbeiten mit Lasten- und Pflichtenheften etabliert, in weiteren werden umfangreiche Vertragswerke ausgehandelt. Dennoch lässt sich Scrum – mit einigen Anpassungen als Scrumbut oder Scrumand – sinnvoll anwenden. Es gibt auch Ansätze, Transitionen von Unternehmen hin zu Scrum als Scrumbut zu verstehen, denn die Rollen, Aktivitäten und Artefakte sind zu Beginn der Einführung noch nicht etabliert, so dass sie noch nicht wie im Scrum Guide beschrieben zum Einsatz kommen (können).

Arten und Beispiele von Scrumbuts

Es gibt verschiedene Arten von Scrumbuts. Sie existieren bei

Rollen,
Events und
Artefakten, sowie entstehen
aus Unwissenheit.

Scrumbuts bei Rollen

Es gibt Scrumbuts, die beziehen sich auf Rollen bzw. Verantwortlichkeiten. Hier finden Sie einige Beispiele. We use Scrum, but …

wir sind sehr effektiv, arbeiten selbst-organisiert und benötigen keinen Scrum Master.
unsere Stakeholder sind zu beschäftigt um an den Sprint Reviews teilzunehmen, also laden wir sie gar nicht mehr ein.
wir entwickeln verschiedene Produkte parallel, also haben wir eine separate Abteilung mit Testern.
wir sind eine kleine Firma, also besteht unsere Entwicklung aus einem Mitarbeiter.
immer auf die Entwickler aufzupassen ist auf Dauer langweilig, also übernimmt jeder einmal die Rolle des Scrum Masters.
bei uns klappt das Selbstmanagement nicht richtig, also weist der Product Owner den Entwicklern User Storys zu.
der Product Owner hat nicht viel Zeit, also formuliert er die Anforderungen so detailliert, dass er nicht am Sprint Planning teilnehmen muss.
wir haben so viele Entwicklungsaufgaben, also entwickelt auch unser Scrum Master als Teil des Teams Software.
unser Scrum Master hat schon in vielen Firmen gearbeitet, so dass er mit seiner Erfahrungen klare Anweisungen geben kann.
unsere Projektmanager sind sehr gut, also unterstützen sie unsere Scrum Master beim Managen der jeweiligen Teams.

Scrumbuts bei Events

Es gibt Scrumbuts, die beziehen sich auf die Events, auf die Dauer, die Frequenz und die Art der Durchführung. We use Scrum, but …

Retrospektiven sind nicht effektiv, also machen wir nur eine zum Ende des Releases.
wir arbeiten mit einem Wasserfall im Sprint, also testen wir alle realisierten User Storys sicherheitshalber erst am Ende des Sprints.
bei uns dauert das Sprint Planning zu lange, also macht der Product Owner die Ansagen, wer was wie entwickeln soll.
bei uns kommunizieren die Entwickler permanent miteinander, also machen wir das Daily Scrum nur einmal pro Woche.
meist haben wir unser Sprint-Ziel in der Kürze der Sprints nicht erreicht, also verzichten wir nun auf eine Definition der Sprintlängen und arbeiten so lange, bis wir alle User Storys realisiert haben.
wir tun uns mit der Aufwandsschätzung und technischen Zusammenhängen schwer, also dauern unsere Sprints sicherheitshalber 12 Wochen.
bei uns machen zwei Sessions im Sprint Planning wenig Sinn, also machen wir eine gemeinsame Planung in der Hälfte der Zeit.
wir glauben bei den vielen Meetings nicht an Timeboxing, also lassen wir es mit Ausnahme der Sprints einfach weg.
wenn wir immer nur für das nächste Release oder den nächsten Sprint planen verlieren wir den Überblick, also planen wir immer für drei Releases im Voraus.

Scrumbuts bei Artefakten

Es gibt Scrumbuts, die beziehen sich auf die Artefakte. Hier finden Sie einige Beispiele. We use Scrum, but …

unser Auftraggeber möchte gerne ein Lastenheft von uns sehen, also erstellen wir zu jedem Sprint für ihn eins.
wir wollen eine klare Verantwortung zwischen Entwicklung und Testing, also teilen wir die User Storys entsprechend in Entwicklungs- oder Test-Storys auf.
die Aufwandsschätzung ist uns zu ungenau, also schätzen wir zusätzlich pro User Story die Aufwände für die Entwicklung von Backend, Frontend, Integration und Testing.
wir haben gute Erfahrung mit dem horizontalen Verfeinern von User Storys gemacht, also verzichten wir auf das vertikale Verfeinern auch wenn wir am Ende des Sprints kein Inkrement liefern können.
da wir lediglich unsere Releases unseren Kunden zur Verfügung stellen, produzieren wir das Lieferergebnis nur auf Zuruf oder einmalig zum Releasetermin.
da alle Mitarbeiter in verschiedenen Projekten aktiv sind und der Zeitdruck hoch ist, verzichten wir manchmal auf die Einhaltung der Definition of Done.
wir brauchen kein separates Sprint Backlog, also nutzen wir einfach die Informationen, die im Product Backlog stehen.
da unser Product Backlog so groß ist, verwalten wir zusätzlich Backlogs für Epics, Features und Kundenwünsche.
unsere höchste Priorität ist die Einhaltung unseres initialen Releaseplans, also machen wir häufig Überstunden um diesen einzuhalten.

Scrumbuts durch Unwissenheit

Scrumbuts können durchaus eine Berechtigung haben – sofern sie bewusst als Abweichung von Scrum verstanden, eingeführt, überprüft und gegebenenfalls adaptiert werden. Scrumbuts, die auf Unwissenheit zurückgehen, sorgen aber in den seltensten Fällen für positive Effekte. Sie beruhen häufig auf unbewiesenen Annahmen, auf Vorurteilen oder Meinungen einzelner Mitarbeiter. Hier finden Sie mögliche Beispiele für Scrumbuts durch Unwissenheit:

Das Management hat gehört, dass “agil” so einfach und gut ist, also machen wir nun größtenteils Scrum.
Scrum besteht nur aus wenigen Verantwortlichkeiten, Aktivitäten und Artefakten, da ist doch kein Training notwendig.
Wir haben 15 Entwickler, die wollen wir nicht in zwei ungleich große Teams aufteilen, also arbeiten wir einfach wie gehabt mit einem gemeinsamen Team.
Wir machen 100% Scrum, also alle Aspekte, die nicht im Scrum Guide beschrieben werden, lassen wir einfach weg.
Warum sollten wir Mitarbeiter ausbilden oder gar zertifizieren?
Scrum steht für Offenheit und Feedback, also dokumentieren wir dies auch öffentlich.
Wir nehmen jetzt einfach mal die besten Elemente aus Scrum heraus und wenn es nicht klappt, dann lassen wir es wieder sein.
Vertrauen ist ja schön und gut, aber mit klaren Ansagen erreichen wir unsere Ziele schneller.
Warum sollten wir miteinander über unsere Erfahrungen sprechen – jeder Mitarbeiter macht doch dieselben.

Die Anpassung von Scrum und der bewusste Umgang mit Scrumbuts

Scrum folgt den Werten, die im Scrum Guide und auch im agilen Manifest festgehalten sind. Das agile Manifest sagt unter anderem, dass funktionierende Software wichtiger sei als eine umfassende Dokumentation. Das bedeutet nicht, dass Dokumentation unwichtig ist, sie ist im Verhältnis zu einer funktionierenden Software nur weniger wichtig. Nun gibt es Organisationen, die für jeden Sprint eine Spezifikation erstellen, die sich aus Items des Sprint Backlogs und Tasks ergeben, die das Team definiert. Scrum sieht ein solches Spezifikationsdokument nicht vor, dennoch können solche Anpassungen für Organisationen sinnvoll sein. Ken Schwaber, einer der Verfasser des agilen Manifests, hat daher schon frühzeitig erkannt, dass die Abweichung von den definierten Prinzipien legitim ist.

Etwas weiter gedacht kann es sogar für Organisationen notwendig sein, von den definierten Ansätzen abzuweichen. Muss eine Retrospektive nach jedem Sprint stattfinden oder reicht es auch zum Ende eines Releases? Darf eine Timebox auch 20 anstatt nur 15 Minuten dauern? Entscheidend für Organisationen ist die bewusste Beantwortung solcher Fragen anhand konkreter Herausforderungen; das agile Manifest und auch der Scrum Guide liefern hier lediglich Empfehlungen.

In manchen Diskussionen entsteht der Eindruck, die Anpassung von Scrum sei eine schlechte Idee – dem ist nicht so. Die Anpassung eines allgemeinen Frameworks auf individuelle Situationen ist sogar zwingend notwendig. Auch wenn die 17 Autoren des agilen Manifests und die beiden Autoren des Scrum Guides viel Erfahrung bei der Entwicklung von Produkten und der Zusammenarbeit in Teams besitzen, sie kennen nicht alle individuellen Situationen und Herausforderungen eines Unternehmens.

Wenn sich Organisationen mit der Anpassung von Scrum beschäftigen, sollten sie ein tieferes Verständnis von Scrum erlangt haben. Ein solches Verständnis entwickelt sich über die Zeit und durch die Einhaltung und Anwendung der definierten Verantwortlichkeiten und Regeln. Erst in der Folge kann eine Anpassung die gewünschte Wirkung erzielen. Eine Anpassung, die lediglich ein Problem verschleiert und nicht löst, ist nicht sinnvoll. Steht ein Product Owner bspw. nicht regelmäßig zur Verfügung und kann daher nicht an den notwendigen Events teilnehmen, sollte nicht die Verbesserung der Dokumentation von Anforderungen im Vordergrund stehen, sondern die Entlastung des Product Owners. Es empfiehlt sich daher – ähnlich wie bei Scrum an sich – Scrumbuts immer wieder zu hinterfragen und anzupassen, denn so kann die Anpassung die bestmögliche Wirkung entfalten.