Sprechen Sie "Scrum"?

Abgesehen von der gewöhnungsbedürftigen Terminologie ist Scrum (wörtlich: Gedränge) erstaunlich einfach: Es basiert auf der Annahme, dass sich komplexe Entwicklungen nicht im Voraus hinreichend detailliert planen und in einzelne Schritte aufteilen lassen. Deshalb sind auch keine sinnvollen Vorgaben für Entwicklerteams abzuleiten - erst recht nicht in Form von Tages- oder Stundenvorgaben für Programmierer oder Projektleiter. An Stelle des umfassenden Masterplans und der ausufernden Dokumentation bei der Wasserfall-Methode treten bei Scrum deshalb sich selbst-organisierende Projekt-Teams, die in einem Rahmen mit festen Regeln in enger Abstimmung mit dem Auftraggeber ("product owner") in zwei- bis vierwöchigen Zyklen ("Sprints") Teilaufgaben umsetzen.

Im Mittelpunkt steht ein zyklischer Ablauf mit festem Regelwerk, definierten Rollen, Ablaufplänen und Artefakten. Das Scrum-Team besteht aus fünf bis neun Mitgliedern und dem Scrum-Master. Der Product-Owner ist direkt beteiligt. Das Team entwickelt innerhalb eines Sprints lauffähige Funktionen und Module. Dabei organisiert und koordiniert es die Arbeit selbständig; die Aufgabe des Scrum-Masters besteht darin, die organisatorischen und technischen Bedingungen zu schaffen. Der Product-Owner priorisiert die anstehenden Aufgaben ("user-stories"), steht den Entwicklern als Ansprechpartner zur Verfügung und wählt zusammen mit dem Scrum-Master und dem Team die jeweils im nächsten Sprint zu realisierenden User-Stories aus.

Alle User-Stories sind in einer Liste ("Product Backlog") festgehalten. Diese wird zum Auftakt eines Projekts im "Grooming-Meeting" erstellt und enthält sämtliche zu diesem Zeitpunkt absehbare Aufgaben, die für das lauffähige Software-Produkt nötig sind. "Ein Product Backlog ist niemals vollständig; es ändert sich im Laufe des Entwicklungsprozesses - neue Funktionen kommen hinzu, andere werden gestrichen oder neu priorisiert", heißt es im Scrum-Guide.

Neben dem Product Backlog gibt es außerdem den "Sprint Backlog". Zu Beginn eines neuen Sprints werden die User Stories, die im nächsten Zyklus anstehen, in den "Sprint Backlog" übertragen. Der Fortschritt des Sprints wird in einem Chart ("Sprint Burndown") festgehalten. Dieser gibt Auskunft darüber, ob das Team im Zeitplan ist und welche Ziele es bereits erreicht hat. Analog dazu ist im Product Burndown der Fortschritt des gesamten Software-Projektes festgehalten.

Eine Reihe von ebenfalls regelhaft festgelegten Meetings mit exakten Zeitvorgaben wie dem "Sprint Planning Meeting" zum Start eines Sprints, den täglichen "Daily Scrums" und dem "Sprint Review" und "Sprint Retrospective" am Ende eines Zyklus sichern die intensive Kommunikation zwischen Auftraggeber und Entwickler-Team. Damit sind Feedback- und Lernprozesse institutionalisiert. Am Ende eines jeden Sprints stehen fertige und lauffähige Programm-Module und Funktionen.