„Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.“ (Scrum Guide).

Historischer Rückblick

In diesem Blog-Beitrag geht es um interdisziplinäre – oder auch näher am englischen Original cross-funktionale – Teams. Bereits vor Scrum  hatten sich herausgestellt, dass diese Teams besonders erfolgreich sind bei der Entwicklung von innovativen Produkten (The New New Product Development Game (hbr.org)). Mit Scrum sind sie dann so richtig populär geworden. Als Scrum in den 1990ern entstand, waren Entwicklungsabteilungen in Form von funktionalen Teams organisiert: es gab Kästchen im Organigramm für die Entwickler:innen (damals noch nicht gegendert ) und die Tester:innen, oft noch aufgeteilt in Integrations- und Systemtest. Ich erinnere mich an meine Zeit in einem großen Konzern damals, als es gerade Mode wurde, Testabteilungen in Indien aufzubauen, um Kosten zu sparen. Weiterhin gab es Spezialfunktionen wie Systemarchitekt:innen (von bösen Zungen als „Elfenbeinturm-Architekten“ bezeichnet), Risk Manager, Integrationsmanager, Requirement Engineers… alle in ihren eigenen Abteilungen, und damit Diener ihrer jeweiligen Herren, den Abteilungsfürsten. Andere Teile des Unternehmens, die nicht direkt zur Entwicklung gehörten, wie z.B. Produktmanagement und Marketing, waren außen vor. Ein cross-funktionales Team dagegen vereinigte die Menschen, die mit ihren unterschiedlichen Expertisen zur Entstehung eines Produktes beitragen sollten, und schwor sie auf ein gemeinsames Ziel ein. Was für ein Fortschritt!

Die Vorteile liegen auf der Hand:

• Für das Team lässt sich leicht ein gemeinsames Ziel formulieren: ein Produkt mit Wert für Kunden zu erzeugen. Entwickler:innen, Tester:innen und die anderen Funktionen ziehen an einem Strang und arbeiten eng zusammen. Das steigert die Identifikation mit dem Team, die Motivation und damit auch die Leistungsbereitschaft.
• Mit ihren unterschiedlichen Skills und Sichtweisen findet das Team innovative Lösungen für komplexe Probleme.
• Übergabeformalitäten, zum Beispiel in Form von Meilensteinen wie „Ready for System Test“, können eingespart werden. So ist der Weg geebnet für ein iterativ-inkrementelles Vorgehen anstelle eines Wasserfallprozesses. Das Team ist in der Lage, schnell und agil zu agieren und seinen eigenen Prozess ständig weiterzuentwickeln.
• Um das gemeinsame Ziel zu erreichen, werden starre Rollenbeschreibungen aufgelöst. Jedes Teammitglied trägt Verantwortung zur Erreichung des Ziels. Statt der Elfenbeinturm-Architekt:innen gibt es nun Team-Mitglieder, die sich besonders gut mit Architektur von Systemen auskannten, aber auch andere Tätigkeiten übernehmen können. Team-Mitglieder lernen voneinander und entwickeln sich weiter. Das Know-How wird verbreitert, nicht nur vertieft.
• Durch die Unterschiedlichkeiten im Team entstehen Herausforderungen wie Umgang mit Konflikten und gemeinsame Entscheidungsfindung. Was auf den ersten Blick als Nachteil erscheint, ist tatsächlich ein Vorteil, wenn das Team lernt, derartige Herausforderungen gemeinsam bewältigen.

All das waren wichtige Verbesserungsschritte – die oft nur gegen den Widerstand der Abteilungsfürsten durchzusetzen waren. Allerdings waren nicht alle Probleme damit gelöst. Es existierten weiterhin Abhängigkeiten zwischen cross-funktionalen Teams, die gemeinsam an einem Produkt arbeiteten. Der Grund: Die Zuständigkeit der Teams beschränkte sich auf einzelne Komponenten des Produkts. Damit die Anteile der einzelnen Komponenten zusammenpassen, ist ein Planungsschritt notwendig, der diese Anteile identifiziert. Zur Erzeugung des Produktes müssen die Beiträge der Komponenten zusammengebaut werden. Es gibt also Analyse, Entwicklung, Integration und Test mit den entsprechenden Verantwortlichkeiten – ist das wirklich der große Fortschritt im Vergleich zum klassischen Wasserfallprozess?

