Scrum zu skalieren bedeutet für verschiedene Menschen verschiedene Dinge.
Woran liegt das?
Ich vermute, es liegt daran, dass immer noch so viele Halbwahrheiten kursieren. Diese Mythen sind so vorherrschend, dass ich sie auch in jedem meiner Scaled Professional Scrum Trainings und auf Vorträgen ansprechen und berichtigen muss.
Hier die fünf weitverbreiteten Mythen im Überblick und wie du sie entkräften kannst.
Mythos #1: Im skalierten Scrum arbeitet ein Scrum Team an mehreren Produkten
Das ist nur eine teure Idee.
Angenommen, wir haben ein Scrum Team, welches an drei Produkten gleichzeitig arbeitet. Dann verschwendet das Team etwa 40 % seiner Arbeitszeit mit Kontextwechseln, wie aus einer Studie von Gerald Weinberg hervorgeht. Wenn ein Teammitglied 1000 Euro am Tag kostet, die Teamgröße 10 ist, die Sprintlänge zwei Wochen beträgt und das Team 22 Sprints pro Jahr absolviert, dann kostet der Kontextwechsel dieses Teams das Unternehmen 880.000 Euro im Jahr!
Das sind die finanziellen Auswirkungen, wenn ein Scrum Team nicht den Scrum Wert Fokus leben kann.
Mythos #2: Jedes Scrum Team hat einen Product Owner
Team Ownership ist nicht gleich Product Ownership.
Scrum beschreibt ein einfaches Rahmenwerk zur Produktentwicklung. Für die erfolgreiche Entwicklung von Produkten sind dabei drei Perspektiven auf die Arbeit nötig. Eine davon ist, den Wert des Produkts zu maximieren, der durch die Arbeit der Entwickler entsteht. Damit der Wert des Produkts ganzheitlich optimiert wird, Entscheidungen schnell getroffen werden können und es einen eindeutigen Ansprechpartner für die Zukunft des Produkts gibt, übernimmt dafür genau eine Person die Verantwortung: der Product Owner. Diese Verantwortung ist unabhängig von der Anzahl der Entwickler und daher unabhängig von der Anzahl der Teams.
Im skalierten Scrum halten wir diese Tatsache in der Rule-of-One fest: Pro Produkt ein Product Backlog und ein Product Owner.
Mythos #3: Wenn ein Team nicht schnell genug liefert, sollten weitere Teams hinzugefügt werden
Fügen wir zu einem verspäteten Projekt weitere Personen hinzu, verspätet es sich noch weiter.
In den fast 10 Jahren, in denen ich bereits in der IT-Branche arbeite, habe ich noch nie jemanden getroffen, der mir glaubhaft bestätigen konnte, dass diese Aussage falsch ist. Das ist auch nicht weiter verwunderlich. Die große Hürde in der Softwareentwicklung besteht darin, dass wir die Arbeiten der einzelnen Teammitglieder zu einer nutzbaren und auslieferbaren Version des Produkts integrieren müssen. Weitere Mitglieder im Team oder ganze Teams machen diese Zusammenführung natürlich noch komplizierter. Deshalb sollten wir bei der Skalierung von Scrum immer den Grundsatz beherzigen:
Nail it before you scale it.
Mythos #4: Alle Scrum Teams halten sich an ihre eigene Definition of Done
Was ist der Zweck der Definition of Done in Scrum?
Wenn du jetzt antwortest, „die Definition of Done beschreibt die Qualitätsstandards für das Produkt“, dann stimme ich dir zu. Es handelt sich also um die Standards, die jeder einhalten muss, wenn er Änderungen am Produkt durchführt. Das ist unabhängig davon, wer er ist und welchem Team er angehört. Natürlich kann jedes Team über diese einheitlich geltenden Qualitätsstandards noch weitere Aspekte hinzufügen, aber die grundsätzlichen Qualitäten müssen gewahrt bleiben und sind Bestandteil des Produkts.
Die Definition of Done macht das Produkt transparent und ist deshalb Bestandteil des Produkts.
Überdies können wir nun die Rule-of-One noch um einen Eintrag ergänzen: Pro Produkt ein Product Backlog, ein Product Owner und eine Definition of Done.
Mythos #5: Das Team-Daily-Scrum findet vor dem teamübergreifenden Daily Scrum statt
Was ist der Zweck eines Sprints in Scrum?
Mehrwert für die Stakeholder des Produkts schaffen. Um diesen Zweck nicht aus den Augen zu verlieren, setzen sich Scrum Teams konkrete Ziele für ihre Sprints. Um die Wahrscheinlichkeit zu erhöhen, dass dieses Ziel auch erreicht wird, treffen sich die Entwickler jeden Tag und überlegen, was sie als Nächstes tun sollten, damit sie diesem Ziel näherkommen. Arbeiten jedoch mehrere Teams gemeinsam an einem Produkt, ändert sich daran erst mal nichts. Mit einer Ausnahme: Jetzt haben nicht mehr die Ziele der einzelnen Teams Vorrang, sondern das übergeordnete Ziel aller Teams. Deshalb müssen die Teams auch den Fortschritt bei der Erreichung dieses Ziels als Erstes überprüfen.
Scrum zu skalieren bedeutet, dem Grundsatz zu folgen: Optimiere erst das Ganze und dann die Teile.
Welchen Mythos habe ich vergessen? Schreibe ihn bitte in die Kommentare!