Das Decision-Tree-Modell: Entscheidungsfindung am Beispiel eines fortlaufenden Projekts in der Produktentwicklung

Im einführenden Artikel über das Decision-Tree-Modell nach Susan Scott hatte ich erläutert, wie sich Entscheidungsstrukturen in einem komplexen Umfeld vereinfachen und transparent machen lassen können. Wie gestaltet sich das in der Praxis? Das will ich am Beispiel der Entwicklung unserer Social-Intranet-Suite Linchpin einmal näher zeigen.

Wir sind dabei, die Nutzung des Decision-Tree-Modells in unserem sogenannten Linchpin Universe zu etablieren. Nun geht es ganz konkret darum, wie wir diese Analogie für uns im Linchpin Universe nutzen und was das für unsere Stakeholder und andere Interessierte bedeutet.

Warum ein Modell zur Entscheidungsfindung?

Die Antwort: Um die Entscheidungsfindung im Linchpin Universe zu erleichtern und Verantwortlichkeiten und Unterstützungsoptionen transparent zu visualisieren. Wir durchlaufen einen Wandel in Richtung Produktanbieter, der andere Strukturen erfordert als die eines reinen Dienstleisters. Zusätzlich ist die Arbeit im Linchpin Universe durch unser stetiges Wachstum deutlich komplexer geworden.

Rund um Linchpin gibt es mehrere Product Owner sowie rund 40 involvierte Mitarbeiter und nicht jeder kennt alle Prozesse und Wege der Zusammenarbeit. Hinzu kommt, dass Linchpin als Gesamtlösung mehr ist als die Summe der einzelnen Plugins. Hieraus erwächst ein erhöhter Bedarf an Austausch zwischen den Teams und den Stakeholdern – es wird also noch komplexer.

Mit der Adaption des Decision-Tree-Modells verfolgen wir das Ziel, genau diese Komplexität zu reduzieren und Verantwortlichkeiten explizit zu machen.

Hier ist noch einmal kurz ein theoretischer Überblick zu diesem Konzept. Es gibt unterschiedliche Entscheidungsebenen, die sich im Hinblick auf Schwere und Wichtigkeit ihrer Auswirkungen unterscheiden:

  • Blattentscheidungen (sehr geringe Auswirkungen auf „das Überleben des Baums“) bis hin zu Wurzelentscheidungen (die Auswirkungen sind für das Überleben des Baums essenziell).
  • Auf jeder Entscheidungsebene treffen unterschiedliche Gremien oder Personen die Entscheidung, während andere Gremien oder Personen beratend hinzugezogen werden sollen.
  • Zusätzlich werden Kommunikationswege konkretisiert und Verantwortliche für die Kommunikation der Entscheidungen ausgewiesen.
  • Details der Umsetzung und weitere konkrete Beispiele aus unserem Alltag werden peu à peu hinzugefügt, um das Modell bzw. den Baum organisch wachsen zu lassen.

Also sehen wir uns einmal an, wie sich all das in der Praxis eines fortlaufenden Projekts macht – in eben jenem Linchpin Universe.

Insgesamt haben wir für das Linchpin Universe sechs Instanzen bzw. Gruppen von Entscheidungsträgern definiert. Das sind:

  • Die aktuell fünf Linchpin-Teams
  • Die Product Owner der jeweiligen Teams
  • Das neu geschaffene Product Board
  • Technical Lead
  • Stakeholder
  • Zusätzlich Scrum Master bzw. Agile Coaches

Die meisten dieser Instanzen dürften selbsterklärend sein, doch zumindest zum Product Board möchte ich ein paar erklärende Worte verlieren. Die Idee hierzu entstand aus der Erfahrung, dass Entscheidungen, die über die einzelnen funktionalen Komponenten (also Plugins) hinaus gehen, häufig Auswirkungen auf Linchpin als Gesamtlösung haben. Diese konnten in der Vergangenheit nicht adäquat und zeitnah bearbeitet werden. Als Konsequenz haben wir in einem ersten Schritt ein Product Board gebildet.

Dieses setzt sich aus Vertretern jeder Fachgruppe im Linchpin Universe zusammen. Das sind bei uns also ein Vertreter der technischen Seite, eine Kollegin aus dem Bereich UX/Design und ein Mitarbeiter aus Umfeld Kunden/Partner/Consulting. Ein weiterer Kollege schaut aus produktstrategischer Sicht auf die Dinge und ein Scrum Master hat die teamübergreifende Zusammenarbeit im Fokus.

Welche Rolle das Product Board für die Entscheidungen im Linchpin Universe zukünftig haben wird, erkläre ich im nächsten Abschnitt.

Typisierung von Entscheidungen

Die nachfolgende Tabelle stellt den aktuellen Stand unserer Adaption des Decision-Tree-Modells auf das Linchpin Universe dar. Einerseits unterscheiden wir zwischen den vier Entscheidungskategorien Blatt, Ast, Stamm und Wurzel. Andererseits gliedern wir dahingehend auf, wer die Entscheidung verantwortet, wer die Entscheidung trifft und wer beratend hinzugezogen werden soll.

Bei der Verantwortung der Entscheidung geht es darum, wer anschließend die Kommunikation übernimmt und Ansprechpartner für das jeweilige Thema ist. Dies sollte immer nur eine Instanz sein. Die Entscheidung selbst können natürlich durchaus mehrere Gremien gemeinsam treffen.

Wer verantwortet die Entscheidung? Wer trifft die Entscheidung? Wer ist beratend heranzuziehen? Arten von Entscheidungen Konkrete Beispiele
Blatt Team Team Product Board
  • Notwendige technische Änderungen an Features (ohne UX-Einfluss)
  • Optimierungen der UI, basierend auf definierten Richtlinien
  • Notwendige Textänderungen
  • Wie implementiere ich die Änderung / Neuerung – technische Umsetzung
  • Marketing-Maßnahmen und Evaluatoren-Management
  • Einfache Refactoring-Maßnahmen zur Sicherung der Qualität
In dieser Spalte stehen intern diverse Beispiele aus der früheren Praxis der Produktentwicklung.
Ast Team Team Product Board, Product Owner
  • Neue Anforderung zur Beschätzung
  • Änderungen eines Plugins mit Kompatibilitäts-Abhängigkeiten zu einem oder mehreren Plugins
  • Struktur / Framework
  • Feature-Set
  • Konzeption und Umsetzung neuer umfangreicher Features innerhalb der bestehenden Plugins
  • Komplexe Refactorings und umfangreiche strukturelle Änderungen
  • Teamwechsel und Teamzusammensetzung
Stamm Product Board Team, Product Board, Stakeholder Product Owner, Technical Lead
  • UX-Pattern-Management über alle Plugins hinweg – Investition in Standardisierung und Konsolidierung
  • Eskalation von Investitionsthemen, die schwer kontrollierbar werden und deren Einschätzung nicht mehr möglich ist (Firescope)
  • Eskalation von Investitionsthemen für die Abschaffung oder die Erweiterung des eigenen Portfolios mit / durch eigene(n) Plugin-Ressourcen
  • Partnermanagement – Technische Kollaboration
Wurzel Product Board Product Board, Stakeholder
  • Positionierung und Neu-Ausrichtung der Linchpin-Gesamtlösung (thematisch, Preispolitik, Platzierung am Markt)
  • Investitionen in neue Themen – Bewertung und Prüfung des Marktpotenzials und Einschätzung der Chancen und Risiken sowie deren Auswirkungen
  • Investition und / oder Aufkauf von Drittanbietern im Linchpin-Kontext zur Einbindung und Stabilisierung der eigenen Plugin-Portfolios
  • Partnermanagement – Investitionen

Kommunikation von Entscheidungen

Haben Sie genau hingeschaut? 😉 Dann haben Sie vielleicht bemerkt, dass in vorangehenden Tabelle etwas fehlt: die Kommunikation der Entscheidung. Um Komplexität zu reduzieren, ist eine transparente Kommunikation der getroffenen Entscheidungen und des Entscheidungswegs nötig.

Zu diesem Zweck haben wir intern eine gesonderte Übersicht aufgesetzt, die zeigt, in welcher Runde oder in welchen unserer etablierten Meetings die Entscheidung kommuniziert werden soll, wer die Zielgruppe ist und wer die Verantwortung für die Kommunikation innerhalb der entsprechenden Plattform trägt. Solche regelmäßigen Formate sind die sogenannten Weeklies, die es jeweils für Product Owner, UX-Fachleute, Entwickler und Scrum Master gibt, der Linchpin Jour Fixe, das Roadmap-Meeting, das Portfolio-Meeting und das Product Marketing Monthly.

