Mitarbeiterführung Teamwork: Aber richtig

Produktmanagement in den Unternehmen wird zunehmend wichtiger um die Software- und Produktentwicklungs-Teams variabel auszurichten.
Produktmanagement in den Unternehmen wird zunehmend wichtiger um die Software- und Produktentwicklungs-Teams variabel auszurichten.

Die Rolle der IT im Unternehmen wandelt sich rapide: vom Anbieter standardisierter Lösungen zum Herzstück moderner Unternehmensführung. Auf dem Weg dahin kämpfen einige etablierte Unternehmen noch damit, ihre Software- und Produktentwicklungsteams auf die Aufgabenschwerpunkte variabel auszurichten.

Es gibt keine allgemeingültige Variante, Teams erfolgreich aufzubauen – Unternehmensstruktur und -strategie spielen eine entscheidende Rolle. Angesichts der Vorteile eines guten Teamkonzepts sollte jedes Unternehmen sich zum Ziel setzen, die für sich richtige Variante zu finden. Die passende Arbeitsumgebung stellt sicher, dass die Praxis der Softwarebereitstellung mit dem sich schnell verändernden Markt Schritt hält.

Feature-Teams: Nicht immer die beste Wahl

Die meisten IT-Unternehmen stellen ihre Teams entweder funktionsspezifisch zusammen, also entsprechend einer bestimmten Spezialisierung, oder funktionsübergreifend, also beispielsweise nach Produkt-Features. Viele sind offenbar der Ansicht, dass sich funktionsspezifisch ausgerichtete Teams in Softwareunternehmen nur mit bestimmten Komponenten eines Softwareprodukts beschäftigen. Diese Teams werden oft als Komponenten- teams bezeichnet. Funktionsspezifische Teams sind für einen bestimmten Teil einer mehrstufigen Architektur zuständig. Das heißt, sie erstellen horizontale Schichten (Bild 1).

Die Frontend-Teams geben also eine Frontend-Funktion frei, die Backend-Serviceteams eine Backend-Funktion, die Data-Tier-Komponententeams ihre jeweilige Funktion. Komponententeams sind eine bestimmte Art funktionsspezifischer Teams innerhalb einer mehrstufigen Architektur. Erst durch die Bereitstellung und Integration der Release-Schichten dieser Teams entsteht sinnvolle Funktionalität beziehungsweise eine für den Kunden wertvolle Lösung (Bild 2).

In der IT-Landschaft sind verschiedene Varianten dieser Teams zu finden. Zu den bekannteren Beispielen gehören die autonomen, unabhängigen Teams beim britischen Geldtransfer-Service TransferWise oder die autonomen »Squads« bei Spotify. Sie alle haben gemeinsam, dass sie vertikale Release-Teile produzieren. Neue Funktionen werden also durch alle nötigen Architekturschichten des Produkts hindurch freigegeben.
Diese Teams erzielen oft Geschäftswachs- tum rund um Alleinstellungsmerkmale und agieren sehr schnell. Das liegt daran, dass sich Feature-Teams schnell Wissen über ihre Kunden und/oder Partner an- eignen können, was ihnen einen strategischen Vorteil verschafft. Sie können für den Kunden wertvolle Lösungen besonders schnell liefern, weil sie Annahmen bezüglich neuer Produktfeatures häufig in einer echten Umgebung testen und sich anhand dieser Erkenntnisse wieder neu aufstellen.

In der Regel sind diese Teams auf eine besondere Funktion oder Disziplin spezialisiert, wie interne Skalierung, Optimierung oder Dinge, die spezielle Fachkenntnisse erfordern – und das alles bei möglichst geringen Kosten. Mit diesem Schwerpunkt fällt es einem Komponententeam meist schwer, neue Möglichkeiten der Wertschöpfung zu identifizieren.

Funktionsübergreifende Teams – auch Feature-Teams genannt – sind dagegen über alle Architekturschichten hinweg für einen bestimmten Teil einer, meist neuen, Funktion zuständig. Sie verfügen über die nötigen Ressourcen, um diese Funktion selbstständig zu liefern (Bild 3).

 

Arbeiten wie ein Wasserfall

Sollen also nun nur noch Feature-Teams eingesetzt werden? Es kommt darauf an. Das Problem ist, dass heutzutage hinsichtlich des Team-Designs oft eine Art Hierarchie vorzufinden ist, die sich in der Praxis nicht bestätigt. Feature-Teams werden als das Nonplusultra der agilen oder schlanken Produktentwicklung hervorgehoben, während Komponententeams als Verlierer abgestempelt werden, die nach dem Wasserfallmodell arbeiten.

Das eigentliche Problem vieler etablierter Unternehmen ist jedoch nicht die Entscheidung für Komponententeams, sondern die Wahl einer Teamstruktur, die nicht zu den jeweiligen Aufgaben passt. Die Produktziele genau zu kennen, ist der zuverlässige Leitfaden, wenn es darum geht, Teammitglieder funktionsspezifisch (nach Komponente) oder funktionsübergreifend (nach Feature) zusammenzustellen.

Jedes Team arbeitet unterschiedlich

Ein typisches Beispiel: Die IT-Abteilung eines Unternehmens ist in viele verschiedene Komponententeams organisiert, die sich mit spezifischen Services beschäftigen. Jedes dieser Teams hat einen eigenen Backlog sowie eine eigene Roadmap und gehört zu einem Cluster aus anderen Teams, die an verschiedenen Projekten mit unterschiedlichen Finanzierungsquellen und unter jeweils anderer Führung beteiligt sind.

Angenommen, all diese Teams würden gemeinsam versuchen, die Innovationsbemühungen des Unternehmens umzusetzen, um damit zur Sicherung der eigenen Wettbewerbsfähigkeit beizutragen. Um das zu erreichen, müssen sie gemeinsam neue Funktionen bereitstellen, die ihre Kunden wertschätzen. Genau darin liegt eine der häufigsten Gefahren: Komponententeams zur Umsetzung zeitkritischer Produktinnovation mit schneller Markteinführung.

Zu den größten Herausforderungen in einem solchen Szenario gehört die Übersetzung »echter« Kundenanforderungen in die Backlogs der Komponententeams, die oftmals auch bereits andere konkurrierende Prioritäten enthalten.