Feature Teams – ein weiterer Schritt zur Business Agility

Feature Teams sind cross-funktionale Teams, die end-to-end Verantwortung für komplette kunden-orientierte Features übernehmen und so eigenständig Wert für Kunden erzeugen können. Hört sich gut an (s. Feature Teams – Large Scale Scrum (LeSS)) – in der Realität ist es ein sehr anspruchsvolles Unterfangen, Feature Teams aufzustellen. Als Voraussetzung sind hervorragende technische Fähigkeiten nötig wie kontinuierlicher Integration, Test und Auslieferung, die leider in vielen Organisationen nicht vorhanden sind. Der Schritt von Komponenten- zu Feature Teams erfordert eine Umorganisation mit vielen Reibungsverlusten. Ich habe als Coach erlebt, dass Organisationen mehrere Versuche und Experimente gebraucht haben, bevor sie genügend Erfahrung beisammen hatten, sich als Feature Teams aufzustellen (s. z.B. German Big Insurance – Large Scale Scrum (LeSS)). Und selbst wenn dies in der Software-/Produktentwicklung gelingt, besteht ein end-to-end-Prozess aus weiteren Aktivitäten, angefangen mit dem Portfolio-Management über Budgetfreigabe bis zum Marketing, die man in großen Organisationen nicht auch noch in den Feature Teams unterbringt.

Also: cross-funktionale, end-to-end Teams sind ein wichtiger Baustein für agile Unternehmen. Um wirkliche Business Agility zu erreichen und damit in der Lage zu sein, als gesamte Organisation schnell zu reagieren und zu liefern, braucht es eine Sicht auf die Abhängigkeiten und Interaktionen zwischen den Teams und die dort entstehenden Wartezeiten. Mit einem Blick auf das gesamte System und seine Wertschöpfungsketten sollte man zunächst herausfinden, wo es kritische Abhängigkeiten gibt und wirklich hakt, um dann an diesen Stellen gezielte Verbesserungen vornehmen zu können.

Einsatzmöglichkeiten für cross-funktionale Teams

Agilität ist als Denkansatz längst über die Software- bzw. Produktentwicklung hinausgewachsen – und damit auch die cross-funktionalen Teams. Ich habe solche Teams in allen möglichen Bereichen unterstützen dürfen: von einem Team, das ein IT-Sicherheitskonzept zum Schutz gegen Hackerangriffe entwickeln sollte, bis hin zu einem Team, das Governance-Richtlinien zur Sicherstellung von Nachhaltigkeitsaspekten erstellen sollte. Mitglieder in diesen Teams waren Personen aus der Unternehmenskommunikation und der Organisationsentwicklung, Jurist:innen, Change Manager, Vertreter:innen aus den einzelnen Regionen… mit den nötigen Entscheidungsbefugnissen und Entlastung von operativen Tätigkeiten ausgestattet, können solche Teams sehr effektiv arbeiten. 

Inter- und extra-dependent Teams

Sind die cross-funktionalen Teams – zumindest als Grundbaustein – also ein Allheilmittel, wenn es um die effektive Lösung von komplexen Problemen geht?

Denken wir zurück an die so oft geschmähten „Silos“ (dieser Begriff wird heute von den meisten Agilisten mit einem unverkennbar abwertenden Gesichtsausdruck verwendet). Die Leistung der „Silos“ besteht in der Weiterentwicklung einer bestimmten Expertise, die allen Mitgliedern des „Silos“ gemeinsam war. Also zum Beispiel Test-Kompetenz. Damit sorgte das „Silo“ dafür, dass Fachwissen in einer Organisation entsteht und erhalten bleibt. Die Motivation dahinter ist die Erhöhung von Qualität und Effizienz – was in der agilen Welt heute als ewig gestrige Denkweise und kontraproduktiv bei der Lösung komplexer Probleme verschrien ist. Erfolgreiche Organisationen brauchen aber beides: agiles Vorgehen bei der Nutzung von neuen Chancen UND effizientes Vorgehen bei etablierten Prozessen mit wenig Unsicherheit. Durch die gemeinsame Expertise schaffen die „Silos“ ein Zusammengehörigkeitsgefühl, das langfristiger sein kann als die Entwicklung eines Produktes. Wo bleibt dieser Aspekt bei den cross-funktionalen Teams? Na klar, dafür gibt es die „Communities of Practise (CoP)“ – ein team-übergreifender Zusammenschluss von Personen einer bestimmten Fachrichtung wie Test oder Architektur. Im Gegensatz zu den „Silos“ aber eher informell und damit im Zweifelsfall weniger wichtig als die Arbeit im „eigentlichen“, cross-funktionalen Produktteam.

