Ziellos?

Kann eine Methode, die sich schon so weit etabliert hat und bei so vielen Unternehmen standardmäßig eingesetzt wird, ziellos sein? Klar, die Frage ist rhetorisch und die Antwort lautet nein. „Agil heißt nur, immer das zu machen, was gerade sinnvoll erscheint“, ist der typische Einwand der Skeptiker. Und ja, das stimmt, und genau aus diesem Ansatz sind die agilen Regeln entstanden. Und mit genau diesen Regeln kann man sich gegen Ziel-Erfüllung gar nicht mehr wehren.

Was nicht mit Ziellosigkeit zu verwechseln ist: Krampfhaft an einem aufgestellten Plan festzuhalten, ungeachtet, was sich im Laufe der Produktentwicklung an Änderungsnotwendigkeiten ergibt. Eine agile Vorgehensweise hat ganz klar das Ziel, das Beste für den Kunden zu erreichen. Und innerhalb des agilen Rahmens haben wir die Möglichkeit, die Antwort auf die Frage „Was ist das Beste für den Kunden?“ immer wieder neu zu justieren und aus den Erfahrungen aus der Entwicklung und von außen getriebenen Gegebenheiten und Veränderungen anzupassen.

Änderungen sind willkommen! Je früher wir von notwendigen Änderungen wissen, umso schneller können wir reagieren und das Produkt adaptieren. Verschwendung in Form von auf-Falschem-aufbauen und nachträglich-reparieren entsteht gar nicht erst. Wenn Scheitern dran ist, scheitern Sie schnell! Denn dann können Sie schnell lernen und es umso schneller richtig machen.

Ziel-Erfüllung

Doch warum ist denn nun eine agile Vorgehensweise so hilfreich für die Ziel-Erfüllung?

Voraussetzung für den Start eines agilen Projektes ist eine Produktvision. Jemand glaubt daran, dass eine bestimmte Zielgruppe bestimmte Bedürfnisse hat, die von einem Produkt mit bestimmten Funktionalitäten befriedigt werden können. Auf Basis solch einer Produktvision werden die sogenannten Epics formuliert. Epics beschreiben ganz grobgranular die gewünschten Funktionalitäten des Produktes. Auf Basis der Epics kann ein passendes Team den Aufwand grob schätzen und gemeinsam mit dem Product Owner einen ersten Releaseplan entwerfen. Das Ziel ist angepeilt – wir haben eine grobe Vorstellung von unserem Produkt, den Kosten und der Entwicklungsdauer – zum aktuellen Zeitpunkt.

Einigt man sich auf die Umsetzung, so werden die wichtigsten Epics feiner spezifiziert und in Stories zerteilt. Auf Basis dieser Stories kann man dann schon in Sprint 1 mit der Entwicklung beginnen.

Der Zielerfüllungskreislauf

Und nun beginnt der Zielerfüllungskreislauf. Nach den ersten Sprints sind die ersten Stories umgesetzt. Product Owner und Team haben erfahren, wie viel Arbeit für die Umsetzung der Stories anfällt. Sie haben ein Gefühl für die Umsetzungsgeschwindigkeit bekommen und können nun die verbleibenden Epics neu und besser einschätzen. Der Releaseplan kann angepasst werden und ist nun ein Stück genauer. Mit jedem Sprint kennt das Team das Produkt und dessen Entwicklungsinfrastruktur besser und bald kann es seine Vorhersagen auf Basis konkreter Erfahrungen am aktuellen Projekt machen und muss sich nicht auf Vor-Erfahrungen aus anderen Zusammenhängen verlassen.

Nach den ersten Sprints haben sich bereits die größten Risiken und Machbarkeitsvoraussetzungen gezeigt. So kann man sich auf einen Releaseplan, der ein paar Sprints gereift ist, immer mehr verlassen. Mit jedem Sprint lernen Product Owner und Team dazu und können immer genauer prognostizieren. Das Vertrauen in das Produkt und in das Vorgehen wachsen. Das Ziel wird immer greifbarer. Und es wird ständig einer Prüfung unterzogen. Bei jedem Review sehen Product Owner und Stakeholder das Produkt in seiner aktuellen Reife. Und nach jedem Review haben sie ein Produktteil, das sie potenziell schon nutzen können.

Wenn Ihnen im Review auffällt, dass Sie bzgl. der Funktionalitäten das eine gar nicht mehr brauchen, das andere modifizieren wollen oder auch etwas ganz Neues hinzufügen möchten, so ist das jederzeit möglich. Änderungen sind willkommen. Sie können das Backlog anpassen und im nächsten Sprint schon den neuen Kurs einschlagen. Den Releaseplan können Sie ebenfalls anpassen, und dieser spiegelt dann sofort wider, wie das Projekt voraussichtlich weiter geht. Das Produktziel hat sich geändert, aber auf die Kundenwünsche konnten Sie dank des iterativen Rahmenwerkes sofort eingehen. Vom Ziel Kundenzufriedenheit sind Sie keinen Millimeter abgewichen.

Fokus

Das agile Rahmenwerk macht es schwer, den Fokus nicht ständig auf das Ziel des Projektes zu halten. Zu Beginn jedes Sprints einigen sich Product Owner und Team auf das Sprintziel und formulieren es. Jedes Sprintziel ist ein kleines Geschwister von Vision und Gesamtziel. Beim Review wird der jeweilige Stand des Produktes begutachtet und in Hinblick auf das gewünschte Endprodukt bewertet.

Tipps & Tricks für den Ziel-Fokus

• Einigen sie sich vor jedem Sprint auf ein Sprintziel und formulieren Sie es.
• Führen Sie einen Releaseplan.
• Passen Sie den Releaseplan regelmäßig an. Der Releaseplan lebt und sollte nach neuen Erkenntnissen z. B. aus Estimation Meetings oder Reviews immer auf dem aktuellen Stand sein.
• Holen Sie sich echtes Feedback in den Reviews. Nur wer das zu erstellende Produkt tatsächlich nutzt, kann auch wirklich rückmelden, ob gerade das Richtige entwickelt wird.
• Heißen Sie Änderungen im Releaseplan willkommen. Je früher Änderungen bekannt sind, umso besser. Das darf und soll sich auch im Releaseplan zeigen.
• Bei Änderungs- oder neuen Anforderungen ziehen Sie immer die Teammitglieder hinzu, um ein realistisches Gefühl bzgl. Inhalt, Umfang und Ausmaß zu bekommen.
• Seien Sie sich bewusst, dass die frühen Teile des Plans ja schon fertig umgesetzt sind, mit all ihrer Integrität und in der Produktivsetzung bewiesenen Qualität. Das macht froh!

Fazit

Agil heißt alles andere als ziellos. Agil arbeiten heißt vielmehr, sich mit einem Rahmenwerk zu umgeben, welches ständig dazu einlädt, den Fokus immer wieder auf das Ziel zu richten. So ist die Verschwendung gering und die Effizienz hoch. Man produziert, was wirklich gebraucht wird. Und das ist Erfolg und macht Spaß.