Agile Produktplanung – Einblick in ein Projekt | 1/2

Die Art und Weise wie wir Software entwickeln, hat sich über die Jahre enorm verändert. Umfangreiche Fachkonzepte gehören der Vergangenheit an. Detaillierte Projektpläne, die jegliche Details von A bis Z für die Umsetzung vorgeben, sind nicht mehr erwünscht. Vielmehr geht es heutzutage darum, die Idee und die Vision für die Software zu vermitteln. Es geht darum die Menschen mit der Vision mitzureißen, die an der Entwicklung beteiligt sind. Und dann mit agilen Mitteln auf die Vision hinzuarbeiten.

Wir geben Dir in unserem Blogbeitrag exklusive Einblicke in eines unserer Projekte und zeigen, wie Du es dadurch schaffst, in einem agilen Umfeld mit Deinem Team einen belastbaren und gleichzeitig flexiblen Plan zu erstellen. Ein Plan, der den Stakeholdern als Orientierung dient und dem Projektteam die richtige Richtung weist.

Wir stellen vor – das Projekt mit seinen Rahmenbedingungen

Viele Softwaresysteme wachsen über die Zeit, verändern sich und kommen schließlich in die Jahre. Eine Neuentwicklung ist häufig der letzte, aber sinnvollste Schritt. In unserem konkreten Fall sollen vier bestehende Legacy Systeme durch genau ein neu zu entwickelndes System abgelöst werden. Damit sind der Scope und das fachliche Ziel für das Projektvorhaben schon weitestgehend bekannt. Dennoch ist die Fachlichkeit für die Neuentwicklung noch nicht komplett durchdrungen, denn es sind umfangreiche Gesetze und Regeln zu berücksichtigen und in der Software zu implementieren.

Auf der technologischen Ebene ist das System vollständig mit neuen und zum Zeitpunkt üblichen Technologien umzusetzen. Um nur einen kleinen Auszug zu nennen: Im Backend sollen Microservices sowie asynchrone Kommunikation mittels Kafka implementiert werden. Das Frontend wird mit Hilfe von Angular entwickelt. Und für ein kontinuierliches Deployment der Microservices in eine Container-Umgebung sind DevOps-Techniken zu nutzen.

Die Entwicklung erfolgt mit durchschnittlich vier agilen Teams, bestehend aus 7-8 Teammitgliedern und jeweils einem Product Owner. Die Teams werden nach Nexus skaliert. Als Vorgehensweise wird Scrum mit 2-Wochen-Sprints gewählt. Zu Beginn kennen sich die Teammitglieder untereinander nur teilweise. Zusätzlich kennt der Großteil der Teammitglieder – bis auf ein paar Domain Experten – die umzusetzende Fachlichkeit noch nicht.

Die agile Planung im Projekt – 3 Schritte sind entscheidend

Als weitere Rahmenbedingung hat der Auftraggeber feste Releasezeitpunkte definiert. Zu diesen Zeitpunkten soll ein bestimmtes Featureset in der Software vorhanden sein. Somit ist es also nur möglich, über den Scope des umzusetzenden Software-Produktes zu diskutieren, nicht aber über den Zeitplan. Doch wie schafft man es, dass das gesamte Team fokussiert auf das Ziel die richtigen Dinge tut? Folgende Schritte sehen wir als erfolgversprechend an, damit die Neuentwicklung nicht im luftleeren Raum ohne maßgebende Vision und sinnvolle Aufgabenpakete passiert.

1. Die Teams und die Stakeholder müssen über das zu entwickelnde Produkt übereinkommen. Das bedeutet, dass die Ziele und die Vision für das Produkt gemeinsam festgelegt werden müssen. 

2. Als nächstes muss der Scope klar abgegrenzt werden. Es sind einzelne kleinere Teile zu identifizieren, die umgesetzt werden sollen. Wir füllen in diesem Schritt also das Backlog. Die Backlog-Items werden priorisiert und geschätzt. 

3. Das so entstehende Backlog ist die Grundlage für den Releaseplan. Und hier hat die Velocity eine maßgebliche Bedeutung.

Im nächsten Teil werfen wir einen genaueren Blick auf die einzelnen Schritte.

Vision und Scope führen zur ersten agilen Planung

An sich arbeitet niemand gerne ohne ein Ziel. Und auch das Team soll jederzeit wissen, was es wofür tut. Hierfür ist es notwendig, dass eine Produktvision entsteht, die für jeden in den Scrum Teams einsehbar ist. Bei Klärungssituationen kann sie herangezogen werden und beim Onboarding neuer Teammitglieder helfen.

