Schwerpunkte

Mitarbeiterführung

Teamwork: Aber richtig

14. Mai 2020, 14:29 Uhr   |  von Robert Bornemann


Fortsetzung des Artikels von Teil 1 .

Zu hoher Druck in den Teams

User Stories, die wesentlichen Bausteine bei der Formulierung neuer Kundenfunktionen, werden schnell zu verstreuten technischen Aufgaben, die dann in gewisser Weise von der Produktvision und den Geschäftszielen insgesamt losgelöst sind. Zum einen erschwert das die Entwicklung dieser Aufgaben, und zum anderen entsteht ein erheblicher Mehraufwand für alle Beteiligten, da die Arbeit über mehrere Komponententeams hinweg verstanden, verwaltet und koordiniert werden muss.

Dazu kommt die Tatsache, dass derartige Projekte oftmals ihren Erfolg an den unmittelbaren Ergebnissen (Output) statt an langfristigen Auswirkungen auf ihre Kunden messen, da die Geschäfts- und Produktziele innerhalb der Organisation nicht konsistent sind und aussagekräftige Daten möglicherweise fehlen.

Das Fazit: In einer derart funktionsspezifisch ausgerichteten Umgebung haben die Komponententeams weder die nötigen Werkzeuge und Ressourcen, die sie zum Erreichen dieser Art von Ziel brauchen, noch die Möglichkeit, den Erfolg der neuen Funktionalität am Kunden zu beurteilen. Dadurch entsteht wiederum erhöhter Druck: Ein Großteil der Verantwortung lastet auf dem Team, während die Entscheidungen rund um Ablieferung außerhalb des Teams getroffen und kritische Informationen nur unzureichend kommuniziert werden. Daher ist das Konzept des Komponententeams bei dieser Art von Arbeit nicht wirklich ideal – was es aber nicht zwangsläufig zu einem schlechten Konzept macht.

Analogie zur Malerei

Eine interessante Analogie des Agile- und Produkt-Design-Experten Jeff Patton macht deutlich, weshalb ein Komponententeam nicht ideal ist, wenn es um die kontinuierliche Auslieferung wertvoller Funktionen für den Kunden geht, bei denen die Markteinführungszeit ausschlaggebend ist: Der Prozess ist vergleichbar mit der Erstellung eines Gemäldes. Es handelt sich dabei um einen sehr individuellen Prozess, bei dem der Künstler das Bild stetig weiterentwickelt (Bild 4).

Ein schlanker Produktansatz weist Parallelen zur Malerei auf
© Jeff Patton

Bild 4: Ein schlanker Produktansatz weist Parallelen zur Malerei auf.

Ausgehend von der Skizze fährt er mit den Umrissen fort und fügt schließlich Farben und Schattierungen hinzu. Ein Team, das Fortschritte erzielen und wettbewerbsfähige kritische Produktfunktionen mit kurzer Markteinführungszeit entwickeln soll, benötigt ein ähnliches Maß an Autonomie und Experimentiermöglichkeiten wie ein Künstler beim Malen seines Gemäldes. Das ist der Kern der schlanken Produktentwicklung und die Komponententeams haben einfach nicht die nötigen Werkzeuge, um diese Art von Aufgabe optimal zu lösen. Vielmehr gestaltet sich die Situation wie inBild 5. Das Gemälde wird in sehr viele Einzelteile zerlegt, die unabhängig voneinander gemalt werden sollen.

Erstellung eines Gemäldes mit einem Komponententeam
© Jeff Patton

Bild 5: Erstellung eines Gemäldes mit einem Komponententeam.

Ein solcher Ansatz bedeutet nicht zwangsläufig, dass ein Team nach dem Wasserfallmodell arbeitet, aber die Umgebung weist starke Abhängigkeiten auf. Teams verlieren schnell die Verbindung zum Benutzer sowie ihre Flexibilität im Hinblick auf den Umfang. Sie verbringen unter Umständen viel Zeit damit, Prioritäten mit anderen Komponententeams auszuhandeln, Abhängigkeiten zu steuern, damit das Gesamtergebnis am Ende passt. In Wirklichkeit erfüllt dieses Gesamtergebnis jedoch, gerade wenn viele Teams beteiligt sind, nicht die Erwartungen des Kunden oder wird mit erheblicher Verspätung ausgeliefert, während die Marktchance schon längst verstrichen ist.

