Warum solltest du Scrum machen?

Gründe Scrum
Von Sebastian Schneider // 05.01.2022 // 0 Kommentare

Viele machen Scrum. Viele versuchen Scrum. Doch warum solltest du Scrum machen? Ist Scrum ein Silver Bullet? Wohl nicht, also ist auch die Frage nach dem Warum eine gute Frage! Ich zeige dir Einblicke aus meiner Erfahrung, wann ich zu Scrum tendiere und wann nicht. Auch wenn es - wie so oft - nicht die 100% gibt, existieren doch gewisse Muster, die dir helfen deine Wahl zu treffen, ob Scrum für dich richtig ist! Hier der komplette Guide für dich!

Wann ist Scrum sinnvoll?

Mir persönlich gefallen die Fragen nach dem Warum schon sehr. Warum? Weil sie mich selbst oft zum Nachdenken anregen und ich Dingen und Perspektiven Aufmerksamkeit schenke, die mir zuvor oft verborgen geblieben sind. Deshalb möchte ich hier auch noch einmal in die Reflexion gehen, warum du Scrum machen solltest.

Sehr nah bei dem Warum Scrum liegt für mich auch die Frage nach dem Wann Scrum - nicht zeitlich gesehen - sondern situativ. Wenn du die ein oder andere Situation bei dir vorfindest, die ich hier nenne, dann gehe doch auch mal tiefer in die Diskussion und die Analyse bei dir.

Für mich ist die Frage nach dem "warum du Scrum machen solltest" und "wann du Scrum machen solltest" nicht ganz trennscharf. Ich vermische die beiden Bereiche hier etwas, die du aber so oder so für deine Reflexion direkt anwenden kannst.

Starten wir hier direkt mal in die Themen rein.

Das Umfeld für Scrum

Einer der am häufigsten genannten Punkte ist mit Sicherheit das sogenannte komplexe Umfeld. Findest du ein solch komplexes Umfeld vor, dann kann dir Scrum helfen. Doch was genau ist das komplexe Umfeld? Schau da mal in das Stacey Landscape Diagram, dort habe ich es genauer beschrieben. Doch warum Scrum im komplexen Umfeld? Weil Scrum durch seine Eigenschaften auf dieses Umfeld besonders gut reagieren kann.

Wann kann Scrum hier sinnvoll sein?

Lohnt sich...
  • ...wenn das Umfeld komplex ist
  • ...wenn du häufigen Änderungen ausgesetzt bist
  • ... wenn ein Ziel nicht klar definierbar ist
  • ... wenn du mit Visionen arbeitest, um dich einer Lösung zu nähern
Lohnt sich weniger...
  • ... wenn das Umfeld einfach ist
  • ... wenn das Umfeld kompliziert ist
  • ... wenn das Ziel / Ergebnis schon sehr klar zu Beginn vorausgesagt werden kann

Wechselnde Anforderungen

Anforderungen sind in der komplexen VUCA Welt nicht statisch. Auch das agile Manifest stellt heraus, dass wir mit wechselnden / späten Änderungen in den Anforderungen umgehen und die sogar zum Vorteil des Kunden verwenden wollen. Wenn du so etwas vorfindest, dann hast du mit dem agilen, inkrementellen und interativen Vorgehen einen möglichen Vorteil. Die wechselnden Anforderungen und der vorherige Punkt mit dem Umfeld werden oft zusammen genannt.

Warum Scrum hier helfen kann

Besser wenn...
  • ... die Anforderungen eher auf der WAS Ebene als der WIE Ebene vorhanden sind
  • ... Spielraum in den Anforderungen existiert
  • ... wenn ein Backlog existiert, welches noch nicht final den Umfang fixiert
Weniger gut wenn...
  • ... eine 100% Spezifikation existiert
  • ... du keine regelmäßige Reflexion über den Inhalt deiner Anforderungen hast

Probleme ans Tageslicht bringen

Scrum schafft es, Probleme über deinen Prozess schnell ans Tageslicht zu bringen. Benötigst du also eine Technik, um auf Probleme im Prozess zu fokussieren, dann kann ein Blick auf Scrum wertvoll sein.

Wann kann Scrum hier sinnvoll sein?

Lohnt sich
  • ... wenn du Probleme schnell erkennen möchtest
  • ... wenn du kontinuierlich Verbesserungen anstrebst
  • ... wenn du mit Teams in den Flow kommen möchtest
  • ... wenn dir KVP / CIP ein Begriff ist
Lohnt sich weniger...
  • ... wenn du Probleme in deinem Prozess eh nicht lösen willst
  • ... wenn du dich mit deinem Prozess nur wenig befassen möchtest
  • ... wenn der Erfolg des Teams für dich nicht oberste Priorität hat
  • ... wenn du Verbesserungsevents (wie Retrospektive) nicht machen willst

Durchführung von Experimenten

