Agilität
Kommentare 4

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.

NEU: Das Manifest für menschliche Führung als Taschenbuch.

Taschenbuch Cover Manifest Zum ersten Jahrestag gibt es das Manifest für menschliche Führung nun in ausführlicher Fassung (inkl. Workshop-Format) als Taschenbuch bei Amazon (auch als E-Book erhältlich). Ich freue mich über Rezensionen und viele Empfehlungen an Freunde und Bekannte.

Buch bestellen

Dir hat dieser Beitrag gefallen? In diesem Blog gibt es keine Werbung, weil nur der Inhalt zählt. Wenn du deine Wertschätzung für diesen Beitrag zum Ausdruck bringen willst, dann teile ihn mit Freunden, Kollegen und in Social Media.

Und ich freue mich, wenn du mir als Zeichen deiner Wertschätzung einen Kaffee ausgibst, denn schließlich ist ein Blogger, in Anlehnung an das Zitat von Paul Erdős and Alfréd Rényi, auch nur eine Vorrichtung um Kaffee in Artikel zu verwandeln. Gerne kannst du dieses Blog monatlich als Mitglied (ab 1€) unterstützen (via Steady).

Vielen Dank!

Einen Kaffee ausgeben

Monatlich unterstützen

Kategorie: Agilität

von

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.

4 Kommentare

  1. Michael Fries sagt

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

  2. Michael Franz sagt

    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.

Schreibe einen Kommentar

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