• 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

The post Starke Ausrichtung für agile Produktteams appeared first on Reza Nazarian.

Agilität basiert auf agilen Werten

Meiner Meinung nach wird Agilität oder eine Methode nicht falsch verstanden. Vielmehr wird nur auf die Methode geschaut und diese umgesetzt. In der Hoffnung, Produkte schneller und besser zu entwickeln. Dabei entsteht nur etwas mechanisches, aber nichts substanziell Neues. Vor einiger Zeit lernte ich einen agilen Coach kennen, der eine Organisation zuallererst auf die agilen Werte besann und ihr dabei half, diese zu verstehen und sie zur Verbesserung ihrer Arbeit einzusetzen. Ich beobachtete während der täglichen Arbeit viele tiefgehende Erkenntnisse der Kollegen und die aktive Auseinandersetzung mit der eigenen Arbeit und den eigenen Werten dazu. Die Methodik haben die Kollegen in kleinen Schritten etabliert. Das begeisterte mich, da auch für mich der übliche Weg war, entweder Scrum oder Kanban einzuführen.

Zur Erinnerung, die Werte aus dem agilen Manifest sind:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Scrum fügte vier weitere Werte hinzu:

• Fokus
• Mut
• Offenheit
• Commitment
• Respekt

Ich will diese Werte hier nicht erklären, dazu empfehle ich diesen kurzen Artikel.

Diese Werte sind für mich ohne Zweifel auch heute noch gültig und hilfreich. Blicke ich jedoch auf moderne agile Produktentwicklung, so fehlt mir in den bisherigen Werten Eindeutigkeit bezüglich Nutzerzentrierung, Schaffung von Mehrwerten, Bereitschaft zum Lernen und Streben nach Exzellenz.

Moderne Werte mit Modern Agile

Joshua Kerievsky adressierte 2016 mit Modern Agile, dass sich die agile Welt seit der Niederschrift des agilen Manifests in 2001 weitergedreht hat. So stellte er vier sehr konkrete Werte auf, die aber auf den bestehenden basieren. Die Werte aus Modern Agile passen zu meiner Arbeit in der agilen Produktentwicklung und spiegeln wieder, wonach ich dabei strebe.

1. Make People Awesome

Produkte werden vom Produktteam umgesetzt. Gute Produkte werden von einem guten Team geschaffen. Produkte werden von den Nutzern eingesetzt. Erfolgreiche Produkte werden von zufriedenen Nutzern zu diesen gemacht. Produktteam und Nutzer: Es geht um Menschen, die wir für die erfolgreiche Produktentwicklung in den Mittelpunkt rücken. Prozesse und Werkzeuge haben dort weniger etwas zu suchen.

Konkret heißt das, dass wir Nutzer verstehen und deren Bedürfnisse adressieren müssen, um begeisternde Produkte zu entwickeln. Für die Produktentwicklung rücken wir Nutzer und nicht uns selbst ins Zentrum. Und es heißt ebenso, dass wir Teams verstehen, deren Bedürfnisse adressieren und wir unsere Ziele mit ihnen teilen, um ein begeistertes Team entwickeln zu lassen. Für den Erfolg rücken wir das Team und nicht uns selbst ins Zentrum.

Relevante Stakeholder binden wir aktiv ein und entwickeln Empathie für ihr Handeln und ihre Bedürfnisse. Kurz gesagt: Alle Menschen, die ein großes Interesse an unserem Produkt haben, werden nicht ausgegrenzt, sondern verstanden, eingebunden, inspiriert und informiert. Das ist eine der Grundlagen für erfolgreiche Produkte.

Hey Product Managers, Your Customers are Humans

2. Deliver Value Continuously

Continuous Delivery ist eine großartige Sache. Produktteams können Software schnell produktiv stellen. Aus Nutzersicht ist die Aussage „Wir liefern alle zwei 2 Wochen eine neue Software“ irrelevant. Vielmehr sollte sie „Wir liefern alle 2 Wochen Mehrwerte“ lauten. Hiermit fokussiert sich ein Team viel mehr auf die Nutzer des Produkts und somit auf Mehrwerte. Und das erfordert in Teams und Organisationen ein Umdenken. Weg von der Feature-Factory. Hin zur tiefen Durchdringung und Qualifizierung von Nutzerproblemen, um den Wert von neuen Features danach zu gewichten. Ein Produktteam, das kontinuierlich Wert liefern will, muss sich intensiv mit Nutzer und deren Problemen auseinandersetzen. Zudem erfordert es, Erfolg messbar zu machen und diesen auch zu messen.

