Die Alternative zu Roadmaps

Folgendes Zitat von General George Patton fand ich schon immer toll:

„Sage den Menschen nicht, wie sie etwas tun sollen. Sage ihnen, was zu tun ist, und sie werden dich mit ihrem Einfallsreichtum überraschen”.

Leider machen Roadmaps aber genau das, wovor der General warnt

Roadmaps sagen den Teams, was sie wie tun sollen. Normalerweise geschieht das in Form von priorisierten Listen mit Features oder Projekten, von denen jemand tatsächlich glaubt, dass sie das Problem lösen werden (auch wenn das Problem oft noch gar nicht klar ist bzw. noch nicht wirklich verstanden wurde).

Wenn auf Ihrer Roadmap beispielsweise etwas steht wie „PayPal als zusätzliche Zahlungsmöglichkeit hinzufügen”, ist der Grund dafür dann, dass Sie glauben, dass es Kunden gibt, die nicht mit Ihren anderen Zahlungsmethoden bezahlen können? Oder hat es etwas mit dem internationalen Zahlungsverkehr zu tun? Oder glaubt vielleicht jemand, dass es ein Wettbewerbsnachteil wäre, diese Option nicht anzubieten?

Ich habe bereits in mehreren Artikeln darauf hingewiesen, dass ich klassische Product Roadmaps als die Quelle für sehr viel Verschwendung (waste) bei Produktteams ansehe. Der Artikel Gescheiterte Produkte handelt von diesem Thema und in [Unangenehme Wahrheiten der Produktentwicklung]/de/product-owner/unangenehme-wahrheiten-der-produktentwicklung/ "Unangenehme Wahrheiten der Produktentwicklung") gehe ich genauer auf dieses Konzept ein.

Da das Problem mit den Roadmaps immer mehr Beachtung findet, wurde ich in letzter Zeit häufiger gebeten, mehr über die Alternative zu Roadmaps zu erzählen.

Ein umfassendes Thema

n diesem Artikel möchte ich das versuchen. Es ist ein großes Thema, welches auch mit Themen wie Produktkultur, Bevollmächtigung und Autonomie zu tun hat. Meistens brauche ich mindestens eine Stunde, um jemandem das alles persönlich zu erklären, aber ich hoffe, dass ich die Essenz hier zusammenfassen kann.

Bevor wir uns auf die Alternative zu Roadmaps stürzen, müssen wir uns klarmachen, dass Roadmaps so lange Zeit genutzt wurden, weil sie zwei ganz bestimmte Bedürfnisse bedienen – und diese Bedürfnisse werden auch nicht einfach so verschwinden.

1) Die Führungsebene möchte sicherstellen, dass die Teams zuerst an den Items mit dem größten Wert für das Unternehmen arbeiten.

2) Da sie ein Unternehmen zu leiten haben, gibt es Situationen, in denen sie konkrete Fristen und Commitments benötigen – und mit Roadmaps können sie diese Commitments erfassen und tracken.

Damit eine Alternative zu klassischen Roadmaps in Unternehmen akzeptiert werden kann, müssen diese beiden Punkte mindestens genauso gut damit adressiert werden wie bisher.

Roadmaps haben ihre Wurzeln in dem alten zentralisierten Command-and-Control-Modell. Einige Stakeholder halten ein Meeting ab – meistens vierteljährlich – um sich Gedanken um die Prioritäten und Projekte der Teams für das nächste Quartal zu machen.

Im Gegensatz dazu sollen Teams im Produktteam-Modell selbst herausfinden können, wie sie die jeweiligen Geschäftsprobleme lösen werden, um die sie sich kümmern sollen.

Aber dafür reicht es nicht aus, einfach nur gute Mitarbeiter zu haben. Das Team braucht den notwendigen Kontext. Die Teammitglieder müssen verinnerlicht haben, wo genau das Unternehmen hin will, und sie müssen verstanden haben, was ihr eigenes Team zu diesem übergeordneten Ziel beitragen soll.

Um auf General Patton zurückzukommen:

Wie Sie vielleicht bereits wissen, arbeitet auch das Militär mit dem Konzept autonomer Teams. Diese Teams (Squads) werden bewusst klein gehalten und sind größtenteils autonom, sie haben stets die gemeinsamen Absichten im Blick, dürfen jedoch selbst entscheiden, was sie für die beste Möglichkeit halten, um ein bestimmtes Problem zu lösen.

Diese gemeinsamen Absichten sind der Kontext, den ich eben erwähnt habe. „Durch Absichten werden die übergeordneten Ziele und Intentionen präzise formuliert…Eindeutige Absichten führen zu zielgerichteten Aktivitäten bei den Streitkräften. Sie geben wieder, was der Befehlshaber erreichen möchte und warum, und sie führen bei den Streitkräfte zu einem Gefühl der Verbundenheit. Normalerweise werden sie durch mögliche Auswirkungen, Ziele und erwünschte Resultate ausgedrückt…Wirklich gut formulierte Absichten sind auch ohne eine große Menge an zusätzlichen Details für Untergebene zu verstehen.”

