posts under: Planung

Komplexität kontern

Planung     no comments    
Steht ein Produktteam vor einem größeren neuem Vorhaben, so muss es sich schnell in einem Gewimmel von unzähligen Ideen, Systemen, Stakeholdern, Anforderungen und Technologien zurechtfinden. Was kann dabei schiefgehen? Es kann leicht passieren, dass das Team sich von der gewaltigen Komplexität erschlagen lässt und nichts vorangeht. Ich stelle hier Vorgehensweise und Methoden vor, die Komplexität kontern zu können.

Nach diesen vier Prinzipien gehe ich dabei vor:

  • Für welche Zielgruppe soll welches Problem gelöst werden bzw. welches Bedürfnis welcher Zielgruppe soll adressiert werden?
  • Welche Ziele verfolgen dieses Vorhaben?
  • Was soll das Vorhaben umfassen, was liefert es?
  • Wie kann das Vorhaben schnell starten?

Das Vorgehen zieht sich kompakt über 2-4 Wochen. Das kann für einige Organisationen echt sportlich sein, fördert aber schnelle Generierung von Erkenntnissen und Durchführung von konkreten Experimenten. Je schneller sich ein Team weg von Planung und Überlegung bewegt, desto besser. Treiber des Vorgehens sind in der Regel Product Owner oder Projektleiter. Teilnehmer sind darüber hinaus relevante Stakeholder/Nutzer und natürlich das gesamten Team (oder Teile davon). Folgende Tätigkeiten wähle ich üblicherweise bei der Vorgehensweise:

1. Stakeholder identifizieren und einordnen

Zuallererst lohnt es sich, alle Stakeholder zu identifizieren und diese zu klassifizieren. In allen Nachfolgeschritten werden nur die relevanten Stakeholder eingebunden. Und diese Gruppe sollte so klein wie nur irgendwie möglich sein. Alle weiteren Schritte im Vorhaben sind eher zu meistern, wenn nicht jeder Stakeholder mitredet und mitbestimmt. Zu groß ist das Risiko, dass Ziele und Inhalte verwässert werden, wenn die Anzahl der Stakeholder zu groß ist. Hier heißt es, konsequent zu sieben, was meist unangenehm ist. Dafür bietet sich die Powert-Interest-Matrix an, die Roman Pichler hier vorstellt.

Power-Interest Matrix

Siehe dazu auch dieser Beitrag von mir.

Um die Stakeholder – Auftraggeber, Nutzer etc. – zu sieben, werden sie anhand vier Kategorien aufgeteilt:

  • Player –  z.B. verantwortliche Produktmanager, Auftraggeber und Manager aus Fachabteilungen mit denen das Team eng zusammenarbeitet.
  • Subjects – z.B. interessierte Produktmanager und abhängige Produktteams, die die Marschrichtung des Teams nicht spürbar beeinflussen, deren Feedback oder Beratung jedoch wichtig ist.
  • Context Setters – z.B. mittleres und höheres Management. Nehmen nicht an der Produktentwicklung teil, schaffen jedoch organisatorische Rahmenbedingungen.
  • Crowd –  Alle anderen, die über das Produkt informiert werden, jedoch keinen Einfluss auf Produktentwicklung haben.

Üblicherweise fallen viele Stakeholder in die „Crowd“ – diese wird zukünftig nur noch informiert. Die Player werden in Konzeption, Planung und Priorisierung eingebunden, Subjects in Tests und Interviews.

Hört sich sehr einfach an, ist es in der Praxis natürlich nicht. Insbesondere in Organisationen, die an „Jeder muss bei allem mitreden“ gewöhnt sind. Aber auch hier hilft es, die Player frühzeitig zu identifizieren. Sie helfen dem Team als erster Ansprechpartner und sind Proxy für ihre jeweilige Organisation.

2. Auftrag klären und Ausrichtung geben

Zu Beginn eines Vorhabens steht immer eine Idee oder ein Auftrag – ausgehend vom Team oder von außerhalb. Um einen ersten Navigationspunkt zu setzen, empfehle ich daher den Auftrag zu klären. Welches Problem soll eigentlich gelöst werden? Warum? Und welche messbaren Ziele verfolgen wir? Erst durch diese Klärung entsteht eine klare Ausrichtung, an der sich Team und Stakeholder orientieren. Ohne messbare Ziele und ohne Klarheit über den Problemraum startet ein Vorhaben schnell schwammig und orientierungslos. Ein gutes Werkzeug zur Auftragsklärung ist der gleichnamige Steckbrief von Xing.

