Auch wenn Scrum diverse Rollen, Events oder auch Werte empfiehlt, lässt die Vorgehensweise Spielraum für die konkrete Wahl von Tools und Methoden. Während sich Kanban-Boards und User Stories etabliert haben, ist der Einsatz von Enterprise- oder Business Architecture auf Team-Ebene bisher weniger verbreitet. Zu Unrecht, denn Business Architecture kann den Product Owner dabei unterstützen, über den Sprint hinaus die Weiterentwicklung zu planen und dabei die Produkt-Vision und die Einflüsse sowie die Struktur der Backlog Items stets im Auge zu behalten.
Die Visualisierungen helfen zudem dabei, Zusammenhänge zu verstehen und Anpassungen zu kommunizieren.
Der Paradigmenwechsel durch die Agilität hat bei vielen entwickelnden Teams Einzug gehalten. Scrum hat neue Massstäbe gesetzt: Die kurzen Entwicklungszyklen, direkte Kommunikation und kontinuierliche Verbesserungen sind heutzutage kaum mehr wegzudenken. Doch manche Aspekte gingen im Gerangel um Wichtigkeit etwas unter.
Dazu gehören:
- Die (nachhaltige) Dokumentation
- Der Übergang von der Idee zur Implementierung
- Die Planung über einen einzigen Sprint hinaus
Wenn nun Unternehmen sich nicht ganzheitlich zur Agilität bekennen und nur auf Team-Ebene mit Scrum arbeiten, kann zwischen der Unternehmensstrategie und dem Sprint Plan leicht eine Kluft entstehen: McGreal & Jocham nennen diese Kluft das «Product Management Vacuum». Dieses Vakuum führt dazu, dass die beiden Welten kaum ein gegenseitiges Verständnis entwickeln können: Während Business-Stakeholder die Auswirkungen ihrer Wünsche nicht ganzheitlich verstehen, ist es für die Entwickler oft nicht klar, warum sie eine bestimmte Funktionalität überhaupt entwickeln.
Mitten in diesem Vakuum befindet sich der Product Owner, der diese Kluft schliessen will. Zur Verständigung zwischen diesen beiden Welten sagt jedoch ein Bild mehr als tausend Worte. Komplexe Zusammenhänge lassen sich in der Software Entwicklung leichter mit «Boxes & Arrows» darstellen und besprechen als vergleichsweise in reiner Textform.
Auch bei den Aufgaben eines Product Owners können Visualisierungen helfen, sei es zur Kommunikation, Planung oder Dokumentation.
Mit «Enterprise Architecture» lässt sich grundsätzlich das ganze Unternehmen abbilden und beinhaltet eine Vielzahl von Modellen und Techniken. Ein Teilbereich der Enterprise Architecture - die «Business Architecture» (nach TOGAF) – fokussiert sich auf Elemente wie Geschäftsprozesse, Stakeholder oder Ziele. Entsprechend decken sich diese Elemente mit der Sprache des Product Owners, und überlässt das Solution Design bewusst den Entwicklern. Für den Product Owner ist es fundamental zu verstehen, wie etwas aktuell funktioniert, um den Wert und die Risiken einer Veränderung abschätzen zu können.
Um den Wert eines Produkts zu maximieren und den inkrementellen Weg zur Vision zu planen, braucht es Übersicht und Weitsicht – auch in einer agilen Welt und trotz Zeitdruck. Viele Aspekte und Abhängigkeiten beeinflussen die Weiterentwicklung des Produkts über einen Sprint hinaus. Die Anwendung von «User Story Maps» mag dabei zwar eine mittelfristige Perspektive aufzeigen, bedingt aber einerseits thematisch kohärente User Stories und zeigt zudem nur ungenügend den Einfluss auf das bereits bestehende Produkt auf. Durch die Modellierungstechniken der Business Architecture lässt sich ein individualisiertes Modell erstellen, welches die Bedürfnisse des Product Owners und die Ausprägungen des Produkts ideal abdeckt.
Um beispielhaft die Möglichkeiten dieser Modellierungstechniken aufzuzeigen, wurde eine Grundstruktur definiert, welche insbesondere dem Product Owner hilft, bei einem sich stetig ändernden Umfeld und Produkt nachhaltig die Übersicht zu behalten. Im folgenden Diagramm sieht man eine mögliche Struktur mit vier miteinander verbundenen Schichten:
- «Product Management»: Hier wird die Vision des Produkts beschrieben, sowie Faktoren, welche diese beeinflussen sowie Ziele, die sich daraus ableiten.
- «Users»: In der zweiten Schicht werden unterschiedliche Benutzer (-Gruppen) beschrieben, sowie ihre Charakteristiken und Berechtigungen.
- «Channels»: In der nächsten Schicht wird beschrieben, über welche Kanäle die Benutzer mit dem Produkt interagieren und wie diese Kanäle ausgestaltet sind.
- «Capabilities»: In der letzten Schicht wird das eigentliche Produkt und seine Funktionen beschrieben. Dazu gehören auch Abhängigkeiten oder Business Rules.
Die Grundstruktur sowie deren benötigte Komplexität ist natürlich je nach Produkt individuell. Die Elemente der Struktur können dann in angemessener Flughöhe beschrieben und als nachhaltige Dokumentation verwaltet werden. Wie es Produkt-Entwicklungen so an sich haben, wird das Produkt nicht so bleiben. Aber auch für Veränderungen ist die beschriebene Grundstruktur gewappnet:«Epics» oder andere Backlog Items lassen sich gut auf die Struktur legen (sozusagen als “Overlay”)um die Prioritäten und Impacts aufdie Roadmap transparent zu machen. Sobald ein Epic die «Definition of Done» erreicht, wird das darunterliegende Element angepasst.
Durch den präsentierten Ansatz lassen sich diverse Herausforderungen eines Product Owners auf einmal angehen:
- Big Picture: Alle inhaltlich relevanten Aspekte für den Product Owner sind abgedeckt. Zudem ermöglicht die Verbindung des Produkts mit der Vision und Zielen (oberste der vier Schichten) den Mehrwert der einzelnen Entwicklungen transparenter zu machen.
- Roadmap: Das Overlay der Backlog Items visualisiert welche Elemente des bestehenden Produkts betroffen sind. Dadurch können Prioritäten, Abhängigkeiten und Zusammenhänge identifiziert werden.
- Slicing: Durch die Struktur des Ansatzes lassen sich Backlog Items ideal darauf platzieren und zerteilen («slicen»), ohne dass unnötige Abhängigkeiten geschaffen werden
- Nachhaltige Dokumentation: Die Struktur gibt die Flughöhe vor und zeigt an, wann (“Definition of Done”) die Beschreibung für ein Element anzupassen ist
- Visualisierung: Die visuelle Natur der gezeigten Struktur erleichtert die Kommunikation mit Business-Stakeholdern oder Entwicklern
Diese Vorteile werden bei bestehenden Tools und Methoden zum Backlog-Management oft vernachlässigt, weswegen der dargelegte Ansatz diese bestehenden Instrumente ideal ergänzt. Die hochgradige Individualisierbarkeit ermöglicht es Ihnen, Ihr Produkt nach Ihren Bedürfnissen zu gestalten. Modellieren Sie ihr Produkt!
