Cross-funktionale Teams – gemeinsam punkten wir!

Komplexe IT-Vorhaben erfolgreich ins Ziel zu bringen, erfordert eine geeignete Zusammenarbeit aller involvierten Personen und Rollen. Gerne vergleiche ich es mit einem Fußballspiel: Jeder Teamplayer hat seine persönlichen Talente und seine Rolle im Team, jeder unterstützt kritische Situationen und übernimmt Verantwortung auf dem Spielfeld. Und gerade dieses Zusammenspiel macht eine gute Mannschaft aus, die ein gemeinsames Ziel verfolgt.

Projekte als einmalige und komplexe Vorhaben benötigen für ihr Gelingen die Zusammenarbeit vieler Personen und Rollen. Gerade in der Softwareentwicklung treffen verschiedene Disziplinen aufeinander, die einerseits hochspezialisiert und andererseits in hohem Ausmaß voneinander abhängig sind. Entwickler benötigen fachliche und technische Vorgaben, die von Analytikern, Fachbereichen oder Architekten stammen. Tester bauen auf den fachlichen Anforderungen und dem entwickelten Programmstand auf, also den Ergebnissen aller zuvor genannten Rollen. Den Auftraggeber und den Anwender interessiert vor allem das Gesamtergebnis, die erfolgreiche Interaktion innerhalb des Projektteams wird dabei vorausgesetzt.

Die früher häufig vorkommende wasserfallartige Organisation von Teams, strukturiert nach Hauptdisziplinen, genügt heutzutage in vielen Fällen nicht mehr, um die für den Projekterfolg notwendige Zusammenarbeit zu etablieren. Teams schaffen Mehrwert durch die Kombination unterschiedlicher Persönlichkeiten und verschiedener Fertigkeiten. In cross-funktionalen Teams können die Stärken unterschiedlicher Berufsgruppen genutzt werden, um in kürzerer Zeit ein besseres Ergebnis zu erzielen. Nachfolgend möchte ich meine Erfahrungen aus der Software-Entwicklung mit cross-funktionalen Teams mit Ihnen teilen.

Wie können unterschiedliche Rollen voneinander profitieren?

Analytiker und Entwickler

Die wohl typischste Zusammenarbeit ist die zwischen Analytikern und Entwicklern. Sie ist nicht neu und hat es immer schon gegeben. Entwickler profitieren vom fachlichen Wissen der Analytiker, die ihnen die größeren Zusammenhänge des zu erstellenden Codes vermitteln können, die Ziele, den Zweck. Developer geben den Analytikern Feedback darüber, welche Situationen in der Analyse noch zu berücksichtigen sind, ob die angedachte Lösung technisch umsetzbar ist, für welche nichtfunktionalen Anforderungen, wie zum Beispiel Sicherheit oder Performance, noch Überlegungen angestellt werden müssen. In agilen Teams ist diese Zusammenarbeit noch enger als früher. Mittels Epics und User Storys werden Anforderungen weniger detailliert festgehalten als in Lasten- oder Pflichtenheften. Die Erarbeitung einer lauffähigen Version steht im Vordergrund, um möglichst rasch Feedback zu erhalten, was viel direkte Kommunikation erfordert.

Analytiker und Tester

Für Analytiker und Tester gibt es ebenfalls gemeinsame Schnittmengen. In meinem letzten Projekt, der Entwicklung von Apps für Android und iOS, machten wir gute Erfahrungen damit, dass die Tester in unserem Team so oft wie möglich Testfälle frühzeitig erstellten, teilweise noch vor Entwicklungsbeginn. So erhielten die Analytiker ein rasches Feedback, ob die von ihnen definierten User Stories aus fachlicher Sicht verständlich und die darin beschriebenen Akzeptanzkriterien nachvollziehbar und praktikabel waren, oft noch bevor die Developer die Stories übernommen hatten. Die Tester konnten so bereits in dieser Phase fachliches Verständnis zu den neuen Funktionen aufbauen. Während der Tests halfen die Analytiker bei Fragen hinsichtlich der Severity bzw. Relevanz von Fehlern. Und bei kritischen Themen testeten sie zusammen, um entstandene Fragen zu klären.

Entwickler und Tester

Die Zusammenarbeit von Entwicklern und Testern kann ebenso für beide hilfreich sein. Unsere Entwickler unterstützten zum Beispiel die Tester bei der Erstellung von Testklassen, um die entwicklungsnahe Testautomatisierung zu erleichtern. Und um eine bessere gemeinsame Testabdeckung zu erreichen, schrieben sie Unit-Tests, welche die Korrektheit übergebener Schnittstellen sicherstellten. Die Tester wiederum machten ihre Entwicklerkollegen oftmals auf fehlende oder falsch verstandene Funktionalitäten aufmerksam bzw. sorgten sie mit ihrer systematischen Vorgehensweise dafür, dass der kreativ umgesetzte Code den letzten Schliff erhielt.

Jeder macht alles?

Jein. Desto kleiner ein gemischtes Team ist, desto mehr verschwimmen natürlich festgelegte Rollen. Dort müssen vermehrt andere Aufgaben übernommen werden, die dringend notwendig und mangels anderer freier Kapazitäten trotzdem bewältigt gehören – im Sinne der Erreichung gemeinsamer Teamziele. Es ist von großem Vorteil für die teaminterne Zusammenarbeit, wenn jeder mal eine andere Rolle einnimmt und so den Blickwinkel des Kollegen oder der Kollegin kennenlernt.

Es schadet zum Beispiel keinem Entwickler zu erleben, wie es Testern ergeht, die feststellen, dass grundlegende Funktionen, welche angeblich bereits den Status „feature complete“ erreicht haben, überhaupt nicht funktionieren und bewiesenermaßen vom Developer vorher noch kein einziges Mal ausprobiert wurden. Beispiele dieser Art, richtiggehende Erkenntnisgewinne, lassen sich zwischen allen Disziplinen finden. Durch das praktische Hineinversetzen in eine andere Rolle entwickelt sich besseres Verständnis für die Schwierigkeiten des anderen, was ein Motor für Verbesserungen in der Zusammenarbeit sein kann, mit direkter Auswirkung auf die Qualität im Team.

In einem größeren Team hingegen, das über die ideale Größe von bis zu sieben Mitarbeitern hinausgeht, was in der Praxis oft genug vorkommt, wird in Summe jeder Einzelne mehr bei seiner eigentlichen Tätigkeit bleiben, weil sich das Ausprobieren einer anderen Rolle auf mehr mögliche Kandidaten verteilt. Das ist nicht weiter schlimm und führt mich zu meinem nächsten Punkt.

Muss jeder seine Rolle wechseln?

Nein! Wer es toll findet, dass jedes Teammitglied seinen grundsätzlichen Aufgabenbereich laufend wechselt, hat zu wenig Respekt vor den Fähigkeiten und Kenntnissen, vor den Ausbildungen und Erfahrungen der verschiedenen Rollenbilder, die in einem Softwareprojekt zusammenarbeiten. Sie sind wertvolles Kapital, das Zinsen bringt und nicht verschleudert werden darf. Es geht auch darum ihren bestmöglichen Beitrag, ihre bestmögliche Leistung fürs Projekt abzurufen! Ein guter Entwickler soll sich vorwiegend jener Aufgabe widmen, von der er etwas versteht, nämlich guten Programmcode schreiben und technische Probleme lösen. Über den Tellerrand blicken wäre dabei gut und hilfreich, aber man sollte nicht jemanden willkürlich auf Themengebiete ansetzen, bei denen die Performance auf Dauer schlechter sein wird.

Wie eingangs erwähnt kann man es mit einem Fußballspiel vergleichen: Jeder hilft aus, unterstützt kritische Situationen, übernimmt Verantwortung auch auf der anderen Seite des Spielfelds. Und es kann in der neunzigsten Minute bei Elfmeter und roter Karte für den Tormann schon mal ein Feldspieler ins Tor gehen, um das Spiel zu retten. Aber es wird nicht die Dauerlösung sein. Ein erfahrener Tormann hält mehr Bälle, dafür hat er das entsprechende Talent, die Ausbildung und Erfahrung.

Falls jemand in einem Projekt vier Wochen einer sozusagen artfremden Tätigkeit nachgeht, kann es Sinn machen in Richtung persönlicher Weiterentwicklung. Genauso muss man aber prüfen, ob für diesen Zeitraum eine zusätzliche Person das Team unterstützen kann. Es gilt, nicht aus der Not eine Tugend zu machen, sondern die jeweils passendste Lösung zu ermöglichen.

Führung von cross-funktionalen Teams

Ein spannendes Thema! Unterschiedliche Charaktere, verschiedene Begabungen und Vorstellungen von der Arbeitsweise finden sich in einem gemeinsamen Team wieder. Wie kann das funktionieren? Auf Dauer nur durch Balance zwischen unterschiedlichen Rollen und Menschen – und für die ist die Führungskraft mitverantwortlich. Zur Führungsaufgabe gehört bis zu einem gewissen Grad auch eine Vermittlungsfunktion, die Fähigkeit, Unterschiede zuzulassen und rollenbedingte Sichtweisen den anderen zugänglich zu machen.