Dieser Zusammenhang ist mir deutlich geworden bei der Lektüre von „Extra-Dependent Teams“ (David Kesby). David argumentiert, dass die gängige Team-Lehre zwischen „richtigen“ Teams und „work groups“ unterscheidet. Die Team-Lehre suggeriert, dass jede Gruppe sich am besten zu einem „richtigen“ Team entwickeln sollte, weil sie nur dadurch „high performing“ werden kann. Dazu sind – so lehrt uns die Lehre – bestimmte Attribute notwendig, wie ein gemeinsames Ziel, gemeinsame Verantwortung und Interdisziplinarität. Dabei wird verkannt, dass die „work group“ ein hervorragendes Modell zum Beispiel für CoPs ist. Um zu vermeiden, dass „work groups“ als bloßes Übergangsstadium zum „richtigen“ Team und damit als minderwertig betrachtet werden, nennt David sie „extra-dependent“ Teams – im Gegensatz zu den „inter-dependent Teams“, unseren Produktteams. Die Mitglieder der extra-dependent Teams arbeiten nicht ständig zusammen, sondern hauptamtlich als Mitglieder von inter-dependent Teams. Sie erfüllen aber eine wichtige Aufgabe, indem sie gemeinsam lernen, strategisch wichtiges Wissen erzeugen und gute Praktiken, Richtlinien, Tools… für die Organisation bereitstellen. Im Gegensatz zu CoPs, die eher informell sind, sind diese extra-dependent Teams in der Regel eine Organisationseinheit mit einer gemeinsamen Führungskraft.

Ein anschauliches Beispiel für ein extra-dependent Team ist die Schwangerschaftsgruppe zur Geburtsvorbereitung. Das inter-dependent Team ist die einzelne Familie. Die Familie hat damit ein gemeinsames Ziel: ein gesundes Baby auf die Welt zu bringen. Die Geburtsvorbereitungsgruppe hat kein gemeinsames, sondern ein identisches Ziel. Übertragen auf die agile Welt sind dies Einheiten, „Silos“, von Tester:innen, Designer:innen, Produkt-Manager:innen, Scrum Master:innen…

Ein weiteres Beispiel sind wir – improuv. Wir arbeiten als Coaches und Berater:innen bei unseren Kunden als Mitglieder von inter-dependent Teams. Wir bilden aber auch gemeinsam mit unseren improuv-Kolleg:innen ein extra-dependent Team: wir entwickeln neuen Ideen, führen kollegiale Fallberatungen und tauschen unsere Erfahrungen aus. Unser identisches Ziel ist es,  gemeinsam zu lernen und Spaß dabei zu haben – und improuv langfristig erfolgreich zu machen. 

Je größer die Organisation ist, desto eher werden bestimmte Funktionen zentral zusammengefasst: HR, Legal, Finance, Marketing, Sales, Procurement… sind Beispiele dafür. Um Kundenorientierung und damit Business Agility zu erreichen, sollte das Geschehen jedoch nicht von diesen Zentraleinheiten bestimmt werden, sondern vom Kunden, bzw. von kundenorientierten Teams. Die Aufgabe der Zentraleinheiten ist es, diese zu unterstützen. Ein Business Partner aus HR, der für einen bestimmten Bereich zuständig ist, ist „interdependent“ Mitglied dieses Bereichs und gleichzeitig „extradependent“ Mitglied seiner HR-Einheit.

Extra-dependent Teams sind die Realität in Organisationen. Nach Untersuchungen von David in drei Organisationen machen sie zwischen 43 un 69% aller Teams aus! Wir sollten also vermeiden, alle Teams über einen Kamm zu scheren und extra-dependent Teams in das Raster eines inter-dependent Teams zu pressen. Das führt nur zu Frustration und nicht zu der erwarteten Verbesserung der Performance. 

Fazit: Cross-funktionale Teams sind super – aber bitte nicht als Dogma. Die Arbeit an Produkten ist eben nur ein Teil einer agilen Organisation. Ein Team ist mehr als die Summe seiner Mitglieder – und eine Organisation ist mehr als die Summe seiner Teams.