Scrum ist ein leichtgewichtiges Framework, innerhalb dessen Menschen komplexe, adaptive Probleme angehen können, während sie Produkte mit dem größtmöglichen Wert liefern. Das ist die Definition des Scrum Guide, und sie ist gut, auch wenn sie zum Verständnis aufgeschlüsselt werden muss.
Das Schlüsselwort ist "Framework". Scrum sagt nicht im Detail, wie die Arbeit erledigt werden soll. Es bietet eine Struktur aus Accountabilities, Events und Artefakten, innerhalb derer sich Teams organisieren und kontinuierlich verbessern können. Das Framework ist bewusst minimal: klein genug, um in ein Dokument zu passen, meinungsstark genug, um bedeutsam zu sein.
Woher es kommt
Jeff Sutherland und Ken Schwaber schufen Scrum in den frühen 1990ern, aufbauend auf früherer Arbeit von Takeuchi und Nonaka, die führende Produktentwicklungsorganisationen untersucht und die "Scrum"-Rugby-Metapher in einem Harvard-Business-Review-Artikel von 1986 geprägt hatten. Die Beobachtung war, dass leistungsstarke Entwicklungsteams sich wie Rugby-Stürmer bewegten, als Einheit, kontinuierlich anpassend, statt einen Stab in einem Staffellauf weiterzureichen. Sutherland und Schwaber formalisierten das zu einem praktischen Framework.
Die drei Accountabilities
Scrum definiert drei Accountabilities innerhalb eines Scrum-Teams.
Die Product-Owner-Person ist verantwortlich für den Wert, den das Team liefert. Das bedeutet, den Product Backlog zu besitzen und zu ordnen, die Liste von allem, was im Produkt eventuell gebraucht werden könnte, und sicherzustellen, dass die wertvollste Arbeit immer oben steht. Die Product-Owner-Person ist eine Person, kein Komitee, und ihre Entscheidungen müssen von der Organisation respektiert werden, damit die Accountability funktioniert.
Der Scrum Master ist verantwortlich für die Wirksamkeit des Teams. Er hilft allen, Scrum zu verstehen und anzuwenden, nicht als Regeldurchsetzer, sondern als Coach, der dem Team hilft, seine Arbeitsweise kontinuierlich zu verbessern. Er dient auch der Organisation, hilft ihr zu verstehen, was Scrum erfordert, und beseitigt strukturelle Hindernisse für die Leistung des Teams.
Die Developer sind die Menschen, die die Arbeit leisten: jeden Sprint ein nutzbares Increment zu erzeugen. Sie organisieren sich selbst darüber, wie die Arbeit erledigt wird, Entscheidungen über Ansatz und Methode gehören den Menschen, die der Arbeit am nächsten sind, nicht Führungskräften oder dem Scrum Master.
Die fünf Events
Der Sprint ist der Container für alles andere, ein fester Zeitraum von einem Monat oder weniger, innerhalb dessen das Team ein nutzbares Increment erzeugt. Sprints laufen kontinuierlich; einer endet und der nächste beginnt sofort.
Sprint Planning eröffnet jeden Sprint. Das Team bestimmt, was geliefert wird und wie, verankert durch ein Sprint Goal, das dem Sprint seinen Zweck gibt.
Der Daily Scrum sind fünfzehn Minuten täglich für die Developer, um den Fortschritt in Richtung Sprint Goal zu überprüfen und ihren Plan für die nächsten vierundzwanzig Stunden anzupassen.
Der Sprint Review schließt die Lieferung des Sprints ab: Team und Stakeholder überprüfen das Gebaute und arbeiten gemeinsam daran, was als Nächstes kommen sollte.
Die Sprint Retrospektive schließt den Sprint ab: Das Team reflektiert, wie gearbeitet wurde, und identifiziert konkrete Verbesserungen für den nächsten Sprint.
Die drei Artefakte
Der Product Backlog ist die geordnete Liste von allem, was eventuell wertvoll zu bauen wäre, besessen von der Product-Owner-Person, nie vollständig.
Der Sprint Backlog ist die für den aktuellen Sprint ausgewählte Teilmenge des Product Backlogs, plus der Plan des Teams zu ihrer Lieferung.
Das Increment ist die Summe aller abgeschlossenen Arbeit, alles bisher Gelieferte, kombiniert zu etwas Nutzbarem. Arbeit, die die Definition of Done nicht erfüllt, ist nicht Teil des Increments.
Warum Scrum funktioniert, und wann nicht
Scrum funktioniert, indem es kurze Feedbackschleifen schafft. Statt sechs Monate an etwas zu arbeiten und am Ende zu entdecken, dass es das Ziel verfehlt hat, wird jeden Sprint etwas Kleines gebaut, echten Stakeholdern gezeigt, aus ihrer Reaktion gelernt, und angepasst. Das Framework macht die Kosten, falsch zu liegen, früh sichtbar, wenn noch etwas dagegen getan werden kann.
Scrum funktioniert tendenziell nicht, wenn es als Zeremonie ohne Substanz umgesetzt wird, wenn die Meetings stattfinden, aber die zugrunde liegenden Entscheidungen weiterhin vom Management getroffen werden, wenn die Product-Owner-Person keine echte Autorität hat, oder wenn die Retrospektive als Checkbox behandelt wird statt als echtes Verbesserungsgespräch. Das Framework ist nur so wertvoll wie die Ehrlichkeit, mit der es praktiziert wird.