In einem lupenrein agilen Team gibt es diese Führungskraft nicht wie in der klassischen Form. Der Scrum Master achtet auf Prozesse, ein oder mehrere Personalverantwortliche kümmern sich um Mitarbeiterentwicklung, das Team selbst ist stärker gefordert, seine Eigenverantwortung einzubringen. Situativ werden dort Führungsaufgaben von verschiedenen Personen übernommen und geteilt.

Aber auch in einer eher klassischen Struktur ist nicht der Teamleiter die einzige tatsächliche Führungskraft. Es gibt immer eine informelle Organisation, nicht-offizielle Alphas, welche Initiative ergreifen und Verantwortung für andere übernehmen. Ebenso haut auch in einem agilen Team mal jemand auf den Tisch und sagt, so machen wir es, egal ob dazu formal berechtigt oder nicht. Die im Folgenden beschriebenen Ideen werden in der Realität eigentlich immer von mehreren Personen geteilt, unabhängig von ihrer Umgebung.

Das JOHARI-Fenster

Es gibt den Begriff JOHARI-Fenster. Damit bezeichnet man bewusste und unbewusste Persönlichkeits- bzw. Verhaltensmerkmale zwischen einem selbst und den anderen einer Gruppe, Unterschiede zwischen Selbst- und Fremdwahrnehmung. In der Arbeit mit Teams treffe ich immer wieder auf typische Rollenmuster, die man nicht auf jeden Einzelnen verallgemeinernd anwenden kann, ich im praktischen Erleben aber oft als signifikant wahrnehme. Kommunikationsverhalten von Softwareentwicklern, Genauigkeit von Analytikern oder Testern, Eigenschaften, die im Zusammenspiel mit anderen eine Reibung ergeben. Oft sogar notwendige. Ohne diese Konflikte ist keine produktive Zusammenarbeit möglich.

Als Teamverantwortlicher kann man dazu beitragen diese Fenster zu erweitern, indem man versucht Person A die Perspektive von Person B nahe zu bringen. Wenn nicht durch praktischen Rollenwechsel (was das Nachhaltigere ist), so durch das Gespräch. Was natürlich im ersten Anlauf nicht immer auf Gegenliebe stößt, da es nicht gleich die Schwierigkeiten in der Zusammenarbeit löst. Entsprechende Kritik muss man als Führungskraft schon mal aushalten können. Solche Gespräche sind mehr als Baustein in der Kette zu verstehen, aus der Lösungsansätze entstehen – manchmal erst zeitversetzt.

Für nicht-cross-funktionale Teams gilt natürlich ebenso, dass das bessere Kennenlernen und Einschätzen des anderen in der Zusammenarbeit helfen kann. In einer Gruppe, die sich aus verschiedenen Berufsgruppen zusammensetzt, werden die Unterschiede jedoch meistens noch größer ausfallen, was in der Arbeit mit dem Team besonders zu berücksichtigen ist.

Es ist nicht Aufgabe des Teamleads alle Konflikte selbst zu lösen, das wird gar nicht möglich sein. Aber man muss dafür sorgen, dass Prozesse eingehalten oder entsprechend verbessert werden. Falls die Mitarbeiter im Team nicht selbst untereinander eine Regelung finden, muss man der Katalysator dafür sein, dass eine gefunden wird – wenn angebracht auch mit Machtwort und Entscheidung.

Auf jeden Fall muss man dafür sorgen, dass nicht eine bestimmte Rolle im Team wichtiger als alle anderen empfunden wird – sowohl innerhalb als auch außerhalb des Teams. Alle Rollen sind gleich wichtig. Im Endeffekt spielt es keine Rolle, ob ein Formel-1-Auto wegen eines schlecht nachgezogenen Bolzens oder eines fehlerhaft produzierten Reifens aus dem Rennen ausscheidet, die Gesamtleistung, das ganze Paket entscheidet.

Fazit

Womit ich den Kreis schließen möchte. Jede Rolle erfordert bestimmte Fähigkeiten, Ausbildungen, Erfahrungen – und oft auch typische Verhaltensmuster. Diesen Flohzirkus zu hüten, dazu ist vor allem Respekt notwendig, Respekt vor den unterschiedlichen Fähigkeiten, die in ihrer Gesamtheit ein tolles Team ergeben können. Diese Unterschiede zuzulassen und trotzdem daraus ein Ganzes zu formen, was bei cross-funktionalen Teams aufgrund ihrer Rollendiversität noch ein gehöriges Stück schwieriger ist als zum Beispiel in einem reinen Entwicklerteam, ist die spannende Herausforderung bei der Leitung eines solchen Teams.