Die verschiedenen Entscheidungen lassen sich möglicherweise nicht immer eins zu eins einer bestimmten Kategorie oder Plattform zuweisen. Für den Großteil der Entscheidungen sollte das beschriebene Vorgehen jedoch helfen, Komplexität abzubauen.

DACI-Prozess als Blaupause

Die Frage ist nun, wie das Modell in der Praxis aussieht. Und hier liegt schließlich die Folgefrage nahe, in welche Kategorie eine Entscheidung denn nun gehört. In einem ersten Schritt haben wir uns retrospektiv Entscheidungen der vergangenen Monate angeschaut (siehe die Beispiele in der Tabelle weiter oben). Zukünftige Entscheidungen sollen sich an den Beispielen orientieren oder – falls das nicht eindeutig oder nicht möglich ist – den Weg über das Product Board nehmen.

In diesem Zusammenhang haben wir ein sogenannte DACI-Register eingeführt, das eine Liste aller aktuell offenen Entscheidungen enthält. Wofür steht DACI?

  • D = Driver (Person mit Durchführungsverantwortung). Diese Person ist dafür zuständig, die Verantwortlichen ins Boot zu holen, alle erforderlichen Informationen zusammenzutragen und bis zum vereinbarten Datum für eine Entscheidung zu sorgen. Es kann sich dabei je nach Entscheidung um den Projektzuständigen oder um eine andere Person handeln.
  • A = Approver (Person, die Entscheidungen freigibt). Diese Person trifft letztlich die Entscheidung.
  • C = Contributors (beitragende Personen). Diese Personen haben für die Entscheidung relevantes Wissen oder entsprechende Erfahrung. Sie können ihre Meinung äußern, haben jedoch kein Stimmrecht.
  • I = Informed (Informationsempfänger). Diese Personen werden über die endgültige Entscheidung informiert.

Die Terminologie ist aktuell noch aus Atlassians Team Playbook übernommen, möglicherweise individualisieren wir den Ansatz künftig für eigene Zwecke.

Zunächst legen wir gemeinsam (im Product Board) die Kategorie der Entscheidung fest. Dann nehmen wir die notwendigen Zuteilungen nach DACI vor.

Ausblick

In der Zusammenfassung läuft unser Vorgehen darauf hinaus, dass Entscheidungen in unserem Linchpin Universe zukünftig nach einem zweiteiligen Schema ablaufen:

  1. Ist die Art der Entscheidung, die ansteht, in gleicher oder ähnlicher Form schon einmal getroffen worden? Dann orientiere dich am damals verwendeten Vorgehen.
  2. Ist eine Entscheidung dieser Art noch nicht getroffen worden oder gibt es Unstimmigkeiten? Dann bringe sie ins Product Board und die Entscheidungsfindung und Kommunikation der Entscheidung nach DACI ein.

Letztlich handelt es sich auch hierbei um eine Art konsultativen Gruppen- bzw. Einzelentscheid mit obligatorischer Konsultation der Stakeholder und transparenter Kommunikation der Entscheidung. Diese Art zu entscheiden hat sich in den letzten Jahren bei uns herauskristallisiert und in vielen Bereichen als sehr positiv erwiesen.

Das adaptierte Decision-Tree-Modell hilft uns in diesem Zusammenhang einfach noch besser, die Grenzen der Entscheidungsfreiheit sichtbar zu machen und damit Komplexität im Arbeitsalltag und unnötige Meetings zu reduzieren. Die Herausforderung wird zukünftig sicherlich darin liegen, das Modell in der Arbeit der Teams zu verankern, es selbstverständlich zu machen und kontinuierlich darauf zu achten, dass wir am Ende auch wirklich schneller und (hoffentlich) besser entscheiden als früher.

Weiterführende Infos

Das Decision-Tree-Modell: Klare Verantwortlichkeiten und Leitlinien auf verschiedenen Entscheidungsebenen
Organisation und Komplexität: Komplexe Probleme lösen
Wie unsere Scrum Master als Agile Coaches auf der Unternehmensebene wirken
Agile Organisation bei //SEIBERT/MEDIA – von der Ideenfindung zur Realisierung


Mehr über die Creative-Commons-Lizenz erfahren