“The key to [defeating] waterfall is to realize that agilists value Outcomes over Features. The feature list is a valuable tool, but it’s a means not an end. What really matters is the overall outcome, which I think of as value to the customers.” Martin Fowler

3. Experiment And Learn Rapidly

Je länger eine Planung dauert, desto überflüssiger und falscher wird sie. Realität überholt Planung in Lichtgeschwindigkeit. Die Zeit die wir für zähe Diskussionen und komplexe Konzepte aufwenden, können wir doch lieber in eine schnell startende und iterative Umsetzung investieren. Und große Fragen und Unsicherheiten, lösen wir doch nicht durch theoretische Übungen. Wenn wir einfache Hypothesen aufstellen und diese schnell durch Experimente (z.B. mit Prototypen) beweisen oder widerlegen, haben wir etwas in der Hand (z.B. Nutzerfeedback, erlebte technische Unwägbarkeiten). Etwas ganz konkretes und erlebtes, anhand dessen wir lernen. Wir lernen, ob die Idee tragbar ist und in welche Richtung sie sich weiterentwickeln sollte.

Stehen ganz neue Themen an, empfehle ich eine schlanke aber intensive Methode wie den Design Sprint. Zur Bearbeitung kleinerer neuer Ideen empfehle ich A/B-Tests, Feature Toggles etc.. Für alles gilt: durch schnelles Experimentieren lernen Produktteam und Nutzer immer mehr über Probleme und deren Lösungen. Schritt für Schritt.

Hi Everyone:

Just a quick reminder that in-person debates are a terrible way to test the merits of ideas.

All they test is the verbal agility and rhetorical style of their participants.

Signed,
A Very Successful College Debator

— Carissa Byrne Hessick (@CBHessick) August 10, 2018

4. Make Safety A Prerequisite

Sicherheit ist eine Grundvoraussetzung, für Leistungsfähigkeit. Und somit für Kreativität, Mut, und Begeisterung. Ein Umfeld, das von Kontrolle und Misstrauen geprägt ist, bietet keine Sicherheit. Hier zählen Konformität und Einhaltung von Prozessen mehr als gute Ideen. Finden Menschen in so einer Umgebung gute Lösungen und kreative Ideen? Nein, denn das könnte zur Bestrafung führen. Daher gilt für uns, Sicherheit als eine der Voraussetzung für erfolgreiche Arbeit zu schaffen. Sicherheit schaffen wir durch Vertrauen und Verantwortungsverteilung. Dies ist die neue Aufgabe vom Agile Leadership.

Ganz wichtig: Erst durch die Sicherheit können die ersten drei Werte ihre Wirkung entfalten.

The post Modern Agile – Moderne Werte appeared first on Reza Nazarian.

Nach diesen vier Prinzipien gehe ich dabei vor:

• Für welche Zielgruppe lösen wir Probleme bzw. welches Bedürfnis welcher Zielgruppe adressieren wir?
• Welche Ziele verfolgen dieses Vorhaben?
• Was soll das Vorhaben umfassen, was liefert es?
• Und zuletzt: 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 Power-Interest-Matrix an, die Roman Pichler hier vorstellt.

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.

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 benötigen wir? Wie sieht der finanzielle Rahmen aus?
• Output – Was bekommen die Kunden zu sehen? Timings?
• Outcome – Woran messen wir den Erfolg des Vorhabens?

Ich empfehle, pro Feld maximal vier, besser nur zwei präzise formulierte Punkte zu verfassen. Besser ausgedrückt, ist die fertige Auftragsklärung schnell verständlich und eingängig. 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 holen wir alle Beteiligten früh ins Boot.

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. Infolgedessen läuft sie so ab:

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. Einschränken (verdichten – auf die vielversprechendsten Ideen beschränken)
5. Validieren (ausprobieren, Hypothesen testen, Feedback einholen)

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? Das gleiche gilt für das Produkt: 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

Nach Erstellung der ersten User-Story-Map, 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 berühren alle beteiligten Systeme. Dabei kommt es nicht auf Vollständigkeit, Stabilität, Eleganz oder Performance an. Das Walking Skeleton macht möglichst früh transparent , 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 es damit umgehen will. 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.

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.

The post Komplexität kontern appeared first on Reza Nazarian.

