Der Scrum Guide kennt eigentlich nur die Zusammenarbeit innerhalb eines Teams. Wollen wir mehrere Teams zusammenführen, stoßen wir schnell auf Begriffe wie SAFe oder LeSS. Bei diesen handelt es sich um Skalierungssysteme, die mitunter sehr aufwändig sind. Was ist aber ein sinnvolles Vorgehen, wenn wir nicht über einen kompletten Konzernumbau sprechen, sondern lediglich über drei Teams oder so?
Gehen wir davon aus, dass Eure Ressourcen höchst begrenzt sind. Diese Ausgangslage wird vielen von uns wahrscheinlich bekannt vorkommen. Wir müssen also Wege finden, mit wenig Aufwand dafür zu sorgen, dass mehrere Teams reibungslos zusammenarbeiten.
Grundsätzlich haben wir zwei mögliche Situationen: Entweder arbeiten alle Teams gemeinsam an einem Projekt, was natürlich etwas komplexer ist, oder die Teams arbeiten getrennt an unterschiedlichen Projekten, was zwar sehr viel weniger aufwändig ist, für unser aber nicht bedeuten sollte, dass wir gar nichts zu tun hätten.
Wir werden uns heute nur um den einfacheren Fall kümmern. Die Situation, dass wir mit mehreren Teams an einem Projekt arbeiten, erfordert natürlich reichlich Koordination. Das sehen wir uns genauer im zweiten Teil an.
Ich möchte jetzt nicht mit Euch Bullshit-Bingo spielen und über »Synergien« sprechen (der Begriff als solches ist einfach rettungslos verbrannt), wir sollten aber dennoch darüber nachdenken, wie wir voneinander profitieren können, wie wir doppelte Arbeiten vermeiden können, und welche gemeinsamen Regeln für uns Sinn machen.
Wir brauchen dafür nichts weiter als einen regelmäßigen Austausch, den wir gern »Community of Practice« nennen können, auch wenn wir uns ein wenig von den gängigen Definitionen des Begriffs entfernen. Einmal pro Sprint eine Stunde reicht im Allgemeinen. Anfänglich kann es auch etwas mehr sein, aber wenn sich die Dinge eingeschwungen haben, sind wir mit einer Stunde alle zwei Wochen ganz gut bedient.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Wir wollen herausfinden, woran welches Team aktuell und in naher Zukunft arbeitet, damit wir unsere Parallelitäten entdecken. Das kann ungefähr so aussehen:
Team 1 sagt, dass es bald an Funktionalität A arbeiten wird. Team 2 erwidert, dass es etwas Ähnliches bereits vor einiger Zeit umgesetzt hat, und bietet an, dass Team 1 die Arbeit recycelt. Jeweils ein Entwickler aus beiden Teams setzen sich später in kleiner Runde zusammen, sichten die Sourcen, der eine erklärt dem anderen die Details.
Man kann auch weiter gehen, indem ein Entwickler aus Team 2 sein Partnerteam für einen Sprint unterstützt. Auf der einen Seite verwenden wir so bereits erledigte Arbeiten mehrfach, auf der anderen Seite schaffen wir einen Wissenstransfer über Teamgrenzen hinweg. Das hilft uns dabei, Silos zu vermeiden.
Man könnte sogar noch weiter gehen und über gemeinsame Repositories nachdenken usw., aber wir wollen es für den ersten Schritt so einfach wie möglich halten.
Der zweite Aspekt, über den wir bei dieser einfachsten Form der Zusammenarbeit nachdenken wollen, sind gemeinsame Regeln. Auch hier halten wir uns an den Grundsatz, dass weniger mehr ist. Wir fragen, wo gemeinsame Regeln oder Standards sinnvoll sind, stellen aber gleichzeitig auch die Frage, was jeweils die Folgen wären, wenn wir sie nicht hätten. Das soll uns davor bewahren, zu viele Regeln aufzustellen, die uns eher behindern als nutzen.
Wir lassen hier die Teams entscheiden und schränken sie nicht thematisch ein. Wir können über Coding Guidelines ebenso sprechen wie über Terminserien, die man vielleicht miteinander koordinieren will. Auch die skalierte Ebene lassen wir bei Regelungen zu Wort kommen, weil aus einer anderen Sicht auch ein anderer Aspekt in die Überlegungen hereingebracht werden kann (z.B. ein kaufmännischer), wir sorgen jedoch dafür, dass wir zu gemeinsamen Entscheidungen kommen, und dass nicht ein Vorgesetzter zu viel vorgibt. In dem Fall bräuchten wir keine Abstimmungsrunden, wir wären wieder bei einem klassischem Management-Vorgesetzten-Gefüge.
Ich rate natürlich dringendst dazu, eine solche Runde zu betreuen. Unmoderiert wird das meistens sehr schwer, und nach kurzer Zeit löst sich der Sinn des Ganzen in Luft auf.
Es ist ebenfalls wichtig, dass wir für kurze Wege sorgen. Oft ist das gegeben, weil alle Teams in Rufweite zueinander ihre Büros haben, aber in aktuellen Homeoffice-Zeiten, wird das etwas schwieriger.
Warum ist dieser Aspekt wichtig?
Manchmal möchte man einfach nur Kleinigkeiten besprechen. Man hat nur eine kurze Frage an einen Kollegen, weil man meint, dass dieser sich in einem bestimmten Thema gut auskenne. Es ist Blödsinn, bis zur nächsten größeren Runde zu warten, weil es bis dahin noch eine gute Woche hin ist, und weil das Thema sowieso nicht für alle relevant ist. Zum Telefonhörer zu greifen, ist für viele eine große Hürde, Mails sind auch immer blöd. Was soll man also tun?
Wir wollen, dass wir uns nicht ständig gegenseitig nerven, aber auf der anderen Seite wollen wir auch kurze Kommunikationswege haben, damit man mal eben schnell eine Frage stellen kann.
Gruppenchats sind da eher schwierig. Wenn zu viel los ist, nervt es alle, und man schaltet sie ab. Wenn nichts los ist, schaltet man sie auch ab, weil eben nichts los ist. Die Möglichkeit von MS Teams oder Skype, einzelne Personen kurz anzuschreiben, wird dagegen gern genutzt. Wenn wir solche Systeme nicht zur Verfügung stehen haben, kann man über Rocket Chat nachdenken der ähnliches.
Bitte unterschätzt diesen Aspekt der einfachen Kommunikation nicht. Ganz besonders jetzt, wenn so viele im Homeoffice sitzen, ist das ganz besonders wichtig. Ich kann überall sehen, dass wir aktuell zu wenig miteinander sprechen. Auch in den Teams selbst sprechen wir oft nicht genug miteinander. Wenn wir uns nur einmal am Tag (und manchmal sogar nicht einmal jeden Tag) 15 Minuten morgens im Daily sehen, und dann versuchen, alle Themen abzuhaken, stellen wir irgendwann fest, dass wir Lücken haben. Gerade dann brauchen wir Ersatz für den kurzen Schnack an der Kaffeekanne oder in der Raucherecke.
Viel mehr müsst Ihr nicht tun, wenn Ihr weitestgehend voneinander unabhängige Teams habt. Alles, was Ihr hier braucht, ist leicht eingerichtet, der Verwaltungsaufwand hält sich in Grenzen, wir haben aber dennoch einen Weg geschaffen, voneinander zu profitieren und Silos zu vermeiden.
Kernaussagen: Wenn wir Scrum über mehrere (wenige) Teams skalieren, diese aber nicht an gemeinsamen Projekten arbeiten, sollten wir dennoch für einen regelmäßigen Austausch sorgen, um sowohl gemeinsame Regeln als auch mögliche gegenseitige Unterstützung zu fördern.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
