Kaum eine Software oder ein Projekt wird heute ohne agile Methoden durchgeführt. Mit Scrum erhalten Sie klare Strukturen, genau definierte Arbeitspakete und eine nachhaltige Weiterentwicklungsmöglichkeit für Ihre Produkte.

 

Was ist Scrum?

Scrum ist eine von vielen Methoden des agilen Projektmanagements, die bei der Softwareentwicklung und dem Produktmanagement eingesetzt wird. Durch die Aufteilung von einzelnen Aufgaben in Umsetzungsrunden (sog. Sprints), werden alle Aufgaben nach und nach erledigt bis das Produkt fertiggestellt wurde. Währenddessen wird durch eine klare Rollenverteilung definiert, wer welche Aufgabe im Team übernimmt und wie Aufgaben in Sprints verteilt werden.

 

Wieso scheitern Projekte und was soll Scrum besser machen?

Das Problem bei klassischen Projektstrukturen ist, dass zu viel geplant und dokumentiert wird. Dies ist zwar auf der einen Seite durchaus wichtig und richtig, aber durch Überorganisation stehen Sie sich irgendwann selbst im Weg.

Auch bei Scrum müssen wichtige Projektbestandteile dokumentiert werden. Allerdings setzt sich Scrum zum Ziel, dass mit vielen kleinen und überblickbaren Schritten das Produkt entwickelt wird und jeder im Team mitverantwortlich ist. Mit diesen Punkten unterscheidet sich Scrum zu klassischen Projektmanagementmethoden. Es sollen Ineffizienzen bei Zuständigkeiten und ein Überblickverlust beim Projekt vermieden werden.

 

Welche Rollen gibt es beim Scrum?

Es gibt Product Owner (Produkteigner), Scrum Master (Project Master), Team, Pigs und Chickens.

Der Product Owner vertritt Kunden oder Stakeholder, (kurz gesagt, alle die ein Interesse am Projekt bzw. Produkt haben), mit deren Anforderungen und Wünschen. Diese werden von ihm auf Umsetzbarkeit, Funktionalität, Performance, Qualität, Funktionalität, Wartungsfreundlichkeit (Support) und Priorität beurteilt.

Der Product Owner sollte daher wissen, was die Kunden oder Stakeholder wollen und in direkter Kommunikation mit den Marketing- und Vertriebsabteilungen stehen. Aus seinen Einschätzungen und Beurteilungen werden die Aufgaben definiert, ins Backlog übertragen und fortlaufend gepflegt. Zudem steht er dem Team bei Rückfragen zur Verfügung und nimmt an den Daily Scrum Meetings teil.

Der Scrum Master (Project Master) sorgt dafür, dass das gesamte Team zielgerichtet arbeiten kann und Probleme beseitigt werden. Agile Methoden bzw. Prozesse weisen eine hohe Dynamik in allen Bereichen (Produktanforderungen, Ressourcen,…) auf, sodass es gerade hier immer wieder zu Engpässen und unvorhersehbaren Komplikationen kommen kann.

Er trägt somit die vollständige Verantwortung der größtmöglichen Effektivität und Effizienz im Scrumprozess, tritt als Vermittler auf, moderiert Meetings, hat die Aktualität der Backlogs und Burndown Charts im Blick, schützt das Team vor Externalitäten und beseitigt die Hindernisse.

Ein Scrum Master muss neben fachlichem Wissen auch gute kommunikative Fähigkeiten mitbringen und im Team akzeptiert werden. Besonders wichtig: Ein Scrum Master ist kein Chef, sondern vielmehr ein Moderator.

Das Scrum-Team besteht aus fünf bis zehn Personen, welche sich selbst organisieren und sich um die Umsetzung der Anforderungen kümmern. Dabei entscheidet das Team, wie Aufgaben verteilt und zerlegt werden. Für einen besseren Überblick über die bereits erledigten Aufgaben, aber auch Probleme innerhalb des Sprints, trifft sich das Scrum-Team täglich zum Daily Scrum Meeting.

Zu den weiteren elementaren Aufgaben des Scrum-Teams zählen die tägliche Pflege des Sprint Backlogs sowie das Anfertigen des Increment of Potentially Shippable Functionality nach jedem Sprint.

Für die Teammitglieder ist es ebenso wichtig, das Big Picture eines Projektes zu kennen. Ohne gewisse Hintergrundinformationen laufen Sprints die Gefahr, das Fragen zum Warum auftreten oder die Motivation einzelner Teammitglieder leidet – Kommunikation ist der Schlüssel zum Erfolg!

Zu den sogenannten Pigs zählen alle Personen, die sich direkt am Projekt beteiligen und somit ein Risiko vom Projekt tragen. Pigs sind daher neben dem Product Owner, dem Scrum Master und dem Team auch die Stakeholder.

Wie bei jedem Projekt gibt es jedoch auch Interessenten, welche sich mehr oder weniger zum Projekt äußern, allerdings nicht direkt integriert sind und somit kein Risiko tragen. Diese Personen werden als Chickens bezeichnet. Wie mit dieser Gruppe umgegangen wird ist von Fall zu Fall unterschiedlich. Von der Rolle als Beobachter bis hin zum Ausschluss aus dem Gesamtprojekt ist vieles möglich.

 

Wie läuft der Scrum-Prozess ab?

Das Product Backlog als Grundlage.

Die gesamten Anforderungen werden im Product Backlog erfasst, aktualisiert und priorisiert. Das Product Backlog ist absolut dynamisch und verändert sich ständig.

Bei manchen Projekten kann die Anforderungsliste sehr umfangreich sein, sodass mehrere Sprints und ggf. mehrere Teams beteiligt sind.

 

Das Sprint Planning vor dem eigentlichen Sprint.

Für die Organisation der einzelnen Sprints, welche maximal vier Wochen dauern sollten, erfolgt zuvor das sogenannte Sprint Planning. In dieser Stufe wird festgelegt, welche Aufgaben auf dem Sprint Backlog stehen und wie die Aufgaben organisiert bzw. erledigt werden. Ein Sprint Backlog ist somit eine Auswahl an Anforderungen des Product Backlogs, welche zu klaren Aufgaben (Tasks) umformuliert und mit einem Umsetzungsplan erweitert wurden. Für jede Aufgabe wird auch eine Definition of Done festgelegt. Diese beinhaltet exakt, unter welchen Voraussetzungen eine Aufgabe als abgeschlossen klassifiziert werden darf.

 

Der Sprint mit Daily Scrum Meetings

Die Verwaltung der Aufgaben aus dem Sprint Backlog erfolgt mittels eines Kanban-Boards. Am Ende eines Sprints sollten alle Tasks in einer Erledigt-Spalte (Done) stehen. Damit dies auch gelingt und Überraschungen außen vor bleiben, gibt es täglich ein Daily Scrum Meeting, welches maximal 15 Minuten dauern darf und den Fortschritt in einem Sprint-Burndown-Chart festhält. In diesen Meetings werden keine Ideen oder Produktverbesserungen besprochen, sondern ausschließlich der Arbeitsfortschritt und die eventuellen Probleme. Um die Probleme kümmert sich der Scrum Master und hält dem Team den Rücken frei. Des Weiteren unterstützt der Scrum Master das Team beim Daily Scrum Meeting mit einem Sprint-Burndown-Chart, um den Fortschritt zu visualisieren.

 

Der Sprint ist vorbei … jetzt wird geprüft

Am Ende eines Sprints ist ein potentiell auslieferbares Produkt-Inkrement (Increment of Potentially Shippable Functionality) entstanden, welches das Team in einem Sprint Review Meeting allen Projekt-Interessenten präsentiert. Bei dem Sprint Review Meeting wird das Produkt-Inkrement live vorgestellt und keinerlei Zwischenstände oder Vortragsfolien. Der Product Owner prüft währenddessen, ob bei den Aufgaben die Definition of Done eingehalten, optimiert oder verfehlt wurden.

Das Feedback der Interessenten, einschließlich der nicht vollständig erfüllten Aufgaben, wird in das nächste Sprint Planning Meeting übernommen und der agile Prozess beginnt von neuem.

 

Feedback, Feedback, Feedback!

Jedes Team ist anders, jede Anforderung bringt neue Herausforderungen mit sich  – entsprechend flexibel müssen Projektbeteiligte sein.

Das dies nicht immer gelingt und jeder Mensch individuell reagiert, wird bei solch dynamischen Prozessen schnell klar.

Mit Hilfe der Sprint Retrospective wird zurückblickend die Zusammenarbeit des Sprints einschließlich der Abläufe, der Tools und der Kommunikation besprochen. Das Ziel eines solchen Meetings ist es, dass die Effizienz für die nächsten Sprints gesteigert wird und fehlerhafte Abläufe oder schlechte Kommunikation vermieden werden.

 

Ist Scrum denn nun so einfach?

Nicht unbedingt. Bei kleinen Projekten mag dies vielleicht der Fall sein, aber bei größeren Projekten mit mehreren Teams und dutzenden Abhängigkeiten durch externe Unternehmen weniger.

Hier werden sehr oft maßgeschneiderte Kanban-Boards und weitere Tools (z.B. Feedback-Software) eingesetzt, welche die große Zahl an Projektbeteiligten besser vertreten. Für eine bessere Präsentation besonderer Schwerpunkte in den Daily Scrum Meetings wählt der Scrum Master aus einer Vielzahl von Reporting-Methoden die Beste aus.

Einfach ist also relativ. 

Titelbild: © André Sandner – andre-sandner.com & stock.adobe.com