Der Mythos von Teamwork und Crossfunktionalität

Werte im Teamwork

Teamwork

Im agilen Kontext lautet die Devise Teamwork – und zwar in einem crossfunktionalen Team. Ich erlebe häufig, dass man versucht, diese Devise auf Biegen und Brechen umzusetzen – ohne Blick auf die Sinnhaftigkeit und Passung zum Geschäft, für das die betroffenen Mitarbeiter:innen verantwortlich sind. Ein Beitrag von Jennifer Rolle (Foto: dmitrydesigner / Adobe Stock).

Was ist eigentlich der Hintergrund für die agilen Organisationsprinzipien Teamwork und Crossfunktionalität?

Viele der agilen Arbeitsprinzipien wie etwa Teamwork und Crossfunktionalität sind für komplexe Herausforderungen „gemacht“. Das heißt für Problemstellungen, deren Lösung unklar ist und bleibt. Probleme, bei denen uns immer weitere Analysen dennoch kein richtiges Vorgehen, keine eindeutige Lösung aufzeigen. Immer da, wo wir nur mit Hypothesen arbeiten, Experimente machen und uns langsam „voran irren“ können wie in der Wissenschaft. (Mehr zum Thema Komplexität: Cynefin-Modell). Hier wären also zum Beispiel die Produktentwicklung und Projekte zu nennen.

Der Vorteil von Teamwork und Crossfunktionalität besteht einerseits nach Ashby’s Law darin, dass ein crossfunktionales, diverses Team durch seine eigene Komplexität besser in der Lage ist, entsprechend komplexe Probleme zu lösen.

Ashby’s Law: Die Varietät des Steuerungssystems muss mindestens ebenso groß sein, wie die Varietät der auftretenden Störungen, damit es die Steuerung ausführen kann.

Die Idee von Teamwork

Weiterhin besteht die Idee von Teamwork darin, dass das Team eine gemeinschaftliche Verantwortung für das Teamziel trägt. Das bedeutet auch, dass wir anstreben, dass sich die Teammitglieder gegenseitig unterstützen.

Sprich: Wenn ein Teammitglied mit seinem Skill und seiner Rolle im Team überlastet ist, während ein anderes Teammitglied gerade nicht so viel zu tun hat, unterstützt man sich. Das bedeutet, dass wir auf ein T-shaped Skill-Profil hinarbeiten: Der vertikale Strich im T steht für eine hohe Expertise in einem bestimmten Feld, der Querstrich dafür, dass nach dem Pareto-Prinzip auch Tätigkeiten in anderen Themen übernommen werden können, also mit 20 % des Aufwands schon 80 % in einem Themenfeld. Das ist nicht effizient, weil man in einem fremden Themengebiet länger für die Ausführung braucht als der:die Expert:in. Aber bevor man drei Wochen auf den:die Expert:in wartet, ist es allemal schneller – was wir im agilen Kontext anstreben.

Wir wollen schnell in die Auslieferung kommen, um schnell lernen zu können, ob unsere Hypothese richtig oder falsch war.

Sinnlosigkeit eines Crossfunktionalen Teams

Dazu trägt auch die Crossfunktionalität bei. Diese bringt nicht nur die benötigte Komplexität ins Team, sondern auch alle Funktionen ins Team, die man benötigt, um ins Ausliefern zu kommen. Idealweise bestehen keine Abhängigkeiten zu anderen, sodass das Team keine Wartezeiten hat und schnell direkt selbst ausliefern kann („ausliefern“ im Sinne von fertig und nutzbar).

Schauen wir uns an, womit sich 90 % der Mitarbeiter:innen in bestehenden Unternehmen beschäftigen, stellen wir in vielen Fällen fest, dass diese vor allem mit dem „normalen“ Tagesgeschäft beschäftigt sind. Das zu einem überwiegenden Anteil nicht komplex ist, sondern einfach oder kompliziert. Hier gibt es klare Prozesse und Regeln, wie die Aufgaben zu erledigen sind. Bei komplizierteren Fragestellungen kann man über Analyse herausfinden, wo Ursachen liegen und welche Lösungsmöglichkeiten es gibt. Dafür braucht es Expertise, aber kein crossfunktionales Team.

Nun erlebe ich es immer wieder, dass die Expert:innen innerhalb ihres Bestandsgeschäfts zu teils crossfunktionalen Teams zusammenfasst werden, die vorher überhaupt nichts miteinander zu tun hatten, völlig unabhängig voneinander arbeiten konnten.

Ihnen werden die neuen agilen Führungsrollen an die Seite gestellt, wie Product Owner:in und Agile Master:in. Ihnen wird der Scrum-Prozess aufgezwungen, und es wird von ihnen erwartet, sich nun als echtes Team mit allen Formaten zum Umgang mit komplexen Herausforderungen entsprechend zu organisieren.

“Funktioniert bei uns nicht”

Da sitzt das neue Team im Planning, und es werden eher 1:1-Übergaben zwischen Product Owner:in und dem:der jeweiligen Expert:in durchgeführt, während der Rest des Teams sich langweilt. Genauso im Refinement. Das Planning II traut man sich als erstes wegzulassen, denn was soll das, hier die eh schon klar definierten Tasks zu diskutieren und herunterzubrechen – vor allem mit Menschen, die ohnehin dazu nichts sagen können. Im Daily erzählt jede:r was sie:er macht, womit der Rest nicht so richtig etwas anfangen kann. Und in der Retrospektive gibt es keine Themen, da es ja kein echtes Teamwork gibt, das es zu optimieren gelten würde.

