Diese Seite gibt einen Überblick, wie man auf eine sehr natürliche Art und Weise von einer soliden Idee (einer Vision) zu einem sehr guten, priorisierten Backlog kommt in einer ziemlich kurzen Zeit und gleichzeitig zusätzliche Vorteile als Seiteneffekt erzielt. Als Kernelement steht immer der Mensch im Vordergrund allen Denkens und Handelns und die dadurch entwickelte Empathie ist dem Thema Change Management extrem zuträglich.

Was ist “Vision Grounding”?

Vision Grounding (VG) ist ein Ansatz und eine Kombination vom Methodiken. Es gibt zwei Kernelemente:

• Das Wichtigste ist ein cross-funktionales Team dazu zu bringen eine gemeinsame Perspektive auf eine „Produktvision“ zu haben und dadurch diese initiale Vision zu „erden“ (grounding) mit den diversen Perspektiven aller relevanten Teilnehmer in diesem cross-funktionalen „Produktteam“.
• Der zweite Teil basiert auf einer erweiterten Version von Jeff Pattons Methodik “User Story Mapping” (LINK), welcher gebraucht wird, um „das Fleisch an die Knochen“ zu bringen rund um die abgestimmte Produktvision. Diese wird heruntergebrochen in einen priorisierten Produkt- oder Releasebacklog. Durch das Herunterbrechen entlang von Personas (den Menschen) in deren User Stories oder Epics (abhängig von der Größe des Investments) wird die Vision in etwas viel konkreteres und greifbares „geerdet“.

Wie funktioniert „Vision Grounding“?

Einigt Euch auf eine Produktvision

Zu Beginn ist sicherzustellen, dass das cross-funktionale Produktteam einschließlich aller Key Stakeholder zu einem Workshop zusammenkommt und gemeinsam eine Produktvision abstimmt.

Aber was ist eine Produktvision? Die Produktvision ist eine nix-blabla, kurze und klare Formulierung von 10 – 20 Zeilen oder einer Liste, was am Ende geliefert wird. Sie beginnt typischerweise mit „Wir stellen <Produkt> bereit, welches unsere Kunden (extern oder Fachbereich) in die Lage versetzt <Fähigkeit 1>, <Fähigkeit 2>, …“. Es ist wichtig, dies auf eine komplett nicht-technische Art zu beschreiben, so dass JEDER weiß, über was geredet wird. Einschließlich und insbesondere Ihre Kunden und auf eine Weise, dass diese sofort den Nutzen verstehen. Es ist wichtig NICHT eine vorgegebene Beschreibung von irgendeinem Manager als in Stein gemeißelt hinzunehmen. Diese mag ein Startpunkt sein, jedoch das Team in die Lage zu versetzen, eine eigene abgestimmte Produktvision zu definieren ist essentiell. Sie wären überrascht, wie oft ich schon Manager habe sagen hören „Warum sollten wir das tun? Die Vision ist für jeden klar.“ und nach ein paar Stunden hitziger Diskussion und anschließender Übereinkunft sagten „Das habe ich nicht erwartet. Erst jetzt haben wir ein gemeinsames Verständnis, wo wir hinwollen. Es war absolut wichtig, das zuerst zu tun!„. Weil erst dann alle Mitglieder des cross-funktionalen Teams in ihrem jeweiligen Verantwortungsbereich Entscheidungen treffen können in vollem Bewusstsein des übergeordneten Ziels und dadurch viel flexibler und agiler handeln können, weil sie das Gesamtbild kennen und die Auswirkungen ihrer Entscheidungen.

Es ist wichtig ein erstes solides gemeinsames Verständnis zu haben. Aber auch jetzt noch ist die Produktvision nicht in Stein gemeißelt. Nicht jetzt für die Zeit des Workshops und noch weniger danach, wenn Sie weiter von Ihren Kunden lernen.

Skizziere die high-level Architekturvision

Da Ihr Lead-Software-Architekt Teil des cross-funktionalen Teams ist, hat er nun ein solides Verständnis davon, was am Ende erreicht werden soll. Und er wird ein Verständnis dafür entwickeln, wie die high level Software-Architektur aussieht, die dieses Ziel nachhaltig unterstützt.

Dies sind Fragen wie Cloud versus hosted versus onPrem versus mobile … aber auch die Hauptkomponenten. Und ich meine wirklich Hauptkomponenten – keine detaillierte Architektur bitte. Sie beinhaltet nur 5 – 10 Hauptbausteine.

Es ist auch wichtig zu verstehen, dass es nicht notwendigerweise die finale Architektur ist, weil Sie weiterhin lernen werden. Und auch die Architektur der Version 1 kann sehr unterschiedlich sein zur letztendlichen Architektur angesichts etwaiger Markteintrittsentscheidungen.

Bilden Sie die Hauptfähigkeiten ab entlang von Personas und eUSM