Ebenso können funktionsübergreifende Feature-Teams ein Nachteil sein, wenn die Geschäftsziele mit dem Teamkonzept kollidieren. Das liegt daran, dass sie bei der Entwicklung ihrer Produkte in der Regel sehr unterschiedlich abwägen. Ein passendes Beispiel ist der Darlehensanbieter Wonga. Dort versuchte man, die Wartbarkeit und die Integrität des Codes auf einem geschäftskritischen Niveau zu halten, das für eine in hohem Maße skalierbare Spitzeninfrastruktur notwendig war, und stellte fest, dass Feature-Teams nicht funktionierten.

Produktziel entscheidend für Teamaufstellung

Es gibt viele Beispiele wie dieses, bei denen Teams ständig Reibungspunkte erleben, wenn die zugrunde liegenden Teamstrukturen mit den Unternehmenszielen kollidieren. Funktioniert ein Team in seiner Zusammenstellung nicht, beeinträchtigt das die Lieferfähigkeit aller Teams. Weil es aber so viele Beispiele für schlecht funktionierende Komponententeams gibt, kann leicht der Eindruck entstehen, Feature-Teams seien das Allheilmittel.

Eine einfache Faustregel kann bei der Entscheidung für die passende Teamstruktur helfen: Das Teamkonzept sollte sich immer am konkreten Produktziel orientieren. Viele der Probleme, die wir aktuell in der IT-Landschaft beobachten, lassen sich darauf zurückführen, dass für eine Aufgabe ein falsches Teamkonzept gewählt wurde. Dieses ist jedoch maßgeblich für den Erfolg eines Produkts verantwortlich.

Warum werden Feature-Teams – selbst in Bereichen, die sich dafür gut eignen – nicht flächendeckender eingesetzt? Ein Grund ist, dass sie eine sehr ausgereifte Umgebung und Verwaltung benötigen. Bei Komponententeams erleben wir währenddessen viel häufiger, dass sie scheitern – was aber zu einem guten Teil daran liegt, dass dieses Teamkonzept selbst als auch die damit oft verbundenen Probleme wie etwa im obigen Beispiel einfach verbreiteter sind. Etablierte Unternehmen tun sich schwer, ihre Strukturen so zu verändern, dass funktionsübergreifende Teams unterstützt werden. Darum ist der Wechsel oft nicht möglich, auch wenn manche im Unternehmen diesen Wunsch durchaus haben.

Darüber hinaus ist die Erfolgskurve im Hinblick auf den nötigen kulturellen Wandel sehr steil – vor allem dann, wenn die Geschäftsleitung an traditionellen Projektrahmen festhält, die sich durch feste Budgets und Umfänge auszeichnen. Allerdings gibt es auch Erfolgsgeschichten, die zeigen, wie unterschiedliche Teamkonzepte beispielsweise erfolgreich nebeneinander bestehen und gleichzeitig optimale Ergebnisse bei der für sie geeigneten Art von Aufgabe erzielen können. Eine Investition in betriebliches Lernen, kulturellen Wandel sowie moderne Produktführung mit Blick auf kurz- und langfristige Ziele kann etablierten Unternehmen dabei helfen, genau die Umgebung zu schaffen, in der die Teams nach konkreten Produktzielen zusammengestellt werden und dadurch Software schneller und qualitativ hochwertiger bereitstellen können. Zu empfehlen ist also immer eine pragmatische und gründliche Evaluierung der Produktziele, um so erfolgreiche Teams zusammenzustellen.

Robert-Bornemann von ThoughtWorks
© ThoughtWorks

Robert-Bornemann von ThoughtWorks

Robert Bornemann

ist ein Experte für Produktmanagement mit Lean- und Agile-Methoden. Er unterstützt Unternehmen dabei, geschäftliche Herausforderungen zu lösen und arbeitet gerne in globalen Produktteams.

Seite 2 von 2

1. Teamwork: Aber richtig
2. Zu hoher Druck in den Teams

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren