Welche Rollen gehören in ein agiles Team?

Viele Unternehmen stellen sich bei einer agilen Einführung anfänglich die Frage, welche im medizintechnischen Umfeld vorhandenen Rollen gehören denn eigentlich in ein agiles Team?

Liest man nicht immer wieder, dass in einem Scrum-Team jeder alles können muss und dass es keine Spezialisten mehr geben darf?

Diese Interpretation ist natürlich völliger Unsinn und geht ganz klar an unseren Realitäten in der Medizintechnik vorbei. Wir müssen bei der Fragestellung zwei Aspekte unterscheiden: die fachliche, also medizinische Expertise und die technische, also die umsetzende Expertise. Natürlich würde unser Team auf einem idealen Planeten aus Mitgliedern bestehen, die auf allen Ebenen in der Lage sind, sowohl das Produkt, als auch die Technologien zu durchdringen.

In der Realität haben wir es jedoch beispielsweise mit einem Entwickler zu tun, der die perfekten Filteralgorithmen für Bio-Impedanzsignale in embedded Code gießen kann. Von diesem würden wir aber nie erwarten, dass er sich in der gleichen Qualität mit den Themen Usability für den Anwender oder Prozess-Qualitätsmanagement auseinander setzen kann. Ja, er sollte sich bis zu einem gewissen Grad auch damit auskennen und mit diesen Themen etwas vertraut sein. Und nein, er soll seine Expertise dennoch behalten können.

In einem agilen Team haben wir an die einzelnen Teammitglieder genau diesen Anspruch, sich über die jeweilige tief gehende Spezialisierung hinaus auch mit allen anderen Themen im Projekt etwas auszukennen. Wir sprechen hier vom sogenannten “T-shaped” Entwickler, der sich in der Breite mit vielen Bereichen grundlegend auskennt und in der Tiefe seine Spezialisierung hat.

Welche Rollen gehören nun alle in ein agiles Team?

Idealerweise befinden sich in einem Team alle Rollen, welche benötigt werden, um das zu entwickelnde Produkt an die Anwender ausliefern zu können. Wenn wir eine Wertstromanalyse für eine Produktentwicklung durchführen, dann würden wir also aus jedem der dort identifizierten Bereiche mindestens eine Person in ein agiles Team stecken, damit diese dort gemeinsam dafür sorgen können, dass das richtige Produkt in der richtigen Qualität gebaut und geliefert wird.

In einem überschaubaren Umfeld kann sich dies beispielsweise in einem Team mit folgenden Rollen manifestieren: zwei Tester, drei Software-Entwickler, ein QM-Beauftragter, ein Usability-Experte und zusätzlich ein Product Owner, sowie ein ScrumMaster.

Aber auch hier müssen wir die Realitäten in den Unternehmen betrachten. Der konsequente Ansatz würde in vielen Fällen bedeuten, mehrere Dutzend oder gar Hunderte von Personen in ein Team zu stecken. Wir wissen jedoch genau, dass Teams ab einer Größe von mehr als 7 Mitgliedern signifikant an Geschwindigkeit und Schlagkraft verlieren. Damit sind wir dann in der Fragestellung der agilen Skalierung. Die Antwort darauf spare ich mir hier, sie ist eine eigene Diskussion an anderer Stelle wert.

Bleiben wir noch kurz im überschaubaren Umfeld mit einem oder wenigen Teams. Es gibt keine allgemeingültige Antwort auf die Frage, ob beispielsweise ein QM-Beauftragter in ein agiles Team gehört. Es kann die richtige Maßnahme sein, wenn die restlichen Teammitglieder keinerlei Wissen und Erfahrung darin haben, eine richtige Risikoanalyse durchzuführen. Es kann je nach Projektumfeld auch die richtige Maßnahme sein, das Thema QM als Team-externe Dienstleistung zu betrachten, auf die das Team jeweils im Bedarfsfall zugreifen kann. Die gleichen Fragestellungen müssen für jeden Teamkontext neu beantwortet werden, z.B. für die Themen klinische Validierung, Vertrieb, Marketing, Marktanalyse, Datenbank-Administration und viele mehr.

Die Kernfrage hierbei lautet: wie viele Beteiligte aus der Kette vor und nach der reinen Entwicklung können sinnvoll in einem agilen Team integriert werden?

Die ideale Antwort darauf lautet: so viele wie möglich.