5 Gründe, warum Ziele wichtig in der agilen Softwareentwicklung sind
Unternehmen setzen heute in der Softwareentwicklung selbstverständlich auf agile Methoden, machen sich jedoch häufig nicht klar, welche Bedeutung einer präzisen Zielsetzung zukommt. Dieser Artikel zeigt auf, dass Ziele im agilen Kontext gerade in Hinblick auf Scrum relevant und möglich sind, wie die Zielsetzungen in der Praxis erfolgen können und welche Vorteile sich daraus für Sie als Unternehmen ergeben.
1. Das Verfolgen eines Ziel macht ein Produkt langfristig zum Erfolg
Das Product Backlog erfasst in einer Liste anfänglich nur die grundlegenden und bekannten Anforderungen einer Produktvision, erfährt jedoch ganz nach dem Motto "Der Product Backlog lebt" während der Verwendung eine kontinuierliche Verbesserung. Das Backlog ist dynamisch und nimmt veränderte Anforderungen auf, die sich während der Entwicklungstätigkeit ergeben. Zur Liste gehören Funktionen, Anwendungsfälle oder Verbesserungen und Fehlerbehebungen.
Verantwortlich für die Pflege und Weiterentwicklung des Product Backlogs ist der Product Owner. Das Ziel seiner Tätigkeit ist den langfristigen Erfolg eines Produkts auf Basis der Poduktvision zu gewährleisten.
Damit dies gelingt, muss er wissen, was für sein Produkt langfristiger Erfolg bedeutet. Im Scrum Framework wird das Ziel häufig als "Wertschöpfung" bezeichnet. Der Product Owner sollte also ein Ziel definieren, das für sein Produkt Wertschöpfung bedeutet. Was will er erreichen? Dies können je nach Produkt beispielsweise "Umsatz generieren" oder auch "effiziente interne Prozesse sein" sein.
Das Ziel eines Produkt Backlogs sollte SMART sein:
Specific: Es ist spezifisch und damit so eindeutig wie möglich formuliert.
Measurable: Es liegen klar definierte Messbarkeitskriterien vor.
Achievable: Das Ziel sollte mit dem Team und seinen jeweiligen Fähigkeiten tatsächlich erreichbar sein.
Reasonable: Es muss sich um ein realistisches bzw. realisierbares Ziel handeln.
Time-bound: Die Realisierung muss im vorgegebenen zeitlichen Rahmen möglich sein.
2. Die Arbeit mit Zielen gibt Scrum-Teams eine Richtung für den Sprint
Das Scrum-Teams setzt sich sein Ziel für jeden Sprint im Sprint Planning. Je nach Sprintrhythmus wird alle paar Wochen ein neues Ziel für den kommenden Sprint definiert.
Der Ideengeber für ein Sprint Ziel ist der Product Owner, der das gewünschte Sprint Ziel von seiner ganzheitlichen Produktvision ableitet. Dementsprechend überlegt er sich vor jedem Sprint Planning, was er im nächsten Sprint erreichen möchte.
Mit seinem Wunsch gibt er dem Entwicklungsteam eine Richtung vor, die dann im nächsten Schritt vom Team auf realistische Machbarkeit geprüft wird. Kann der Wunsch des Product Owners umgesetzt werden, dann ist das Sprint Ziel somit definiert.
Ist es in der Zeit nicht umsetzbar, wird gemeinsam während des Sprint Plannings ein Ziel formuliert, das realistisch ist. Als Metrik zur Überprüfung, was realistisch ist und was nicht, dient die Velocity eines Teams.
Vier Schritte führen zum Sprint Ziel
Folgende Schritte gehören typischerweise zur Formulierung der Ziele in einem Sprint Planning:
1. Zuerst präsentiert der Product Owner das Ziel, das er gerne in dem Sprint umsetzen möchte.
2. Das Entwicklungsteam ermittelt, welche User Stories dazu umgesetzt werden müssen und gleicht den Aufwand anhand ihrer verfügbaren Velocity ab. Ist das Ziel realistisch?
3. Ist das Ziel realistisch, wird es angenommen. Ist es nicht angenommen, muss im gesamten Scrum Team ein Kompromiss gefunden werden. Dabei hat der Product Owner jederzeit die Möglichkeit, ein neues Sprintziel auf Basis der neuen Informationen vorzuschlagen.
Typische Beispiele für im Sprint zu erreichende Ziele
Wichtig ist, dass die Ziele kurz und präzise formuliert sind und jedes Teammitglied sofort versteht, was als Nächstes zu tun ist. Denkbar sind folgende Beispiele für Sprint Goals:
"Eine Funktion soll überprüfen, ob der Benutzer sich vor der Nutzung des Produkts registriert hat."
"Das Design des Produkts soll zum Corporate Design passen."
"Reduzierung der durchschnittlichen Ladezeit, bevor der Nutzer Zugang zum Produkt erhält."
Typisch ist, dass neue Ziele an vorherige anschließen. Im Falle der Überprüfung der Nutzerregistrierung könnte zum Beispiel ein weiteres Sprint Ziel anschließen, das die Optimierung der Registrierungsfunktion vorsieht. Häufig bauen die Ziele also aufeinander auf, insofern sie für den Product Owner langfristig zu den Produktzielen passen.
3. Erfolg wird durch Ziele messbar
Ist für ein Produkt klar definiert, was das Ziel ist und ist innerhalb eines Sprints klar, was erreicht werden soll, dann ist dem Team auch bewusst, wenn sie es erreicht haben.
Jeder kennt das Gefühl ein Ziel erreicht zu haben: Man ist stolz, glücklich und motiviert, die nächsten Schritte zu gehen. Diesen Effekt sollte man auch in der Softwareentwicklung nicht unterschätzen.
Die Messbarkeit erstreckt sich allerdings noch weiter bis auf User Story-Ebene. Auch hier ist es wichtig zu definieren, wann eine User Story fertig bearbeitet worden ist, damit man sie abschließen kann und sich der nächsten Story widmen kann.
Eine Chance der Messbarkeit liegt aber auch im Gegenteil von Erfolg. So wird durch diese natürlich auch ersichtlich, wenn ein Team einen Misserfolg erlebt hat. Ist dies der Fall, dann gibt es aber keinen Grund den Kopf in den Sand zu stecken. Es ist vielmehr die Gelegenheit den eigenen Arbeitsprozess genauer zu analysieren und zu hinterfragen, warum ein Ziel nicht erreicht worden ist. So können Gegenmaßnahmen definiert werden, damit das Team im nächsten Sprint wieder Erfolge feiern kann.
4. Ein Scrum-Team mit Zielen kann sich besser selbst managen
Setzt sich ein Scrum-Team in der Entwicklung keine Ziele, kann es im Team schell zu Missverständnissen, Konfusion und Aktionismus kommen. Es mangelt dann an einem gemeinsamen Verständnis. Das kann im im schlimmsten Fall dazu führen, dass am Ende eines Sprint kein wirkliches Ergebnis präsentiert werden kann.
Das Ziel ermöglicht es jedem Teammitglied zu prüfen, ob das gesamte Team auf Kurs ist, und selbst sein Bestes geben, um das Ziel zu erreichen.
Innerhalb des Sprints dient das Daily dazu, täglich im Team sicherzustellen, dass weiterhin am Sprint Ziel gearbeitet wird, und zu prüfen, ob irgendetwas darauf hindeutet, dass das Ziel nicht erreicht werden kann. Werden dafür Hinweise im Daily entdeckt, kann das Teams schnellstmöglich darauf reagieren, so dass das Ziel wieder erreicht werden kann.
5. Ziele ermöglichen Konzentration auf das Wesentliche und eine emotionale Verbindung
Die Ziele sollten für das Unternehmen, dem Product Owner und dem Entwicklungsteam wichtig und wesentlich sein. So muss der Mehrwert klar erkennbar sein. Hier geht es also nicht um die Realisierbarkeit, sondern die Bedeutung des Ziels. Bedeutet eine neue Funktion zum Beispiel, dass der Nutzer von einem höheren Komfort profitiert oder sich eine stärkere Kundenbindung einstellt? Diese Fragen gilt es zu beantworten, um das Team wirklich den Grund zu geben, mit höchster Motivation an dem Produkt zu arbeiten.
Das Ziel schafft aber auch die Möglichkeit, Tätigkeiten und Aufgaben zu priorisieren und ggfs. sogar ganz zu streichen. Zahlt eine User Story innerhalb eines Product Backlogs nur wenig auf das Produktziel ein, so wird der Product Owner diese wahrscheinlich relativ weit unten in der Liste priorisieren.
Ebenso verhält es sich während des Sprints im Entwicklungsteam. Aufgaben, die weniger dazu beitragen das Sprint Ziel zu erreichen, werden erst nach den Themen eingeplant, die für die Zielerreichung unabdingbar sind.
Die Zusammenstellung in diesem Artikel macht deutlich, wie wertvoll die Formulierung von Zielen ist. Sie geben Orientierung und machen Entscheidungen einfacher. Sie sorgen dafür, dass ein Team gemeinsam an einem Strang zieht. Abschließend gilt es daher nur noch anzumerken, dass das Geheimnis einer Zielformulierung allerdings nicht darin liegt ein Ziel zu formulieren, sondern es über einen längeren Zeitraum konsequent zu verfolgen. Erst dann zeigt das Ziel seinen wahren Wert.
