Seit nicht ganz fünf Monaten arbeite ich fest bei comm-press. Eigentlich ist meine Rolle „Product Owner“. Aber auf meiner Visitenkarte steht „Projektmanagement“. Wir organisieren unsere Arbeit nach Scrum, einem Management Framework agiler Softwareentwicklung mit wenigen, klaren Regeln.

Eine der grundlegenden Regeln lautet: Es müssen drei verschiedene Rollen angewendet werden: Product Owner, Team und Scrum Master. Eine andere: Ein priorisiertes Backlog muss geführt werden. Und eine weitere Regel besagt: Die Umsetzung erfolgt in mehreren Abschnitten, die Sprints genannt werden. Mehr zu Scrum: https://de.wikipedia.org/wiki/Scrum

Vor meiner Zeit bei comm-press hatte ich bereits einige Male in Teams gearbeitet, die ähnliche Regeln für die Umsetzung von Projekten aufgestellt hatten. Allerdings ist die Arbeit bei comm-press meine erste Erfahrung, bei der diese Regeln gelebt und vor allem „durchgehalten“ werden.

In diesem Beitrag will ich einen Überblick über die Abläufe geben, um vorzustellen, was Scrum für unseren Projekt-Alltag bei comm-press bedeutet.

Weil Scrum nur wenige Regeln vorgibt, sieht der Alltag mit Scrum für jedes Team anders aus.

Scrum-Basics / Begriffserläuterungen

Scrum-Rollen:

Product Owner Der Product Owner vertritt die Bedürfnisse der Kunden und verantwortet die äußere Qualität des Produkts oder Projekts.

Scrum-Team Gruppe von Entwicklern, mit diversen Fähigkeiten, die das Projekt umsetzen und die innere Qualität des Produkts verantwortet. (Das Team im folgenden Beispiel besteht aus vier Personen.)

Scrum Master Der Scrum Master unterstützt Team und Product Owner bei der Anwendung von Scrum.

Sprint Dauer: Die Länge eines Sprints legt jedes Team individuell fest. 
Für meine aktuellen Projekte: 1 Woche, von Mittwoch bis Dienstag

User Story Beschreibung eines Features aus der Perspektive des Users
Bsp: “Als Redakteurin möchte ich eine Zeit für die Veröffentlichung eines Blog-Beitrags festlegen können, um Content auch in meiner Abwesenheit bereitzustellen.”

Backlog Liste der erfassten User Storys und Aufgaben

Backlog Refinement Gemeinsames überprüfen, ob die User Storys des Backlogs klar und verständlich beschrieben wurden. Aufwandsschätzung neuer User Storys und Aufgaben

Sprint Planung Festlegen, welche Vorgänge im nächsten Sprint fertiggestellt werden sollen

Sprint Review Präsentation der fertiggestellten Features ggü. den Stakeholdern

Retrospektive (Vorschlag) Teamtreffen - eine Rückschau (in der Regel auf den vergangenen / aktuellen Sprint, aber auch darüber hinaus) mit dem Ziel aus Erfahrungen zu lernen. Gemeinsam schaut das Team zurück und analysiert, was “gut” und was “schlecht” gelaufen ist, der Schwerpunkt liegt darin zu analysieren warum etwas “gut” und was “schlecht” bewertet wurde. So können kontinuierlich Verbesserungen in der Sprintbewältigung und in der Zusammenarbeit erreicht werden

Der Scrum-Kreislauf:

Backlog Refinement > Sprint Planning > Umsetzung > Sprint Review > Retrospektive > Repeat

Um zu verdeutlichen, welche Auswirkung Scrum auf die tägliche Arbeit hat, stellen wir uns folgendes Szenario vor: Am einem Montag Nachmittag erhalte ich eine Email von einer Kundin, die in ihrer Nachricht eine neue Anforderung für eine bestehende Unternehmenswebseite beschreibt. Sie bittet mich, den Aufwand zu schätzen und die Umsetzung zu planen.

Dienstag (Woche 1):

Ende des laufenden Sprints. Die Anfrage vom Montag hat keine Auswirkung darauf. Ich kontaktiere die Kundin und erfrage weitere Details zur neuen Anforderung und kläre sie, um die Ziele und Erwartungen zu verstehen. Aus den Informationen erstelle ich eine oder mehrere User Stories, die als Vorgänge in unserem Ticketsystem (Jira) festgehalten werden.

Mittwoch (Woche 1):

Wir planen und starten den nächsten Sprint. Die Anfrage vom Montag wird dabei noch nicht in die Plannung aufgenommen. In einer Sprint-Planung werden nur bereits geschätzten Vorgänge berücksichtigt.