Möchtest du Experimente für dein Produkt oder auch den Prozess durchführen, um zum Beispiel zu erkennen, welche Lösung für einen Kunden besser geeignet ist, dann kann dir Scrum aufgrund der kurzen Zyklen (Sprints) und Möglichkeiten der Kundeninteraktion helfen. Ebenso kannst du auch Experimente für deinen eigenen Prozess und deine Arbeitsweise kontinuierlich durchführen. Die Durchführung von Experimenten und auch die "Probleme ans Tageslicht bringen" liegen eng bei einander

Wie unterstützt dich Scrum dabei?

Lohnt sich...
  • ... wenn du nicht genau weißt, ob ein Experiment Erfolg hat
  • ... wenn du lernen möchtest (sei es Prozess oder Produkt)
  • ... bei häufigen und regelmäßigen Überprüfen der Experimente
Lohnt sich weniger...
  • ... bei sehr klaren Aufgaben
  • ... bei wenig Lernmöglichkeiten

Reaktionsfähigkeit

Wenn du klein, schlank und wendig bist - dann hast du auch die Chance schnell zu reagieren. Diese Reaktionsfähigkeit hängt natürlich nicht alleine an Scrum, aber Scrum selbst kann dir hier durch den Aufbau und die Eigenschaften helfen.

Wann kann Scrum hier sinnvoll sein?

Lohnt sich...
  • ... bei einem nicht immer klaren Weg für deine Aufgaben
  • ... wenn du schnell Richtungswechsel vornehmen können möchtest
Lohnt sich weniger...
  • ... bei einem statischen Rahmen
  • ... bei sehr einfachen und klaren Aufgaben oder Wegen

Kundenkontakt

Scrum funktioniert dann sehr gut, wenn du deinen Kunden zum einen kennst und auch mit ihm sprechen kannst. Er oder sie nutzt dein Produkt und was liegt zum Beispiel näher ihn zu fragen, ob er dein Produkt mag? Findet er das Feature A wichtiger oder B? Was genau hilft ihm oder ihr, um ein Problem zu lösen? So etwas bekommt man meistens sehr gut im Dialog heraus.

Warum kann Scrum hier helfen?

Besser wenn...
  • ... das Scrum Team direkter Kontakt zum Kunden hat
  • ... der Kunde direkt in den Ablauf der Entwicklung eingebunden ist
  • ... wenn Entwicklung und Fachbereich zusammen arbeiten
  • ... wenn der Kunde direkt Leistungen entgegen nimmt und Rückmeldung gibt
Weniger gut wenn...
  • ... der Kunde für das Scrum Team nicht erreichbar ist
  • ... der Kunde nicht mit Scrum Team sprechen darf
  • ... der eigebundene Kunde das Produkt selbst nicht nutzt

Ein Team mit einem Ziel

Es wird gerne vergessen und immer wieder falsch gemacht: Scrum funktioniert nicht ohne ein Team, welches hinsichtlich eines Zieles zusammenarbeitet. Du benötigst für die Menschen in deinem Team dieses gemeinsames Ziel, an dem alle arbeiten und welches auch verstanden ist.

Deshalb hier Scrum machen

Besser wenn...
  • ... das Team in Vollzeit zusammen arbeitet
  • ... wenn das Team mit dem Ziel autonom arbeiten kann
  • ... wenn wenig Schnittstellen existieren bzw. klar abgegrenzt sind
Weniger gut wenn...
  • ... das Team nur teilweise zusammen kommt, um ein Ziel zu verfolgen
  • ... das Team kein gemeinsames Ziel verfolgt
  • ... wenn das Team nicht die Eigenschaften und Skills mitbringt, die für das Ziel notwendig sind

Änderungskosten niedrig und Änderungsfrequenz hoch

Wenn du schnell Änderungen zu geringen Kosten durchführen kannst und eben dann hohe Änderungen hast, lohnt sich ein Blick auf Scrum. Je höher deine Änderungskosten sind, desto mehr Rahmenbedingung musst du für dein Scrum berücksichtigen!

Darum hilft dir Scrum hier

Besser wenn...
  • ... dich Änderungen wenig Aufwand kosten
  • ... wenn du klare Vorstellung über die Möglichkeit der Bewältigung bei höheren Änderungskosten hast
  • ... Änderungen häufig stattfinden und günstig sind
Weniger gut wenn...
  • Kunde ist für Scrum Team nicht erreichbar
  • Kunde darf nicht mit Scrum Team sprechen

Hinweis: Nur weil die Änderungskosten bei einem Haus oder Autobau und auch in Bereichen von anderen physikalischen Bereichen oder der Medizintechnik hoch sein können, bedeutet das nicht, dass du Scrum nicht nutzen kannst. Wichtig ist nur zu verstehen, das manche Änderungen eben sehr teuer sind, andere deutlich geringer. Wenn Änderungen bei dir teurer sind, dann solltest du hierfür gute Überlegungen / Vorgehen haben und dir diese Gedanken vor dem Start durchspielen.

