2 Tage Planung für ein Produkt Release – geht das?

(Autor: Sven Krause, Co-Autor: Arnaud LHote)

Die Planung eines Produkt-Releases an denen über 100 Entwickler beteiligt sind, ist für jede Firma eine Herausforderung und mit vielen Risiken verbunden. Wie schaffen es Firmen, den Übergang vom Produkt Management in die Entwicklung effizient zu gestalten, alle Teilnehmer zu integrieren und das Risiko der Fehlinvestition massiv zu reduzieren?

Mit diesem Bericht möchte ich meine Erfahrung aus dem 2-tägigen Release-Planning Workshop weitergeben. Der Beitrag zeigt auf, dass mit einem kollaborativen, integrativen und agilen Ansatz eine Release Planung effizient, risikominimierend und zielorientiert durchgeführt werden kann.

Ein Unternehmen in der Schweiz organisiert seine TV-Produkt-Entwicklung basierend auf agilen Prinzipien und Vorgehen. Als Grundlage dient das SAFe Framework.

Ein zentraler Bestandteil des SAFe Frameworks ist der „Program Increment Planning Workshop“. Dieser zweitägige Event ist Teil des agilen Produkt- und Programmmanagements und findet in regelmässigen Abständen über den ganzen Entwicklungszeitraum statt. Ziel ist, ein gemeinsames Verständnis der Produkt-Vision, der wichtigsten Produkt-Features sowie der Rahmenbedingungen für die Arbeiten der nächsten Monate bei allen an der Umsetzung beteiligten Personen (insb. Entwickler) zu schaffen.

Mit einem Glockenschlag wird der Release-Planning-Workshop eröffnet. Alle Teilnehmer nehmen Platz. Um Emotionen zu wecken, starten wir mit dem neusten „Produkt-Werbevideo“. Danach wird auf das Kredo der Veranstaltung hingewiesen: „We want to maximize our value of our work!“

Die wichtigen Informationen – z.B. die wichtigsten Meilensteine und „Must Launch Dates“ stehen auf dem Release-Planning-Board (BVIR; Big Visible Information Radiators). Auch der Ablauf des Workshops ist dort für alle sichtbar.

Zum Abschluss der Warm Up Session werden Erkenntnisse der letzten Monate aufgegriffen und somit die agilen Prinzipien erneut dargestellt, geschärft und konkreter etabliert:

• We are not going to die if we do less. Let’s maximize value!
• We still need to get better at saying No
• Dependencies on other teams always limit us
• We make features smaller

Nun sind alle Informationen an die Teilnehmer geflossen und es gilt, die Features durch die Entwicklungsteams (Teilnehmer) zu vertiefen, Abhängigkeiten aufzudecken und die Aufwände zu schätzen.

Kann ein Teilnehmer keinen Beitrag leisten – da beispielsweise eine Abstimmung Vorrang hat, an der er nicht teilnehmen muss – zieht sich die Person einfach zurück, um andere Arbeiten auszuüben.
Bei Zuruf oder nach einer bestimmten Zeit unterbricht er diese und kehrt zum Team zurück.

Das Release-Planning-Board ist ca. zehn Meter lang, zeigt acht Sprints – also mehr als der Release selbst hat – und hat pro Team eine Kolonne, in der sie ihre Stories, die sie pro Sprint bearbeiten wollen, einfügen können. Die ersten Stories werden schnell erarbeitet und in die vorgesehenen Kolonnen eingefügt. Sind die ersten Features bearbeitet, wandern sie auf dem separaten Planungs-Board (Kanban Prinzip) vom Status „Backlog“ zum Status „Done“.

Ein Team ist in diesem Release besonders gefordert und schnell ist klar, dass es zum Engpass werden wird (Bottleneck-Team). Das ist auch auf dem Release-Planning-Board ersichtlich. Besagtes Bottleneck-Team ist bereits über alle Sprints hinweg durchgeplant und hat keine Kapazitäten mehr. Die Planning-Session wird ausserordentlich gestoppt.