Auftragsklaerung

Der Steckbrief verfügt über sieben Felder.

  • Situation – Was ist die Ausgangssitutation des Vorhabens?
  • Complication – Was ist der Auslöser des Vorhabens?
  • Higher Intent – Wie zahlt das Vorhaben auf die Vision (Team-, Produkt- oder Unternehmensvision)?
  • Intent – Was wollen sie mit dem Vorhaben wirklich erreichen?
  • Boundaries – Was darf nicht passieren? Was nicht Teil des Vorhabens?
  • Hypotheses – Welche Annahmen zum Mehrwert des Vorhabens machen sie?
  • Input – Welche Rollen/Skills werden benötigt? Welcher finanzielle Rahmen?
  • Output – Was bekommen die Kunden zu sehen? Timings?
  • Outcome – Woran wird der Erfolg des Vorhabens gemessen?

Ich empfehle, pro Feld maximal vier, besser nur zwei präzise formulierte Punkte zu verfassen. Schließlich soll die fertige Auftragsklärung schnell verständlich und eingängig sein. So eine Auftragsklärung nehme ich in kurzen Workshops (2-3 Stunden) vor. Teilnehmer einer Auftragsklärung sind PO, mindestens Teile des umsetzenden Teams und die relevanten Stakeholder.  Zu jedem Feld sollte es aber kurze Analysen im Vorfelde geben. Besonders zu „Complication„, „Hypotheses und „Outcome„. Hier gilt es noch nicht, alles bis ins kleinste Detail zu durchleuchten, aber schon früh sich darüber einig zu sein, was als wichtigstes Problem angesehen wird, welche Ideen/Hypothesen es gibt, diesen zu lösen und wie die Lösung grob aussehen könnte. So werden alle Beteiligten früh mit einem groben Bild ins Boot geholt.

3. Lösungen entwerfen

Okay, nachdem wir das Vorhaben umrissen haben, durchleuchten wir den Problemraum weiter und entwerfen wir die erste Lösung. Das lässt sich am besten mit einer Product Discovery umsetzen. Die Product Discovery lässt PO, Team und Stakeholder das neue Produkt entdecken. Welches Problem löst das neue Produkt? Wie macht es das? Wie sieht es aus? Die Discovery läuft über einen Sprint (wieder sehr sportlich, fördert aber Ergebnisorientierung), das Ergebnis sind Artefakte wie ein Produkt-Steckbrief, Scribbles von der User-Journey und am besten auch ein erster Prototyp. Eingangsdaten sind wiederum Kundenfeedback, Daten (z.B. Tracking, Transaktionen etc.) usw. alles was man kriegen kann, um den Problemraum besser zu durchdringen und um erste Anregungen für neue Ideen zu haben.

Wichtig ist, hier offen und breit zu denken. Es geht darum, möglichst viele Lösungsoptionen zu generieren und deren Hypothesen prototypisch zu beweisen oder zu widerlegen. Lange Diskussionen oder persönliche Befindlichkeiten bringen niemand weiter. Was zählt ist Feedback vom Kunden und das wollen wir hier schnell einholen.

Der Ablauf einer Product Discovery ähnelt dem Design Thinking:

  1. Den User verstehen (viele Daten heranziehen, Erkenntnisse daraus ziehen)
  2. Das Problem verstehen (verdichten – welche Probleme sind besonders schwerwiegend?)
  3. Lösungsoptionen entwerfen (aufspannen – möglichst viele Ideen generieren)
  4. Lösungsoptionen einschränken (verdichten – auf die vielversprechendsten Ideen beschränken)
  5. Lösungsoptionen validieren (ausprobieren, Hypothesen testen, Feedback einholen)

Der grobe Ablauf einer Product Discovery

Eine hervorragende Sammlung von Methoden für Product Discoveries findet sich im Product Discovery Activity Guide der New York Times. Der einwöchige Google Design Sprint ist ebenfalls ein exzellentes Vorgehen hierfür.

