Was ist eigentlich ein crossfunktionales Team?

Muss bei Scrum jeder alles können? Worum es bei crossfunktionalen Teams wirklich geht.

Written by Patrick Schönfeld · 3 min read >
Teams beim Seitenwagenrennen

Da das Thema immer mal wieder aufkommt und regelmäßig zu Verwirrung führt („Muss bei Scrum wirklich jeder alles können?“) wollte ich das Thema cross-funktionales Team mal aufgreifen: was das ist und was es nicht ist.

Zunächst mal zu der Frage, ob in Scrum denn jeder alles können muss: nein, auch in Scrum muss nicht jeder alles können.

Cross-funktional oder nicht – wie stelle ich mein Team zusammen?

Eigentlich geht es bei crossfunktionalen Teams in erster Linie um die Zusammensetzung des Teams – statt einer Teamzusammenstellung nach Fachrichtung wie in Spezialistenteams soll es sich interdisziplinär (also aus Mitgliedern verschiedener Fachrichtungen) zusammensetzen.

Der Scrum-Guide ist da eigentlich sogar ziemlich eindeutig. Dort heißt es, dass die Leute als Team alle Fähigkeiten haben sollen, um ein funktionsfähiges Produktinkrement (also etwa eine lauffähige Version einer Software) zu erstellen. Statt also Menschen zusammen zu bringen, die dieselben Fähigkeiten aufbringen, liegt der Fokus auf dem gemeinsamen Ziel.

Warum das Team cross-funktional sein soll, wird im Scrum-Guide übrigens auch beleuchtet: es geht darum, dass das Team (möglichst) ohne externe Abhängigkeiten in der Lage sein soll, ein voll funktionsfähiges Produktinkrement – oder allgemeiner gesprochen: das Sprint-Ziel – zu erreichen.

Die Vorteile cross-funktionaler Teams

In der Praxis lässt sich das vielleicht am besten an der Softwareentwicklung verdeutlichen.

Um beispielsweise ein Webportal zu bauen, in dem Bestellungen von den Benutzern erfasst werden können, wird man mindestens mal Folgendes brauchen: Entwickler, die den Code schreiben; jemand mit genügend Wissen über Datenbanksysteme, der sich über die Datenspeicherung Gedanken macht und sicherlich auch eine Person, die etwas von Benutzerführung (UX oder User Experience) oder von Design versteht – denn optisch ansprechend und benutzbar soll es ja letztlich auch sein.

Ein cross-funktionales Team könnte sich dementsprechend aus einem Entwickler, einem Datenbankler, einem UX-Spezialisten und einem Designer zusammensetzen, die von Anfang an gemeinsam am jeweiligen Produkt oder Projekt arbeiten. Ein Vorteil dabei ist, dass die Koordination der Arbeiten und deren Abhängigkeiten einfacher wird, weil die jeweiligen Experten auf dasselbe Ziel hinarbeiten und von Anfang an bei der Planung und Entscheidungsfindung beteiligt sind.

Im Gegensatz dazu hätten wir bei einer funktionalen Teamzusammenstellung vielleicht ein Datenbank-Team, eine Entwicklungsabteilung und ein Team von Designern, die in ihren Fachbereich fallende Aufgaben erledigen und ihre Ergebnisse zu einem bestimmten Zeitpunkt an ein anderes Team abgeben. Die ohnehin schon nicht einfache Koordination von Abhängigkeiten (Aufgabe A muss erledigt werden, bevor Aufgabe B starten kann) wird dabei zusätzlich erschwert – denn in der Regel arbeiten funktionale Teams nicht ausschließlich an einem Projekt, sodass sich Verzögerungen bei einem Projekt auch auf andere Projekte auswirken können.

Die Schwierigkeit solche Abhängigkeiten zu managen, kennen wir auch aus anderen Bereichen des Lebens: wer in seinem Leben mal ein Haus gebaut hat oder hat bauen lassen, wird ein Lied davon singen können: was ist beispielsweise, wenn sich die Maurerarbeiten verzögern, die Gerüstbauerin aber schon den nächsten Auftrag in der Pipeline hat? Ob die Fassadenarbeiten dann wohl ohne Verzögerung starten können?

Woher aber kommt der Glaube, dass jeder alles können muss?

Nun – auch das beste Konzept muss sich der Realität stellen.

So muss man sich beispielsweise auch in cross-funktionalen Teams mit einigen schwer beeinflussbaren Faktoren rumschlagen: die Menschen im Team können mal krank werden, wollen Urlaub nehmen oder in Elternzeit gehen – und natürlich wird es für die ein oder andere Fachrichtung mal mehr und mal weniger zutun geben. Zudem kann es natürlich auch ganz schön „tricky“ sein, die Meinungen der verschiedenen Experten unter einen Hut zu bringen. 😉

Wenn die Mitglieder des Teams auch über Kenntnisse in anderen Bereichen als in ihrer Fachrichtung verfügen, kann das deshalb tatsächlich von Vorteil sein.

Der Anspruch hierbei ist aber nicht „alles zu können“ sondern neben einer Spezialisierung über eine gesunde Portion Breitenwissen zu verfügen. Man spricht in diesem Zusammenhang auch von einer T-Shaped Person oder einem „generalisierten Spezialisten“.

Unabhängig davon erfordert nicht jede Arbeit auch jemanden, der oder die genau auf dieses Thema spezialisiert ist: in vielen Fällen verstehen beispielsweise die Entwickler genügend von Datenbanken, um das eigentliche Ziel – ein funktionsfähiges Produktinkrement – zu erreichen.

Nicht alle Herausforderungen lassen sich auf der Teamebene lösen

Last but not least bleibt noch zu sagen, dass man sich auch von der Vorstellung verabschieden sollte, dass man alle Probleme auf der Teamebene lösen kann.

Das fängt schon bei der Fragestellung an, welche Funktionen denn eigentlich tatsächlich im Team vertreten sein müssen (macht es beispielsweise Sinn, dass ein Produktteam seinen eigenen Buchhalter oder Einkäufer hat?) und führt zu der Feststellung, dass es manchmal eben doch sinnvoll ist, bestimmte Aufgaben an andere Teams auszulagern. Nur eben nicht für die direkte Arbeit am Produkt sondern indem sie Dienstleistungen für das Team erbringen: die Entwicklung von Werkzeugen für die Teammitglieder etwa oder auch die Bereitstellung von Infrastruktur. Dabei sollte beachtet werden, dass keine unnötigen Abhängigkeiten von menschlicher Arbeitskraft entstehen: Automatisierung und Self-Service-Systeme sind hier das Stichwort.

Letztlich ist immer die Frage, wo genau man die Grenze zieht und natürlich werden in vielen Fällen solche Berührungspunkte mit anderen Teams auch schon bestehen. Deshalb macht es Sinn, sich im Sinne des Systemthinking-Ansatz immer Unternehmen als Ganzes anzusehen und zu optimieren.

Aber das ist ein ganz eigenes Thema. 😉

Im Artikel Welche Skills braucht ein crossfunktionales Team? gehe ich etwas näher auf die Teamzusammenstellung ein und darauf wie man mit kurzfristigem Bedarf an bestimmten Skills umgeht.

Weiterführende Informationen

  • Ich kann etwas, was du nicht kannst: Die Arbeit in cross-funktionalen Teams ist natürlich auch mit gewissen Herausforderungen verbunden. Diesen widmet sich ein Artikel auf wissensdialoge.de.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen