Value Maps für Agile Entwicklung

Agiles Arbeiten braucht eine konsequente Ausrichtung aller Unternehmensaktivitäten auf die Erzeugung von Wert (Value). Doch was erzeugt letztendlich den Wert? Die Produkte, Systeme oder Services, die wir erstellen. Meist stellt es für die Unternehmen eine große Herausforderung dar, von der Vision zu einer erfolgreichen Umsetzung zu gelangen. Die Value Map hilft dabei, Vision und Umsetzung zu verzahnen und einfach zu visualisieren.
Wer kennt sie nicht, die endlosen Diskussionen über das beste Skalierungsframework, über Hierarchie, über Scrum oder doch lieber Kanban? Das Produkt selbst wird dabei fast zur Nebensache. Dabei sollte doch das Produkt im Fokus stehen und die Organisation und die Arbeitsprozesse sich danach ausrichten, die Produktentstehung zu unterstützen. Auch die eigentliche Vision zum Produkt gerät im Alltagsgeschäft gerne in Vergessenheit. Mal ehrlich – wie oft fragen Sie sich und andere nach dem "Wozu"? Wozu brauchen wir diese neue Funktionalität denn eigentlich?
Hier kann die Value Map Abhilfe schaffen. Sie konkretisiert eine Produktvision, macht Ziele greifbar und liefert eine Visualisierung, die laufendes Planen auf Sicht ermöglicht. Die Value Map unterstützt uns dabei, unser Produkt so zu gestalten, dass wir uns konsequent am Kunden und an der Wertschöpfungskette orientieren: Kunde und Produkt rücken in den Mittelpunkt. Die Value Map bietet Orientierung – dabei ist es gleichgültig, ob es sich um die Neuentwicklung eines Produktes oder um die Weiterentwicklung bestehender Anwendungen handelt.
Damit wird sie zu einem idealen Kommunikationsmittel für alle Beteiligten im Entwicklungsprozess – vom Kunden über den Fachbereich und die IT bis hin zum Management.
Die Value Map basiert auf dem Informationsmodell von Colin Hood [2]. Der Artikel beschreibt die Weiterentwicklung des Informationsmodells zur Value Map und basiert auf den Ideen und Ausarbeitungen von Uwe Valentini und Susanne Mühlbauer.
Das Konzept der Value Map
Die Value Map ist ein Denkmodell, eine statische Abbildung und Strukturierung eines Produktes oder eines Systems. Sie ist eine abstrakte Visualisierung eines Systems. Die Value Map ist kein Vorgehensmodell, kein Prozess und hat keinerlei zeitlichen Bezug. Im ersten Schritt geht es darum, die Geschäftsziele oder auch ein Problem zu benennen und von der eigentlichen Lösung zu trennen. Entscheidend ist, klar herauszuarbeiten, wozu wir ein Produkt oder System eigentlich bauen. Welchen Kundennutzen wollen wir bieten, bei welchem Problem wollen wir den Kunden unterstützen, welche Ziele sollen durch die Lösung erreicht werden. Vor allem bei bestehenden Systemen ist die Rückbesinnung auf die Ziele oder das Problemverständnis sinnvoll, um zu verstehen, welche Lösungen oder Systemteile (noch) dazu beitragen, das Ziel zu erreichen oder das Problem zu lösen. Diese Geschäftsziele sind bei Legacy-Systemen in Vergessenheit geraten oder auch nicht mehr aktuell. Weiterentwicklungen und Änderungsanforderungen werden daher häufig nicht mehr an den Zielen und dem Kundennutzen ausgerichtet, sondern beispielsweise an der Macht und dem Einfluss einzelner Stakeholder.
Abb.1 zeigt eine methodische Darstellung der Basis-Value Map. Damit es nicht so abstrakt bleibt, liefert Abb.2 ein Beispiel für eine konkrete Anwendung.
Die Ziele beschreiben, wozu das System entwickelt wurde/werden soll. Die fachliche Lösung beschreibt, was, also welche Funktionalitäten, notwendig sind, um diese Ziele zu erreichen bzw. zu unterstützen. Die technische Lösung kümmert sich um das SW-Design, das Wie, für die Implementierung. Die Implementierung beschreibt dann, wie genau die technische Lösung umgesetzt wird bzw. ist die Implementierung selbst.
Wenn Sie mit der Erstellung einer Value Map beginnen, starten Sie zunächst damit, ein Ziel, eine fachliche Lösung und eine technische Lösung zu benennen (s. auch Abb.2). Es geht darum, das Wesentliche zu benennen. Erst wenn Sie dann mit der Value Map arbeiten, detaillieren Sie die einzelnen Bereiche der Map weiter aus.
Ziele, fachliche Lösung, technische Lösung und Implementierung repräsentieren dabei Gruppen von Anforderungen oder auch Beschreibungen der aktuellen Lösung. Jede Gruppe stellt in sich eine vollständige Beschreibung des Systems/ Produkts auf unterschiedlichen Abstraktionsebenen dar und beantwortet jeweils eine eigene Fragestellung.
Interessant sind die Ebenen auch im Hinblick darauf, wer für die Inhalte die Verantwortung trägt. In dem Artikel beziehe ich mich auf das Arbeiten mit Scrum. Alle Fachbegriffe können im aktuellen Scrum Guide nachgelesen werden [1]. In einem Scrum-Team ist der Product Owner für das Was und das Wozu verantwortlich, das Development Team für das Wie und das Wie genau. Die Konversation im Backlog Refinement kann dabei durchaus über alle Ebenen im gesamten Scrum-Team geführt werden. Genau dafür ist die Value Map da – sie stellt sicher, dass sich der Product Owner nicht zu stark in die Lösung einmischt bzw. dass allen klar ist, dass er genau das gerade tut. Die Value Map schafft Transparenz.
Schauen wir uns die Value Map nun in einem Beispiel an: Abb.2 zeigt uns, dass das Ziel für den Kunden nicht "Online Banking" ist, sondern "Selbstbestimmt Geldgeschäfte erledigen", unabhängig von Öffnungszeiten der Bank. Die Lösung ist zunächst offen – Telefonbanking war hierzu bereits ein Lösungsangebot. In diesem Beispiel gibt es drei Anwendungsfälle, die der Kunde durchführen möchte: Sparen, Anlegen, Bankgeschäfte erledigen. Damit ist die Kernfachlichkeit bereits beschrieben, wir haben eine erste Vorstellung davon, was das System tut. Als technische Lösung wird eine Web-Lösung genannt. In einer Diskussion sollte jetzt eine der ersten Fragen sein: Wieso nur Web-Lösung? Gibt es auch eine App? Und sollte die technische Lösung zunächst nicht einfach nur "Online Banking" heißen, damit lassen wir die Umsetzungsoptionen offen?
Das sind die wesentlichen Fragen für die initiale Value Map. Wie man diese dann weiter verfeinert, betrachten wir später im Artikel.
Die Value Map als Arbeits- und Kommunikationsmittel
Die Value Map ist in erster Linie ein Arbeitsmittel. Eine erste Visualisierung, zum Beispiel am Flipchart, unterstützt die Konversation zwischen Fachbereich, IT und auch mit dem Management. Auf dieser Abstraktionsebene ist ein Gespräch über die eigentlichen Ziele möglich, Fachbereich und IT können verschiedene Lösungsalternativen besprechen ohne sich in Details zu verlieren. User Stories sind dabei eine schöne Möglichkeit, um den Zusammenhang zwischen dem "Was" und dem "Wozu" auch bei der Diskussion um Anforderungen nicht aus den Augen zu verlieren. Sie lassen sich für die Zielbeschreibung auf der obersten Abstraktionsebene einsetzen, verbinden aber auch die fachliche Lösungsbeschreibung wieder mit den Zielen.
Für die Umsetzung der User Stories beziehen wir alle Ebenen der Value Map ein, denn eine User Story ist erst dann fertig (Done), wenn sie einen Kundennutzen erfüllt und potentiell auslieferbar ist. In der Value Map in Abb.3 wird gezeigt, dass hierfür ein "Durchstich" durch das System notwendig ist. Erst wenn das SW-Design und die Implementierung für eine User Story fertig sind und alle notwendigen Tests durchgeführt sind, ist auch die gesamte User Story fertig. Übrigens lassen sich auch die Tests auf der Value Map verorten, wie Abb.4 zeigt.
Die Value Map als Navigationshilfe
Bisher haben wir SW-Design und Implementierung als Blackbox betrachtet. Die Value Map lässt sich jedoch rekursiv erweitern. Wir beschäftigen uns mit der technischen Lösung. Um die fachlichen Anforderungen umzusetzen, werden häufig verschiedene einzelne Subsysteme benötigt. Diese können wir jetzt in die erweiterte Value Map einzeichnen. Wie bereits bei der Basic Map ist jetzt die spannende Frage: Wozu brauchen wir dieses Subsystem? Welchen Beitrag liefert es zur technischen Lösung und zur Erreichung des Ziels?
Angenommen, wir sprechen gerade über eine bestimmte User Story, können technische Experten (z. B. das Development Team) relativ schnell benennen, welche Subsysteme entwickelt oder angepasst werden müssen. Abb.4 zeigt die Idee schematisch. Dadurch ermöglicht uns die Value Map innerhalb existierender oder auch neuer Systeme zu navigieren, ohne den Überblick und den Blick auf das Ganze zu verlieren. Offene Fragen zur Fachlichkeit und zur Implementierung können diskutiert und geklärt werden, ohne bereits zu tief in Detaildiskussionen einzusteigen. Anforderungen an die Fachlichkeit können identifiziert und besprochen werden. Hier erfolgen bereits erste Priorisierungen, Anforderungen können verworfen oder weiterverfolgt werden, je nachdem wie stark sie zur Erfüllung des Ziels beitragen. Auch Anforderungen auf technischer Ebene, wie z. B. Schnittstellenanforderungen zwischen Teilsystemen können abgeleitet werden.
Auch hier bleiben wir eher abstrakt, die genauen Details sind an dieser Stelle noch gar nicht wichtig. Das Entscheidende ist, dass Fachexperten und Entwicklungsexperten sich gemeinsam klar darüber werden, welche Teile des Systems von einer User Story betroffen sind. Fachliche und technische Abhängigkeiten können bereits auf dieser Ebene identifiziert werden. Ebenso können wir User Stories priorisieren, da ein erster grober Aufwand abgesehen werden kann, den wir in Bezug zum Beitrag für das Gesamtziel setzen können. Eine Detaillierung erfolgt dann gemeinsam im Backlog Refinement bzw. im Planning Event.
Für das Online Banking-Beispiel könnte die erweiterte Value Map dann wie in Abb.6 aussehen.
Aus Abb.6 lässt sich zum Beispiel ableiten, dass eine App erstellt werden soll. Die Frage nach dem Wozu wird beantwortet, da das Ziel der App darin besteht, auch von unterwegs seine Geldgeschäfte zu erledigen. Gibt es nun eine User Story, die sowohl von zu Hause als auch von unterwegs ausgeführt werden soll, sind bereits 5 Subsysteme betroffen. Im Rahmen einer Priorisierung kann nun bestimmt werden, welche technische Lösung zuerst umgesetzt werden soll. Eine andere Anforderung ist der Wunsch nach Austausch mit anderen Anwendern. Hier könnte man eine eigene Lösung implementieren – oder wie im Beispiel – für eine erste einfache Umsetzung auf bestehende Anwendungen zugreifen.
Value Map und Dokumentation
Bisher haben wir uns der Value Map als Kommunikationsmittel und als Navigationshilfe für die Neu- und Weiterentwicklung von Produkten/ Systemen gewidmet. Beispielsweise für Scrum Teams ist die Value Map ein lebendes Artefakt, das im gesamten Sprint – während aller Events – verwendet, verändert und genutzt werden kann.
Die Value Map dient als Leitfaden für die Konversation zu User Stories und richtet diese immer wieder auf den Kundennutzen aus. Dabei reichen tatsächlich grobe Skizzen auf Flipcharts, die ständig vom gesamten Scrum-Team bearbeitet werden und am besten auch prominent im Raum sichtbar sind.
Wir können das Konzept der Value Map aber auch nutzen, um unser System zu dokumentieren. Letztlich ist die Value Map ein Modell unseres Systems. Im Rahmen der Implementierung können wir die Value Map beispielsweise in ein UML-Diagramm überführen und dann mit jeder User Story an den entsprechenden Stellen durch weitere Diagramme erweitern. Die Pflege und Aktualisierung des Modells erfolgt dann über eine entsprechende Erweiterung der Definition of "Done" und ist Teil des potentiell lieferbaren Produktinkrements. Die Konversation im Rahmen von Backlog Refinement und Planning Event kann zusätzlich auf Basis des Dokumentationsmodells der Value Map erfolgen – je nach erforderlichem Detailgrad.
Value Map und Agilität
Eine Value Map ist natürlich nicht ausschließlich für agile Entwicklung geeignet. In diesem Beitrag möchte ich mich jedoch darauf fokussieren. Die Value Map ermöglicht einen leichtgewichtigen und pragmatischen Ansatz, um strukturiert Vision, Geschäftsziele, Anforderungen und Systemumsetzung zu verbinden. Das ist jedoch noch nicht alles. Die Value Map lässt auch Rückschlüsse auf Teamzuschnitt und Skalierungsszenarien zu.
Value Map und Teamzuschnitt
Hierzu stellen wir unsere erweiterte Value Map zunächst einem Organigramm des Unternehmens gegenüber.
Angenommen, wir wollen eine bestimmte Funktionalität umsetzen, können wir anhand der Value Map ableiten, welche fachlichen und technischen Aspekte betroffen sind. Ein Blick auf das Organigramm zeigt nun, in welchen Bereichen/Abteilungen die entsprechenden Kompetenzen vorhanden sind. Für die Teamzusammenstellung müssen Personen mit diesen Skills berücksichtigt werden. Auf dieser Basis kann eine Diskussion stattfinden, die sich an der Wertschöpfungskette für das Produkt orientiert und damit auch organisatorische Konsequenzen nach sich ziehen kann.
Wir sprechen dann nicht mehr über Abteilungen, Macht, Hierarchie und Re-Organisation, sondern über die Zusammenstellung von langfristig bestehenden (Scrum-)Teams, die möglichst unabhängig voneinander möglichst viel Kundennutzen erzielen können.
Die Abbildungen 8 und 9 zeigen beispielhaft zwei Möglichkeiten zur Teamzusammensetzung, die jeweils die Produktverantwortung auf Subsysteme zuordnen. In Abb.8 ist ein Team für zwei Subsysteme verantwortlich und kann die geforderte Funktionalität selbständig realisieren.
In Abb.9 ist jeweils ein Team für ein Subsystem verantwortlich. Die geforderte Funktionalität bedingt jedoch Änderungen in beiden Subsystemen. Durch die Visualisierung wird klar, dass die Teams nur gemeinsam den Kundenwert erstellen und liefern können und ggf. Abhängigkeiten bestehen. Dieser Sachverhalt kann in der Planung frühzeitig berücksichtigt werden. Häufen sich diese Abhängigkeiten, kann über die Art der Teamzusammensetzung erneut diskutiert werden.
Abb.10 zeigt die Value Map für unser Online Banking-Beispiel mit sogenannten Komponenten-Teams. Diese Teams sind nur für eine technische Komponente verantwortlich. Kein Team kann den geforderten Kundennutzen alleine liefern. Nur wenn alle Teams ihren Beitrag fertiggestellt haben, kann eine erlebbare Funktionalität mit entsprechendem Kundennutzen realisiert werden. Die Abhängigkeiten dieser Teams sind entsprechend größer. Komponenten-Teams werden in agilen Ansätzen meist als die schlechtere Alternative zu Feature-Teams (s. Abb.7 und Abb.8) gesehen. Es gibt allerdings durchaus Gründe dafür, mit Komponenten-Teams zu arbeiten oder auch mit einer Kombination. Die Value Map erleichtert hierbei das Handling, indem frühzeitig und laufend über Abhängigkeiten und Schnittstellen gesprochen werden kann.
Die Value Map und Skalierungsszenarien
Für das Thema Skalierung brechen wir unsere Value Map noch weiter auf. Wir fügen eine weitere Ebene hinzu. Hier können wir beispielsweise ganze Systeme oder Applikationslandschaften abstrakt visualisieren. Wichtig ist dabei, dass die Fragen nach dem "Wozu", dem "Was" und dem "Wie" auf jeder Ebene wieder gestellt werden. Sie beziehen sich dann nicht mehr auf das Gesamtsystem, sondern auf einzelne Subsysteme. So konzentrieren wir uns immer darauf, zu hinterfragen, ob das was wir tun wollen auch tatsächlich einen Wert hat. Dabei bezieht sich der Beitrag auf das Subsystem. Die Summe der Subsysteme und deren Wertbeitrag zahlt dann wiederum auf das Gesamtsystem ein.
Die Value Map in Abb.11 zeigt zunächst einmal, dass die Realisierung einer Funktionalität auf oberster fachlicher Ebene Änderungen an verschiedenen Teilen der Anwendung erforderlich macht. Je nach Teamzuschnitt sind nun verschiedene organisatorische Lösungen zur Abstimmung der Beteiligten notwendig.
Skalierungsframeworks beschäftigen sich genau mit dieser organisatorischen Steuerung von Teams und deren Arbeit. Leider gerät dabei das eigentliche Produkt aus dem Fokus. Mit der Value Map stellen wir dieses wieder konsequent in den Mittelpunkt und richten die Skalierungsaktivitäten daran aus. Wir unterhalten uns nicht mehr nur über Organisationsstrukturen (und damit Macht), sondern über Wertschöpfung anhand des Produkts. Das macht Entscheidungen objektiv und schafft Freiraum für sachliche Diskussionen.
Die Value Map ist dabei die Navigationshilfe durch eine Transition und für die Skalierung der agilen Organisation. Mit dieser Landkarte kann jedes beliebige Skalierungsframework genutzt werden oder eben auch nicht. Anpassungen an agilen Frameworks lassen sich auch anhand der Value Map vornehmen.
Bekannte Skalierungsframeworks wie SAFe oder LeSS [3] liefern zu diesen organisatorischen Lösungen viele gute Ideen, die mittels der Value Map direkt auf das Produkt/ die Anwendung abgebildet werden können.
Abb.12 zeigt am Beispiel des SAFe Frameworks ein sehr grobes Mapping der SAFe-Ebenen auf eine Applikation. Das kann als erster Überblick dienen, um Organisationsänderungen sukzessive anzugehen.
Auch Konzepte aus LeSS lassen sich mittels der Value Map zuordnen, wie in Abb.13 sichtbar.
Die hier vorgestellten Abbildungen von Skalierungsframeworks sind nur eine erste grobe Idee, die natürlich im Rahmen von Skalierungsmaßnahmen viel detaillierter betrachtet werden muss. Es kann durchaus lohnend sein, die Value Map zu detaillieren und immer wieder mit den Skalierungslösungen abzugleichen. So können organisatorische Lösungen zur Skalierung immer wieder dahingehend hinterfragt werden, inwieweit sie zur Wertschöpfung beitragen und Kundennutzen stiften.
Neben den hier genannten Skalierungsframeworks ermöglicht die Value Map natürlich auch, die agilen (Standard-)Praktiken für die Skalierung zu verwenden, die bereits genutzt werden. Die Value Map dient hierbei ebenfalls zur Orientierung. Abb.14 zeigt ein Beispiel.
Einfach starten – jetzt
Zum Abschluss möchte ich Sie nun ermuntern, sich ans Flipchart zu begeben und gemeinsam mit Ihrem Team eine erste Value Map zu erstellen. Fangen Sie einfach an. Das Format ist nicht wichtig – es ist wichtig, die Frage nach dem "Wozu" zu stellen. Sie werden feststellen, dass die Schwierigkeit nicht darin liegt, eine abstrakte Value Map zu erstellen, sondern diese Frage zu beantworten.
Starten Sie daher die Konversation mit allen Beteiligten, fokussieren Sie sich auf die Business-Ziele und hinterfragen Sie die Liste an Anforderungen, die Sie für die Zukunft planen. Sind diese wirklich wichtig, um das Ziel zu erreichen? Wenn nicht, welche sind es stattdessen?
- Scrum Guide
- Value Map: Informationsmodell von Colin Hood
- Informatik Aktuell: Fabian Schiller: Agile Skalierung? Kein Problem! – Das LeSS-Framework
Neuen Kommentar schreiben