Scrum Programmierung
Was Scrum ist
Scrum ist ein Rahmenwerk für die Arbeit an komplexen Produkten. Bewusst dünn gehalten: Der offizielle Scrum Guide hat in der Fassung von 2020 gerade dreizehn Seiten. Er beschreibt, wer welche Verantwortung trägt, welche Termine es gibt und welche Ergebnisse dabei entstehen. Wie die Arbeit selbst gemacht wird, lässt er offen. Das ist Absicht und gleichzeitig der Grund, warum Scrum so unterschiedlich gut funktioniert.
Die drei Verantwortlichkeiten
- Product Owner: entscheidet, was gebaut wird und in welcher Reihenfolge. Eine Person, kein Gremium, sonst funktioniert die Priorisierung nicht.
- Developers: alle, die am Produkt arbeiten. Sie entscheiden gemeinsam, wie viel sie in einen Sprint nehmen und wie sie es umsetzen.
- Scrum Master: sorgt dafür, dass das Rahmenwerk verstanden und gelebt wird, und räumt Hindernisse aus dem Weg. Keine Führungsrolle im klassischen Sinn, und schon gar kein Projektleiter mit neuem Titel.
Seit 2020 heißt das Ganze übrigens Scrum Team und nicht mehr Entwicklungsteam plus Anhang. Klingt nach Kosmetik, zielt aber auf ein reales Problem: Product Owner und Scrum Master galten in vielen Firmen als Zulieferer und Aufpasser statt als Teil der Mannschaft.
Wie ein Sprint abläuft
Ein Sprint dauert höchstens vier Wochen, in der Praxis meist zwei. Er beginnt mit dem Sprint Planning, in dem das Team ein Sprint-Ziel setzt und die Arbeit dafür auswählt. Täglich gibt es das Daily Scrum, fünfzehn Minuten zur Abstimmung. Am Ende steht das Sprint Review, in dem das Ergebnis gezeigt und mit den Stakeholdern besprochen wird, und danach die Retrospektive, in der das Team die eigene Arbeitsweise anschaut. Direkt im Anschluss beginnt der nächste Sprint. Ohne Pause, das gehört zum Rhythmus.
Die Artefakte
- Product Backlog: die geordnete Liste all dessen, was das Produkt braucht. Nie fertig, ständig in Bewegung.
- Sprint Backlog: was sich das Team für diesen Sprint vorgenommen hat, plus der Plan, wie es dahin kommt.
- Increment: das Ergebnis, das am Ende des Sprints tatsächlich funktioniert. Was die Definition of Done nicht erfüllt, ist kein Increment, auch wenn es fast fertig aussieht.
Was es bringt
Der Takt ist der eigentliche Gewinn. Alle zwei Wochen ein Ergebnis zu zeigen, zwingt zu Entscheidungen, die sonst gern liegen bleiben. Und weil das Team selbst festlegt, wie viel es sich vornimmt, entsteht nach ein paar Sprints eine belastbare Vorstellung davon, was in dieser Zeit realistisch machbar ist. Das hilft bei Absprachen mehr als jede Schätzung im Voraus.
Typische Fehler
- Der Sprint wird zum Terminplan. Wer die Aufgaben von oben zuteilt, hat kurze Wasserfälle statt Sprints.
- Die Retrospektive fällt aus, wenn es eng wird. Also genau dann, wenn sie gebraucht wird.
- Die Definition of Done ist unklar, und am Ende ist alles zu neunzig Prozent fertig.
- Das Review wird zur Präsentation statt zum Arbeitsgespräch. Ohne echtes Feedback bringt es nichts.
- Scrum wird eingeführt, wo Kanban besser passt. Für Support und laufenden Betrieb ist ein fester Sprintrhythmus oft Ballast.
Wann Scrum passt und wann nicht
Scrum lohnt sich, wenn die Anforderungen unsicher sind und ein Team über längere Zeit gemeinsam an einer Sache arbeitet. Bei planbarer Routinearbeit, bei Einzelkämpfern oder bei ständig wechselnden Prioritäten von außen erzeugt es vor allem Termine. Diese Entscheidung ehrlich zu treffen, ist der halbe Erfolg, und im Zweifel eine gute Frage für einen Abend unter Kolleginnen und Kollegen.