Scrum

Was Scrum ist

Scrum ist ein Rahmenwerk für die Zusammenarbeit an Aufgaben, deren Ergebnis sich nicht vollständig vorausplanen lässt. Die Arbeit läuft in gleich langen Abschnitten von ein bis vier Wochen, den Sprints. Am Ende jedes Sprints steht ein benutzbares Zwischenergebnis, das bewertet wird und die Planung des nächsten Abschnitts beeinflusst. Verbindlich beschrieben ist der Ansatz im Scrum Guide, der von den Urhebern gepflegt wird.

Wichtig ist, was das Scrum Framework ausdrücklich nicht ist. Es beschreibt eine Arbeitsweise, keine Methode für Softwareentwicklung. Wie geplant, getestet und ausgeliefert wird, bleibt offen und wird vom Team selbst festgelegt. Genau deshalb findet sich der Ansatz heute auch außerhalb der agilen Softwareentwicklung, etwa in Marketing, Verwaltung und Produktentwicklung.

Die Scrum Rollen

Das Regelwerk kennt drei Verantwortlichkeiten. Der Product Owner entscheidet, was gebaut wird, und verantwortet die Reihenfolge der offenen Aufgaben. Die Developers, also alle, die am Ergebnis arbeiten, entscheiden, wie gebaut wird, und wählen selbst aus, wie viel sie in einen Sprint nehmen. Der Scrum Master sorgt dafür, dass die Arbeitsweise verstanden und eingehalten wird, und räumt Hindernisse aus dem Weg. Fachliche Weisungsbefugnis hat keine dieser Rollen.

Die Scrum Artefakte

Drei Arbeitsmittel halten den Stand fest. Das Product Backlog ist die geordnete Liste aller offenen Anforderungen und gehört dem Product Owner. Das Sprint Backlog enthält den Ausschnitt, den das Team im laufenden Abschnitt bearbeitet. Das Increment ist das fertige Zwischenergebnis am Sprintende. Jedes Artefakt trägt eine Zusage darüber, wann etwas als erledigt gilt. Ohne diese Zusage ist ein Zwischenergebnis nur ein Zwischenstand. Deshalb wird die Definition von fertig einmal vereinbart und nicht je Aufgabe neu ausgehandelt.

Wann der Ansatz nicht trägt

Kurze Zyklen helfen dort, wo sich Anforderungen im Verlauf klären. Steht der Umfang von vornherein fest, etwa bei einer Migration mit festem Zieltermin und unveränderlichem Datenmodell, kostet der Rahmen mehr, als er bringt. Ohne Entscheidungsbefugnis im Team bleibt vom Ansatz nur der Terminkalender. Ein festes Budget mit fester Leistungsbeschreibung passt ebenfalls schlecht dazu, weshalb Verträge über Individualsoftware hier eher Zeitkontingente als Werkleistungen beschreiben. Umgekehrt scheitert Scrum selten an der Technik. Die Zusagen aus einem Sprint gelten anderswo im Haus oft nicht, und Freigaben brauchen dann länger als der Abschnitt selbst.