Agile Architektur

Um Scrum erfolgreich durchzuführen benötigt es immer eine gewisse Grundstruktur von dem, was du entwickelst. Und diese Struktur muss eine gewisse Flexibilität mit sich bringen. Nehmen wir die gängige Architektur eines Auto, dann ist diese komplett andere, als mit dem Wikispeed Projekt verfolgt wird.

Auch hier: Es geht nicht um besser oder schlechter, richtig oder falsch! Es geht darum, sinnvolle Rahmenbedingung in der Architektur zu haben, auf oder mit der entwickelt wird. Eine Architektur kann immer so sein, dass sie zu einer agilen Entwicklung passt oder eben nicht. Passt sie nicht, dann wirst du mit Scrum auch deine Probleme bekommen, da zum Beispiel die Änderungskosten dann sehr hoch sein können.

Darum hilft dir Scrum hier

Besser wenn...
  • ... die Architektur eine agile Entwicklung unterstützt
  • ... wenn möglichst lose Komponenten entwickelt werden können
  • ... wenn eine Architektur Freiraum und Wahlmöglichkeiten ermöglicht
Weniger gut wenn...
  • ... du eine starre Architektur hast, die eine langsame Entwicklung indirekt erzwingt
  • ... wenig Wahlmöglichkeiten und Flexibilität auf der Architektur möglich sind 

Hohe Testautomatisierung möglich

Mit einer hohen Testautomatisierung hast du eine gute Grundlage, Änderungen innerhalb von einem Sprint schnell zu überprüfen. Es bringt dir absolut gar nichts, wenn du zwar schnell in der Entwicklung bist, dann aber nicht in der Lage bist, deine Entwicklung auch zu prüfen. Wann immer du also in der Lage bist, eine hohe Testautomatisierung an den Start zu bekommen, kann Scrum auch sinnvoll sein.

Darum hilft dir Scrum hier

Besser wenn...
  • ... du jede Änderung möglichst schnell testen kannst
  • ... wenn du jede Änderung automatisiert testen kannst
  • ... wenn du ca. 80% Testautomatisierung erreichst
Weniger gut wenn...
  • ... Tests nur in einem "Bulk" stattfinden können
  • ... Tests manuell ausgeführt werden 
  • ... wenn du nicht in der Lage bist eine DoD mit Tests zu erzeugen

Sichtbarkeit von Arbeit

Scrum macht Arbeit sichtbar. Durch verschiedene Mechanismen ist die Arbeit sichtbar, an der gearbeitet wird. Das ist nicht nur für uns Menschen besser zu verstehen (ein Bild sagt mehr als 1000 Worte) sondern hilft uns auch zu verstehen, welche Arbeit wirklich im System ist.

Darum hilft dir Scrum hier

Besser wenn...
  • ... Menschen bereit sind ihre Arbeit zu visualisieren
  • ... wenn du Möglichkeiten hast, deine Arbeit in deinem Kontext auch visualisieren zu können (remote wie digital)
  • ... wenn Visualisierung kein Selbstzweck ist
Weniger gut wenn...
  • ... Menschen Transparenz als Kontrolle ansehen
  • ... Mitarbeiter Arbeit einfach nicht sichtbar machen wollen 

Diese Liste ist nicht abschließend. Hast du weitere Gründe? Dann schreib mir doch gerne einen Kommentar dazu! Ich werde diese Liste von Zeit zu Zeit überarbeiten, besuche die Seite deswegen gerne immer mal wieder.

Was ich über die Jahre gelernt habe

Persönlich finde ich die Frage nach dem Warum immer noch sehr wichtig. Ich stelle sie mir und Kunden auch gerne. Ja, ich gehe sogar meine eigene Liste von von oben ("wann Scrum") des öfteren durch, reflektiere und erweitere diese Liste auch.

Ich weiß nur auch: Ich kenne nicht alle Perspektiven und Ansichten da draußen. Und da hilft es nur, mit ausreichend Erfahrungen und einem guten Rahmen in die Diskussion zu gehen. Früher war mir das alles immer zu ungenau. Ich wollte Checklisten, ich wollte klare Ansagen, wann nutze ich Scrum? Warum sollte ich Scrum anwenden?

Ich würde lügen, wenn ich das heute nicht auch wollen würde. Das ist eine Perspektive und das ist in meinen Augen auch menschlich. Ich habe eine eher abstraktere Checkliste in Form von Skalen erarbeitet. Diese darfst du dir gerne herunterladen.

Lade dir die Checkliste für deine TOP Scrum Gründe herunter

10 Gründe Scrum

Als kleinen Leckerbissen habe ich noch eine Checkliste für dich. Dort kannst du dich anhand der hier aufgelisteten Gründe mit einer Skala durcharbeiten und dich und deine Gründe visuell darstellen. Probiere es doch einfach mal aus!

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>