124 crossfunktional

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,


Janina & Henry


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


Janinas Ultimativer OKR Guide


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:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post 124 crossfunktional appeared first on Znipcast - für
gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.