Agilität

Die Vorteile von Featureteams

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).

component-vs-feature-teams.png

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.

Autor

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.