Einige Fragen wiederholen sich in meinen Kursen. In den kommenden Woche werde ich ein paar wiederkehrende Fragen hier einmal aufgreifen und meine quasi Standard-Antworten auf meinem Blog einmal verschriftlichen – nicht weil ich glaube, dass die Fragen damit weggehen, sondern vielmehr, weil ich hoffe, dass meine Perspektiven auf diese wiederkehrenden Fragen dadurch etwas weitere Verbreitung finden als lediglich bei den 10-20 Teilnehmenden in meinen Kursen. Wir beginnen heute mit der Frage, warum im aktuellen Scrum Guide beim Scrum-Team erwähnt wird, dass dieses aus maximal 10 Personen bestehen soll.
Im 2020er Scrum Guide findet sich die Aussage, dass das Scrum-Team aus maximal 10 Personen bestehen soll. In vorherigen Versionen stand beim Entwicklungs-Team etwas ähnliches, wobei die Begrenzung da bei 3-9 Personen lag. Was mache ich bei komplexeren Produkten? ist bei meinen Erklärungen dann häufig auch noch eine Folgefrage, die auftaucht.
Wie hart sollte man diese Grenze fahren?
Als erstes, wie hart ist diese 10-Personen-Grenze zu sehen? Jeff Sutherland hat dazu vor einiger Zeit auf der Scrum-Trainer-Mailingliste einmal eine eigene Erfahrung geteilt. Die Situation war, dass sie ein 9-Personen-Team hatten und wussten, dass sie zukünftig noch weiter wachsen wollten. Also stellte sich die Frage, ob sie jetzt sofort das Team splitten in beispielsweise ein 4- und ein 5-Personen-Team, und dann unabhängig in beiden Teams weiterwachsen, oder ob sie in dem einen Team auf beispielsweise eine Größe von 12 zunächst wachsen und dann erst eine Aufteilung in zwei Teams unternehmen. Sie haben sich für die erste Option entschieden und diese Grenze als harte Grenze angesehen.
Über die Jahre habe ich gelernt, dass man Zahlen von Jeff Sutherland stets etwas suspekt gegenüber sein sollte. Von dem 9-Personen-Team wussten sie, dass es 60 Story Points jeden Sprint erledigt bekommt. Nach dem Aufteilen in ein 4- und ein 5-Personen-Team haben sie darin investiert, dass zwei gute neue Teams entstehen konnte, die gut aufeinander eingespielt sind. Jeff Sutherland hat nach eigener Aussage damals einen sehr guten Team-Coach, so nach drei Sprints getrennt voneinander Arbeiten beide Teams ziemlich gut funktioniert haben. Nach diesen drei Sprints haben sie eine kombinierte Geschwindigkeit der zwei Teams von 180 Story Points gemessen.
In nur drei Sprints hat sich nicht viel dramatisch an den Story Points im Product Backlog getan, so dass eine gewisse Vergleichbarkeit zwischen Vorher und Nachher noch existieren dürfte. Euphorisch ausgedrückt haben sie mehr oder weniger durch das einfach Aufsplitten des Teams die Produktivität verdreifacht – könnte ich behaupten, wenn ich nicht gesunde Skepsis an den Tag legen würde. Allerdings sind selbst mit Skepsis betrachtet, diese Zahlen immer noch überzeugend für mich.
Sowohl Alistair Cockburn als auch Jerry Weinberg haben diesen Effekt unabhängig von einander wie folgt beschrieben. In der sozialen Dynamik in einem Team hat jedes Teammitglied nicht nur die sozialen Verbindungen von sich selbst zu jeder anderen Person im Team im Kopf, sondern das Netzwerk, das die Teammitglieder untereinander entfalten, also wie die anderen jeweils zu den anderen stehen. Bei einem 5-Personen-Geflecht sind die Anzahl der Verbindungen untereinander noch einigermaßen überschaubar, bei einem 10-Personen-Geflecht wächst die Anzahl der Verbindungen untereinander exponentiell.
Dieses exponentielle Wachstum der sozialen Verbindungen im Team ist nach Aussagen von Weinberg und Cockburn der Grund, warum ein kleineres Teams besser funktioniert. Im letzten Jahr beim Lesen von Virginia Satir fiel mir noch auf, dass es noch komplizierter wird, wenn man nicht nur 1:1-Verbindungen im Team betrachtet, sondern zusätzlich noch Konstellationen von 1:2-Verbindungen aufnimmt, oder sogar noch weiter darüber hinausgeht. Die von Sutherland geteilten Effekte sind somit durch die soziale Dynamik in Teams erklärbar.
Aber was machen wir mit <spezielle Funktion einer Person hier einfügen>?
Meistens kommt dann sofort die Folgefrage: Wenn wir jetzt aber einen Java-Entwickler, zwei Frontend-Entwicklerinnen, einen Architekten, einen Hardware-Designer, einen CAD-Spezialisten, einen Tester, einen UX/UI-Designer, und zwei Musterbauer benötigen, sind wir schnell über dieser Grenze. Wie geht man mit diesen ganzen Spezialfähigkeiten um? Hier wittere ich sofort eine falsche Dichotomie.
Das Problem liegt darin, dass Fähigkeiten mit Menschen gleichgesetzt oder verwechselt werden. „Ich brauche Fähigkeit X im Team“ wird dann schnell gleichgesetzt mit „Ich muss noch eine Person im Team aufnehmen, die Fähigkeit X mitbringt“. Wenn ich bei Fähigkeit X bleibe, kann ich aber auch noch die Frage stellen, wie ich im Team Fähigkeit X aufbauen kann. Natürlich kann ich einen Spezialisten für X einstellen und in mein Team packen. Ich kann auch fragen, ob jemand im Team X vielleicht lernen möchte und wir ihn auf eine Schulung zu X schicken sollten, die Person mit einem Spezialisten zu X eine Zeit zusammen arbeiten möchte, oder, oder, oder. Als Menschen sind wir nicht auf die Welt gekommen mit den Fähigkeiten die wir heute besitzen, sondern wir haben diese Fähigkeiten über die Zeit gelernt. Wenn ich bei der 10-Personen-Grenze bleiben möchte, kann oder muss ich also regelmäßig auch nach Alternativen suchen, um Fähigkeit X im Team zu verankern, die nicht bedeuten, dass dauernd eine Person hinzukommen muss. Die Alternative wäre sonst, dass ich mein Team immer größer und damit immer weniger effektiv werden lasse. Bei aller guter Intention den Spezialisten zu X ins Team aufzunehmen, würde ich somit die Geschwindigkeit des Teams wieder verringern, so dass sich Vorteile eventuelle durch die Nachteile aus der Sozialdynamik aufheben. Wenn ich das verhindern will, geht kein Weg daran vorbei, dass ich über Fähigkeiten und deren Aufbau in einem bestehenden Team nachdenke und nicht dauernd neue Leute in das Team werfe.
