Diesen Monat habe ich in drei verschiedenen Professional Scrum Product Owner Kursen diese Frage bekommen. Könnte Zufall sein. Andererseits, wenn eine Product Owner:in erfolgreich ihr Produkt voranbringt, dann könnte der Wunsch entstehen in mehr Mitarbeiter:innen zu investieren.
- Mehr Scrum Teams => mehr Wertschöpfung?
Genau hier liegt die erste Herausforderung. Auch wenn die finanziellen Mittel zur Verfügung stehen, sollte man sich gut überlegen, ob die steigende Komplexität durch mehr Mitarbeiter:innen wirklich nötig und hilfreich ist. Ich habe in meinem Berufsleben schon so extreme Fälle erlebt, dass eine Abteilung um 1000 Mitarbeiter:innen reduziert wurde (keine Sorge, die 1000 Mitarbeiter:innen bekamen neue Aufgaben in anderen Abteilungen) und damit das Produkt gerettet werden konnte. Mehr Mitarbeiter:innen kann mit erheblichen Nachteilen verbunden sein.
Zunächst sollte man fragen, ob zum Beispiel die Scrum Team(s) in jedem Sprint in der Lage sind ein verwendbares Increment zu liefern, und in der Lage sind ein Sprint Ziel zu formulieren, das sie dann auch erfolgreich umsetzen können, und so weiter. Das alleine könnte schon helfen die Wertschöpfung signifikant zu steigern. Wenn man die Probleme im Kleinen nicht löst, so werden sie sich in einer größeren Organisation exponentiell vergrößern.
- Mehr Scrum Teams => mehr Product Owner:innen?
Egal wie viele Scrum Teams an EINEM Produkt arbeiten, es gibt nur EINE Product Owner:in.
Was passiert, wenn man mehr als eine Product Owner:in hat?
Lokale Optimierung, politische Spiele und verzögerte Entscheidungen führen oft zu suboptimalen Lösungen, schlechterer "Time to Market" und demotivierten Mitarbeiter:innen. Das ist auf Dauer typischerweise kein Erfolgsrezept.
Firmen haben auch nur einen CEO egal wie viele Mitarbeiter:innen die Firmen haben. Die Aufgaben einer Product Owner:in ändern sich, wenn mehr Scrum Teams dazu kommen weg von taktischen hin zu strategischen Aufgaben. Ein wichtiges Instrument ist dabei unter anderem geeignete Vorgaben in Form von Vision und Zielen zu gestalten.
Mehr Scrum Teams => mehr Status Reporting?
Auf keinen Fall! Das sogenannte Wassermelonen-Reporting (aussen grün und innen rot) hat schon so manche Firma bzw. manches Produkt in den Abgrund gestoßen. Es gilt weiterhin das agile Manifesto mit dem Prinzip: "Funktionierende Software ist das wichtigste Fortschrittsmaß".
Das Gegenmittel heisst: die Product Owner:in setzt gemeinsame Ziele, so dass die Scrum Teams daraus lokale Ziele ableiten können.
Und im gemeinsamen Sprint Review wird EIN Integriertes Increment genutzt, Bruchstücke von verschiedenen Scrum Teams sind nicht verwendbar und damit unzulässig.- Wie schneidet man mehr Scrum Teams sinnvoll?
Die grösste Herausforderung beim Scaling sind Abhängigkeiten. Es gilt diese soweit wie möglich zu reduzieren. Prinzipiell gibt es die Möglichkeit Komponenten Teams versus Feature Teams zu schneiden.
Wenn man Komponenten Teams schneidet, dann entstehen typischerweise die meisten Abhängigkeiten zwischen den Teams und keines der Teams kann alleine Wert für Nutzer:innen erzeugen. Wahrscheinlich profitiert die Software-Architektur durch Komponenten Teams, aber das ist auch so ziemlich der einzige Vorteil. Ja, es ist ein Herausforderung für die Feature Teams eben jene Features durch den gesamten Stack zu bauen. Deshalb kommt es darauf an, dass die Mitarbeiter:innen in einem Feature Team in Summe alle Schichten beherrschen, also ein interdisziplinäres Scrum Team sind. - Wie schneidet man Produkte sinnvoll?
Und schließlich gibt es noch eine andere wichtige Stellschraube, die enormen Einfluß auf den Erfolg haben kann. Wenn man an ein Auto denkt, dann besteht dieses aus vielen Teilprodukten, die eine wahrnehmbare Nutzererfahrung erzeugen. So gibt es ein Radio, die Sitze, die Felgen und so weiter, die von verschiedenen Zulieferern erstellt werden. Man kann ein Produkt in kleinere Produkte zerlegen. Ich habe zum Beispiel mal in einer Organisation mit 2200 Mitarbeiter:innen gearbeitet, die 9 Produkte entwickelt haben, die zusammen als Suite verkauft werden. Was es beim Schneiden von Produkten zu beachten gibt, habe ich in diesem Blog beschrieben.
Wie man Business Agilität für eine Menge von Produkten - d.h. ein Portfolio - managen kann, ist in diesem Paper beschrieben.
Aus meiner Erfahrung sind das sind die TOP 5 Punkte. Prinzipiell gilt es ein möglichst einfaches Scaling Rahmenwerk wie zum Beispiel das Nexus Rahmenwerk zu wählen, dass diese Punkte unterstützt. Einfach deshalb, weil Scaling alleine schon schwer genug ist und man daher unnötige Komplexität unter allen Umständen vermeiden sollte.
Ich hoffe, das bringt ein wenig Licht in das Thema und wenn Ihr mehr wissen wollt, dann kontaktiert mich einfach.