Donnerstag (Woche 1):

Beim wöchentlichen Backlog Refinement stelle ich dem Team die neuen User Stories vor. Wir besprechen sie gemeinsam. Anschließend schätzt das Team(!) den voraussichtlichen Aufwand für die Umsetzung.

Es kann vorkommen, das sich während des Backlog Refinements herausstellt, das für eine neue User Story noch nicht ausreichend Informationen vorliegen, um den Aufwand einschätzen zu können. In diesem Fall wird die Aufwandsschätzung verschoben und wir stellen weitere Fragen an die Kundin. Falls die Kundin zum Zeitpunkt unseres Backlog Refinements online erreichbar ist, kontaktieren wir sie – zum Beispiel via Skype – und können die benötigten Informationen sofort einholen.

Anmerkung: Mit den meisten Kunden haben wir Rahmenverträge, die uns befähigen, Anfragen zu Erweiterungen oder Anpassungen ohne neue Angebotsphase umzusetzen. Trotzdem informiere ich unsere Kunden über die Ergebnisse der Aufwandsschätzung. Manchmal ist die Umsetzung eines Features nicht mehr so wichtig, wenn sich herausstellt, dass die Umsetzung einen sehr hohen Aufwand bedeutet.

Dienstag (Woche 2)

Ende des letzten Sprints. Die neuen User Stories haben keine Auswirkung darauf.

Retrospektive: Zum Ende eines Sprints reflektieren wir gemeinsam über die den Verlauf des letzten Sprints. Wie haben wir zusammengearbeitet? Was können wir im nächsten Sprint noch verbessern?

Mittwoch (Woche 2)

Heute beginnt der nächste Sprint mit dem Sprint Planning. Als Product Owner bestimme ich den Fokus der Sprints und entscheide, das an dem neuen Feature unserer Kundin gearbeitet werden soll. Wie viele User Stories im neuen Zyklus umgesetzt werden können entscheidet aber das Team. Der Sprint-Umfang ist abhängig davon, welche Kapazität das Team momentan hat. Ist jemand krank oder im Urlaub, wird der Umfang geringer ausfallen, als bei voller Teamstärke. Unser Scrum Master unterstützt das Team bei der Sprint-Planung. Zum Beispiel erinnert er uns daran, unsere Kapazität nicht zu überschätzen.

Nach dem Termin zur Sprint Planung informiere ich die Kundin über den beschlossenen Sprint-Umfang. Alle User Stories zu der angefragten Erweiterung der Webseite werden im Sprint berücksichtigt.

Donnerstag:

Backlog Refinement

Dienstag (Woche 3)

Letzter Tag des aktuellen Sprints. Heute werden die letzten User Storys des Sprints fertiggestellt. Am Nachmittag haben das Team und ich einen Skype-Termin mit unserer Kundin, bei der wir die umgesetzte Erweiterung der Webseite vorstellen und bei Bedarf nachfolgende Iterationen vereinbaren.

Mittwoch (Woche 3)

Der nächste Sprint startet …

Von der Feature-Anfrage bis zur fertigen Umsetzung hat es 11 Tage gedauert. Zwei Sprints sind zu Ende gegangen, bevor die neuen User Storys angefasst wurden. Warum beginnen wir nicht schneller mit der Umsetzung?

Ein wesentlicher Grund ist unser Anliegen, jedem Projekt(-teil) die gleiche Aufmerksamkeit zu geben. Würden wir laufende Arbeiten für neue Anfragen sofort unterbrechen, wäre die Folge „ältere“ User Stories zu vernachlässigen. Die Auslieferung von früher geplanten Features würde sich verzögern. Ein weiterer Grund für dieses Vorgehen ist die Plannungssicherheit: Wir wollen wissen, womit wir uns in den nächsten Tagen beschäftigen werden. So können wir uns besser auf Themen einlassen und fokussieren. Manchmal braucht die beste Lösung etwas mehr Überlegungszeit. Würden wir ad hoc zu anderen Aufgaben oder Projekten springen, ginge der Fokus schnell verloren und das hätte negative Folgen für die Qualität der Entwicklung.

Wir sind uns sicher: Unser Scrum-Prozess reduziert Stress und verbessert die Qualität unserer Arbeit. Und genau das ist gut für den Erfolg unserer Kunden.

Unsere Prozesse sind nicht in Stein gemeisselt. Finden wir eine neue Idee, unseren Work Flow zu verbessern, probieren wir sie aus. Wenn sie nicht funktioniert, verwerfen wir sie und probieren eine andere.

Mark Engelhardt