Starke Ausrichtung für agile Produktteams

Mit einer starken Ausrichtung beantwortet ein Team zwei Fragen:

• Welchen Mehrwert für unsere Organisation schaffen wir mit unserem Vorhaben?
• Warum sind der jetzige und der nächste Schritt für unser Vorhaben wichtig?

Simon Wardley leitet aus einer strategischen Sicht diese beiden essentiellen Fragen (“Why of Purpose”, “Why of Movement”) aus Sun-Tzus Werk über Strategie “Die Kunst des Krieges” ab. “Purpose” (Vision, Ziel) ist dabei das, was eine Organisation zusammenhält, was Menschen sich gegenseitig bei dem gemeinsamen Vorhaben unterstützen lässt. “Movement” ist dabei jeder Schritt, der sich aus dem aktuellen Kontext (Distanz zum Purpose, Umfeld, Vorgehensweise, Hindernisse) ableitet. Es ist wie ein Schachspiel: Die Schritte werden nicht im Voraus geplant, sondern die Entscheidung für jeden Schritt wird aus dem aktuellen Kontext heraus getroffen. Trotzdem sorgt das grundsätzliche Ziel (“Das Spiel gewinnen”) für eine starke Ausrichtung.

Um tiefer in die Materie einzudringen, empfehle ich das lesenswerte Online-Buch von Simon Wardley zu den Wardleymaps und die hervorragende Artikelserie “The Art of Strategy” von Erik Schön.

Kann ihr Team die beiden einleitenden Fragen eindeutig und einheitlich beantworten? Wenn ja: Glückwunsch, ihr Team arbeitet mit einer starken Ausrichtung. Wenn nein: Vermutlich fehlt ihrem Team eine starke Ausrichtung und es fällt ihm schwer, zu erkennen, ob es auf dem richtigen Weg ist.

Wie kommt es dazu?

Zunächst hilft es hier, zwischen Output und Outcome zu unterscheiden. Output umfasst Artefakte wie Software und Pläne, aber auch reine Features ohne weiteren Zusammenhang. Beim Outcome geht es um Mehrwerte für Nutzer, die Adressierung konkreter Probleme. Den Mehrwert zu erreichen ist wichtig, die Lösung dahinter ist zweitrangig.

Organisationen die eher Output produzieren, arbeiten in der Regel projektorientiert: Teams müssen frühzeitig aufgestellte Pläne und Meilensteine erreichen. Wenn diese erreicht sind, ist das Projekt ein Erfolg. Echte Mehrwerte geraten in den Hintergrund. Durch die frühzeitige Beschreibung von Lösungen oder reinen Features ist der Weg zum Ziel auch schon im Voraus geplant. Da dieser vorgegeben wird, findet vor allem ein Dialog zum Verständnis der Lösungen und Features statt, der zum Mehrwert des Vorhabens wird schwächer und schwächer. Übliche Symptome eines Teams in so einem Kontext sind dabei:

• Mitglieder desselben Teams beantworten die Frage nach dem Mehrwert des Vorhabens und einzelner Schritte mit zunehmender Zeit immer unterschiedlicher, ungenauer und unmotivierter.
• Konformität zur Planerfüllung wird gern gesehen, dagegen sind Kreativität und neue Ideen Unruhe.
• Ob das Team auf dem richtigen Weg ist, erkennt es erst sehr spät.

Starke Ausrichtung auf Outcome (und Impact)

Organisationen, die ihren Erfolg anhand von Outcome bewerten, agieren eher in Produkten als in Projekten. Die Sicht auf Produkte bedingt, Nutzer und deren Probleme/Bedürfnisse zu kennen. Denn um Mehrwerte für die Nutzer (Outcome) zu schaffen, müssen wir Probleme und Bedürfnisse adressieren und diese immer in den Vordergrund stellen.