Am Ende der Discovery muss klar sein, welches Problem gelöst werden soll. Warum ist es das wichtigste Problem? Für welche Zielgruppe wird das Problem gelöst? Was liefert das Produkt? Wie sieht es für die Zielgruppe aus? Welche Geschäftsziele verfolgt oder unterstützt das Produkt? Sind all diese Fragen beantwortet und strukturiert erfasst (Steckbriefe, Steckbriefe, Steckbriefe!), so ist eine starke Ausrichtung für das Vorhaben geschaffen. Die Leitplanken sind gesetzt, in dem sich die Umsetzung zukünftig bewegt.

4. Das Vorhaben strukturieren

Sind die Leitplanken gesetzt, können Product Owner und Team sich einen Überblick über notwendige Features/Stories und Umfang des gesamten Vorhabens verschaffen. Dazu empfiehlt sich eine Story Map. Das Vorhaben wird zunächst nach potentiellen Vorgängen (z.B. „Bezahlung“, „Produktsuche“) unterteilt. Die Vorgänge werden nach ihrer in der Praxis vermuteten zeitlichen Reihenfolge sortiert.

Zu jedem Vorgang sammeln PO und Team nun die notwendigen Features/Stories.

Nun haben wir einen sehr guten Überblick über die Stories unseres Vorhabens, nur sind nicht alle gleichermaßen wichtig. Daher wird die Map nach Releases aufgeteilt. Stories können verschoben werden, so dass sie für ein bestimmtes Release geplant werden. Im Zuge dieser Planung gibt es auch immer wieder Stories die einfach unwichtig sind und gestrichen werden können.

Im Laufe der Umsetzung sammelt ein Team kontinuierlich Erkenntnisse, die neue Features hervorbringen oder bestehende überflüssig werden lasse. Daher ist eine einmal erstelle Story Map auch nicht beständig und erfüllt ihren Zweck für mich vor allem in den ersten Wochen eines Vorhabens. Üblicherweise lasse ich nach den ersten Sprints die Features des Vorhabens in die Roadmap (die aber auch – je nach Geschmack – eine kontinuierlich gepflegte Story Map sein kann) einfließen. Nur Stories für die nächsten 2-3 Sprints liegen ausformuliert im Backlog.

Gute Artikel zum User-Story-Mapping finden sich hier und hier.

5. Schnell anfangen, schnell scheitern

Ist die erste User-Story-Map erstellt, kann die Umsetzung grundsätzlich beginnen.

Eine gute Methode, um einen ersten Prototyp zu erstellen, ist das Walking Skeleton. Das Walking Skeleton ist ein möglichst schnell errichteter Prototyp eines Vorhabens. Daten fließen vom Anfang bis zum Ende und alle beteiligten Systeme werden berührt. Dabei kommt es nicht auf Vollständigkeit, Stabilität, Eleganz oder Performance an. Das Walking Skeleton soll möglichst früh transparent machen, wo große technische Risiken (üblicherweise: Infrastruktur und unbekannte Technologien) schlummern und wie sie sich in der Praxis bemerkbar machen. So erhält das Team früh ein Gefühl dafür, wie damit umgegangen werden muss. Lassen sich einzelne große Risiken isoliert betrachten, empfiehlt sich eher ein Spike. Diese Methode lässt sich während der gesamten Umsetzung immer wieder einsetzen.

Bild von https://codeclimate.com/blog/kickstart-your-next-project-with-a-walking-skeleton/

Ein potentielles Ergebnis dieses risikobasierten Vorgehens kann auch sein, dass sich das Vorhaben nicht umsetzen lässt. Aber so wird es früh transparent und eben nicht erst zum Ende.

Zielorientierte agile Produktplanung

Agile , Planung     no comments    
AAgile Produktteams fokussieren sich gerne auf ihr Backlog. Jegliche Produktplanung darüber hinaus fällt schnell in die Kategorie „nicht agil“. Verständlich, schließlich erinnert „Planung“ an „Projektplan“. Tatsächlich kommt ein agiles Team mit einem nicht agilen Management in den Konflikt. Die eine Seite plant Sprint für Sprint, die andere will Budgets und Produktreleases planen – mindestens für ein ganzes Jahr. Das beißt sich.

