Unsere Projekte sind oft zu groß, als dass ein einziges Team an ihnen arbeiten könnte. Wir müssen also dafür sorgen, dass mehrere Teams zusammenarbeiten. In unserem Beispiel haben wir uns darauf verständigt, dass alle nach Scrum leben und arbeiten. Was sind nun unsere ersten Schritte?
Vorweg: Ihr habt wahrscheinlich schon das Eine oder Andere gelesen, wie man Scrum am besten skaliert, und dabei seid Ihr wahrscheinlich auch auf SAFe gestoßen. Für 4 – 8 Teams oder Irgendwas in dieser Größenordnung ist das zu groß und zu komplex. SAFe bedeutet, die gesamte Organisation umzustülpen – lasst die Finger davon. Wenn wir über sehr große und sehr komplexe Projekte mit mehreren hierarchischen Ebenen sprechen, wird SAFe vielleicht interessant. Sollte das Eure Aufgabe sein, können wir natürlich miteinander sprechen, aber für heute betrachten wir die einfachen Fälle.
Wir beginnen, indem wir den größten Fehler vermeiden: Weder Teamschnitt noch Aufgaben oder Kompetenzen sind unverrückbar, in Stein gemeißelt und mit Blut unterschrieben. Organisationen neigen dazu, das aktuell Bestehende zu nehmen und dies miteinander verbinden zu wollen. Wir treten jedoch einen Schritt zurück und fragen uns zunächst, wie die Teams aktuell miteinander verwoben sind.
Wir versuchen, uns ein Bild davon zu machen, wie die Abhängigkeiten aussehen. Je mehr Abhängigkeiten wir haben, je komplexer die sind, desto schwieriger und unzuverlässiger wird der ganze Mist am Ende. Wir fragen uns also, wie wir die Teams weitestgehend voneinander entkoppeln können. Ignorieren wir diesen ersten ganz wichtigen Schritt, landen wir möglicherweise in der Abhängigkeiten-Hölle, weil wir in jedem Sprint Aufgaben von einem Team zum anderen übergeben müssen.
Unser Idealbild sieht so aus, dass unsere Teams unabhängig voneinander Features entwickeln können – wir sprechen also von Featureteams. Diese Teams sind so gestaffed, dass in ihnen alle nötigen Fähigkeiten vorhanden sind, wir haben also z.B. jemanden für Datenbanken, jemanden für Frontend, Architekt usw. Die Architektur unseres Produkts unterstützt die unabhängige Arbeit voneinander. Klingt in der Theorie ganz wunderbar, und ist auch in der Praxis unser Ziel. Wir werden es niemals vollständig erreichen, aber das ist der Weg, den wir einschlagen.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Der Gegensatz hierzu – und das ist es, was wir in vielen Organisationen finden – sind Komponententeams. Die können wir ganz frei als Spezialistenteams bezeichnen. In einem Team sind also all unsere Datenbankleute, im nächsten alle Infrastrukturleute usw.
Das Komponententeammodell bedeutet, dass jedes Feature mehrere Teams durchlaufen muss, was bedeutet, dass die Absprachen sehr komplex werden, und dass die Entwicklung sehr fragil wird.
Was ist damit gemeint? Ein Beispiel: Zuerst muss Infrastruktur einen Server aufsetzen, auf den kommt ein Betriebssystem, darauf eine Datenbank, die konfiguriert werden muss. Diese wird mit Daten gefüllt, die ausgelesen und ausgewertet werden. Damit haben wir eine Kette gebildet. Wenn nun das erste Glied in dieser Kette seine Zusage nicht einhalten kann und nicht nach einem Sprint fertig ist, sind alle weiteren Elemente der Kette betroffen, die Dominosteine fallen also einer nach dem anderen.
Wenn Ihr irgendwie die Chance habt, vermeidet diese Abhängigkeitsketten. Wir kommen also zurück zum Entkoppeln unserer Teams und damit eventuell auch zum Teamschnitt. Wenn wir das vermeiden und sagen, dass uns das jetzt zu aufwändig ist, wird der Aufwand, den wir später treiben müssen, noch viel größer sein. Glaub mir: Ihr seid besser dran, jetzt in den sauren Apfel zu beißen und den Teamschnitt zu überdenken als später in die Abhängigkeitenhölle zu kommen.
Wie man die Abhängigkeiten zwischen Komponententeams auflösen kann, ist wahrscheinlich ein Thema für einen anderen Beitrag, weil das nicht ganz einfach ist. Im Zweifel sprecht mich an, und wir reden miteinander.
Vielleicht wird der eine oder andere von Euch jetzt sagen, dass wir auf diesem Weg Silos schaffen, und Ihr habt damit sogar Recht. Wir müssen also auch darauf achten, die zu vermeiden.
Wir gehen davon aus, dass wir sparen müssen. Wir haben also keinen Chief Product Owner (was das ist, sehen wir uns auch ein anderes Mal an), wir haben keinen dedizierten Scrum Master für eine skalierte Ebene. Wir haben eine Handvoll Teams, in jedem Team gibt es einen Product Owner und jeweils zwei Teams teilen sich einen Scrum Master.
Ja, ich weiß, der Scrum Guide will das anders, aber in der echten Welt müssen sich viele Teams Scrum Master teilen.
Wir beginnen damit, auf Entwicklerebene zu sprechen. Jedes Team entsendet einen oder maximal zwei Vertreter, und wir klären die Gemeinsamkeiten. Das sind zunächst technische Fragen Richtung Architektur, Entwicklungsumgebung, Deployment Chain usw., woraus sich Regeln für unser gesamtes Konstrukt ergeben. Die Teilnehmer tragen diese Regeln und Erkenntnisse in ihre eigenen Teams. Moderiert wird die ganze Runde von einem der Scrum Master.
Zusätzlich haben wir selbstverständlich auch organisatorische und Prozessfragen wie z.B. eine gemeinsame Definition of Done oder gemeinsame Austauschrunden, gemeinsame Planungssessions und vieles mehr. Hierfür kommen wir zusammen mit Product Ownern, Scrum Mastern und einzelnen Entwicklern, damit wir alle Stimmen hören.
Dies wird eine relativ große Runde. Wenn wir von sechs Teams ausgehen, haben wir 6 x 3 Personen darin. Ich rate also dringend dazu, schon Vorschläge vorzubereiten. Dies kann in kleineren Runden geschehen.
Es moderiert wieder einer der Scrum Master.
Teamschnitt, Zuständigkeiten, gemeinsame Regeln erarbeiten wir, bevor wir tatsächlich starten. Für die eigentliche Arbeit am Projekt sollten wir ein gemeinsames übergreifendes Backlog anlegen, das die POs gemeinsam füllen und priorisieren. Hier bewegen wir uns auf Überschriftenebene. Die Einträge hier werden möglicherweise zu Epics, wenn sie an die Teams übergeben werden.
Diese eine skalierte Ebene der Product Owner kann dabei durchaus in einem Kanban-light-Modus agieren. Wir haben also ein Board, und die Dinge, die in einem Team bearbeitet werden, sind in Progress. Wir einigen uns hier darauf, welches Team welches Feature (wir bewegen uns also auf dieser Ebene) übernimmt. Der betreffende Product Owner nimmt das Feature mit in sein Team, zerteilt es gemeinsam mit seinen Entwicklern in einzelne Anforderungen und füllt das Teambacklog.
Wenn wir keine saubere Trennung hinbekommen und mit zwei Teams an einem Feature arbeiten müssen, ist es Aufgabe dieser beiden Teams sich miteinander abzusprechen. Da hat sich kein anderer einzumischen. Viele Köche verderben den Brei – wir wissen das. Zwei Teams finden eigentlich immer eine Lösung, sich zu ergänzen. Das kann so aussehen, dass Dinge zu bestimmten Zeitpunkten übergeben werden. Es kann aber auch so aussehen, dass einzelne Kollegen zeitweise ein anderes Team unterstützen, um dort die nötigen Skills beizutragen. Ihr seid vollkommen frei in der Wahl Eurer Methoden. Achtet jedoch darauf, nicht zu viel Fluktuation zu haben. Unsere Teams sind und bleiben stabil. Einen Kollegen für eine kurze Zeit auszuleihen, ist ok, aber wir tun das nicht ständig. Unser Ziel ist nach wie vor, Abhängigkeiten zwischen den Teams zu vermeiden.
Wir sollten nach jedem Sprint neben den Reviews der Teams auch ein gemeinsames Review einplanen, das weniger der Abnahme als eher der Information dient, damit alle wissen, was im Projekt geschehen ist.
Ebenso benötigen wir neben den Retrospektiven in den Teams auch eine Form der gemeinsamen Retro, in denen wir Themen ansprechen, die uns alle betreffen. Ein einfacher Weg hierfür ist es, nach den Retros in den einzelnen Teams noch einmal in größerer Runde (die Scrum Master und jeweils einer aus jedem Team zusammenzukommen und die Dinge zu betrachten, die in den einzelnen Retros aufgekommen sind, die uns aber alle betreffen. Auch diese Runde wird von einem der Scrum Master moderiert.
Letztlich müssen wir uns noch darum kümmern, dass wir den fachlichen Austausch zwischen den Teams gewährleisten. Wir haben einen Austausch bei den Product Ownern durch die Arbeit am gemeinsamen Backlog. Zusätzlich rate ich Euch dazu, eine Entwicklerrunde einzuführen. Das soll keine klassische Community of Practice sein, auch wenn wir sie meinetwegen so nennen können. Hier geht es darüber, dass Entwickler untereinander über all die Dinge sprechen, die sie alle betreffen. Das können Architekturthemen sein, das können gegenseitige Schulungen sein. Dies ist eine unserer Möglichkeiten, die Silos zu vermeiden.
Kernaussagen: Skalieren wir Scrum über mehrere (wenige) Teams, achten wir zunächst darauf, die Teams weitestgehend zu entkoppeln. Danach erarbeiten wir gemeinsame Regeln. Ein gemeinsames Backlog füttert die Backlogs der einzelnen Teams, die weitestgehend unabhängig voneinander agieren können.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