Doch was passiert, wenn das besagte Team anfangen will, agil zu arbeiten? Zunächst hilft es, wenn das Team cross-funktional aufgestellt wird. Das Team verfügt über alle Fähigkeiten, sein Produkt mit möglichst wenig spürbaren externen Abhängigkeiten umzusetzen. Beispielsweise kann ein cross-funktionales Entwicklungsteam sein Produkt entwickeln, testen, produktiv stellen und betreiben. Und es organisiert sich dabei selbst, so dass Umsetzung, Zusammenarbeit und Vorgehensweise selber bestimmt werden. Zweck und Sinn des Produkts sind klar herausgearbeitet. Der Fokus des Teams liegt darauf, kontinuierlich wertvolle Produktinkremente zu liefern und nah am Kunden zu sein.

Erste Hürde: Alte Organisationsstruktur

Das erste was Teams in der Transition zur Cross-Funktionalität und Selbstorganisation im Wege steht sind alte Organisationsstrukturen. Und ist das agile Team mit Spaß und Selbstbewusstsein unterwegs, stellt es auf einmal diese alten Strukturen infrage und lässt diese (hoffentlich) bröckeln. Aber wie kommt es dazu? In einer hierarchischen Organisation gibt es funktionale Teams (Entwickler, Projektleiter, Tester etc.). Ein cross-funktionales Team setzt sich aus Mitgliedern der funktionalen Teams zusammen – die Hierarchie bleibt aber bestehen. Die Mitarbeiter des cross-funktionalen Teams, die sich eigentlich auf das eine Produkt ausrichten möchten, berichten weiterhin ihren ursprünglichen Abteilungsleiter. Das heißt, dass das Team weiterhin im Einflussbereich von mehreren Abteilungsleitern steht. Das führt zu Konflikten, wenn jeder Abteilungsleiter seine Abteilungsinteressen weiterhin in dem Team verfolgt und verhindert, dass das Team seinen Job gut macht.

Erste Hilfe: Abbau von Organisationsstruktur

Nach der Einführung von Agilität auf Teamebene, ist der nächste Schritt also die Veränderung der Organisationsstruktur. Genauer gesagt, der Abbau. Eine Matrix-Organisation hilft aus meiner Sicht erstmal wenig. Sie ist nur ein Versuch, die alte Struktur zu retten. Die Matrixorganisation hat ihren Fokus eher darauf, die Auslastung zu optimieren. So fördert sie auch weiterhin Abteilungsinteressen und weniger die Leistungsfähigkeit von Produktteams. Was hierarchische Organisationen hervorgebracht haben, sind Misstrauen, Kontrolle, Intransparenz und Distanz.

Der Abbau von alten Strukturen bedeutet, dass jedes Produktteam zu einer abgeschlossenen Organisationseinheit wird. Doch was für einen Schritt muss die Organisation hierfür gehen? Keinen kleinen, soviel ist klar. Denn es findet ein Wechsel weg von Misstrauen, Kontrolle, Intransparenz und Distanz (die alte Industriekultur) statt. Weniger Führungskräfte als vorher sind für ein Produktteam verantwortlich. Verantwortlich in dem Sinne, dass sie alles tun, damit Teams gut arbeiten. Weniger Führungskräfte bedeutet auch Aufbau des Vertrauens, Förderung der Verantwortung (für erste Schritte empfehle ich Delegation Poker) – bei gleichzeitiger Erhöhung der Transparenz (woran arbeitet ein Team? Warum? Ist das Team erfolgreich?).

Das alles umfasst die beiden Prinzipien von Agile Leadership: Servant Leadership und Alignment.

Servant Leadership – Alles tun, damit Teams gut arbeiten

Mit diesem neuen Begriff tun sich viele Leute schwer. Mit Servant – Diener – verbinden Führungskräfte Machtverlust und Unterwürfigkeit. Aber es beschreibt sehr gut die neue Rolle der Führungskraft. Diese sorgt zukünftig dafür, dass das Team seine Arbeit gut machen kann. Dazu gehört, dass dem Team Hindernisse aus dem Weg geräumt werden. Ein Beispiel dafür sind die eingangs erwähnten alten Organisationsstrukturen. Hier wird auch klar, was der Unterschied zum ScrumMaster ist, der auf Teamebene ebenfalls Hindernisse beseitigt. Der agile Leader ist Führungskraft und hat das Mandat, dem Team innerhalb der Gesamtorganisation den Weg zu bahnen. Weitere Beispiele sind die Neuorientierung von Verträgen mit Dienstleistern und Zulieferern.

Als Führungskraft hat der agile Leader die Aufgabe, die passenden Rahmenbedingungen für das Team zu schaffen. Ein typisches Beispiel hierfür ist die Schaffung eines Recruiting-Prozesses, der so gut wie möglich auf das Team zugeschnitten ist.

Alignment – Ausrichtung geben

Jedes Produktteam möchte seine Produkte erfolgreich sehen. Doch was ist eigentlich Erfolg? Und wie weit ist das Team vom Erfolg entfernt? Hier kommt die zweite wichtige Eigenschaft des agile Leaders ins Spiel: Alignment. Die Führungskraft gibt nicht mehr vor, was zu tun ist. Sie definiert für ein oder mehrere Produktteams Ziele und Metriken, um die Zielerreichung zu messen.

Gemessen wird kontinuierlich, damit alle wissen, wie weit die Zielerreichung noch entfernt ist. Die Artefakte einer Führungskraft sind hier Vision, Roadmap und Strategie. Je klarer und je messbarer diese Artefakte sind, desto eher ermöglichen sie dem Team Ausrichtung für dessen Arbeit. Eine klare Ausrichtung ist die Grundlage für Priorisierung von Themen und die Auswahl von Features (was ist wichtig, was nicht? was ist Pflicht, was ist Kür?).

Das Produktteam plant basierend auf der Ausrichtung des agile Leaders seine Produktvision, seine Produktroadmap und sein priorisiertes Backlog. Die Führungskraft führt hier durch konsequente Ausrichtung.

Verschwinden nun die meisten Führungskräfte?

Agile Führungskräfte fokussieren sich auf Servant Leadership und Alignment. Um diese beiden Eigenschaften auszufüllen, rückt die Führung wieder in den Vordergrund. Es kommt bei einem agile Leader weniger darauf an, dass er nach jahrelanger guter fachlicher Arbeit befördert wird. Vielmehr kommt es darauf an, dass ein agile Leader gute Führungseigenschaften mit sich bringt. Sind sie Führungskraft? Überlegen sie sich doch mal für sich selbst: Wie viel beschäftigen sie sich mit Management, wie viel mit Führung (siehe auch dieser Artikel dazu)?

Um auf die obige Frage zu antworten: Jein. Die meisten Führungskräfte verschwinden nicht. Sie richten sich vor allem neu aus, aber das wird sicherlich nicht jedem liegen. Schließlich geht es weg von steiler Hierarchie, hin zur Arbeit auf Augenhöhe. Ob einzelne Führungspositionen wirklich wegfallen, hängt stark von der Komplexität der Führungsstrukturen im Unternehmen ab. Je komplexer und je mehr Führungskräfte, desto höher die Wahrscheinlichkeit, dass für gut selbstorganisierte und ausgerichtete Teams weniger Führungskräfte benötigt werden.

Artikelbild lizensiert von shutterstock

The post Agile Leadership – Wo bleiben die Führungskräfte? appeared first on Reza Nazarian.

Product Owner = Superman?

Das Lesen von Artikeln auf medium und die Teilnahme an Konferenzen wie MTP formen das Bild des Product Owners des allwissenden Supermans. Er muss einen riesigen Wissensschatz mitbringen, um das Wunderwerk zu vollbringen:

• Stories schreiben
• Backlog priorisieren
• Visionen erschaffen
• Roadmaps bauen
• Marktforschung betreiben
• Stakeholder verstehen und organisieren
• Kreativ-Workshops durchführen
• Innovation vorantreiben
• Produkte vertreiben
• User Experience ermöglichen
• Business Modelle ausdenken
• Finanzvorhersagen treffen

Dass dies relevante Aufgaben eines POs sind, ist richtig. Dass ein PO sich aber perfekt (inkl. vieler Methoden und Tools) und aus dem Stand mit allem auskennen muss, nicht. Ich will mich nun einmal auf die Kernfähigkeiten eines POs zurückbesinnen.

Was sind die Kernfähigkeiten des Product Owners?

Trennen wir uns mal von jeglicher Methodik, Vorgehensweise und von Tools. Was bleibt dann eigentlich noch übrig, mit dem sich ein PO richtig gut auskennen muss?

• Das Wichtige vom Unwichtigen unterscheiden
• Die wirklichen Probleme und Bedürfnisse von Kunden erkennen und adressieren
• Komplexitäten durchdringen
• Empathisch gegenüber Team und Stakeholdern agieren
• Von einer klaren Linie überzeugt sein, Nein sagen können

Diese Fähigkeiten (die erlernbar sind) sind das Fundament eines jeden Product Owners. Er läuft sonst Gefahr, sich immer mehr und mehr zu verlaufen, bevor sein Fundament steht. Überspitzt dargestellt: Design-Thinking, MVP, OKR und Lean Startup helfen auf der einen Seite nicht, wenn sich der PO mit unwichtigen Features beschäftigt, am Kunden vorbei plant, das Produkt nicht versteht, sich von Team bzw. Stakeholdern gelöst hat und nur situativ reagiert. Die genannten Methoden erfordern aus meiner Sicht erst das genannte Fundament. Hier ist der PO kein besserer PO, wenn er besonders viel davon kennt, sondern wenn er verstanden hat, wofür er sie einsetzt, und wie sie ihn schneller und besser machen.

Muss ein Product Owner technische Kenntnisse haben?

Nein, aber sie helfen eigentlich immer! Treffen sich Team und PO auf der Architektur-Ebene, finden beide Seiten einen einfacheren Zugang zueinander. War der PO früher selber Entwickler, versteht er es, dass die Lösung zunächst einfacher Probleme mehrere Tage dauern können. Es fällt beiden Seiten leichter, über technische Schuld, Refactoring und Tech-Stories zu sprechen.

Kennt oder beschäftigt sich der PO nur mit der fachlichen Seite, sehe ich ein Risiko: Die Isolation vom Team / der Elfenbeinturm (ein übliches PO-Antipattern). Das muss nicht passieren, wenn beide Seiten über Empathie verfügen und die jeweils andere Seite respektieren. Doch ein isolierter PO kann in Discoveries, unzähligen Canvasses usw. abdriften. Er verliert dann immer die Bindung ans Team, weil ihn kaum noch jemand versteht. Einen schönen Artikel dazu gibt es hier.

Wieder auf den Boden der Tatsachen zurückfinden

Die Suche nach dem PO-Superman ist nicht sinnvoll. Man wird ihn nur schwer finden. Diese Notwendigkeit ist stark aus dem Rockstar-Image des Product Owners geboren. Methoden und Werkzeuge sind nur Mittel zum Zweck. Sie einzusetzen, um gefühlt dran zu bleiben, hilft nicht. Wenn man aber das konkrete Problem/die Komplexität verstanden hat und sie versucht zu durchdringen, ist es richtig, die passende Methode zur Lösung zu suchen.

Dann teilen wir die Rolle einfach?

Aber ich möchte wieder zur langen Liste von Aufgaben zurückkehren. Das breite Spektrum lässt sich mit den genannten Kernfähigkeiten inhaltlich gut adressieren, es bleibt aber viel Arbeit. Ist das Produktteam groß, die Stakeholder-Landschaft komplex oder die Anzahl der Produkte groß, so muss sich der PO mit der Skalierung seiner eigenen Rolle beschäftigen. Dazu hat Roman Pichler drei sinnvolle Optionen beschrieben. Kurz gesagt managed der PO ein PO-Team (z.B. mit einem Business Analysten und einem UX-Experten) oder das Produkt wird zerteilt. Meiner Meinung nach sind das die richtigen Optionen. Beim PO-Team ist liegt die Verantwortung immer noch beim PO und nicht verteilt. Die Zerteilung von Produkten ist nicht einfach, schafft aber auch klare Strukturen. Ein sehr ungünstiges Modell ist die Zerteilung der PO-Rolle in ein Zwei- („PO-Technisch“ und „PO-Fachlich“), Drei- („PO-Technisch“, „PO-Fachlich“, „PO-Management“) oder gar Viergestirn („PO-Technisch“, „PO-Fachlich“, „PO-Organisatorisch“, „PO-Feelgood-Management“). Zum Einen entsteht diese Zerteilung meist am Reißbrett und hat ihren Ursprung in alten Abteilungsstrukturen (Produktmanagement, Software-Development, Projektleitung). Zum Anderen fördert eine solche Konstellation komplexe und unklare Wege in Kommunikation, Entscheidung und Verantwortung.

The post Was muss ein Product Owner können? appeared first on Reza Nazarian.

Doch Produktplanung ist eigentlich eine sehr agile Vorgehensweise. Vor allem dann, wenn wir mit Zielen planen. Klare Ziele, Mehrwert und Nutzen, motivieren ein Team loszulegen. Wie wir das das Ziel erreichen, 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 wir Zielgruppe und deren relevanten Probleme/Bedürfnisse beleuchten. 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:

• Product Vision Board von Pichler http://www.romanpichler.com/tools/vision-board/
• Auftragsklärung von Xing https://auftragsklaerung.com/

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 lösen wir Probleme bzw. welches Bedürfnis welcher Zielgruppe adressieren wir?
• 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/

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

Roadmap-Ziel

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.

Roadmap-Features

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.

Roadmap-Metriken