Doch Produktplanung ist eigentlich eine sehr agile Vorgehensweise. Vor allem dann, wenn mit Zielen geplant wird. Klare Ziele die eindeutig darstellen, dass Mehrwert und Nutzen erreicht wird, motivieren ein Team loszulegen. Wie das Ziel erreicht wird, ist dabei aber völlig offen und läuft agil ab.

Im Zuge einer agilen und zielorientierten Produktplanung agiert ein Produktteam auf drei Ebenen. Vision, Roadmap und Backlog.

1. Die Vision

Die Vision bringt alle Gedanken und Ideen für die Neu- und Weiterentwicklung eines Produkts zusammen. Sie konkretisiert den Auslöser für das Vorhaben und motiviert alle Beteiligten loszulegen. Dabei hilft sie, indem Zielgruppe und deren relevanten Probleme/Bedürfnisse beleuchtet werden. Sie erfordert einen groben Umriss des neuen Produkts und stellt die Businessziele heraus. Kurz gesagt ist die Vision, das langfristige Ziel. Richtung und Erfolg der Produktentwicklung werden an ihr gemessen. Der Auftrag des Teams wird mit Stakeholdern geklärt.

Hört sich leicht an, oder? Ist es aber nicht, denn schon die Vision erfordert für viele ein Umdenken von einem Bauchgefühl hin zu einer Konkretisierung. Aber genau das ist das Wichtige, um sich nicht schon früh in einem diffusen Raum von unklaren Zielen und Vorstellungen zu verlieren.

Zwei Frameworks mit entsprechenden Steckbriefen zur Visionserstellung kann ich hierfür empfehlen:

Beide durchleuchten die relevanten Elemente einer Vision und helfen hier strukturiert vorzugehen. Die „Auftragsklärung“ beleuchtet die äußeren Rahmenbedingungen stärker.

Beide Ansätze helfen, sich auf das Wesentliche zu fokussieren:

  • Für welche Zielgruppe soll welches Problem gelöst werden bzw. welches Bedürfnis welcher Zielgruppe soll adressiert werden?
  • Welche Ziele setzt man sich für das Vorhaben?
  • Was soll das Produkt umfassen, was liefert es?

Man bewegt sich hier schnell in einem schwammigen Raum. Daher hilft es, solange alles immer wieder zu hinterfragen, bis es konkret wird. Mein Tipp: Die gute alte 5-Whys Methode anwenden. Nur so werden das wirkliche Problem, das echte Bedürfnis und das konkrete Ziel transparent. Schlechte Beispiele wie „Wir wollen die Daten verbessern“ und „Unsere Kunden sollen eine Software nutzen, die den neuesten UX-Anforderungen entspricht“ helfen niemanden.

Die Vision ist die Grundlage für die Roadmap und das Backlog.

2. Die Roadmap

In dieses Thema ist in den letzten Jahren viel Bewegung gekommen. Viele Blogs schreiben über die Product Roadmap für agile Produktteams. Trotzdem: Der Regelfall für agile Teams ist aber immer noch ein klassischer Projektplan („dann starten wir und dann sind wir mit genau diesen technischen Features fertig“) der für Auftraggeber erstellt wird. Doch genau diese Mentalität – ob vorgegeben oder frei gewählt – hilft einem agilen Team nicht.

Gibt man über eine Roadmap jedoch klare fachliche Ziele vor („Dieser Mehrwert für Kundengruppe Y soll bis Datum X erreicht werden“, „Dazu wollen wir bis Datum X befähigt sein“), kann das Team agil agieren, um das Ziel zu erreichen. Zudem beinhaltet die Roadmap pro Ziel Metriken, um die Erreichung zu messen. All das gibt ein Projektplan nicht her.

Zur Etablierung einer Product Roadmap empfehle ich ein Framework: Die GO-Roadmap von Pichler http://www.romanpichler.com/tools/product-roadmap/


go roadmap

Die GO Roadmap fokussiert sich auf bis zu vier Releases, die aus fünf beschreibenden Elementen bestehen:

  • Das Release-Datum, üblicherweise der letzte Tag im Quartal oder Monat
  • Der Release-Name
  • Das Release-Ziel das erreicht werden soll
  • Die Features die zur Erreichung des Release-Ziels notwendig sind
  • Die Metriken um die Erreichung des Ziels zu messen

