Immer am Puls des Kunden mit dem agilen Projektmanagement Scrum

Scrum – Was ist eigentlich Scrum?

Scrum verlangt den regelmäßigen, in kurzen Abständen wiederkehrenden Austausch zwischen Auftragnehmer und Auftraggeber in Form von Feedback-Schleifen. „Grob erklärt funktioniert das so: Der Kunde sagt uns, was er sich wünscht. Wir legen dann eine Zeitspanne fest, den sogenannten Sprint, innerhalb derer ein bestimmtes Sprintziel erreicht werden soll. Wichtig ist, dass am Ende eines jeden Sprints quasi eine funktionierende Mini-Version dessen steht, was sich der Kunde gewünscht hat und was der Kunde prüfen kann. Auf diese Weise kann der Kunde frühzeitig Feedback geben, ob unsere Entwicklung in die richtige Richtung läuft oder vielleicht etwas verbessert werden muss“, erläutert Jana Cervinka, Scrum Master bei der PROMOS consult.

Die zur Verfügung gestellten Mini-Versionen werden auch Inkremente genannt und das Vorgehen beruht auf dem „Minimum Viable Product“ Ansatz (siehe Abbildung 1). Dieser bietet dem Kunden Transparenz über den aktuellen Stand und ermöglicht es, Feedback frühzeitig einzuholen, so dass die Rückmeldung des Kunden in der kommenden Entwicklung berücksichtigt werden kann. Durch den kontinuierlichen Abgleich zwischen dem IST-Zustand und den Erwartungen werden unnötige Entwicklungen schnell identifiziert und die eingesparte Zeit wird in Anforderungen investiert, die dem Kunden einen echten Mehrwert bringen. Nachträgliche Change Requests (CRs) zu umgesetzten Features werden damit unnötig und verursachen keine Kosten.

Die Beteiligten – Wer spielt alles eine Rolle?

Scrum gibt den Projektbeteiligten eine Rahmenstruktur vor, innerhalb derer sie sich Schritt für Schritt an die Anforderungen des Kunden heranarbeiten. Zu diesem Rahmen zählen unter anderem vordefinierte Rollen, welche die Aufgabenbereiche innerhalb des Teams definieren. Dazu gehören die Rolle des Product Owners, Scrum Masters und des Entwicklerteams. Der Product Owner hat die Wertmaximierung des Produkts zum Ziel und trägt die Verantwortung für das Produkt. Er entscheidet Was und Wann umgesetzt wird. Hierunter fällt alles Fachliche. Er schützt das Team vor äußeren Einflüssen und dient gleichzeitig den Stakeholdern als Ansprechpartner. Der Scrum Master ist ein Bindeglied im Scrum-Team. Sein Ziel ist die Steigerung der Effizienz durch die Umsetzung der Scrum Prinzipien. Hierfür versucht er, die Zusammenarbeit zu optimieren und eine ideale Arbeitsumgebung zu schaffen. Während der Product Owner für das Was verantwortlich ist, wird das Wie vom Entwicklungsteam entschieden. Sein Hauptaugenmerk liegt auf der Erreichung des Sprintziels. Cervinka erklärt den Vorteil der genauen Aufgabenverteilung: „Abgeschirmt durch den Product Owner ist es dem Team möglich, fokussiert und selbstorganisiert zu arbeiten. In kürzester Zeit wird ein den Kundenwünschen entsprechendes Resultat geliefert.“

Product Backlog – Wo und wie werden die Anforderungen des Kunden gesammelt?

Neben den in Scrum festgelegten Rollen gibt die Rahmenstruktur zudem sogenannte Artefakte vor. Cervinka erläutert: „Artefakte können im Rahmen von Scrum als Arbeitsergebnisse verstanden werden. Das wichtigste Artefakt ist das Entwicklungsergebnis selbst, welches nach jedem Sprint zur Verfügung steht. Ein weiteres Arbeitsergebnis in Scrum ist eine Art Logbuch, was geführt wird, um alle Anforderungen des Kunden zu sammeln, zu priorisieren und zu schätzen. Bei diesem sogenannten Product Backlog handelt sich um eine priorisierte Liste von Anforderungen an das Produkt, welches fortlaufend vom Product Owner erweitert und angepasst wird. Es hilft dabei, zu jedem Zeitpunkt des Projekts zum einen auf die Kundenwünsche einzugehen und uns zum anderen auf die wesentlichen Produkteigenschaften zu konzentrieren.“ Unterstützt wird dieses Denken durch die Art der Formulierung der Anforderungen. Diese erfolgt in sogenannten User Stories nach dem Schema: „Als [Rolle] möchte ich [Funktion], damit [Geschäftswert].“ So könnte eine User Story im Bereich der Produktentwicklung in easysquare beispielsweise lauten: „Als Mieter möchte ich mich in der easysquare Mieter-App registrieren, um meine Betriebskostenabrechnung einzusehen.“ Das Product Backlog ist nicht final und entwickelt sich im Laufe des Projekts weiter (siehe Abbildung 2). Die User Stories werden vom Product Owner regelmäßig verfeinert oder entsprechend der Kundenbedürfnisse verändert.

