Welche Skills braucht ein crossfunktionales Team?

In einem früheren Artikel habe ich erläutert, was es mit crossfunktionalen Teams auf sich hat. Aber wie geht man eigentlich damit um, wenn man einen temporären Bedarf für bestimmte Skills hat? Und ganz generell gefragt: woran mach ich denn fest, welche Skills ein Team dauerhaft braucht?

Was ist, wenn das Team kurzfristig Bedarf für einen professionellen Texter hat?

Ein Scrum Master steht vor folgendem Szenario: Das Team muss einen neuen Prozess umsetzen und benötigt dafür gute Texte. Im Unternehmen ist man überzeugt, dass die Texte dazu beitragen können, Kunden zu gewinnen oder gar zu verlieren. Die Texte sollten also eine aus Marketingsicht hohe Qualität aufweisen. Der Scrum Master steht vor einem Dilemma. Das Development-Team ist crossfunktional, aber einen Werbetexter hat es nicht.

„Wer soll nun die Texte schreiben?“, fragt er sich.

Der Scrum-Guide sagt, dass im Team alle Skills vorhanden sein müssen, um Anforderungen in ein Produktinkrement umzusetzen. Das ist der Dreh- und Angelpunkt, wieso sich der Scrum Master vor diesem Dilemma sieht. Aber geht es bei dem, was im Scrum-Guide steht wirklich um Ausnahmesituationen?

Nein, geht es nicht.

Abhängigkeiten sind ungünstig aber nicht immer vermeidbar

Hinter der Idee, ein Team crossfunktional aufzustellen, steht eine praktische Erfahrung.

Wenn ein Team bei Aufgaben auf andere Teams angewiesen ist, kann sich das auf die Lieferfähigkeit des Teams auswirken:

• Zusätzliche Arbeit: die Anforderung muss dem unterstützenden Team erläutert werden, und zwar in einer Art und Weise die keine oder wenig Rückfragen erforderlich macht. Denn diese würden den „Handover“ zusätzlich erschweren oder mehrere Feedbackschleifen nötig machen.
• Erschwerte Planung: Das unterstützende Team wird im Regelfall mehrere andere Teams zu bedienen haben. Demnach ist es schwierig bis unmöglich, dass sich das andere Team auf einen Termin festlegt, der auch im Einklang mit dem Sprint-Zyklus unseres Scrum-Teams steht.

Zwar gelten die benannten Nachteile auch für solche Ausnahmefälle. Dennoch: wenn sich Abhängigkeiten im Einzelfall nicht vermeiden lassen, ist das eben so.

Ein Team dauerhaft mit Skills auszustatten, ergibt aber nur dann Sinn, wenn es diese regelmäßig braucht. Auch in Scrum ist es legitim und sogar gewünscht, sich auf die Umstände einstellen. Fundamental in Scrum ist immerhin der Gedanke, von Erkenntnissen geleitet zu handeln.

Welcher Mechanismus steht hinter den Problemen?

Woran aber sollte ich mich in der Regel bei der Aufstellung des Teams orientieren? Dafür hilft es den Mechanismus zu verstehen, der in die oben genannten Nachteile mündet.

Die Nachteile entstehen in der Regel durch eine Kombination aus zwei Faktoren:

• Ein Zielkonflikt: die beiden Teams haben eigene Ziele.
• Der Abhängigkeit von menschlicher Arbeitskraft: das Team muss etwas tun oder entscheiden, damit das andere Team sein Ziel erreichen kann.

Für die Zusammenstellung einzelner Teams lohnt folglich zunächst mal ein Blick auf die Ziele des Teams: Welche Ergebnisse soll das Team regelmäßig erzielen?

Daraus ergeben sich Aufgaben, die erfüllt werden müssen und dafür benötigte Skills. Wenn mein Team beispielsweise Software entwickelt aber nicht betreibt, werde ich zum Beispiel Entwickler und Leute für das Requirements Engineering brauchen. Je nach konkreter Zielstellung kann sich dabei auch der Bedarf nach weiteren Rollen wie UX-Designern und Datenbankspezialisten ergeben. Wenn mein Team die Software auch im Produktivbetrieb betreuen soll – was ja im Zuge der DevOps-Bewegung immer häufiger der Fall ist – brauche ich wohl auch Kenntnisse über den Produktivbetrieb von Software.

Mit Kenntnis über Ziele, Aufgaben und benötigte Skills kann ich dann den Bedarf mit der Realität im Unternehmen und praktischen Erwägungen abgleichen.

Aus Sicht der Zielerfüllung wäre es ideal, wenn alle benötigten Skills immer Teil des Teams sind. Taktisch gesehen müsste man dabei auch Urlaube und Krankheiten berücksichtigen. Damit stößt man allerdings schnell an praktische Grenzen, die sich auf der Team-Ebene nicht mehr sinnvoll überwinden lassen.

So will ich ja eigentlich eine gewisse Redundanz haben, um flexibel auf unerwartete Anforderungen reagieren zu können. Auf der anderen Seite kann ich mir übermäßige Redundanz schon aus wirtschaftlichen Gründen nicht erlauben. So wäre es beispielsweise Unsinn in jedem Team gleich zwei UX-Designer zu haben, wenn deren Arbeitskraft für die Zielerfüllung nur in geringem Umfang benötigt wird. Auch würde das Team schnell eine Größe erreichen, bei der die Effektivität durch den Koordinationsaufwand innerhalb des Teams abnimmt.

Sollte man die Skills aus dem Team auslagern?

Es wird schnell klar, dass sich nicht alle Probleme auf der Ebene der Team-Ebene lösen lassen. Die folgenden Fragen geben eine Hilfestellung, um das Dilemma aufzulösen:

• Handelt es sich um einen Skill, der von mehreren Teams benötigt wird?
• Kann ich die Anforderung des Skills auch externalisieren, ohne mir die oben benannten Nachteile einzuhandeln?

Ein klassischer Ansatz wäre, die verbundenen Aufgaben in ein eigenes Team auszulagern. So könnte man beispielsweise ein UX-Team gründen, das dann einzelne Aufgaben für die anderen Teams übernimmt.

Der Ansatz funktioniert, verlangsamt das Unternehmen aber insgesamt. Denn damit verschärft sich das Problem mit der Abhängigkeit von menschlicher Arbeitskraft (die Leute im UX-Team haben mehr Projekte gleichzeitig und damit Kontextwechsel, die einen Produktivitätsverlust zur Folge haben) und das UX-Team hat jetzt mehrere, unterschiedliche Ziele unter einen Hut zu bringen.

Lösungsansätze

Besser wäre eine Lösung, die es den beiden Teams erlaubt zeitlich entkoppelt zu arbeiten oder bei denen die Nachteile wenigstens abgeschwächt werden. Dafür hilft es, das Team mit den spezialisierten Skills so aufzustellen, dass es Hilfe zur Selbsthilfe leistet.

Dafür gibt es beispielsweise die folgenden Möglichkeiten:

1. Ein Consulting-Modell für das unterstützende Team: die Leute aus dem UX-Team werden als Berater in die Teams geschickt. Dabei sollen sie aber nicht eigenständig Aufgaben im Sprint übernehmen, sondern das Team durch beispielsweise Trainings und Workshops befähigen. Das Ziel besteht also in einem Wissensübertrag, der im Idealfall darin mündet, dass die Leute im Team viele Aufgaben selbst übernehmen können.
2. Ein Guidance-Modell als Erweiterung des Consulting-Modells: auf der Ebene des UX-Teams könnte das UX-Team Leitfäden verfassen, die man allen Teams im Unternehmen an die Hand geben kann.
3. Phasen-basierte Mitarbeit: in manchen Fällen reicht Beratung und „Aufschlauung“ allein nicht. Wenn sich bestimmte Phasen im Produktzyklus feststellen lassen, wo bestimmte Skills benötigt werden, könnten Leute mit entsprechenden Skills auch temporär in die Teams geholt werden.
4. Ein Self-Service-Modell: das Support-Team könnte auch selbst zum Produkt-Team werden und eigenständig Werkzeuge oder Dienste bauen, mit denen sich die Teams auch ohne Erwerb neuer Fähigkeiten selbst helfen können. Beispielsweise könnte ein Plattform-Team Self-Service-Facilities für die Bereitstellung von Infrastruktur zur Verfügung stellen. Oder ein Team könnte Tools entwickeln, um Security-Compliance automatisiert zu prüfen.

In der Praxis wird man wohl eine Kombination aus diesen Modellen benötigen.

Das Guidance-Modell ist zum Beispiel sehr viel nützlicher, wenn die Leute im regelmäßigen Austausch mit den Produkt-Teams stehen und sogar hin und wieder direkt mitarbeiten. So können beide Seiten voneinander lernen. Außerdem fällt es leichter ein Verständnis für die alltäglichen Sorgen und Nöte der Anderen zu entwickeln.

Die Datenschutzabteilungen in vielen Unternehmen zeigen, dass sonst manchmal eher Frankenstein-artige Konstrukte entstehen. Beispielsweise werden verpflichtende Richtlinien erlassen, die an der Realität der Teams vorbeigehen und damit nicht umsetzbar sind. Oder eben Richtlinien, die einfach näher erläutert werden müssten, damit sie auf Verständnis stoßen und auch praktisch angewendet werden.

Leider gestaltet sich auch das Self-Service- oder Produkt-Modell in der Praxis leider schwieriger als gedacht. So könnten beispielsweise Modelle entstehen, in denen das Development-Team selbst zum Flaschenhals für die Agilität der Support-Abteilung wird.

Zielkonflikte tun sich etwa auf, wenn ein Team die Entwicklung und Betrieb einer Business-nahen Software verantwortet und ein Plattform-Team darunter verwendete Services verwaltet. Denn die Betreuung der Services ist manchmal mit Aufgaben verbunden, die für das Plattform-Team nötig sind (zum Beispiel Software-Upgrades mit dem Ziel die verschiedenen betreuten Versionen zu harmonisieren), aber Anpassungen an der vom Development-Team verwalteten Software erfordern. Diese nicht vom Business getriebenen Anforderungen sind in der Regel schwer zu vermitteln und ziehen bei der Priorisierung dann den Kürzeren.

Die Ironie dabei ist, dass den Development-Teams häufig vorgeworfen wird, sie wollen immer nur neue Features entwickeln. Dabei befeuert die KPI-getriebene Unternehmenssteuerung Probleme wie das zuvor Beschriebene. Security-Updates wirken sich zum Beispiel genau gar nicht auf die Kundenzufriedenheit oder den Umsatz aus – bis die Kreditkartendaten der Kunden in die Hände von Hackern fallen.

Zusammenfassend geht es also nicht allein um die Zusammenstellung der Teams als einzelne Einheit, sondern um die Schnittstellen dazwischen, praktische Erwägungen und die Ziele des Unternehmens insgesamt. Bei der Lösung kommen auch Zielsystemen eine gewisse Bedeutung zu. Denn (in begrenztem Umfang) lassen sich die unterschiedlichen Ziele der Teams auch ausmitteln.

Generell hilft es, das kollektive Wissen im Unternehmen anzuzapfen – und sich bei der Lösungssuche immer wieder an die beschriebenen Mechanismen zu erinnern.