Das Ziel beschreibt die Motivation hinter dem Release. Hier soll der Mehrwert klarwerden. Ein eher schwammiges Ziel („Funktionalität … wird released, optional auch Funktionalität …“) ist schnell aufgestellt und lässt zur Erfolgsmessung viel Spielraum zu, hilft aber auch niemanden so wirklich. Ein scharfes Ziel („Die neue Funktion … ermöglicht unseren Kunden … und erleichtert so ….“) ist die Basis für fokussierte und zielorientierte Arbeit. Natürlich ist ein scharfes Ziel von Anfang an verbindlicher.

Die aufgeführten Features zeigen die Funktionalität auf, die zur Erreichung des Ziels notwendig ist. Auch hier helfen eine fachliche Beschreibung der Funktionalität und keine technische Komponente.

Die Aufstellung von Metriken ist nicht einfach. Sie messen, ob das Ziel erreicht wurde (quantitativ und/oder qualitativ). Schnell neigt man zur Aufstellung von sog. Vanilla Metrics, also solchen Metriken die keinen wirklichen Mehrwert oder Erfolg messen. Ein Beispiel dafür sind Metriken á la „Die Anzahl der Visits erhöht sich um 45%“. Dies alleine macht keine Aussage über den Mehrwert eines Ziels – vermutlich ist jenes schon schlecht formuliert. Der Artikel Data-Driven Product Roadmaps – Choosing the Right Metrics erklärt die Arbeit mit Metriken sehr eingängig. Auch hier gilt wieder das Prinzip des Fragens nach Was und Warum.

Als eine mögliche Methode für die Erstellung einer Roadmap wird auch das User Story Mapping aufgeführt. Meiner Erfahrung nach bewegt sich ein Team damit zu früh auf der Story-Ebene und diese wandern dann zu früh in das Backlog. Erfahrungsgemäß lohnt sich die frühe Erstellung einer Vielzahl an Stories – lange vor ihrer Umsetzung – nicht. Der Weg der Umsetzung wird zu schnell festgelegt und lässt eher wenig Platz für neue Ideen. Und wer kennt es nicht: Alte User Stories werden fast immer kurz vor der Umsetzung wieder überarbeitet.

Zurück. Je nach Reife des Produkts und Volatilität des Umfelds (Organisation, Markt) wird die Roadmap monatlich oder quartalsweise angepasst. Sprich, bei einem noch jungen Produkt und/oder einem sich ständig änderndem Umfeld aktualisiert man monatlich. Erreicht das Produkt eine gewisse Reife und/oder beruhigt sich das Umfeld, kann man quartalsweise aktualisieren. Bei der Aktualisierung werden Team und relevante Stakeholder eingebunden. Dabei wird die Zielerreichung vom letzten Release analysiert und die nächsten Releases geplant.

3. Das Backlog

Inhalt und Priorisierung des Backlogs werde nun maßgeblich an Vision und Roadmap ausgerichtet. Für die Mehrheit der User Stories muss klar sein, wie sie auf Roadmap-Ziele einzahlen. Die Priorisierung richtet sich ebenfalls an dem Ziel aus. Ein guter Einstieg zu Priorisierungstechniken findet sich hier.

Features aus der Roadmap generieren Epics und/oder Themes für das Backlog. Die Walking-Skeleton Methode ist gut geeignet, um schnell einen zielgerichteten Prototyp anhand von Ziel und Features zu bauen. So lassen sich frühzeitig Komplexitäten aufdecken und die Richtigkeit des Ziels überprüfen.

Und alles zusammen…

Die drei Ebenen der Produktplanung

Die drei Ebenen der Produktplanung Vision, Roadmap und Backlog ermöglichen einem Team über einen längeren Zeitraum zu planen und dabei agil zu bleiben. Aber: In Zielen zu denken erfordert Umdenken. Den Problemraum zu erforschen erfordert Umdenken. Erfolg ehrlich zu messen erfordert Umdenken. Nicht resignieren, wenn beim ersten Versuch noch nicht alles klappt. Ausprobieren, Team und Stakeholder einbinden, Probleme verstehen, Probleme lösen und wieder probieren. Und nicht vergessen: Eine One-Man Show des Product Owner ist nicht sinnvoll. Alle – Team, ScrumMaster, Stakeholder – müssen für eine Produktplanung am selben Strang ziehen.