Das Setting: Mehrere Produkte im Team entwickeln
Mehrere Produkte im Team – eine Herausforderung vor der ich einmal mit einem Team stand. In dem besagten Projekt standen die Rahmenbedingungen fest. Ich bin ein Fan von Scrum nach Lehrbuch, da bei allen Derivaten zwar immer Verbesserungen erzielt werden können – nie aber so gigantische, wenn das Framework komplett und vollständig angewendet wird.
Nicht immer sind die Rahmenbedingungen so, wie diese sein sollten. Nicht immer haben wir wirklich alle Ansatzpunkte in der Hand, um Scrum in seiner Gänze zu machen. Auch wenn dann solche Implementierungen streng genommen kein Scrum (vgl. Scrum Guide) sind, kann es eine beachtliche Prozessverbesserung mit sich bringen.
[thrive_testimonial name=“Scrum Guide“ company=““ image=““]Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.[/thrive_testimonial]
Mehrere Produkte im Team war in diesem Setting die einzige Möglichkeit, denn es gab nicht mehr Teams, es konnten nicht weniger Produkte entwickelt werden und Scrum sollte ausprobiert werden. Es stand damit auch der experimentelle Charakter im Vordergrund.
Um was für Produkte geht es?
Die Produkte, die durch das Team umgesetzt wurden, waren reine Softwareapplikationen. Es waren teilweise kritische Applikationen im Unternehmen, teilweise auch nicht. Die Wichtigkeit der kritischen Applikationen war enorm, denn darüber verdiente das Unternehmen sein Geld. Dabei wurden die Produkte nicht im klassischen Sinne verkauft, sondern durch die Nutzung und Anwendung dieser Produkte entstand für das Unternehmen Geld.
Nicht jede Applikation wurde neu entwickelt. Es gab diese Applikationen bereits und an einigen wurde mehr neues umgesetzt, an anderen weniger. Mehrere Produkte im Team waren nötig, da diese Produkte durch ein Team betreut wurden und alle Produkte noch Anpassungen bekamen.
Zusammenstellung des Teams
Das Entwicklungsteam mit Scrum Master befanden sich an einem anderen Standtort als die drei Produkt Owner, aber alle in Deutschland. Das Team hatte die benötigten Skills aus diesem Produkt ein Produktinkrement herzustellen. Alle Teams waren bei einem Softwareunternehmen tätig. Die Product Owner waren nicht im direkten Konkurrenzkrieg sondern partnerschaftlich unterwegs. Sie stammten auch alle aus dem gleichen Unternehmen, mussten aber für bestimmte Applikationen den Mehrwert im Sinne des Kunden treiben.
Wie wurden mehrere Produkte im Team entwickelt?
Mehrere Produkte im Team zu entwickeln benötigte einige Anpassungen, die sich aber grundsätzlich einfach und unkompliziert durchführen ließen. In diesem Abschnitt gehe ich einmal auf diese Änderungen im Detail ein.
Sprint Planning 1
Das Sprint Planning 1 wurde mit allen Product Ownern der einzelnen Produkte durchgeführt. Dazu gab es im Vorfeld schon eine Abstimmung (PO-Arbeit) zwischen den einzelnen Personen. Die Product Owner haben im Vorfeld Ihre Product Backlog Items (aus drei Backlogs) gegeneinander konsolidiert und sich auch eine Reihenfolge einigen müssen. Für das Team stand genau ein Product Backlog zur Verfügung, in dem alle relevanten Items vorhanden waren. Diese waren beschrieben, geschätzt und in einer Reihenfolge sortiert. Ebenso war der Business Value in jedem Product Backlog Eintrag für das Unternehmen erkennbar.
Die Product Owner haben Ihre Einträge vorgestellt und das Team hat solange Einträge aufgenommen, solange klar war, dass die Product Backlog Einträge noch in den Sprint gepasst haben und zusätzlich auch bei Abhängigkeiten möglich waren.
Backlog Refinement
Im Backlog Refinement wurden die einzelnen Product Backlog Einträge (PBI) durchgesprochen. Für die Vorstellung und die Durchspräche eines PBI wurde in etwa 20 Minuten benötigt. Vor dem eigentlich Projekt wurden ebenso zwei Refinements unternommen, damit genug Product Backlog Einträge zur Verfügung standen. Bei einigen Einträgen war das Wissen über die Product Backlog Einträge bei allen Product Ownern verteilt und nicht alle Product Owner mussten immer anwesend sein. Um mehrere Produkte im Team zu entwickeln, war es absolut notwendig, dass immer ein Product Owner dabei war, der die Einträge erklären konnte. Das ist natürlich nicht verwunderlich, aber wichtig zu verstehen, ist es trotzdem!
Sprint Ziele
Wie sich jeder vorstellen kann, war es mit den Zielen nicht ganz so einfach, da unterschiedliche Produkte in der Regel auch unterschiedliche Ziele haben. Ebenso war es auch bei diesem Projekt. Es gab zu Beginn Ziele, die alle Teams nutzen konnten. Als die Teams starten gab es mehr „lernende“ Ziele und ebenso waren einige „qualitative“ Ziele durchaus für alle zu benutzen.
Soweit es wirklich möglich war, haben wir versucht in Abhängigkeit der Vision immer Sprint Ziele zu finden, die für alle Applikationen / Produkte galten. Das war uns wichtig, denn je nach Anzahl der User Stories war es nicht immer leicht für wenige Stories (für ein Produkt) ein extra Ziel zu finden. Es gab aber tatsächlich solche Moment, in denen wir dann pragmatisch diesen Weg gegangen sind.
Vision
Die Vision hat recht gut funktioniert. Wir haben hier den Weg gewählt, diese in vier Sätzen auf einem Flipchart zu erstellen. Es war hilfreich, dass wir die Applikationen in Summe mehr oder weniger das gleiche Ziel für das Unternehmen hatten, die Vision war also für alle gemein gültig.
Produktinkremente
Mehrere Produkte im Team bedeutete auch mehrere Inkremente, die das Team zeigt und vorstellt. Nun war es so, dass nicht alle Inkremente übermäßig viel Arbeit und Aufwand bedeuteten. Es gab nicht immer für jede Applikation ein Inkrement, sobald aber Product Backlog Items für eine Applikation vorhanden waren, gab es auch ein Inkrement.
Mehrere Produkte im Team – was war nicht so gut?
- Wenig überraschend, hat ein Team, das mehrere Produkte entwickelt, nicht viel Zeit für jedes Produkt, wie wenn das Team ein Produkt am Stück entwickeln würde. Der Arbeitsfortschritt für die einzelnen Applikationen wäre wohl schneller gewesen, wenn alle Applikationen nacheinander entwickelt worden wären. Das ist der Blick von außen auf alles. Da hier aber teils auch Wartungsarbeiten und kleine Verbesserungen vorgenommen wurden, wäre es nicht trivial, das anders aufzustellen. Die Velocity war damit nicht überragend hoch, reichte aber den Product Owner der jeweiligen Applikationen für Ihre Umsetzungen. Bei Problemen haben die Product Owner Prioritäten und Abhängigkeiten vor dem Sprint Planning mit weiteren Hierarchieebenen besprochen und eine Lösung im Vorfeld gesucht.
- Mehrere Produkte im Team bot eine neue Herausforderung für die Product Owner in der Releaseplanung. Es war nicht immer klar, wann welche User Story auf Basis der Velocity umgesetzt werden kann. Die finale Abstimmung wurde in der Product Owner Runde besprochen und dann final priorisiert. Das erforderte häufiger eine Neuplanung auf Basis aktueller Product Backlog Items, die nicht wie geplant umgesetzt werden konnten.
- Man stößt bei dem Thema „Mehrere Produkte im Team“ immer wieder an Grenzen. Diese lassen sich in Retrospektiven gut untersuchen. Das haben wir gemacht, aber keine entscheidende Verbesserung aufgrund der Rahmenbedingungen erzielen können. Es wurden mögliche Änderungen identifiziert das Setting „Mehrere Produkte im Team“ anzupassen – diese Änderungen wurden dann im Ganzen unter Berücksichtigung aller Pro und Contras mit dem Management nicht mehr adressiert.