Jetzt wird die Produktvision mit Leben gefüllt. Üblicherweise bitte ich die Teams, die ich gecoacht habe, die Personas aufzulisten, die sie das Produkt nutzen / damit arbeiten sehen. Sie sollen deren Hauptaspekte beschreiben, um sie möglichst greifbar zu machen für die Diskussionen. Die Workshop-Teilnehmer sollen ihnen Namen geben wie “Lennie Lagerleiter”, “Arnold Arbeitsvorbereiter” und irgendwann beginnt das Team darüber zu reden, „was Lennie noch benötigt“. Das ist der Punkt, wo sie beginnen Empathie aufzubauen für ihre Benutzer. Es gibt viele gute Beispiele für das Format (wie LINK) und Sie können über Google den besten Weg für sich selbst zu finden. Ich bin persönlich ein Freund eines Tabellenformats mit einer Auflistung, weil das auf den ersten Blick leicht zu erfassen ist, aber finden Sie heraus, was am besten zu Ihnen passt.

Bis hierher coache ich das Team typischerweise im Plenum, weil es wichtig ist, die Diskussionen gemeinsam zu führen. Nun empfehle ich aus Effizienzgründen in Teilgruppen zu splitten (angenommen Sie haben eine Gruppe, die sinnvoll aufgeteilt werden kann, d.h. >= 4 Personen). Lassen Sie die Arbeitsgruppen ihre Personas aussuchen und sie möglichst konkret ausarbeiten, dann kehren Sie ins Plenum zurück und die Teilteams präsentieren ihre Ergebnisse und stimmen sie in der Gruppe ab zu einem gemeinsamen Verständnis.

Achtung: Übertreiben Sie es nicht mit zu vielen Personas. Gehen Sie in Richtung einer Handvoll, wenn nötig vereinfachen Sie oder beschränken es auf die wichtigsten, um Ihr Leben nicht am Anfang zu kompliziert zu machen. Das wäre überwältigend und kann zu Beginn die Energie rauben.

Denken Sie über die „Nutzungsfolge“ (usage sequence) Ihres Produkts nach, d.h. von z.B. der Installation (wenn passend) zur Konfiguration (wenn benötigt) über Hauptgeschäftsabläufe bis hin zu Support und Wartung. Der Kern ist, nichts Wichtiges zu vergessen, so dass Sie nicht am Ende eine perfekte Software haben, aber niemand kann sie herunterladen / installieren … . Nehmen Sie nicht mehr als fünf bis sechs „Nutzungsschritte” (usage steps).

Der nächste Schritt ist, für die Personas deren Tag-im-Leben-von (day-in-the life-of) zu besprechen. Machen Sie dies wieder in den Teilgruppen. Ich halte diese Teilgruppen üblicherweise stabil, wie sie waren und sie können ihre Diskussion zu „ihren Personas“ fortführen, weil sie bereits begonnen haben, Empathie zu entwickeln. Beginnen Sie mit der Überlegung, was Persona A am Morgen als erstes macht und wie der Tag irgendwann endet. Nehmen Sie nicht zu viele „Aktivitäten“ (activities) auf, weil das Ihr Leben zu kompliziert macht (nicht mehr als 5 – 10). Der einzige Sinn ist, Ihrem Backlog später eine innere Struktur zu geben, entlang derer Sie priorisieren können. Am Ende nur einen riesigen Stapel der bestmöglichen User Stories zu haben, erlaubt Ihnen nicht, mit diesem Backlog vernünftig umzugehen.

Nun haben Sie das „Rückgrat“ (backbone) von dem, was Sie liefern möchten. Es ist eine breite Einordnung, wer Ihr Produkt nutzen wird und wie es in deren Tag passt.

Dieses Rückgrat ist nun die Basis um tiefer einzusteigen in das User Story Mapping (USM), wie von Jeff Patton eingeführt. Wir hatten den Ansatz bei SAP ein wenig erweitert, deshalb nenne ich es ein „erweitertes User Story Mapping“ (eUSM) im Kern des Vision Grounding.

Teilen Sie wieder auf in die Arbeitsgruppen und lassen Sie diese weiter entlang ihrer ersten Persona denken. Das ist ein natürlicher Fluss, um noch mehr Empathie aufzubauen für die Personas in Ihrem Team. Überlegen Sie, was es braucht, damit eine Persona ihre Aktivität ausführen kann. Hier entsteht Ihre möglicherweise lange Feature-Liste, jedoch nicht als Stapel von User Stories, sondern sehr strukturiert – und sehr natürlich. Und seien Sie am Anfang nicht so kritisch mit der Größe der User Stories. Sie werden automatisch merken, wenn eine zu groß ist – was auch immer „groß“ in Ihrem Kontext bedeutet. Ich habe diesen Ansatz schon genutzt, um ein Investment von 30.000 Personentagen (PD – person days) initial zu strukturieren und dort war es völlig ok, 300 PD für eine Story zu haben. Wohingegen in einer anderen Situation eine Größe von 10 PD angemessen war.

