Scrum ist das meistgenutzte und das am häufigsten missverstandene Rahmenwerk in der Softwareentwicklung. Die Mehrheit der Teams, die von sich sagt, Scrum zu machen, betreibt etwas anderes: ein Vorgehen mit zweiwöchigen Abschnitten, täglichen Statusrunden und einem Aufgabenbrett — ohne die Mechanismen, aus denen der Nutzen entsteht.
Das ist kein moralisches Problem. Es ist ein praktisches: Diese Teams tragen die Kosten des Rahmenwerks, ohne seinen Ertrag zu erhalten, und schliessen daraus verständlicherweise, dass Scrum nicht funktioniert.
Der Kern ist nicht der Sprint
Was Scrum wirksam macht, ist nicht der Sprint als Zeitabschnitt, sondern das, was am Ende jedes Sprints entstehen soll: ein potenziell auslieferbares Ergebnis. Diese Anforderung erzwingt eine Reihe von Dingen — dass Aufgaben klein genug geschnitten sind, dass Qualität nicht auf später verschoben wird, dass ein Ergebnis vorführbar ist.
Fällt diese Anforderung weg, bleibt vom Sprint ein Kalenderraster. Ein Team, das am Sprintende „fast fertig" ist und im nächsten Sprint weiterarbeitet, hat keinen Sprint, sondern eine Zwischenüberschrift. Genau daran scheitert der grösste Teil der Scrum-Einführungen — nicht an den Zeremonien, sondern daran, dass fertig nicht definiert ist.
Die Rollen und wer sie in der Realität ausfüllt
Die Product-Owner-Rolle ist die anspruchsvollste und die am häufigsten unterbesetzte. Sie verlangt drei Dinge gleichzeitig: fachliche Entscheidungsbefugnis, Verfügbarkeit für das Team und die Bereitschaft, Nein zu sagen. Fehlt eines davon, entsteht der häufigste Fall überhaupt — ein Product Owner, der Wünsche weiterreicht, statt zu priorisieren.
Ein weitergereichter Wunsch ist keine Priorisierung. Wenn alles ins Backlog kommt und die Reihenfolge nach Lautstärke der Anfragenden entsteht, entscheidet nicht das Produkt, sondern die Organisation. Das Team merkt das schnell und hört auf, die Reihenfolge ernst zu nehmen.
Was die Retrospektive leisten müsste
Von allen Elementen ist die Retrospektive dasjenige mit dem grössten Hebel und der niedrigsten Umsetzungsqualität. Ihr Zweck ist nicht, Probleme zu benennen — das gelingt fast überall. Ihr Zweck ist, eine Änderung zu beschliessen, die im nächsten Sprint sichtbar wird.
Eine Retrospektive ohne beschlossene Änderung ist eine Gesprächsrunde. Nach drei bis vier solchen Runden hört ein Team auf, Probleme zu nennen, weil sich ohnehin nichts ändert — und dann ist der wirksamste Mechanismus des Rahmenwerks still abgeschafft. Die einfachste Gegenmassnahme ist eine Regel: genau eine Änderung pro Retrospektive, mit Verantwortlichem, und zu Beginn der nächsten überprüft.
Schätzen ist kein Selbstzweck
Um kaum ein Thema wird mehr Zeit verbraucht als um Schätzungen. Dabei ist der Nutzen einer Schätzung nicht die Zahl, sondern das Gespräch, das sie auslöst: Wo zwei Personen stark unterschiedlich schätzen, haben sie die Aufgabe unterschiedlich verstanden — und genau diese Differenz ist die wertvolle Information.
Wo Schätzungen dagegen zu Zusagen umgedeutet werden, gegen die später gemessen wird, kehrt sich der Effekt um. Teams schätzen dann defensiv, die Zahlen werden grösser und weniger aussagekräftig, und der ursprüngliche Zweck ist verloren. Wer Schätzungen als Leistungsmass verwendet, bekommt bessere Schätzungen und keine besseren Ergebnisse.
Wann Scrum die falsche Wahl ist
Scrum passt schlecht, wenn die Arbeit überwiegend aus unvorhersehbaren, kurzfristigen Anforderungen besteht. Ein Team im Betriebs- oder Supportkontext kann keinen Sprint planen, wenn die Hälfte des Inhalts während des Sprints hereinkommt. Der Versuch, es trotzdem zu tun, erzeugt Sprints, die jedes Mal umgeworfen werden — und die Erfahrung, dass Planung sinnlos ist.
Für diesen Fall ist ein flussorientiertes Vorgehen mit Begrenzung paralleler Arbeit die passendere Antwort. Das ist kein Rückschritt, sondern die Wahl des Werkzeugs nach der Aufgabe. Ebenso wenig passt Scrum für ein Vorhaben, dessen Umfang vollständig feststeht und sich nicht ändern wird — dort erzeugt der Mechanismus Aufwand ohne Gegenwert.
Der brauchbare Prüfstein
Ob ein Team wirklich Scrum betreibt, lässt sich an zwei Fragen erkennen. Erstens: Gibt es eine verbindliche Definition von fertig, die auch unter Zeitdruck gilt? Zweitens: Hat die letzte Retrospektive zu einer sichtbaren Änderung geführt? Wo beide Antworten Ja lauten, funktioniert das Rahmenwerk in aller Regel. Wo eine Nein lautet, hilft keine zusätzliche Zeremonie.