Und dann sind diese sogenannten Teams vielleicht in Teilen crossfunktionaler besetzt. Aber es ist dennoch nicht möglich und sinnvoll, alle Kompetenzen und Rollen, die benötigt werden, um in die Auslieferung zu bekommen, ins Team zu holen. So bleiben immer noch Abhängigkeiten und Wartezeiten.

Und dann heißt es „Agilität haben wir auch schon ausprobiert. Funktioniert bei uns nicht.“ – Das kann ich gut verstehen, denn so erzeugt es auch keinen Nutzen!

Teamwork – 2

Foto: aerial-drone / Adobe Stock

Umdenken in Unternehmen

Nun kann man einwenden, dass es trotzdem gut wäre, so zu arbeiten, um voneinander zu lernen. Singuläre Expert:innen sind schließlich ein hohes Risiko für ein Unternehmen. Und dem stimme ich absolut zu. Hier scheint langsam ein Umdenken in den Unternehmen einzusetzen, die lange Zeit sehr stark auf Expert:innen gesetzt haben.

Immer mehr verstehen, dass der Lastwagenindex – Anzahl der Mitarbeiter:innen, die von einem Lastwagen überfahren werden können, bevor das Geschäft still steht -, wie man ihn häufig scherzhaft-morbide nennt, möglichst hoch sein sollte. Allerdings kann man Lernen im komplizierten Kontext auch einfacher organisieren. Mit weniger Overhead, den man für die Selbstorganisation eines echten Teams benötigt. Weiterhin sind die Teams häufig viel zu groß, da es vielleicht nur eine:n Expert:in zu einem Thema gibt, die:der aber aus unterschiedlichen Richtungen Aufgaben weiterführt oder zuarbeitet. Oder weil es schlicht zu wenig Product Owner:innen und/oder Agile Master:innen gibt. Das hemmt die Motivation, in andere Themengebiete hineinzuwachsen, schlicht aufgrund von Überforderungsempfinden mit den vielen Themen im Team. Man zieht sich lieber in seine bekannte Ecke zurück und schottet sich ab.

Und man kann einwenden, dass auch mehr Crossfunktionalität für schnelles Ausliefern besser ist als gar keine Crossfunktionalität. Und auch dem stimme ich absolut zu. Die agilen Arbeitsprinzipien passen also auch für das häufig eher einfache und komplizierte Bestandsgeschäft, aber dort erfüllen sie teils einen anderen Zweck. Vor allem müssen sie anders organisiert werden, um einen Nutzen zu erzeugen.

Werte im Fokus

So steht in der Organisation des Tagesgeschäfts die Betrachtung des Ende-zu-Ende-Wertstroms, der Wertschöpfungskette, des Prozesses vom Bedarf bis zur Auslieferung im Vordergrund. Crossfunktionalität ist hier mehr eine Haltung als eine Eigenschaft von Teams. Es geht darum, das Ganze im Blick zu behalten und gut zusammenzuarbeiten im Sinne der schnellen Auslieferung. Sich gemeinsam entlang des Wertstroms zu organisieren, sich gegenseitig zu unterstützen. Zum Beispiel im Sinne des Swarmings zu einem Engpass hinzuströmen und zu unterstützen, Blockaden aufzulösen – auch in anderen Abschnitten des Wertstroms als dem, wo ich normalerweise zu Hause bin.

Im Zweifel ist es besser, die funktionale Aufteilung erstmal zu lassen, wie sie ist, anstatt zu große Teams zu bilden. Dann schaffen wir Transparenz über den Gesamtprozess und die Arbeit, die sich darin befindet.

Hier geht es NICHT darum, Flussdiagramme für ein Handbuch zu schreiben, abzuheften und nie wieder anzuschauen. Es geht darum, den Prozess in einem Board (aka Lean Kanban Flight Level 2-Board) abzubilden, um die darin vorhandene Arbeit zu visualisieren. Auf diese Weise wird sie besprechbar – auch zwischen unterschiedlichen Funktionen.

In gemeinsamen Meeting-Formaten fokussieren wir NICHT auf das Verstehen und Herunterbrechen der Aufgaben, denn da gibt es nicht viel zu verstehen und herunterzubrechen. Vielmehr konzentrieren wir uns darauf, wie der Prozess durchläuft. Wo gibt es Störungen? Wo staut es sich? Wer benötigt wobei Unterstützung? Somit haben auch ein Daily und eine Retrospektive einen ganz anderen Fokus.

Auf diese Weise sehen die Beteiligten nach und nach, wie der Prozess gradliniger und schlanker gestaltet werden kann. Engpässe werden sichtbar und können gelöst werden. Nach und nach findet man vielleicht auch sinnvollere Teamkonstellationen.

Teamwork – 3

Foto: aerial-drone / Adobe Stock

Fazit

Die agilen Werte und Prinzipien passen in fast jeden Kontext. Scrum – und die damit verbundenen Skalierungsmodelle wie LeSS, SAFe usw. – hingegen in die wenigsten Kontexte in einem etablierten Unternehmen.

Schreibe einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit * markiert.

Formular zurücksetzenBeitragskommentare