Scrum Methode für agiles Projektmanagement

Agile Projektmanagement-Methoden ermöglichen es einem Team, größere Projekte selbstverwaltend und flexibel zu verwirklichen. Statt wie beim klassischen Projektmanagement das Ergebnis in den Mittelpunkt der Planung zu stellen, sind beim agilen Projektmanagement Zeit und Aufwand Basis der Projektplanung. Erst nachdem ein Team einen festen Zeit- und Kostenrahmen definiert hat, darf entschieden werden, welche Ergebnisse innerhalb dieses Rahmens realistisch zu erreichen sind. Durch diese Herangehensweise fragt sich das Team »Was können wir schaffen?«, statt »Was müssen wir schaffen?«. Agiles Projektmanagement hilft so, realistisch zu planen und Deadlines einzuhalten.

Zeit und Arbeitskraft der einzelnen Teammitglieder sollen beim agilen Arbeiten möglichst effizient genutzt werden. Ist ein Projekt nach den Maßstäben des agilen Managements organisiert, sollte jedes Mitglieds des Teams stets konzentriert an der Bewältigung einer Aufgabe arbeiten, bis diese erledigt ist.

Scrum ist die wohl meistgenutzte Methode für agiles Projektmanagement und sollte vielen Teams bereits in Grundzügen vertraut sein. Scrum strukturiert die Arbeit am Projekt in sogenannte »Sprints«, einzelne Entwicklungsphasen, in denen konzentriert an einem Teilaspekt des Projekts gearbeitet wird, bis dieser fertiggestellt ist. Sprints sind im Normalfall auf 30 Tage begrenzt und dürfen nicht verlängert werden. Auf einen Sprint folgt eine Retrospektive, in der das Team die geleistete Arbeit sowie genutzte Methoden und Tools bewertet. Was hat funktioniert, was nicht? Wo herrscht Optimierungspotenzial? Aufgabenverteilung und -fortschritt werden auf einem speziell eingeteilten »Scrum Board« festgehalten. Digitale Lösungen gibt es natürlich auch.

Voraussetzung für die reibungslose Zusammenarbeit eines Scrum-Teams ist eine fest organisierte Teamstruktur. Innerhalb des Teams sind zwei Rollen fest zu besetzen: Scrum-Master und Product Owner. Der Scrum-Master regelt die interne Kommunikation, verteilt Aufgaben und sorgt dafür, dass Sprint-Fristen eingehalten werden. Der Product Owner behält die Anforderungen von Kunden und Vorgesetzten im Auge und korrigiert gegebenenfalls den Kurs, falls das Team Gefahr läuft, diese Vorgaben aus den Augen zu verlieren. Bei größeren Projekten kann es vorkommen, dass der Kunde selbst einen Product Owner stellt, der dann in das Team integriert werden muss. Damit Scrum richtig funktioniert, sollten die Teammitglieder flexibel und interdisziplinär arbeiten. Spezialist:innen konzentrieren sich soweit möglich auf ihr Fachgebiet, sollten aber aushelfen können, wenn es an anderer Stelle brenzlig wird.

Ein Scrum-Team trifft sich einmal am Tag zum »Daily Scrum«, einem möglichst kurzen täglichen Meeting, in dem die Teammitglieder mitteilen, woran sie momentan arbeiten, wie die Arbeit vorangeht und wann mit der Fertigstellung der Aufgabe gerechnet werden kann. »Dailys« sollten eine Länge von 15 Minuten nicht überschreiten und sind reine Informationsmeetings. Diskussionen sollten vermieden werden – diskutiert wird in Planungsmeetings und Retrospektiven. Das Arbeiten nach der Scrum-Methode sorgt für eine klare Arbeitsteilung. Mit dem Scrum-Master ist stets jemand im Team, der dafür sorgt, dass jedes Teammitglied seine Arbeitskraft optimal einsetzt. So wird Leerlauf vermieden und die Effizienz des Teams gesteigert. Die festgelegten Zeitintervalle der Sprints vermeiden ein »Festbeißen« in Teilbereiche des Projekts und treiben die Projektentwicklung fortwährend von Meilenstein zu Meilenstein an.

Dass die Dauer der Sprints im Vorfeld festgelegt ist, kann andererseits schnell zur Stolperfalle werden. Können Meilensteine nicht wie geplant erreicht werden, müssen Sprints im schlimmsten Fall verlängert werden. Gerade unerfahrene Teams bringen sich mit unzureichender Projektplanung schnell aus dem Konzept und verwenden in Folge Zeit und Energie darauf, neue Pläne aufzubauen. Zudem lässt das Sprint-Modell wenig Platz für flexible Entscheidungen. Offenbaren sich überraschend neue Aufgaben, können diese erst in der nächsten Sprintphase begonnen werden.

Viele Teams möchten die Vorteile von Scrum für sich nutzen, erachten aber nicht alle Teilaspekte des Systems als für ihre Situation sinnvoll. Teilweise Integrationen von Scrum bezeichnet man als »ScrumButs«, denn sie sind »Scrum, aber...« Welche Scrum-Aspekte gestrichen werden, hängt von den Ansprüchen und der Größe des Teams ab. Kleine Teams etwa verzichten häufig darauf, die Position des Scrum-Masters fest zu besetzen. Teammitglieder sind so gezwungen, sich ihre Aufgaben in Absprache mit dem Rest des Teams selbst auszusuchen und müssen Sprintfristen selbstständig einhalten. Weitere beliebte ScrumBut-Änderungen sind flexible Sprintlängen oder die Abschaffung der »Dailys« zugunsten von wöchentlichen Meetings.

ScrumBut spaltet die Scrum-Gemeinde. Einige sehen Scrum als offenes System, das von jedem Team auf seine individuellen Bedürfnisse angepasst werden kann, andere sehen in der Notwendigkeit, Scrum anzupassen ein Symptom für tiefergehende Probleme im Team. Ein funktionierendes Team, so die Argumentation, sollte mit einem unveränderten Scrum problemlos und effizient arbeiten können. In jedem Fall sollten Änderungen an Scrum-Prinzipien auf Erfahrungswerten basieren. Nur wer mit seinem Team schon umfassend mit Scrum gearbeitet hat, kann wirklich beurteilen, ob eine ScrumBut-Lösung Sinn ergibt. Es lohnt sich also, ein vollständiges Scrum bei einigen kleineren Projekten auszuprobieren, bevor man Eingriffe im System vornimmt.