Die Ausrichtung auf Outcome können wir uns als einen Rahmen vorstellen. Unseren Ausgangspunkt bilden dabei die Nutzer des Produkts, deren Ziele und die Probleme die ihnen im Weg stehen. Die Adressierung dieser Probleme erhöht den Mehrwert des Produkts, der durch den Outcome formuliert wird. Outcome wird dabei in der Regel qualitativ ausgedrückt: Wie ändert sich der Kontext des Nutzers? Dies ist unser Ziel.

Die Motivation für unser Ziel festigen wir aber noch stärker: Unsere Organisation verfolgt mit dem Outcome des Vorhabens immer eine höhere Intention. Die Auswirkungen, die wir mit dem Outcome beschreiben, sollen eine positive Wirkung (Impact) auf die Organisation erzielen. Beispiele dafür sind höhere Erträge, reduzierte Kosten etc. Diese stellen sich in der Regel langfristig ein und lassen sich aufgrund von Rauchen anderer Vorhaben und Marktparameter schwieriger messen, als der Outcome.

Erfolg messbar machen

Ein relevanter Aspekt für die Arbeit mit Outcomes fehlt noch: Metriken zur Erfolgsmessung. Diese machen den Outcome greifbarer und drücken aus, wann der Outcome für die Nutzer hergestellt ist. Pro Outcome reichen 2-5 Metriken.

Beispiele für eine Kombination aus qualitativen und quantitativen Metriken für den Outcome “Unsere Bezahlseite ist für unsere Nutzer angenehmer zu nutzen”:

• Die durchschnittliche Ladezeit unserer Bezahlseite beträgt 1,2sec.
• Die Abbruchrate der Bezahlseite beträgt maximal 3%.
• Das Ops-Team kann frühzeitig Engpässe bei der Ladezeit erkennen.

Während die ersten beiden Metriken quantitativ formuliert sind, ist die dritte qualitativer Natur. Nehmen wir an, dass es dem Ops-Team in diesem Fall noch gar nicht möglich ist, Engpässe zu erkennen. Die Metrik ist nicht klar messbar, drückt jedoch die Ausrichtung für eine Neuerung aus (ohne Vorgabe einer technischen Lösung).

Zwischen dem Ausgangspunkt “Nutzer” und dem Ziel spannt sich so ein klarer Rahmen auf. In diesem Rahmen ist maximale Kreativität und Freiheit erwünscht, nur erkennt das Team mit diesem Rahmen eindeutig, ob es auf dem richtigen Weg ist.

Jeder Schritt wird nämlich danach bewertet, ob das Team damit dem Outcome näher kommt und beinhaltet für sich auch einen Outcome. Start und Ziel sind dabei immer wieder Ankerpunkte für das Team, um das festzustellen.

Starke Ausrichtung in der Praxis

Für die Praxis gelten folgende Grundsätze:

• Wir bereiten immer nur den nächsten Schritt detailliert vor.
• Der nächste Schritt richtet sich immer nur am Gesamtziel aus.

Wir setzen auf

• Personas und User Story Mapping
• Produktinkremente
• Ein sehr schlankes Backlog
• Ein physikalisches Taskboard

Personas und User Story Mapping

Zunächst bauen wir Verständnis für unsere Nutzer auf. Dafür haben sich bei mir zwei Techniken besonders bewährt:

• Personas – Diese repräsentieren jeweils einen typischen Nutzer unseres Produkts. Ein einfaches Workshop-Format für die initiale Erstellung von einfachen Personas hat Jeff Patton hier beschrieben: Persona Sketching
• User Story Mapping – Hiermit baut man ein tiefes Verständnis für relevante Personae auf, indem alle Aktivitäten mit dem Produkt erfasst werden. Probleme der jeweiligen Persona werden auf die Map übertragen. Daraus leiten sich wiederum neue Produktideen, Varianten von Tätigkeiten etc. ab. Die User Story Map ist somit eine exzellente Grundlage, um mit Nutzern, Stakeholdern und Team in den Dialog zu gehen. Ich empfehle dazu das gleichnamige Buch von Jeff Patton und als Einstieg die Schnellübersicht dazu: Story Mapping Quick Reference In einem Workshop über 1-2 Tage mit einem cross-funktionalen Team (4-7 Teilnehmer, z.B. 1xPO, 1-2xEntwickler, 1xSales, 1xFachabteilung) lässt sich eine Story Map gut ausarbeiten.

