Scrum bis ans Limit skalieren

Wahrscheinlich hat man Ihnen schon einmal die Frage gestellt: "Wir müssen schneller werden, wie viele Leute brauchen wir dafür?" Den meisten Menschen ist natürlich klar, dass eine beliebige Anzahl von Mitarbeitern uns kurzfristig nicht schneller machen wird. Wie können Sie also Scrum bis an die Grenzen skalieren? Und was sind diese Grenzen? Lernen Sie Peter kennen. Er ist Produktverantwortlicher eines neuen Teams, das an der größten Erfindung seit geschnittenem Brot arbeitet. Sie wird riesig sein. Es wird das Beste sein. Peter hat mit einem kleinen Team, bestehend aus sechs seiner besten Freunde, mit diesem neuen Produkt begonnen und es hat sich wirklich gut entwickelt. Um den Anforderungen gerecht zu werden und gleichzeitig neue Funktionen hinzuzufügen, muss Peter entweder mehr Wert aus seinen Teams herausholen und, wenn das nicht mehr möglich ist, mehr Teammitglieder einstellen. Er und seine Teams haben eine Reihe von Sprints durchgeführt, um Scrum zu verbessern, Continuous Integration eingeführt und sogar mehrmals am Tag in die Produktion geliefert. Es ist erstaunlich, was man mit einem engagierten Team, das bereit ist, sich zu verbessern, erreichen kann. Aber seit ihr Produkt in den Google Play Store aufgenommen wurde, sind sie an ihre Grenzen gestoßen. Peter befand sich in der klassischen Situation, in der sich viele Produktverantwortliche und Projektmanager befinden. Wie können Sie die Fähigkeiten Ihres bestehenden Teams replizieren, ohne die derzeitigen Hochleistungsteams zu zerstören? Er wendet sich an eine gute Freundin, Anna, die bereits mit dieser Situation zu tun hatte, und bittet sie um Rat. Anna erklärt, dass es zwei Optionen für ein schrittweises Wachstum gibt, die eine sehr hohe Erfolgschance bei begrenztem Risiko für sein produktives Team haben.

1. Modell "Wachsen und Teilen

Bei diesem Modell werden neue Teammitglieder dem bestehenden Team hinzugefügt, und zwar ein Teammitglied nach dem anderen, wobei Sie sich genügend Zeit nehmen, um das neue Mitglied einzugewöhnen, bevor Sie das nächste hinzufügen. Sobald das Team einen kritischen Punkt erreicht, kommt es zwangsläufig zu einer natürlichen Aufspaltung und Sie haben am Ende zwei oder mehr kleinere Teams. Peter bleibt der alleinige Product Owner (ein Produkt gehört in Scrum immer einem einzigen Eigentümer), aber mit zunehmendem Wachstum kann ein zusätzlicher Scrum Master hinzukommen, der die Teams unterstützt und ihnen hilft, sich weiter zu verbessern.

Meistens geschieht die Aufteilung auf natürliche Weise, wenn ein Team über eine bestimmte Größe hinauswächst. Dies ermöglicht es dem Team, seine neue Zusammensetzung selbst zu verwalten. Allerdings kann es sein, dass die neuen Teams nie so gut arbeiten wie das ursprüngliche Team.

2. Das Lehrlingsmodell

Das zweite Modell, erklärt Anna, nutzt ein uraltes Modell, um neue Mitarbeiter auszubilden. Beim Lehrlingsmodell nimmt das bestehende Team zwei Lehrlinge auf, die in den Arbeitsweisen und dem Funktionsbereich geschult werden. Nach ein paar Sprints erreichen diese Lehrlinge ihren Gesellenstatus und gründen ein eigenes Team.Der größte Vorteil dieses Modells ist, dass das ursprüngliche Team zusammenbleibt. Sie müssen die Auszubildenden einarbeiten und anlernen, was sich wahrscheinlich auf die Art und Weise auswirkt, wie sie zusammenarbeiten, aber dieses Modell hat eine viel höhere Chance, die Produktivität des ursprünglichen Teams beizubehalten. Es kann ein paar Sprints dauern, bis das neue Team das gleiche Produktivitätsniveau erreicht wie das ursprüngliche Team, aber Sie haben eine höhere Chance, Ihr erstes Team stabil und produktiv zu halten. Leider gibt es auch bei diesem Modell keine Garantien. Die Aufnahme neuer Mitarbeiter in ein bestehendes Team kann dauerhafte Auswirkungen haben, auch nachdem diese Mitarbeiter das Team verlassen haben. Diese Auswirkungen können sowohl positiv als auch negativ sein. Sie können z.B. eine neue Testtechnik mitbringen, die allen hilft, produktiver zu werden, oder sie können neue Erkenntnisse mit sich bringen, die zu einer Spaltung des ursprünglichen Teams führen. Je nach Team können sie von beidem profitieren, aber es kann sie auch auseinanderreißen. Es ist immer so, dass das ursprüngliche Team nun lernen muss, mit dem neu gebildeten Team zusammenzuarbeiten, was sich wahrscheinlich massiv auf seine Produktivität auswirken wird.

Wissen, wann man aufhören sollte zu skalieren

Peter fragt sein Team, mit welchem Modell es sich am wohlsten fühlt, und das Team beschließt, mit dem Grow-and-Split-Modell zu beginnen und, nachdem sie sich in zwei Teams aufgeteilt haben, das Lehrlingsmodell zu übernehmen, um bei Bedarf weiter zu wachsen. Er bittet auch Anna, sich seinem Unternehmen anzuschließen. Sie übernimmt die Rolle des Scrum Master und konzentriert sich darauf, den Teams zu helfen, sich zu verbessern und Lösungen für viele der Probleme zu finden, die durch die Arbeit mit mehreren Teams entstehen. In der Zwischenzeit bittet Peter die Teams immer wieder, neue Teammitglieder auszubilden und die Zahl der Teams wächst stetig. Eines Nachmittags klopft Anna an Peters Tür und zeigt ihm ein paar Statistiken, die sie schon so lange führt, wie sie in der Firma arbeitet. Ihren Statistiken zufolge hatte sie den pro Sprint gelieferten Wert sowie die Geschwindigkeit der einzelnen Teams verfolgt - die letzten Neuzugänge waren nicht in der Lage, wirklich mehr zu liefern. Sie argumentiert, dass der Aufwand für die Zusammenarbeit mit so vielen Teams das Maximum erreicht hat, das die derzeitige Architektur verträgt. Sie hat die Teams befragt und herausgefunden, dass die Mitarbeiter über die Arbeit der anderen stolpern, dass die Integration regelmäßig scheitert und dass die Mitarbeiter zu viel Zeit in Meetings und zu wenig Zeit mit der "echten Arbeit" verbringen. Trotz der Praktiken, die sie eingeführt hat, wie teamübergreifende Verfeinerung und Visualisierung von Abhängigkeiten, scheint es, dass sie die maximale Größe für das Produkt erreicht haben. Peter ist zwar ein wenig enttäuscht, aber er muss zugeben, dass Anna ihn gewarnt hat, dass er nicht einfach immer mehr Leute einstellen und erwarten kann, dass immer mehr Arbeit erledigt wird.

Nützliche Metriken bei der Skalierung

Während die Geschwindigkeit (gelieferte Story Points), die aufgewendeten Stunden und die Anzahl der bestandenen Tests brauchbare Methoden sind, um den Fortschritt eines Entwicklungsteams zu verfolgen, ist es einfach, die Geschwindigkeit zu messen, mit der wertloser Schrott in die Produktion geliefert wird. Aus diesem Grund hat Anna auch andere Metriken im Auge behalten, wie den gelieferten Wert, die Kundenzufriedenheit (durch App-Store-Rezensionen), Vorfälle in der Produktion (durch die eingesetzten Überwachungstools) und mehr.[1] Es ist wichtig, Statistiken über die Menge des gelieferten Werts zu führen, während Sie skalieren. Sie werden wahrscheinlich feststellen, dass die Gesamtzahl der Teams zwar steigt, aber jedes neue Team immer weniger Wert liefert. Dies ist eine Art gläserne Decke, an die Sie früher oder später stoßen werden. Um sie zu durchbrechen, sind möglicherweise drastische Änderungen an der Architektur der Anwendung oder an der Art und Weise, wie die Teams zusammenarbeiten, erforderlich. Da Peter und das ursprüngliche Team nicht damit gerechnet hatten, dass das Produkt so schnell auf den Markt kommen würde, wurde die Architektur der Anwendung etwas willkürlich zusammengestellt. Und unter dem Druck, das Produkt zu liefern, haben sie links und rechts ein paar Abstriche gemacht. Er ruft alle seine Teams in die Firmenkantine und erklärt ihnen seine missliche Lage. Jedes Team wählt ein oder zwei seiner erfahrensten Teammitglieder aus und sie bilden ein temporäres Expertenteam, um herauszufinden, wie sie ihr kleines architektonisches Monstrum aufbrechen können. Nachdem sie einige Funktionsbereiche herausgelöst und in kleinere, einzeln einsetzbare Teile einer zusammenhängenden Funktionseinheit umstrukturiert haben, wird schnell klar, dass diese neue Architektur verhindert, dass sie sich gegenseitig über die Füße treten. Vielleicht haben Sie schon einmal von diesem Modell gehört: kleine funktionale, zusammenhängende Code-Einheiten, die ihre eigenen Daten verwalten und die als Microservices bezeichnet werden. Diese kleinen Einheiten sind ideal, um Teams zu bilden und geben diesen Teams eine Menge Freiheit.

Hätten wir es anders machen können?

Einige Zeit später trifft Peter Anna in der Kaffee-Ecke der Firma und fragt sie, ob sie nicht einen anderen Ansatz hätten wählen können, der die Probleme in ihrer ursprünglichen Architektur in einem früheren Stadium der Produktentwicklung aufgezeigt hätte. Er fragt sich auch, ob sie schneller hätten skalieren können, indem sie erfahrene Teams eingestellt hätten. Anna erklärt, dass es noch eine dritte Option gab, die sie Peter nie erklärt hat, weil sie ein viel höheres Risiko darstellte und sie sich nicht traute, das Produkt zu gefährden. Die dritte Option bestand darin, schnell eine Reihe von Teams auf einmal hinzuzufügen, vorzugsweise Teams aus Personen, die bereits Erfahrung in der Zusammenarbeit hatten und die Erfahrung mit der Arbeit in einer solchen Größenordnung hatten. Gleichzeitig würden die ursprünglichen Teammitglieder auf die neu gebildeten Teams verteilt werden, optional im Wechsel, um ihr spezifisches Wissen über den Bereich oder die Prozesse weiterzugeben und die Architektur und Infrastruktur zu erläutern. Da Sie bei diesem Modell die Probleme in den etablierten Prozessen und in der Architektur frontal treffen, müssen alle zusammenarbeiten, um schnell Lösungen für alle Probleme zu finden, auf die sie stoßen. Wenn ihnen das gelingt, können sie vielleicht schnell einen Weg finden, um zusammenzuarbeiten. Sie können aber auch völlig zum Stillstand kommen oder das Ausmaß der Konflikte kann ungeahnte Ausmaße annehmen.

3. Modell streuen und rotieren

Um sicherzustellen, dass die neuen Teams den gleichen Zugang zu den Kenntnissen und Fähigkeiten des ursprünglichen Teams haben, rotieren die ursprünglichen Teammitglieder oft zwischen den neu gebildeten Teams oder sie sind für ein paar Sprints keinem Team zugeordnet, bevor sich alles einpendelt. Wenn dieses Modell erfolgreich gewesen wäre, hätten sie vielleicht viel schneller skalieren können. Sie hätten aber auch ihr Geschäft aufgeben können. Peter meint, dass sie dieses Risiko hätten eingehen können, wenn sie einen direkten Konkurrenten auf dem Markt gehabt hätten, der viel schneller hätte liefern können. Aber es wäre ein totales Risiko gewesen. Er ist froh, dass sie sich nicht in dieser Situation befanden.

Fazit

Es gibt eigentlich keine feste Grenze dafür, wie viele Menschen zu einem agilen Produkt oder Unternehmen beitragen können. Aber natürlich gibt es Grenzen für die Geschwindigkeit, mit der Sie wachsen können, für die Kontrolle darüber, was in jedem Team vor sich geht, und für das, was die Architektur und die Prozesse des Produkts oder der Organisation aushalten können.Es gibt mehrere Modelle, um Ihre Fähigkeit, Werte zu liefern, zu steigern. Auch wenn das Hinzufügen von Teams die einfachste Lösung zu sein scheint, können Investitionen in kontinuierliche Integration, automatisierte Bereitstellungen und eine flexible Architektur schneller zu einem nachhaltigeren Wert führen. Wenn Sie über das hinauswachsen müssen, was mit einem einzelnen Team möglich ist, denken Sie daran, dass Sie die Funktionsstörungen Ihres Teams exponentiell vergrößern werden, wenn Sie nicht darauf vorbereitet sind. Um es ganz unverblümt zu sagen: Wenn man Scheiße skaliert, hat man am Ende haufenweise davon. Wenn Sie in der Lage sind, schnell, effizient und professionell zu liefern, können Sie Ihre Teams skalieren. Messen Sie weiter, während Sie skalieren, und evaluieren Sie Ihre Arbeitsweise, Zusammenarbeit und Architektur. Anhand Ihrer Statistiken können Sie eine fundierte Entscheidung darüber treffen, ob Sie weiter skalieren wollen. Ohne sie könnten Sie Ihre Fähigkeit, Werte zu liefern, verschlechtern, ohne es zu wissen. Überprüfen Sie regelmäßig Ihre Prozesse, Tools, Architektur und Teamzusammensetzung. Ihr Team wird wahrscheinlich wissen, was zu verbessern ist, um mehr von den richtigen Dingen effizienter zu liefern.

Möchten Sie mehr erfahren? Nehmen Sie an einem Scaled Professional Scrum-Kurs teil und erleben Sie Scrum mit Nexus hautnah.