Sprint Planning – Wird in Scrum wirklich gerannt?

Ein Sprint hat je nach Projekt eine gleichbleibende Dauer von ein bis vier Wochen und beginnt mit dem Sprint Planning. Bei diesem Meeting wird der Sprintplan festgelegt. Der Product Owner präsentiert die geplanten User Stories für den bevorstehenden Sprint und das Entwicklungsteam stellt Fragen. Im Laufe der Diskussion werden die User Stories konkretisiert und die Akzeptanzkritierien zur Abnahme der Anforderung erläutert. Orientiert an der Priorisierung durch den Product Owner und der Komplexität der User Stories entscheidet das Entwicklungsteam, wie viele User Stories in den Sprintplan aufgenommen werden. In den Sprintplan aufgenommene User Stories sind final und werden während des Sprints nicht geändert.

Der Daily Scrum – Wie stimmen sich die Entwickler ab?

Im Laufe eines Sprints stimmen sich die Entwickler jeden Morgen im Daily Scrum ab. Hierbei kommt das Sprint Taskboard zum Einsatz, an dem der aktuelle Arbeitsstand der Entwicklung gepflegt wird. „Software-Entwickler werden häufig mit dem Bild des stillen Einzelkämpfers assoziiert. Das allmorgendliche Meeting verhindert solche Szenarien und ermöglicht dem Team, Probleme anzusprechen, gemeinsam Lösungen zu finden und das gewonnene Know-how auszutauschen. Wir haben mit diesem Vorgehen ausschließlich positive Erfahrungen gemacht“, stellt Cervinka rückblickend fest.

Das Sprint Review – Haben wir alles geschafft?

Zum Ende des Sprints findet das Sprint Review statt, in dem das Entwicklungsteam die umgesetzten User Stories präsentiert. Der Product Owner prüft, ob die Akzeptanzkriterien zur Abnahme erfüllt wurden und nimmt die User Stories ab. Während der Präsentation kann zu den Anforderungen Feedback gegeben werden, welches in das Product Backlog einfließt. „Das Sprintergebnis, also die funktionierende Mini-Version der Software, enthält alle bis dato umgesetzten User Stories und wird dem Kunden zur Verfügung gestellt“, fasst Cervinka zusammen.

Die Retrospektive – Was können wir besser machen?

Nach Abschluss des Sprint Reviews absolviert das Scrum-Team eine Retrospektive. Bei diesem Meeting reflektiert das Team den Sprint. Was ist gut gelaufen und was kann verbessert werden? Positive Erfahrungen können in der Zukunft intensiviert werden oder als Orientierungshilfen dienen. Sollten Probleme im Sprint aufgetreten sein, so wird versucht, die Ursachen zu analysieren und Maßnahmen zur Lösung oder Vorbeugung zu finden. Die regelmäßige Reflektion des Produkts und des Vorgehens zum Ende eines jeden Sprints führen zu einer kontinuierlichen Verbesserung im Projekt.

Fazit – Alles in Butter mit Scrum?

Scrum ermöglicht eine Entlastung auf allen Ebenen. Durch die intensive Auseinandersetzung mit den Anforderungen und die Einbeziehung des Kunden werden Kosten in Fehlentwicklungen minimiert. Dem Kunden wird ein Produkt geliefert, das seinen Anforderungen entspricht. Da das Reagieren auf Veränderungen zu Scrum gehört, können zeitgerecht Maßnahmen ergriffen werden. Die gewonnene Zeit wird in Entwicklungen investiert, die Mehrwerte bringen. Zum jetzigen Zeitpunkt kommt Scrum in der Vermietung, der App Family und dem Projekt EXAD 2.0 bei PROMOS zum Einsatz.

redaktion@openpromos.de