Damit die Akzeptanz und das Verständnis für die Produktvision von Anfang an vorhanden sind, entsteht die Produktvision nicht im Elfenbeinturm. Vielmehr stehen für uns das gesamte Team und die Stakeholder im Zentrum des Handelns. Stakeholder sind für uns nicht nur die Auftraggeber. Stakeholder sind auch Fachbereichsvertreter, die stellvertretend für die Anwender des Produktes stehen. Und ganz wichtig: Zusätzlich involvieren wir in dieser Phase bestimmte Vertreter aus den Scrum Teams, wie den Product Owner sowie technische und fachliche Architekten.

In dieser kleinen Runde erarbeiten wir mithilfe von mehreren Workshops die erste gemeinsame Produktvision. Ein weiterer Effekt bei diesem Vorgehen ist auch, dass die Produktvision bereits wichtige Eckpfeiler bzw. Rahmenbedingungen der technischen Architektur berücksichtigt. Wir erinnern uns, dass neue Technologien zum Einsatz kommen sollen, welche teilweise erprobt werden müssen. Jeder Beteiligte hat also gleichermaßen die Chance, seinen Fokus einzubringen – denn am Ende wollen alle ein ausführbares Produkt erhalten.

Da wir so aber noch nicht konkret definiert haben, welcher Funktionsumfang wirklich pro Release vorliegen soll, gehen wir noch einen Schritt weiter. Wir zerlegen die Vision und bestimmen für jedes Release eine eigene Produktvision. Die Ergebnisse werden zentral für alle Teammitglieder in einem Knowledge-System abgelegt.

Die Produktvisionen können uns nun schon als Leitstern für die Entwicklung dienen. Das ist schön und gut – und dennoch nicht genug.

Der fachliche Prozess – die Basis, um alle Tätigkeiten auszurichten

Die Produktvision eines jeden Releases muss weiter verfeinert werden, damit wir den Teammitgliedern etwas Konkretes an die Hand geben können. Deshalb schauen wir uns den fachlichen Prozess genauer an. In dem gleichen Arbeitsteam wie für die Erarbeitung der Produktvision analysieren wir in mehreren Event-Storming-Sessions die High-Level-Ebene des fachlichen Prozesses. Die Sessions helfen uns auf natürliche Art und Weise ein gemeinsames Verständnis über das Produkt aufzubauen. Sie helfen uns auch den gemeinsamen Sprachgebrauch (die sogenannte Ubiquituous Language) festzulegen. Außerdem bilden die Sessions die Basis für einen ersten Schnitt und eine erste Abgrenzung der Microservices gegeneinander.

Jedoch am wichtigsten für die agile Planung ist in dieser Phase, dass wir den fachlichen Prozess von Anfang bis Ende durchdenken. Die Ausführbarkeit des Prozesses im sogenannten Happy Path soll im Blick bleiben. Pro fachlichem Prozessschritt identifizieren wir die fachlichen Themen, die mit diesem in Verbindung stehen. Um nicht im eigenen Handeln zu stolpern, lassen wir bewusst Varianten und Fehlerfälle außen vor. Falls diese maßgeblich für den Produkterfolg sind, parken wir sie in einem Bereich und schauen sie uns später erneut an.

Wir wiederholen die Analyse des fachlichen Prozesses in weiteren Sessions, verfeinern die fachlichen Themen und schneiden sie kleiner. Wir konzentrieren uns dabei immer mehr auf das MVP für ein Release – also auf ein Minimum Viable Product. Dafür nehmen wir pro Release die Produktvision als Basis und identifizieren die fachlichen Themen, die auf diese Produktvision einzahlen. Alle Themen, die nicht darauf einzahlen, werden nicht berücksichtigt und kommen erst später in der Entwicklung dran.

Und noch ein Wort zwischendurch zur Heterogenität der Arbeitsgruppe: Diese ist klar von Vorteil. Denn auch in dieser Phase ist es wichtig, dass die technischen Architekten das Verständnis schärfen, welche Themen zum MVP gehören müssen, da mit ihnen neue Technologien erprobt werden müssen. Eine zu späte Erprobung könnte den Projekterfolg negativ beeinflussen.

Am Ende der Event-Storming-Sessions erhalten wir pro Release ein Minimum Viable Product. Jedes MVP durchläuft den fachlichen Prozess von Anfang bis Ende. Und pro fachlichem Prozessschritt kennen wir für jedes einzelne MVP die fachlichen Themen. Diese haben mittlerweile die Detaillierungsebene eines Epics erreicht, mit denen die Scrum Teams weiterarbeiten und im Sinne der Agilität planen können. Die Epics werden in einem Backlog für die Scrum Teams transparent festgehalten.

Wie das Projekt weiter verläuft, verraten wir Dir in unserem zweiten Blogbeitrag „Agile Produktplanung – Vom Backlog zum Forecast“.