Skalierung der Produktentwicklung durch Zusammenarbeit

Eine gemeinsame Mission und das Know-How mischen

Ein Team baut ein Produkt. Diese Sicht ist bei vielen fest verankert. Aber wie kann man damit umgehen, dass ein großes Software-Produkt mehr als 20 Kolleg*innen braucht, um schnell einen Mehrwert zu liefern? Ist es sinnvoll, dass ein Team ausschließlich das neue und ein anderes nur das bestehende Produkt verantwortet? In diese Richtung gingen unsere ersten Fragestellungen. 

Ende 2019 planten der Produktmanager und ich als Agile Master die ersten Schritte. Hinzu kamen Sorgen über eine mögliche schlechte Meeting-Kultur und wie Software-Entwicklung in einem so großen Team funktionieren kann. Führen wir das Sprint Planning zukünftig mit mehr als 20 Leuten durch? Für welche Architektur entscheiden sich die Teams? Wie treffen wir Entscheidungen?

Dadurch wurden die Anforderungen stets in Summe betrachtet und die beiden Anwendungen waren mögliche Umsetzungsorte für diese Anforderungen. Angeleitet vom Produktmanager, haben wir am Anfang in einem One-Pager die groben Eckpfeiler abgestimmt. Wir führten eine Reihe von Workshops durch, um fachlich und technisch eine gemeinsame Ausrichtung zu erreichen. 

Neben den Workshops wurde zeitnah über Mission und Produktvision diskutiert und gemeinsam mit den Stakeholdern festgelegt. Natürlich fielen uns die ersten gemeinsamen Workshops schwer. Zu groß und unbekannt erschien uns diese Mammutaufgabe. Die Tatsache, dass Funktionalitäten des bestehenden Produkts in dem neuen aufgehen sollten, hat die Komplexität zusätzlich gesteigert. 

Aus meiner Sicht war es gewinnbringend, dass die groben Eckpfeiler direkt zu Beginn gemeinsam diskutiert und alle Kolleg*innen sich durch eine treffende Mission orientieren konnten. 

Wir sind mit zwei Teams gestartet. Eines, welches das bestehende Produkt weiterentwickelt und gleichzeitig am neuen Produkt arbeitet, sowie ein anderes, welches exklusiv das neue Produkt entwickelt. Um einen Know-how-Transfer sicherzustellen sind zwei Kolleg*innen vom bestehenden zum neuen Produktteam gewechselt. Mittelfristig sollten beide Teams am neuen Produkt programmieren. Der Betrieb und die Weiterentwicklung der bestehenden Anwendung wurden dadurch aufrechterhalten.

An Frameworks orientieren, eigene Erfahrungen sammeln und Anpassungen durchführen

Da wir mit mindestens zwei Teams an einem Produkt arbeiten wollten, haben wir uns am LeSS Framework (Large Scale Scrum) orientiert. Die schlanke Struktur mit einer überschaubaren Anzahl an Meetings erschien uns geeignet für den Start. LeSS erweitert die bestehenden Regeln und Rahmenbedingungen von Scrum und ermöglicht die Skalierung mit mehreren Teams. Beide Teams hatten bereits Erfahrung mit Scrum, so dass wir auf bestehende Kenntnisse aufbauen konnten. 

Wir sind mit einer Sprintdauer von zwei Wochen gestartet, synchron mit beiden Teams. Die kurze Sprintdauer hat uns viele Retrospektiven ermöglicht, um unser Vorgehen in der Anfangsphase häufig zu reflektieren und anzupassen. Dabei hat jedes Team seine eigene und anschließend gemeinsame Retrospektive durchgeführt. 

In der Reflexion wurde klar, dass dieses Setup weniger zielführend ist und nicht 20+ Personen an einer Retrospektive teilnehmen sollten. Stattdessen haben sich rollierende Vertreter*innen aus beiden Teams für den gemeinsamen Termin etabliert. Diese Anpassung hat wie viele andere Punkte im Rückblick eingeleuchtet, aber die eigene Experimentierfreude und Erfahrung der Teams stand bewusst im Vordergrund.

Die Modifikation mit den rollierenden Team-Vertreter*innen in der Retrospektive wirkt so, als hätten wir eine Kursänderung vorgenommen, die dauerhaft funktioniert hat. „Das mit den zwei Teams und einer gemeinsamen Produktverantwortung fühlt sich irgendwie anstrengend an“ war eine typische Aussage, die sich auf das sich wiederholende Reflektieren und Anpassen bezog. Wir hatten angenommen, dass notwendige Änderungen mit zwei Teams langsamer entstehen als bei einem Team, aber das Gegenteil war der Fall. Gefühlt war der Änderungstakt so hoch, dass nach einem 2-wöchtigen Urlaub Termine anders besetzt oder gar nicht mehr vorhanden waren sowie neue Coding-Guidelines oder zusätzliche Teams-Räume entstanden sind. Allen Beteiligten hat dies sehr viel abverlangt, jede*r musste ständig am Ball bleiben. 

Die Anstrengungen und der Wille, alles jederzeit unter die Lupe zu nehmen und zu verändern, hat sich aus unserer Sicht als absolut gewinnbringend für die Teams und die gemeinsame Produktentwicklung erwiesen.

Ein gelungenes Experiment der neuen Zusammenarbeit

Jede Einführung von neuen Prozessen braucht zunächst Zeit und Raum zum Experimentieren und Lernen. Bei einer geteilten Produktverantwortung ist es also sinnvoll, die Teams iterativ an neuen Strukturen und Prozessen lernen zu lassen. So können die Teams herausfinden, welcher Ansatz am besten funktioniert. Gleichzeitig sollte auch die Basis für das Gemeinschaftsgefühl stehen. Mit gemeinsam entwickelter Mission und Produktvision trägt jedes Team früh zum neuen Zielbild bei und wächst mit dem neuen Produkt.