Technologieunternehmen haben verschiedenste Möglichkeiten, diesen Kontext bzw. diese Absichten zur Verfügung zu stellen. Ich plädiere allerdings für zwei ganz bestimmte Komponenten:

Die Produktvision: sie beschreibt die ganzheitliche Sichtweise der Dinge, die die Organisation als Ganzes zu erreichen versucht.

Die Unternehmensziele: sie beschreiben die spezifischen, priorisierten Unternehmensziele für jedes einzelne Produktteam.

Es gibt einige Systeme und Methodologien um diese Unternehmensziele zu managen. Mein Favorit ist momentan jedoch das OKR-System (Objectives and Key Results).

Die Idee an sich ist recht simpel: Sagen Sie den Teammitgliedern, was sie erreichen sollen und wie die Ergebnisse gemessen werden. Dann lassen Sie das Team selbst entscheiden, was sie für die beste Möglichkeit halten, um die jeweiligen Probleme zu lösen.

Nehmen Sie beispielsweise an, bei Ihrem Produkt bräuchten Sie momentan 30 Tage für den Onboarding-Prozess neuer Kunden. Um jedoch effektiv skalieren zu können, muss das auf 3 Stunden oder weniger reduziert werden. Das wäre also ein gutes Beispiel für ein Ziel eines oder mehrerer Produktteams: „Die Zeit, bis ein Kunde live ist, stark reduzieren.” Eines der Hauptergebnisse davon könnte sein: „Durchschnittliche Onboarding-Zeit weniger als 3 Stunden.”

Auch wenn das Konzept von Teamzielen recht einfach klingt, gibt es doch viele Möglichkeiten, es in Produktteams und Organisationen zu institutionalisieren, und es kann einige Quartale dauern, bis die Organisation in den Genuss der Vorteile dieses Konzepts kommt.

Es gibt einige Erkenntnisse über die Produktvision und besonders über die gute Anwendung des OKR-Systems, die ich in den nächsten Artikeln in den Fokus stellen werde. In der Zwischenzeit können Sie sich ja schon einmal das Material von Christina Wodtke anschauen.

Dieser Kontext ist also sehr wichtig – also die Produktvision und die Teamziele.

Am Anfang habe ich darauf hingewiesen, dass wir die beiden Hauptgründe für die guten alten Roadmaps berücksichtigen müssen. Der erste davon war der Wunsch, zuerst an den Items mit dem größten Wert für das Unternehmen zu arbeiten. Es ist hoffentlich klar, dass sich das Management um dieses Bedürfnis kümmert, indem sie die spezifischen Ziele für die Organisation und deren Priorisierung liefern. Der Unterschied ist allerdings, dass sie nun die Wichtigkeit von Geschäftsergebnissen priorisieren statt den subjektiven Wert der Features.

Der zweite Grund war die Notwendigkeit für Commitments, worauf wir mit dem Konzept von Commitmens mit hoher Integrität eingehen. Das bezieht sich auf Situationen, in denen wir tatsächlich ein Commitment für ein Datum oder ein bestimmtes Resultat benötigen.

Diese Vorgehensweise hat einige Vorteile:

Erstens sind die Teams viel motivierter, wenn sie sich selbst überlegen dürfen, was sie für die beste Lösung des Problems halten.

Zweitens kommt das Team nicht einfach damit davon, ein gewünschtes Feature oder Projekt zu liefern; das Feature muss auch tatsächlich funktionieren (was anhand der Key Resultes gemessen wird). Falls nicht, muss das Team einen anderen Ansatz für die Lösung des Problems ausprobieren.

Drittens – egal wo die Idee für eine Lösung herkommt – funktioniert sehr häufig der erste Ansatz nicht und statt das zu leugnen, ist man sich dessen bei diesem Modell sehr bewusst.

Es dreht sich alles eher um Outcome statt Output – also ein sinnvolles Ergebnis zu bekommen, statt nur irgendein Ziel zu erfüllen.

Oft fordere ich die Teams auf, auf das vergangene Jahr zurückzublicken und sich selbst anhand der Erfolgsrate ihrer Roadmap zu bewerten, und zwar im Hinblick darauf, wie viele Items tatsächlich den Unternehmenszielen entsprachen. Wenn Sie dies tun und nicht stolz darauf sind, was Sie herausfinden, dann hoffe ich, dass Sie diese Alternative in Erwägung ziehen. Stellen Sie sicher, dass Ihre Produktorganisation über eine überzeugende Produktvision verfügt. Stellen Sie sicher, dass jedes Produktteam klar definierte und priorisierte Unternehmensziele hat. Stellen Sie sicher, dass alle Commitments, die eingegangen werden müssen, Commitments mit hoher Integrität sind.
Und nun bevollmächtigen Sie Ihre Produktteams, damit sie selbst entscheiden können, welche Lösungen sie für bestimmte Geschäftsprobleme am geeignetsten finden, und sehen Sie, wie viele Ihrer Teams Sie mit ihren Ergebnissen überraschen werden.

Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.

Product Owner Seminar

=> Besuche jetzt ein Product Owner Seminar der Agile Academy.

Das Product Backlog

=> Lese mehr über das Product Backlog im agilen Lexikon.

Die Product Owner Rolle

=> Lerne mehr über die Rolle vom Product Owner.