Was ist der Unterschied zwischen agilem Produktmanagement und klassischem Projektmanagement?
Typischerweise denken wir im Projektmanagement in den Entwicklungsschritten:
- Anforderungen
- Entwurf
- Implementierung
- Überprüfung
- Wartung
Jeder Schritt wird in der Laufzeit des Projekts einmal durchlaufen.
Agiles Produktmanagement funktioniert anders:
Wir nutzen Feedback.
Feedback vom Markt, den Stakeholdern und aus der Zusammenarbeit im Team. Nur Feedback macht aus einem einmal durchlaufenen Prozess einen wiederkehrenden, sich selbst fütternden Prozess. Ein Prozess, der davon lebt, dass wir versuchen, die Wünsche und Schmerzen der Nutzer zu erkennen, ihnen eine Lösung für ihre Probleme zu liefern, zu messen, wie wir ihnen geholfen haben, und dies immer und immer wieder zu wiederholen. Ein Prozess, der auch funktioniert, wenn wir vor Beginn der Arbeit nicht alle Parameter für den Erfolg kennen.
Quasi ein Regelkreis.
Im agilen Produktmanagement besteht dieser Kreislauf aus:
- Entdeckung
- Lieferung
- Validierung
Ähnlich wie ein Thermostat. Nur dass wir nicht die Temperatur regeln, sondern, wie gut wir die Probleme unserer Kunden lösen können.
Wie erfolgreich ein Team im agilen Produktmanagement ist, hängt also davon ab, wie erfolgreich es entdeckt, liefert und validiert. Deshalb nenne ich Entdeckung, Lieferung und Validierung auch die drei Kernkompetenzen des agilen Produktmanagements. Diesen Regelkreislauf zu etablieren und die Kernkompetenzen zu verbessern – darum geht es in Scrum. Oder in anderen Worten ausgedrückt: Scrum hilft Teams zu entdecken, zu liefern und zu validieren. Und die Aufgabe eines Scrum Masters besteht somit darin, seinem Team zu helfen, die Elemente des Scrum Rahmenwerks so einzusetzen, dass Entdeckung, Lieferung und Validierung möglich werden.
Betrachten wir die Kompetenzen genauer:
Kompetenz #1: Entdeckung
Ein häufiger Irrglaube: Bei der Entdeckung geht es ausschließlich darum, neue Features für das Produkt zu finden.
Damit wäre Entdeckung zu kurz gegriffen. Entdeckung im agilen Produktmanagement ist der Gegenentwurf zur Anforderungsanalyse, zum Requirements-Engineering oder zum Erstellen von Pflichten- und Lastenheften im klassischen Projektmanagement.
Die Grundannahme bei der Produktentdeckung ist, dass wir davon ausgehen, dass sich die Wünsche, Probleme und Bedürfnisse unserer Kunden wandeln werden. Deshalb müssen wir kontinuierlich ihre Wünsche, Probleme und Bedürfnisse weiterentdecken. Am Ende ist Entdeckung auch der Prozess, das Risiko zu minimieren, Features zu entwickeln, die nicht mehr gewollt sind.
Wie ermöglicht Scrum Entdeckung?
Hier drei Beispiele:
Beginnen wir mit der Verantwortung des Product-Owners.
Die Verantwortung des Product-Owners wird häufig missverstanden.
Lass uns das deshalb gemeinsam ansehen. Der Scrum Guide schreibt:
„Der Product-Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.“
Dort steht „Maximierung des Wertes des Produkts“. Was häufig nur auf die Verwaltung des Backlogs reduziert wird. Viel wichtiger ist es jedoch, vorab zu bewerten, was ins Backlog kommt und welche Einträge des Backlogs tatsächlich weiterverfolgt werden sollen. Also die Einträge zu entdecken, die den meisten Wert versprechen. Entdeckung ist eine Kernkompetenz eines Product-Owners.
Nicht selten benötigt er dabei Unterstützung.
Deshalb müssen Scrum Teams interdisziplinär sein.
Übernimmt nur eine Person die Entdeckungsarbeit im Team, kann dies schnell zum Flaschenhals werden.
Davor warnt uns bereits der Scrum Guide mit dieser Forderung an Scrum Teams:
„Scrum Teams sind interdisziplinär, d. h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.“
Die nötigen Fähigkeiten, um bei der Entdeckung von Wünschen, Problemen und Bedürfnissen der Nutzer erfolgreich zu sein, können UX-Researcher, UI-Designer, Data-Scientists oder Produktmanager mitbringen. Welche Fähigkeiten und in welchem Umfang sie nötig sind, hängt vom Produkt und der Lebensphase des Produkts ab. Die Aufgabe eines Scrum Masters ist es deshalb, die Interdisziplinarität des Teams ständig im Auge zu haben und besonders darauf zu achten, dass auch die nötigen Fähigkeiten für die Entdeckungsarbeit im Team vorhanden sind.
Wann passiert Entdeckungsarbeit?
Hierfür gibt es auch einen Platz in Scrum:
Das Product-Backlog-Refinement
Wenn ich ehrlich mit dir sein darf:
Für mich macht es keinen Unterschied, ob das Scrum Team Entdeckungs-, Liefer- oder Validierungsarbeit verrichtet. Solange am Ende des Sprints eine neue Version des Produkts entsteht, ist alles für mich einfach nur Arbeit.
Natürlich ist das jetzt sehr pragmatisch formuliert und ich trete damit bestimmt dem einen oder anderen UX-Designer auf die Füße. Deshalb ist es für mich auch in Ordnung, wenn wir Entdeckung als Bestandteil des Product-Backlog-Refinements sehen.
Und damit bin ich nicht allein. Der Scrum Guide schreibt dazu:
„Product-Backlog-Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint-Planning-Event. Diesen Transparenzgrad erreichen sie in der Regel durch Refinement-Aktivitäten.“
Das Schlüsselwort ist „Transparenzgrad“. Also wie transparent es dem Scrum Team ist, welches Problem es lösen soll. Und die Transparenz darüber, welche Probleme die Nutzer haben, entsteht durch Entdeckungsarbeit.
Kompetenz #2: Lieferung
Was verspricht Scrum?
Spätestens nach einem Monat neue Software zu liefern. Ich denke, das ist kein Geheimnis. Deshalb entscheiden sich Unternehmen auch, Scrum einzuführen. Sie wollen schneller und regelmäßig liefern. Die Vorteile liegen auf der Hand: Schneller liefern zu können, minimiert das finanzielle Risiko. Regelmäßiges Liefern sorgt für mehr Vertrauen bei Kunden, Nutzern und Stakeholdern.
Wie Scrum die Kernkompetenz des „Lieferns“ ermöglicht, möchte ich dir an ausgewählten Beispielen zeigen. Denn unterm Strich gibt es kein Element im Scrum Rahmenwerk, das dies nicht ermöglichen soll.
Allen voran die Verantwortung der Entwickler
Der Scrum Guide schreibt hierzu:
„Developer sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Inkrements zu schaffen.“
Soll heißen, in Scrum Teams sind nur Menschen, die sich aktiv an der Lieferung einer neuen Version des Produkts beteiligen. Dies reduziert nicht nur die Kosten, sondern gibt auch einen klaren Auftrag.
Da es keine Manager in Scrum Teams gibt, müssen die Qualitätsansprüche des Unternehmens auf andere Weise gewahrt werden.
Die Definition-of-Done
Die Definition-of-Done macht dem Team die Qualitätsansprüche des Unternehmens transparent.
Der Scrum Guide schreibt hierzu:
„Die Definition-of-Done ist eine formale Beschreibung des Zustands des Inkrements, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.“
Diesen Satz kennen die meisten Scrum Master. Was jedoch häufig überlesen wird:
„Wenn die Definition-of-Done für ein Inkrement Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen.“
Das bedeutet, dass Qualitätsstandards des Unternehmens durchaus Teil der Definition-of-Done sein können und wenn diese nicht erfüllt sind, darf die Software nicht geliefert werden.
„Wenn ein Product-Backlog-Eintrag nicht der Definition-of-Done entspricht, kann er weder released noch beim Sprint-Review präsentiert werden.“
Neben der Verantwortung eines Entwicklers und der Definition-of-Done unterstützt Scrum auch durch konkrete Ziele bei der Lieferung:
Das Sprintziel
Das Sprintziel hilft dem Team, sich auf die Lieferung zu konzentrieren:
„Das Sprintziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten.“
Mehr noch: Es soll eine Gruppe von Entwicklern zu einem Team einen. Getreu dem Motto: Das Ganze ist mehr als die Summe seiner Teile.
Nun zur letzten Kompetenz:
Kompetenz #3: Validierung
Scrum ermöglicht Überprüfung.
Denn Scrum beruht auf Transparenz, Überprüfung und Anpassung. Somit ist Überprüfung eines der drei Scrum Prinzipien.
Allerdings ist Validierung im Produktmanagement noch ein Schritt mehr.
Validieren bedeutet nicht nur zu überprüfen, sondern auch zu entscheiden, ob die Version des Produkts tatsächlich den Bedürfnissen und Erwartungen der Benutzer oder Stakeholder entspricht und ihren beabsichtigten Zweck erfüllt.
Wie liefert Scrum diese Grundlage zur Entscheidung? Wie ermöglicht Scrum also Validierung?
Zuallererst durch Ziele.
Allen voran das Produktziel.
„Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, welcher dem Scrum Team als Planungsziel dienen kann.“
Hinter „zukünftigem Zustand“ verbirgt sich eine Zukunft, in der einige Probleme oder Bedürfnisse der Nutzer gelöst wurden und somit Wert für die Nutzer und dann in letzter Konsequenz für das Unternehmen geschaffen wurde.
Das Produktziel liefert dem Scrum Team die Möglichkeit, seinen Fortschritt zu überprüfen und zu validieren, ob Wert geschaffen wurde.
Wann passiert diese Validierung?
Spätestens im Sprint-Review.
Ähnlich wie Entdeckung ist Validierung eine kontinuierliche Aktivität.
Damit diese Aktivität aber nicht vergessen wird, erinnert das Scrum Rahmenwerk regelmäßig daran.
Die Rede ist natürlich vom Sprint-Review:
„Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholdern vor, und die Fortschritte in Richtung des Produktziels werden diskutiert.“
Spätestens am Ende des Sprints fordert das Scrum Rahmenwerk, dass das Scrum Team und die Stakeholder des Produkts die Fortschritte überprüfen. Daraufhin kann entschieden werden, ob Wert gestiftet wurde oder ob der gestiftete Wert ausreicht.
Den Wert zu validieren, ist eine weitere Verantwortung des Product-Owners, der dieser im Sprint-Review nachkommen kann.
Betrachten wir deshalb zum Schluss noch einmal:
Die Verantwortung des Product-Owners
Der Scrum Guide schreibt:
„Der Product-Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.“
Und „Maximierung“ ist nur durch Validierung möglich. Da Wert häufig erst einmal subjektiv ist und im Auge des Betrachters liegen kann, muss Wert bestmöglich quantifiziert und messbar gemacht werden. Das ist eine weitere Aufgabe eines Product-Owners. Je besser er diese beherrscht, desto besser kann er den Wert auch maximieren.
Wenn du bei der Quantifizierung von Wert Unterstützung suchst, dann empfehle ich dir den Besuch unseres „Professional Product Discovery and Validation“-Trainings. Dort erhältst du von Boris und mir viele Tipps und Methoden, wie du die Kernkompetenz „Validation“ auch in deinem Te