t2informatik » Wissen kompakt » ScrumBut

Was ist ScrumBut?

Wie entsteht ein ScrumBut, sind ScrumButs gut oder schlecht und welche Beispiele gibt es?

ScrumBut – Definition

Scrum definiert ein Set aus Rollen, Regeln und Ritualen zur Entwicklung von Software, Produkten oder Services. Dabei 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. ScrumBut bezeichnet den Verzicht auf Teile der ursprünglich festgelegten Rollen, Regeln und Rituale. Der Ausdruck geht auf „We use Scrum, but …“ zurück, auf Deutsch also „Wir nutzen Scrum, aber …“.

Die Intention von ScrumBut

Die Intention eines ScrumButs liegt in der Optimierung der Arbeit nach Scrum in einer und für eine konkrete Organisation. Der Verzicht auf Teile von Scrum kann sich auf Rollen, auf die Durchführung der typischen Aktivitäten wie Sprints, Sprint Planning, Daily Scrum, Sprint Review, Retrospektive oder Backlog Refinement, oder auf die Verwendung der Artefakte wie Backlogs und Inkremente beziehen. Die Bandbreite für mögliche ScrumButs ist sehr groß, sie reicht damit von der Interpretation der Rollen („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 nicht der 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.

Was ist Scrum?
\

Der Verzicht

Die Rollen, Aktivitäten und Artefakte von Scrum sind im Scrum Guide beschrieben. Der Verzicht auf einzelne Aspekte bei der Verwendung von Scrum wird als ScrumBut bezeichnet.

\

Individuelle Situationen

Die Abweichungen erfolgen durch die Anpassung an individuelle Gegebenheiten oder sollen Probleme lösen. Bspw. könnte ein Daily Scrum nur alle 2 Tage durchgeführt werden, da die Entwicklung in einem gemeinsamen Ort sitzt und sich die Teilnehmer daher permanent austauschen.

ScrumBut Syntax

ScrumBut erkennt man meist an einer typischen Syntax: ScrumBut, Grund, Workaround. Beispiel:

ScrumBut Syntax - Wissen kompakt - t2informatik

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.

Scrum Whitepaper - t2informatik Download Vorschau

Jetzt das Scrum Whitepaper kostenlos downloaden.

Alles Wichtige über Scrum, die zentralen Begriffe, Rollen, Events und Herausforderungen auf 29 Seiten zum Mitnehmen.

Hier klicken »

ScrumButs in der Praxis

Gründe für ScrumButs

Es gibt verschiedene Gründe für die Verwendung von ScrumButs. Manche Teams nutzen ScrumButs, um kurzfristig Probleme zu lösen. Oft stehen sie unter Zeitdruck und eine Modifizierung hilft scheinbar, ein Problem zu beseitigen. Um Zeit zu sparen, könnten bspw. einzelne Daily Scrums entfallen, da die Sorge besteht, ein Sprint-Ziel zu verpassen. Ein akutes Problem ließe sich so lösen, dauerhaft sollte dies aber nicht mit einer solchen Begründung zur Reduzierung von Daily Scrums führen. Ursächliche Probleme – bspw. die falsche Schätzung von Aufwänden – tauchen oft zu späteren Zeitpunkten wieder auf.

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).

Das agile Manifest

Scrum folgt den Werten, die im agilen Manifest festgehalten sind. Dieses 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? Sollte es Bestrafungen für verspätetes Erscheinen zum Daily Scrum geben? Entscheidend für Organisationen ist die bewusste Beantwortung solcher Fragen anhand konkreter Herausforderungen; das agile Manifest liefert hier lediglich Empfehlungen.

Gut oder schlecht?

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

Bei einer Anpassung von Scrum ist die bewusste Auseinandersetzung mit einer konkreten Herausforderung wichtig. Das setzt voraus, dass es sich bei der Anpassung nicht nur um eine kurzfristige Beseitigung eines Problems als Quick Fix handelt. Mit ScrumBut sollten Probleme gelöst und nicht verschleiert werden. Muss ein Product Owner bspw. mehrere Produkte betreuen und kann daher nicht an Meetings teilnehmen, wäre es keine gute Lösung, ihn nicht mehr zu den Meetings einzuladen; es wäre sinnvoller, seine Arbeitslast auf andere Mitarbeiter zu verteilen, so dass er seiner Verantwortung auch tatsächlich nachkommen kann.

ScrumBut und ScrumAnd

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 ScrumBut arbeiten. Bei ScrumBut 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.

ScrumBut Beispiele

ScrumButs bei Rollen

Es gibt ScrumButs, die beziehen sich auf die Rollen oder die Interpretation der Rollen. Hier finden Sie einige Beispiele. We use Scrum, but …

  • wir sind sehr effektiv, also arbeiten wir ohne 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 die Selbstorganisation 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 Aktivitäten

Es gibt ScrumButs, die beziehen sich auf die Aktivitäten, 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 Rollen, 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.

 

Wollen Sie mehr über Scrum erfahren?

Dann erfahren Sie hier mehr über Sprint Planning, Tipps und Tricks zum Sprint Review, die verschiedenen Methoden einer Retrospektive oder den idealen Ablauf von Scrum of Scrums.

Herausforderungen für Unternehmen

Der bewusste Umgang mit ScrumButs

Die Entwicklung von Software, Produkten und Services mit Scrum ist nicht immer so leicht, wie es vielleicht auf den ersten Blick klingen mag. Für Unternehmen kann es daher sinnvoll sein, das Vorgehen auf die konkreten Herausforderungen und Möglichkeiten anzupassen. Niemand erhält ein Sternchen im Notenheft, wenn eine Entwicklung 100% nach Scrum durchgeführt wird. 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 Rollen, Regeln und Rituale. Erst in der Folge kann eine Anpassung – ein ScrumBut – seine 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 Meetings teilnehmen, sollte nicht die Verbesserung der Dokumentation von Anforderungen im Vordergrund stehen, sondern die Entlastung des Product Owners. Die fehlende Kommunikation ist der Schwachpunkt, da hilft ein ScrumBut vermutlich wenig. Es empfhielt 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.

Sie wollen die Abläufe in Ihren Projekten durch ein einheitliches Vorgehen verbessern? Sie wollen den Projektablauf nachvollziehbar machen und Mehrwerte für Ihre Kunden schaffen? Gerne bieten wir Ihnen Wissen zu Prozessen in Verbindung mit langjähriger Erfahrung. Wir unterstützen Sie beim Arbeiten mit Scrum, coachen Ihre Mitarbeiter, etablieren ein sinnvolles Backlogmanagement und helfen Ihnen bei der Software- und System-Modellierung.

Hier erfahren Sie mehr zum Thema Prozesse und Methoden  »

Weitere Details und Hintergründe ...
Share This