Das oben genannte Persona-Sketching erzeugt zügig nutzbare Personas. Damit das Team und die restliche Organisation zunehmend mehr Empathie für die Personas aufbauen, müssen diese kontinuierlich mit Daten und Erkenntnissen weiterentwickelt werden. Einen guten Artikel dazu gibt es hier.

Um unser übergreifendes Ziel auszuarbeiten, priorisieren wir unsere Personas und für jede Persona die jeweiligen Probleme. Wir haben jetzt schon eine starke Ausrichtung geschaffen. Zur Fokussierung selektieren wir die wichtigsten Personas und jeweils wichtigsten Probleme aus. Hier gilt: Je weniger desto besser, um das Team so klar wie möglich auszurichten. Zu viele Personas oder zu viele zu adressierende Probleme erschweren das.

Outcome und Metriken definieren

Als Nächstes leiten wir aus den priorisierten Personas den zu erzielenden Outcome für unser Vorhaben und entsprechende Metriken ab. Erst wenn die wichtigsten Probleme unserer wichtigsten Personas ausreichend adressiert werden, haben wir das Ziel erreicht. Beschäftigt sich ein Team das erste Mal mit Outcome und Metriken, so gelingen diese auf Anhieb selten. Der Artikel “4 Steps to Defining GREAT Metrics for ANY Product” gibt hierzu viele Tipps. Am besten verzettelt man sich hier nicht. Viel besser ist es, mit dem ersten Wurf anzufangen, um in den ersten Wochen immer wieder nachzubessern.

Produktinkremente

Die nächsten Schritte vom Ausgangspunkt hin zu unserem Ziel planen wir als Produktinkremente. Dabei reicht es, wenn wir immer nur 3-5 Inkremente grob im Voraus planen. Nur das nächste muss im Team fundamental verstanden sein. Jedes Inkrement kann so minimal wie möglich gestaltet sein, damit es nur den nächsten kleinen und sinnvollen Schritt beschreibt. Jedes Inkrement wird – genau wie das übergreifende Ziel – mit Outcome und Metrics beschrieben.

Schlankes Backlog

Durch die starke Ausrichtung vermeiden wir ein prall gefülltes Backlog, das in einem solchen Zustand eine sehr schlechte Ausrichtung gibt. Die allermeisten im Vorfeld geschriebenen Stories, sind nach wenigen Wochen überholt. Selbst, wenn sie sehr schlank verfasst sind, überholt das Team Stories zu schnell. Wir schreiben also immer nur so viele Stories damit das Team nicht leer läuft.

Physikalisches Taskboard

Mit dem physikalischen Taskboard machen wir unsere Arbeit transparent. Personas, Ziele und Inkremente hängen nah bei dem Board, damit das Team diese kontinuierlich nutzt. Sprintziele, Stories und Discoveries richten sich an dem aktuellen Inkrement aus. Stories sind erst fertig, wenn der geplante Schritt in Richtung in Outcome validiert wurde.

Die hier beschriebene starke Ausrichtung ermöglicht Produktteams eine leichtgewichtige, fokussierte und strukturierte Arbeitsweise. Einmal erstellt und kontinuierlich weiterentwickelt, fokussiert sich das Team kontinuierlich zur Bewertung von Maßnahmen auf Nutzer, deren Ziele, deren Probleme und dem übergreifenden Ziel. Das gesamte Team hat eindeutige Ankerpunkte zur Hand, um sich immer wieder auszurichten. Planung findet nur noch so statt, wie es dem Team hilft und verständlich für die restliche Organisation ist. Komplizierte User Stories, unmotivierte Featurelisten und lange Pläne – in allen steckt Konfliktpotential – entfallen.

Artikelbild: Jonathan Smith on Unsplash