Das Produkt-Management ist nun an der Reihe und überlegt Optionen, wie die Situation entschärft werden kann:

• Auf welches Feature kann verzichtet werden?
• Wie kann das Bottleneck-Team verstärkt werden?
• Soll eskaliert werden?

Die Teilnehmer werden ein wenig früher in den Feierabend entlassen, nur das Produkt-Managementteam tagt noch einige Zeit, bis sie eine adäquate Lösung gefunden haben. Diese teilen sie am nächsten Tag, dem zweiten Workshop-Tag, allen Teilnehmern mit.

Das Produkt-Management hat entschieden, auf ein EPIC in diesem Release zu verzichten. Der Scope ist somit erheblich reduziert, was die Situation, insbesondere für das Bottleneck-Team, entschärft.

Nun ist es möglich, bis dahin blockierte Features oder solche, die noch nicht berücksichtigt sind, anzugehen und einzuplanen.

Die Entwickler ziehen sich erneut zurück und besprechen die Aufwände für die Realisierung der Features. Am Ende der Session steht der „Gesamtplan“ wie immer transparent am Release-Planning-Board. Schnell sieht man, dass durch den Verzicht auf das eine EPIC die Kapazitätsverteilung aller Teams erheblich besser ist. Das heisst, alle Teams sind über die vorgesehenen sechs Sprints gut ausgelastet.

Während der Release-Planning-Session sind mir zwei interessante Punkte aufgefallen:
Erstens hat ein Team den Aufwand eines Features nicht abschätzen können. Es war nicht klar, welcher Lösungsweg möglich und welcher schlussendlich der Beste ist. Daher wurde im Team entschieden, verschiedenen Varianten auszuprobieren. Die dadurch gewonnen Erkenntnisse dienen als Entscheidungsbasis, wie das Feature umgesetzt wird.

Der zweite Punkt ist, dass jedes Team eigene Ziele definiert hat. Damit haben sie beschrieben, was ihrer Meinung nach in den nächsten Monaten zu erreichen ist. Dies haben sie mit dem Produkt-Management besprochen und diskutiert. Dies hatte zur Auswirkung, dass manche Stories angepasst wurden, um die Zielerreichung noch weiter zu optimieren. Zum Abschluss wurden im Plenum die Release-Ziele aufgezeigt und jedes Team hat kontrolliert, ob ihre Ziele einem Release-Ziel zugeordnet werden können.

Am Ende des zweiten Workshop-Tags, werden alle Teilnehmer nach Ihrer „Confidence“ befragt. Dabei geben sie per Handzeichen die „Zuversicht“ bezüglich der Realisierbarkeit der Planung ab. Teilnehmer mit geringer Zuversicht, werden gefragt, was geschehen muss, damit Ihre Zuversicht steigt. Ihre Äusserungen werden sehr ernst genommen, protokolliert und sofort im Plenum diskutiert.

Im Anschluss wird eine kurze Retrospektive durchgeführt: Der Workshop-Leiter bittet die Teilnehmer per Handzeichen, die Einschätzung ihres ROTI (Return on Time Invested) zu zeigen. Die meisten liegen bei einer Vier oder Fünf (Fünf ist dabei die beste Note). Die Wenigen, die eine Zwei gezeigt haben, erklären, dass Sie selbst nur einen kleinen Beitrag zu leisten hatten und somit an den Diskussionen mehrheitlich nicht beteiligt waren. Sie bestätigen jedoch, dass ihre Präsenz den gesamt Prozess beschleunigt hat, da sie dank dem Umfeld an anderen Themen arbeiten konnten.

Mein Fazit ist, dass die gute Vorbereitung durch das Team (RTE, Portfolio und Produktmanagement mit Feature Champions und Product Ownern) den Prozess sehr beschleunigt hat: speziell wichtig war, dass die Features für das Release klar waren und nach WSJF (Weighted Shortest Job First) priorisiert waren.

Nach dem Abschied applaudieren alle Teilnehmer und gehen gemeinsam in den verdienten Feierabend.