Die Aufstellung von Metriken ist nicht einfach. Sie messen, ob wir das Ziel erreicht haben (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.

Roadmap-Methodik

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.

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 analysieren wir die Zielerreichung vom letzten Release und planen die nächsten Releases.

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 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.

The post Zielorientierte agile Produktplanung appeared first on Reza Nazarian.

• Stakeholder außerhalb des Teams denken weiterhin in Aufwandsschätzungen, Projektbudgets, Gantt-Charts und Ressourcen („1 Entwickler braucht 4 Tage, 2 brauchen 2“). Story Points und Team-Velocity werden mit hoher Komplexität auf die alten Artefakte umgerechnet.
• Das Entwicklungsteam entscheidet sich für die Verwendung von idealen Manntagen. Es hat aber keinen sinnvollen Umgang mit externen Abhängigkeiten und Risiken gefunden. Ein Teil des Teams schätzt risikoreiche Stories höher als der andere Teil der nur in ideale Manntage schätzt.
• Der Fokus des Schätzens liegt auf der Zahl an der Story. Ob nach Abarbeitung der Story die Schätzung gut oder schlecht war, ist zweitrangig. Das Team lernt nicht daran.

Ist diese Zahl wirklich so wichtig?

Die Idee des Schätzens im agilen Kontext ist, dass das Team an seinen Schätzungen lernt. Es baut ein gemeinsames Verständnis zu Anforderungen, Zielen und Machbarkeit auf. Doch ist die geschätzte Zahl an einer Story wirklich so wichtig für das Entwicklungsteam? Ich meine, dass das Schätzen nur Mittel zum Zweck ist. Sobald ein Team gut darin ist, Stories zu durchdringen, zu verstehen und sie anhand von Komplexitäten zu zerteilen oder zusammenzuführen, ist die eigentliche Zahl überflüssig. Denn wenn das Team ein verlässliches Gefühl dafür entwickelt, welche Stories zusammen in einen Sprint passen, hilft die Zahl nicht mehr. In der Praxis hieße das, dass wir so etwas wie ein Backlog-Refinement weiterhin nutzen, um Stories vorzustellen, zu hinterfragen und anders zu strukturieren. Die Schätzrunde fällt aber weg.

Von der Altlast zum Lernen

Der Fokus der agilen Transition eines Teams liegt daher zunächst darauf, dass die Schätzungen eines Teams nur dem Team dienen sollen. Das bedeutet, dass das Team nicht deswegen schätzt, um externe alte Prozesse zu bedienen (die Erreichung dieses Ziels ist in vielen Organisation eine große Aufgabe). Sehr hilfreich ist auch die Einführung der Komplexität für Story Points. In idealen Manntagen geschätzte Stories lassen sich sicherlich gut in alte Strukturen hinein berichten. Übliche Risiken und externe Abhängigkeiten fließen aber gar nicht in die Schätzung mit idealen Manntagen ein. Diese sind also nur bedingt hilfreich.

Als Nächstes lernt das Team anhand der Schätzung, Sprints optimal auszulasten und ob an der Schätzung etwas verbessert werden muss. Wenn das länger sicher funktioniert kann auf die eigentliche Schätzzahl verzichtet werden.

The post Schätzung – Die Spitze des Eisbergs appeared first on Reza Nazarian.

CamScanner

CamScanner erfasst den Inhalt von Whiteboards, Flipcharts und sonstigen Dokumenten. Die Ränder des Dokuments oder des Boards werden zuverlässig erkannt, wenn auch nicht ganz so wie bei Office Lens. Sehr gute Lichtverhältnisse sind erforderlich – eine Nachjustierung per Hand ist aber einfach möglich. Die Aufnahme wird danach – je nach Auswahl – automatisch optimiert oder es wird händisch ein Verfahren gewählt (z.B. nur Aufhellen). Aufnahmen lassen sich im Einzel- oder Batch-Modus vornehmen, um diese dann zu einem Dokument zu arrangieren. Jede Aufnahme bildet dabei eine Seite. Ist man damit fertig, wird das Dokument als PDF oder JPG exportiert und in gängige Speicher- und Notizdienste (Dropbox, Evernote, Google Drive, iCloud, OneNote) geladen. Ebenso kann das Dokument gedruckt oder per Email versendet werden.

Diese App setze ich in den meisten Workshops ein. Zuschneiden und Auswahl von vorgefertigten Verfahren zur Optimierung geht schnell von der Hand. Das Arrangieren von einzelnen Aufnahmen zu einem Dokument und der anschließende Export ist leistungsfähig. Auch wenn mir die automatische Aufbereitung der gesamten Aufnahme bei Office Lens und die Einzel-Optimierung von Haftnotizen bei Post-it Plus besser gefällt, ist CamScanner das leistungsfähigere Gesamtpaket.

• Hersteller: INTSIG
• Preis: 1,99 – 4,99$
• iOS: Link
• Android: Link

Office Lens

Eine schlanke Alternative zum CamScanner. Diese App von Microsoft erkennt – je nach Vorauswahl – Dokumente (inkl. Flipcharts), Whiteboards, Fotos oder Visitenkarten. Eine einfache automatische Aufbereitung mit Entzerrung und perspektivischer Korrektur des Fotos findet auch statt.

Darüber hinaus gibt es eine Exportfunktion die für eine oder mehrere Aufnahmen Microsoft-Applikationen (OneNote, OneDrive, Word, PowerPoint und Outlook) bedient, nach PDF konvertiert oder per Email versendet.

Alles in allem liefert die App sehr gute Ergebnisse. Erkennung des Hintergrunds und  automatische Aufbereitung klappen in den allermeisten Fällen hervorragend – gute Lichtverhältnisse vorausgesetzt. Zuverlässig sind dabei auch Entzerrung und perspektivische Korrektur. Im Vergleich zu CamScanner fehlt allerdings eine erweiterte Funktionen zum Export. Erkennung des Hintergrunds und automatische Aufbereitung sind etwas leistungsfähiger als beim CamScanner.

• Hersteller: Microsoft
• Preis: Gratis
• iOS: Link
• Android: Link

Post-it® Plus App

Hier liegt der Fokus auf das digitale Einsammeln von Haftnotizen. Die App erkennt einzelne Notizen auf Hintergründen, isoliert und optimiert sie einzeln. Extrahierte Notizen können verschoben und neu arrangiert werden. Sehr hilfreich, wenn nach einem Workshop mit einem verteilten Team weiter gearbeitet wird. Hierfür gibt man die Ergebnisse einfach Kollegen frei. Die Exportfunktion sieht u.a. PDF, Powerpoint und Dropbox vor.

Die Extraktion klappt sehr gut, auch die Aufbereitung der einzelnen Notizen. Die Ergebnisse sehen sehr sauber und ansehnlich aus. Erforderlich ist aber – neben guten Lichtverhältnissen – sichtbarer Abstand zwischen den Haftnotizen. Wer gerne mit Haftnotizen arbeitet und die Ergebnisse sauber in digitale Form überführen möchte (für Präsentationen, für die weitere Arbeit mit verteilten Teams) für den ist diese App sehr hilfreich.

• Hersteller: 3M Company
• Preis: Gratis
• iOS: Link

Time Timer

Diese App bildet die beliebte Time Timer in einer digitalen Variante ab. Mit der App lassen sich wie beim physikalischen Pendant Countdowns einstellen, die nach Ablauf einen Alarm abspielen. Der Countdown wird mit dem Finger eingestellt.

Der minimalistische Countdown ist das Basis-Tool für alle mit Timeslots durchgetaktete Workshops. Gegenüber der physikalischen Variante spart die App viel Platz im Gepäck.

• Hersteller: Time Timer
• Preis: 0,99$ – 2,99$
• iOS: Link
• Android: Link

POP – Prototyping on Paper

Mit POP lassen sich einzelne Aufnahmen zu einem Prototypen mit GUI und User-Flow arrangieren. Das klappt in Windeseile und so lassen sich Ideen und Lösungsansätze schnell ausprobieren.

Die Aufnahmen werden wie Screens ins Applikationen behandelt. Dazu malt man den Screen auf Papier, nimmt ihn mit dem Smartphone auf und schneidet ihn zu. In den Screens markiert man beliebige Flächen und weist diesen ein Klick- / Tapverhalten zu. So ein Verhalten ist die Transition von einem Screen auf einen anderen. Ebenso lassen sich Gesten der Transition auf einen weiteren Screen zuordnen.

Die App ist unverzichtbar, wenn in kurzer Zeit Prototypen von Apps gebaut werden. Perfekt für Ideation-Workshops geeignet, mindestens ein Smartphone pro Arbeitsgruppe vorausgesetzt.

Der Preis der App richtet sich nach der Anzahl der Projekte die mit POP bearbeitet werden. Die Gratis-Variante erlaubt immerhin 2.

• Hersteller: Microsoft
• Preis: 0 – 25$
• iOS: Link
• Android: Link

The post Hilfreiche Apps für erfolgreiche Workshops appeared first on Reza Nazarian.

Ich stelle hier ein paar Tipps vor, die hilfreich zur Etablierung eines guten Stakeholder-Managements waren. Wie zu Beginn von neuen großen Aufgaben ist auch hier zunächst Überblick und Priorisierung wichtig.

1. Mit einer Stakeholder-Matrix priorisieren

Wer sind eigentlich Stakeholder? Jeder der ein Interesse am Produkterfolg hat, beispielsweise…

• Fachabteilungen
• Abhängige Produktteams
• Vertrieb
• Marketing
• Produktmanager
• Führungskräfte aus dem Umfeld des Teams
• Geschäftsführung

Da kommen sehr schnell sehr viele Personen zusammen. Das erschwert die Einbindung ungemein und blockiert das gemeinsame Vorankommen. Bevor willkürlich nur die Lieblings-Stakeholder ausgewählt werden, empfehle ich zunächst den Aufbau einer Stakeholder-Matrix. Einfach und bewährt ist das Power-Interest Grid, das Colin Eden und Fran Ackermann in ihrem Buch „Making Strategy“ veröffentlicht haben.

Stakeholder werden über vier Quadranten verteilt, abhängig von dem Interesse am Erfolg des Produkts und dem Einfluss auf Organisation und Produktentwicklung. Diese Einteilung hilft, um die Stakeholder zu identifizieren, die die Produktentwicklung vorantreiben können und wollen. Folgende Einteilung ergibt sich:

• 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.

2. Mit den Playern Zusammenarbeiten, Subjects einbinden

Für die Ausarbeitung von Vision, Strategie, Roadmap und Backlog übernimmt das Produktteam die Ownership, Player werden aber aktiv eingebunden – nur so wird Akzeptanz hergestellt. Workshops wie regelmäßige Roadmap-Updates oder die Ausarbeitung der Produktvision werden also mit ihnen vorbereitet und durchgeführt.

Was die Team-Meetings angeht, werden Stakeholder nur zum Sprint-Review eingeladen. Hier sehen die das Produkt-Inkrement und geben Feedback, ob alles in die richtige Richtung geht. Stand-Ups, Plannings, Refinements und Retrospektiven fokussieren sich auf das Team. Die Anwesenheit von Stakeholdern dort ist kontraproduktiv.

3. Warum? … Warum? … Nein!

Auch wenn es anstrengend werden kann: Um aus Anforderungen Features werden zu lassen, müssen alle Beteiligte Inhalt und Mehrwert verstehen. Das ist die Grundlage, damit Entwickler nicht nur Arbeit nach Vorschrift machen. Der Product Owner hinterfragt jeden relevanten Input der Stakeholder so lange, bis Inhalt und Mehrwert verständlich sind. Die kontinuierliche Hinterfragung und das Liefern der Antworten ist meistens anstrengend, aber nur trennen sich unausgegorene Themen von wichtigen.

Jeder Product Owner darf „Nein“ zu seinen Stakeholdern sagen. Wenn Anforderungen und Ideen schwammig sind oder einfach nicht passen, lehnt er sie besser ab. Wenn spontane Anforderungen gemeinsame Planungen und Strategie torpedieren, ist ein „Nein“ angebracht.

4. Empathie angewöhnen

Ist die Beziehung zwischen Produktteam und Stakeholder distanziert, so lassen sich auch entsprechende Verhaltensmuster beobachten.

• Produktteam: „Wir wissen am besten, was richtig und falsch für unser Produkt ist“
• Produktteam: „Stakeholder nerven nur“
• Stakeholder: „Das Team arbeitet echt langsam“
• Stakeholder: „Die wollen mitreden, obwohl die gar nicht wissen, was wichtig ist“

Hier sind erste Annäherungsschritte wichtig und beide Seiten gewöhnen sich am besten eine Portion Empathie an. Dem Produktteam sollte klar werden, dass Stakeholder einem Produktteam viel Vertrauen entgegen bringen. Sie verlassen sich auf teure Spezialisten, die richtigen Produkte zu bauen. Aber auch das Produktteam erwartet, dass Stakeholder ihre Arbeitsweise und Bedürfnisse verstehen.

5. Zur gemeinsamen Planung stehen

Nach gemeinsamer Ausarbeitung von Vision, Zielen, Roadmap etc. sollten diese auch als bindend angesehen werden. Die gemeinsame Planung ist die Grundlage der Zusammenarbeit und der Produktentwicklung. Auch hier hilft ein klares „Nein“ vom Product Owner. Das gilt auch für die Stakeholder. Inkonsequenz und es allen recht machen zu müssen, ist Zeitverschwendung.

The post 5 Tipps für gutes Stakeholder-Management appeared first on Reza Nazarian.