Agile Methoden und insbesondere Scrum sehen bei einem kleinen Produkt mit einem einzigen Team ganz einfach aus. Sobald mehrere Teams an einem Produkt arbeiten, muss die Arbeit irgendwie aufgeteilt werden. Der naheliegende, weil bekannte, Ansatz ist es, das Produkt mehr oder weniger logisch und sinnvoll in Komponenten zu zerlegen und diese mit Komponententeams zu besetzen. Aus Sicht des Kunden sind diese Komponenten allerdings völlig irrelevant. Im besten Fall merkt er davon gar nichts. In den meisten Fällen allerdings schon, weil zwischen seinem Nutzen und den dafür notwendigen Funktionen des Produkts in der Regel mehrere Komponentengrenzen und damit Übergaben oder Abstimmungen zwischen Teams stehen, die den Fluss unterbrechen. Schöner wäre es aus Kundensicht, wenn die neue Funktion, das Feature, von einem einzigen sogenannten Feature-Team umgesetzt würde ganz egal welche Komponenten betroffen sind.
Jeder der schon mal ein Haus gebaut oder renoviert hat kennt das gut. Eigentlich will man „nur“ Sonnenschutz an den Fenstern anbringen lassen. Leider geht das oft nicht aus einer Hand, sondern erfordert neben dem Handwerker, der den eigentlichen Sonnenschutz montiert, einen Elektriker, der die Stromkabel legt, einen Maurer, der alles verputzt und einen Maler, der alles wieder streicht. Der Wertstrom von der Idee bis zum Nutzen ist mehrfach durch Übergaben unterbrochen und muss mehr oder weniger aufwändig (vom Bauherrn) abgestimmt und koordiniert werden. Wie viel unkomplizierter und schneller wäre es, den Sonnenschutz mit allem was dazu zu tun ist einfach bei einem einzigen Handwerker beauftragen zu können! Genau das ist der Unterschied aus Kundensicht zwischen Komponententeams (die spezialisierten Handwerker mit ihren jeweiligen Teilaufträgen) und Featureteams (ein Team das den Auftrag komplett abarbeitet egal welche Fähigkeiten dazu notwendig sind).
Da Kundenorientierung ein wesentliches Prinzip von Agilität ist, sind Komponententeams zwar die einfachere, aber nur die zweitbeste Lösung, um die Arbeit an einem großen Produkt aufzuteilen. Egal wie die Komponenten geschnitten werden, es bleiben die Übergaben und die Koordination zwischen den Komponenten, um dem Kunden seinen Nutzen zu bieten. Zwar sind manche Schnitte sicherlich besser als andere. Der oftmals in Software-Produkten übliche Schnitt in horizontale Schichten wie Frontend, Backend und Datenbank ist zwar ganz praktisch für die jeweiligen Experten. Aber aus Sicht des Kunden ist dieser Schnitt extrem unbefriedigend, weil jede nicht-triviale Anforderung sich durch alle Schichten ziehen wird und damit langsame und fehleranfällige Übergaben zur Folge hat. Besser sind vertikale Schnitte die das Produkt in logisch abgeschlossene Teilprodukte zerlegen. So wird ein Warenwirtschaftssystem aus wenigstens den Komponenten Einkauf, Lagerhaltung und Verkauf bestehen. Dennoch wird es auch hier Anforderungen geben, die sich nicht auf eine Komponente beschränken und dann wieder koordiniert werden müssen.
Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
Conway’s Law benannt nach Melvin E. Conway
Unabhängig vom Schnitt führen Komponententeams zur Bildung von Silos, weil sich jedes Team nur für seinen Ausschnitt des Produkts verantwortlich fühlen wird. Verstärkt wird dieser Effekt durch das Gesetz von Conway wonach „die Strukturen von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt sind“ (Wikipedia). Organisationen tendieren also dazu Systems so zu schneiden, dass sie der Organisations- und Kommunikationsstruktur ähneln. Wenn also der vertikale Komponentenschnitt dieser Organisationsstruktur folgt und mit Teams der jeweiligen Organisationseinheiten besetzt wird, zementiert das nur die Mauern der ohnehin schon vorhandenen Silos.
Featureteams, also Teams die eine Kundenanforderung von der Idee bis zum realisierten Nutzen egal in welcher Komponente des Produkts umsetzen können, sind sicherlich die bessere Wahl. Aus Kundensicht sowieso, aber auch auch aus Sicht der Organisation. Da Komponententeams nur in ihrer Komponente arbeiten können erfordert es immer einen nicht geringen Planungsaufwand, damit diese Teams immer optimal ausgelastet werden, weil nicht jede Anforderung gleich viel Aufwand je Komponente haben wird. Featureteams bedingen aber eine hohe Reife der Organisation, weil hier das Produkt von allen gemeinsam gestaltet und verantwortet wird. Organisationen die es bisher gewohnt waren, Arbeit in kleinste Schritte zu zerlegen und Menschen in starre Rollen in definierten Prozessen zu zwängen, werden sich hier anfangs große Schwierigkeiten haben. Es empfiehlt sich, dem Prinzip Shu-Ha-Ri folgend, mit kleinen Produkten mit jeweils einem Team zu starten und dabei die Haltung und Prinzipien von Agilität zu verinnerlichen. Dann kann man sich an größere Produkte mit vertikalen Komponententeams wagen und nach und nach einzelne Teams zu Featureteams ausbauen.
4 Kommentare
Hallo Marcus,
Du schöpfst mit Deinen Beispielen gerne aus unserer täglichen Arbeitspraxis und den Diskussionen in der Community unseres gemeinsamen Arbeitsgebers.
Es wäre schön wenn die Erkenntnisse, die auch in vielen anderen Foren zu finden sind, bei uns schneller aufgenommen würden. Aber wahrscheinlich gehört es eben auch zum Lernen jeder einzelnen Organisation, alle Fehler zu wiederholen. Dass durch fehlende Vernetzung grosse Organisationen – bestehend aus vielen kleinen Organisationen – schlecht bis nicht lernen haben wir beide ja bereits vor Monaten besprochen.
Wenn diese Dinge immer mehr zum Ärgernis in der täglichen Arbeit werden, was kann man dann tun?
Magst Du nicht einen Artikel schreiben über Frustbewältigung anlässlich einer agilen Transformation? Auch wenn ich weiss dass alle mitgenommen werden müssen ist es doch frustrierend, dass ausgerechnet die langsamsten die Geschwindigkeit bestimmen sollen…
Lieber Michael, das wäre in der Tat schön, wenn das Lernen schneller voran ginge. Ein Rezept zur Frustbewältigung habe ich leider auch nicht. Ich halte es mittlerweile mit Götz W. Werner und seinem Motto: „Beharrlich im Bemühen, bescheiden in der Erfolgserwartung.“
Stehen Featureteams nicht grundsätzlich im Konflikt mit der ursprünglichen Definition von Scrum Teams?
Ein wesentlicher Aspekt eines Scrum Teams ist die Selbstorganisation. Task/Stories erledigen zu können, ohne dabei von anderen Teams abhängig zu sein. Denn diese Abhängigkeit bedeutet immer Reibungsverluste. Bei Featureteams müssen mehrere Teams ihre Änderungen an derselben Komponente koordinieren. Im schlimmsten Fall stehen die Anforderungen, die verschiedene Teams umsetzten müssen, sogar im Konflikt zueinander. Die Gefahr besteht, dass innerhalb einer Komponente nochmals vertikale Silos entstehen – um diese Konflikte zwischen verschiedenen Teams zu umgehen.
Nach meiner Interpretation von Conways Law, sollte man genau deshalb diese Situation vermeiden. Im Wesentlichen sagt dieses ja aus, dass um Teams automatisch Silos entstehen werden. Darum sollten auch Teams, Komponenten und Organisations-Struktur korrelieren, damit daraus möglichst wenige Konflikte entstehen.
Komme ich regelmäßig in die Situation Features über mehrere Teams verbreiten zu müssen, dann deutet das meiner Meinung auf ein Architektur-Problem hin. Die Silos korrelieren nicht mit den Anforderungen. Die Verletzung des Single-Reponsibility-Prinzips führt genau zu solchen Problemen. Ziel sollte es sein dieses Problem zu beheben.
Spannende Gedanken. Wie immer kommt es drauf an. Natürlich ist es toll, wenn jedes Team seins hat und es eine klare Verantwortung gibt. Darunter leidet aber auch die Flexibilität und letztlich die Wertschöpfung. Was passiert nämlich, wenn in einer Komponente mal weniger zu tun ist und umgekehrt an einem anderen Eck mehr zu tun wäre um die wirklich wichtigen Sachen umzusetzen? Dann macht jedes Team immer noch seins und das führt dazu, dass auch an Sachen gearbeitet wird, die global gesehen nicht so wichtig wären.
Ich sehe auch keinen Widerspruch zur Selbstorganisation. Die beinhaltet doch auch die Koordination mit anderen Teams.