crossfunktional
Wir wollen heute über crossfunktional aufgebaute Teams oder auch Gruppen sprechen.
Gerade im Projektalltag kommt häufiger die Frage auf „Warum haben wir folgende Kompetenzen nicht im Team?“. Berechtigte Frage und damit beschäftigt sich die Crossfunktionalität.
Henry Schneider hat eher die Frage, was es denn mit dem crossfunktional auf sich hat. Steht ja schließlich im Scrum Guide und wird dort nicht näher erklärt. Dort übrigens unter dem Wort cross-functional.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. – aus dem Scrum Guide 2022 – Seite 5
Dies passt ja auch gut zum 4. Prinzip aus dem Agilen Manifstest für Softwareentwicklung. Principles behind the Agile Manifesto
Diese Folge auf YouTube: https://youtu.be/V0rcRHxLq6M
Skalierung
Der Scrum Guide betrachtet natürlich ein einziges Team. Im Skalierten Umfeld bei größeren Produkten haben wir natürlich deutlich mehr Kompetenzen und da ist das Thema der Crossfunktionalität noch einmal ein ganz anderer Schnack.
Bei größeren Entwicklungsketten (siehe auch KanBan) kann natürlich jedes Team 100% crossfunktional sein.
Doch heute soll es gar nicht um Skalierung und eventuelle koordinierende Ebenen aus den Flightlevels gehen, sondern schön easy auf Teamebene.
Warum & Wozu?
Warum brauche ich denn nun crossfunktionale Teams?
Es kommt sehr darauf an, was ich mit meinem Produkt, Team oder Unternehmen erreichen möchte. Je nachdem ist crossfunktionalität hilfreich oder eben nicht. Hilfreich ist dies vor allem bei Teams, die kreative Arbeit machen oder Unternehmen, die sich selbst oder ihre Produkte neu erfinden wollen. Vor allem in einer sich ständig und viel ändernden VUCA-Welt.
Diese crossfunktionalen Teams ermöglichen neue Ideen und Blinkwinkel für neue, vielleicht bessere Produkte. Somit erhalten wir auch die Chance disruptive Dinge zu entwickeln.
Es geht also darum, die Dinge, die man schon immer so gemacht hat, vielleicht einmal anders zu machen.
Ein gutes Beispiel für diese Kraft ist die Entdeckung vom Post-It Klebstoff. 3M wollte eigentlich einen neuen richtig kräftigen Klebstoff entwicklen. Der neue Klebstoff entsprach nicht den Anforderungen und zeigte seine bahnbrechende Errungenschaften erst in den Gesprächen mit anderen aus anderen Disziplinen. So zum Beispiel für Gesangsbücher im Kirchenchor. Quelle: Die Geschichte der Post-it® Notes | 3M in Deutschland (3mdeutschland.de)
Henry macht sich die Welt hier wieder viel einfacher:
Mit Crossfunktionalität werden unsere Teams effizienter und effektiver.
In Janina Kappelhoffs Welt ist es vor allem wichtig die Systeme so durch kleine Störungen in ein neues Lernen zu führen. Denn die meisten Systeme schaffen nur wieder Systeme, die den gleichen Regeln folgen. Für Änderungen bedarf es hier vorab einer Störung oder Intervention. Die Crossfunktionalität ist hier ein guter Katalysator.
Bedeutung
Crossfunktionalität bedeutet, dass ich verschiedene Kompetenzen, Fähigkeiten und Fachrichtungen in einem Team habe.
Dies kennen wir vor allem von Taskforces, als auch von Katastrophenhelfern. Gerade bei größeren Unglücken, wie den 13 Fußballspielern, die in einer Höhle eingeschlossen waren, zeigt sich, wie wichtig es ist verschiedene Disziplinen zu einem Team zusammenzuführen um gemeinsam ein besseres Ergebnis zu erreichen. Hier haben Hobbyhöhlentaucher, Medizinier, Militär und Katastrophenschutz bestens zusammengearbeitet.
Nach Henrys Meinung sind die Agilen Frameworks ein Destillat aus erfolgreichen Taskforces, wo wir die Teams auch crossfunktional zusammenstellen. Nur, dass es in der Agilität kein Zufall ist und auch nicht spontan auftritt und Menschen erst einmal in ein Chaos führt. Wir nutzen also die Kraft dahinter liegt um stetig besser zu werden, ohne uns auszupowern. By the way sind die Menschen in einer Taskforce dieser auch zu 100% zugeordnet, da es ja ein Riesen Unternehmensproblem zu lösen gibt. Daher ist dies auch essentiell für erfolgreiche Teams. 😉
Dabei werden auch übliche Regeln und Strukturen im Unternehmen abgebaut. Die bisherigen sogenannten Silogrenzen der Bereiche gelten also nicht mehr in crossfunktionalen Teams.
Weitere Beispiele aus der IT
In der IT sehen wir solche Crossfunktionalität häufig in sogenannten DevOps-Teams. Indem beispielsweise Entwicklerinnen mit Supporterinnen oder Testerinnen in einem Team zusammengefasst werden, statt da unterschiedliche Silos in einem Wasserfallprojekt draus zu machen.
So kann ein Tester im Team gut beschreiben, wie er die Software am Ende testen würde und man kann dagegen entwickeln oder das Testen der Software einfacher gestalten. Supporterinnen geben häufig gute Rückmeldungen zum Einsatz der Software, wie weniger Kundenfragen aufkommen oder was es allgemein für Kundenwünsche oder Probleme gibt. Am Ende gibt es häufig anwenderfreundlichere Software. 🙂
Ein Riesen Benefit dieser Teams ist also meist, dass die Qualität enorm steigt. Auch die Trefferquote der richtigen Funktionalität des Produktes steigt enorm. Also haben wir auch das entwickelt, was der Kunde braucht?
Wir sparen uns vor allem das Warten auf andere im Entwicklungsprozess, da die Aufgaben komplett von dem jeweiligen Team erledigt werden können. In klassischen Projekten darf man häufig auf die Rückmeldung der Testabteilung warten und dann entsprechend am Feature nachbessern. Sind alle in einem Team, so kann dies auch dort direkt erledigt werden. Ohne warten.
Gut aufgebaute crossfunktionale Teams haben es leichter Sprints zu planen. Zusätzlich wird die Kommunikation über Teamgrenzen hinaus leichter, da ein größeres Verständnis für das Umfeld besteht.
Nachteile
Crossfunktionale Teams haben auch Nachteile. Wir haben beispielsweise plötzlich sehr viele verschiedene Blickwinkel im Team. Dies steigert vor allem das Konfliktpotential und auch die Kommunikationskomplexität nimmt zu. Aus Henys Sicht handelt Agilität sowieso nur von Kommunikationskomplexität und darf daher auch vorrangig vom Agile Master im Blick behalten werden.
Also ein Thema, was wir im Vorfeld beachten und nicht einfach ignorieren dürfen.
Wir dürfen zusätzlich Menschen dazu motivieren auf Aufgaben zu übernehmen, die demnach nicht zu ihrem eigentlichen Kern gehören, da sie nun als Team komplett für die Ergebnisse verantwortlich sind. Genau hierin liegt die Magie, dass beispielsweise Tester, wenn sie bei der Softwareentwicklung unterstützen sollen, mehr und andere Fragen stellen, die vielleicht zu besseren Ergebnisse oder einem Umdenken beitragen.
Gerade dieser Aufbau macht Teams zu Beginn langsamer, erfordert mehr Teambuildingmaßnahmen und kann auch mehr Konflikte hervorrufen. Wobei Konflikte auch sehr gut sind und auftreten sollten, nur halt kontrolliert. Gerade Storming Phasen (Teamphasen) können somit auch schlimmer ausfallen und Teams dysfunktional machen. Große Verantwortung für den Agilisten im Team.
Bei Teams die nur kurz zusammenarbeiten, wie bei Taskforces oder Höhlenunglücken, brauche ich darauf natürlich nicht so sehr achten, da wir hier swift-trust nutzen können.
Der Agile Master bekommt Arbeit
Neben den bisher genannten Themen ist häufig auch der Irrglaube, dass es ausreicht Menschen einfach über Aufgabengrenzen zusammen in ein Team zu schmeißen und die crossfunktionalität ergibt sich dann. Dem ist meist nicht so. Hier bekommt die Agile Masterin also gut zu tun. Beispielsweise wegen der genannten Konflikte, Kommunikationskomplexität und auch um die Menschen zu ermutigen zusammen zu arbeiten und auch die Blickwinkel übereinander zu legen.
Steuerkreise & Gremien
Häufig sehe ich, dass mit dem validen Argument der Crossfunktionalität, Steuerkreise und Gremien gegründet werden. Schon einmal schön, dass erkannt wurde, dass crossfunktionale Teams wichtig sind. Ein Gremium oder Steuerkreis ist aber kein Team. Es ist nicht mehr Arbeit dadurch erledigt, dass sich 30 Personen aus 20 verschieden Disziplinen einmal die Woche für 2h treffen. Es sind dann lediglich 60 Arbeitsstunden pro Woche verbraucht wurden. Der Austausch der dort passiert kann trotzdem sehr sinnvoll sein und ist gleichzeitig nicht was wir mit einem crossfunktionalen Team erreichen wollen und können.
In freier Wildbahn
So richtig crossfunktionale Teams sehen wir dann doch seltener als wir dachten. Bei Henry fing das ganze schon in den ersten Jahren als IT-Projektleiter an. Damals waren Entwicklung und Betrieb voneinander getrennt und er vereinte erstmals diese beiden Bereiche in einem Projekt. Quasi DevOps. Meist sind Teams aber nur vermeintlich crossfunktional. Dies liegt auch danach, dass viele Organisationen nach Fähigkeiten geschnitten sind und dies dann Team nennen. Also hier ist fas Team der Konstrukteure, hier das der Entwicklerinnen und so weiter. Im Taylorismus war das auch sehr gut und hat zu hervorragenden Ergebnissen geführt. Für den komplizierten Bereich also weiter machen, nicht für den komplexen Bereich (Cynefin).
Natürlich brauchst Du auch nicht alle Funktionen in einem Team integrieren, denn das kann schnell auch sehr mannigfaltig werden und würde dann die Teamgröße sprengen. Hier wäre wichtig, dass das Team für seinen Bereich die komplette Verantwortung durchgängig übernehmen kann. Beispielsweise lohnt es sich für rechtliche Belange dann ein zusätzliches Team zu gründen, welches beratend zum ersteren Team hinzugezogen wird.
Ähnlich verhält es sich bei Bereichen wie Personal, Frontend, Backend, Konstruktion, Zerspahnung, Fertigung, alle Bereiche häufig getrennt und hier kann man gut auch mal crossfunktionale Teams experimentell aufbauen.
Meine Empfehlung: Nimm es einfach hin, dass die Organisation so geschnitten ist und das vielleicht auch Team nennt. Betrachte sie wie Gilden und bau in einer informellen Struktur bessere Teams dazu. 😉
Home Office
Homme Office macht das Ganze natürlich komplizierter. Warum? Die zufälligen Kontakte und Zusammenarbeit kommen seltener zustande. Natürlich rufe ich eher Kollegen aus meinem eigenen Berufsstand an um Probleme mit ihnen gemeinsam zu besprechen. Hier dürfen wir Agilisten auch wieder entsprechende Kontaktpunkte schaffen. Dabei ist vor allem wichtig Freiräume im Kalender zu haben, damit diese zufälligen Kontakte auch zustandekommen können.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
- Teams
- Scrum Guide
- KanBan
- Flightlevels
- Warten
- Sprints
- planen
- Teamphasen
- Agile Master
- dysfunktional
- swift-trust
- Cynefin
Connecte dich gerne hier mit uns:
