Die Scrum-Erfahrungen bei Payback

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 die Stelle des umfassenden Masterplans und der ausufernden Dokumentation bei der "Wasserfallmethode" treten bei Scrum deshalb sich selbst organisierende Projektteams, 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 selbststä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 absehbaren Aufgaben, die für das lauffähige Softwareprodukt 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 den Beteiligten 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 Softwareprojektes 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 Entwicklerteam. Damit sind Feedback- und Lernprozesse institutionalisiert. Am Ende eines jeden Sprints stehen fertige und lauffähige Programmmodule und Funktionen.

Noch Fragen? Weitere Informationen finden Sie unter anderem hier und hier.