Hängen Sie die Stories höher in der Spalte, die Sie zuerst adressieren möchten. Basis für die Einschätzung dieser Priorität ist oftmals eine Kombination aus Geschäftsnutzen, geschätztem Aufwand, technischem Risiko und ich tendiere auch aus Portfoliomanagement-Gründen dazu den sogenannten Kano-Wert miteinzubeziehen. Mehr dazu in einem späteren Blog.

Jetzt erstellen Sie den Plan für Ihr nächstes Release oder den Sprint oder … indem Sie die Linie ziehen (draw-the-line). User Stories oberhalb der Linie sind Teil der nächsten Iteration, die anderen nicht. Die Linie zu ziehen zwingt manchmal dazu, die Prioritäten innerhalb einer Spalte zu ändern, weil Sie vielleicht Abhängigkeiten erkennen.

Nun haben Sie einen ausführbaren und priorisierten Backlog für Ihr Produkt / Release / Version / … . Sie werden wahrscheinlich ausgewählte User Stories ausdetaillieren müssen, wenn Sie diese dem nächsten Sprint zuweisen, aber das ist „das Ausdetaillieren“ der „richtigen User Stories“.

Iterieren und anpassen

NEIN, das ist nicht das Ende! Ich empfehle normalerweise Teams, die ich coache, dass sie ihre Story Map alle 3 – 6 Monate (nein, nicht kontinuierlich) aktualisieren. Verarbeiten Sie, was Sie auf der Kunden- oder Architekturseite gelernt haben. Das wird Ihr Grundgerüst aktuell halten mit nur geringen Anpassungen.

Welche anderen positiven Effekte können nicht vermieden werden

Wie Sie sich nach der Lektüre bis hierher leicht vorstellen können, hilft diese Übung auch unglaublich dabei, ein sehr gutes Verständnis aus der UX-Perspektive zu bekommen durch eine sehr gute Empathie für die Personas und ihren Flow. Zusätzlich hilft es direkt im ganzen Testbereich, wie bei BDD, Akzeptanztests, Testfallentwicklung, …

In welchem Kontext funktioniert “Vision Grounding”?

Basierend auf meiner Erfahrung ist die Größe des Investments irrelevant. Ich habe damit gearbeitet für

• Investments von 30.000 Personentagen
• die Entwicklung eines neuen Produkts mit 5.000 Personentagen
• die Releaseplanung für 1.000 Personentage
• kleine Investments von 150 Personentagen.

Ich habe persönlich etwa 20-30 Teams bei SAP gecoacht und wir hatten bei SAP eine Community von USM-Coaches etabliert, um diesen Ansatz in die riesige Entwicklungsorganisation der SAP zu tragen. Auch nach meiner Zeit bei SAP konnte ich meinen Kunden mit diesem Coaching zu erfolgreichen Projekten verhelfen.

Eine persönliche Anmerkung: Ich bin völlig überzeugt, dass „nur Lesen und Anwenden“ nicht gut genug ist. Sie sollten zu Beginn einen erfahrenen Coach haben, der Sie anleitet, d.h. einen initialen Workshop leitet und dann immer wieder mal reinschaut, ob das Team noch auf dem richtigen Pfad ist.

Und einer meiner ehemaligen SAP-Kollegen hatte tatsächlich die Methodik genutzt, um die “main features” seines neuen Hauses zu planen :-).

Wie stehen “Vision Grounding” und “Design Thinking” in Beziehung?

Ein sehr geschätzter SAP-Kollege hat es einst sehr gut in einem Foliensatz zu den „Innovationsphasen“ aufgezeigt. Design Thinking (DT) wird oft als Startpunkt gesehen, wenn Ihnen noch unklar ist, was das eigentliche Problem des Kunden ist und die Ideenfindung (ideation) wichtig ist. Dann kommt man in die Validierung des Ganzen (speziell wenn man ein Startup ist) mit dem “Lean Startup Framework” (Ich schätze dieses sehr und nutze “Running Lean” von Ash Maurya sehr oft).

Und dann kommen sie in die Planung und Ausführung, wo SCRUM eine wichtige Rolle spielt.

Wichtig: Denken Sie nicht in einem Wasserfallmodell! Sie springen vor und zurück, wie Sie es benötigen pro Unterthema.

Und Vision Grounding nimmt praktisch das Ergebnis der DT-Phase (oder wie auch immer Sie zu dem Ergebnis kamen) und plant das soweit wie notwendig, damit Sie in SCRUM übergehen können. Sie erinnern sich an die Eingangsfrage, die wir beantworten wollten?

“Wie komme ich von einer Vision zu einem sehr guten Backlog?” – nun, so funktioniert es!

Vision Grounding …

Das hört sich gut an? Lassen Sie uns in Kontakt kommen!