Richtig gute Teams im Projektgeschäft

Die Art der Zusammenarbeit hat Auswirkung auf die Lieferobjekte

Gutes Teamwork ist wichtig. Und das nicht erst, seit das Thema “Agil” en vogue geworden ist. Wer würde dies nicht so unterschreiben?

Gerade in der IT-Beratung wechseln Projekte in kurzen Abständen. Daher begegnen Teams ständig neuen fachlichen und technischen Herausforderungen. Die Aufgabestellungen sind meist sehr komplex. Richtig gutes Teamwork ist somit besonders im Entwicklungsteam ein elementarer Erfolgsfaktor.

Neben fachlichen Anforderungen und vielen weiteren Rahmenbedingungen beeinflusst die intensive Zusammenarbeit im Entwicklungsteam nicht nur, wie etwas gebaut wird, sondern auch was gebaut wird.

Nicht nur “Gutes Teamwork”, sondern “Richtig Gutes Teamwork”

Es stellt sich die Frage: Ist das Streben nach gutem Teamwork nur Selbstzweck? Was bedeutet schon gut? Und was hat eigentlich der Kunde davon?

Besonders im Projektgeschäft ist es oft so, dass sich die Entwicklungsteams nach dem Projektende auflösen. Bei Projektbeginn finden sie sich dann in neuer Konstellation wieder zusammen. In den vergangenen Jahren war ich für unsere Kunden in verschiedenen Projektkontexten unterwegs, was Zusammensetzung, Teamgröße oder Projektdauer anbelangt. Daraus habe ich einiges gelernt:

Ein neu zusammengestelltes Team durchläuft verschiedene Phasen, in denen sich die einzelnen Mitglieder erst zusammenfinden müssen. Bis sich die volle Leistungsfähigkeit des Teams zeigt, dauert es ein wenig. Die Reihenfolge der zu durchlaufenden Phasen nach Tuckman [1] sind, vereinfacht dargestellt: Forming, Storming, Norming, Performing und Adjourning.

Zunächst muss sich das Team kennenlernen (Forming). Es werden Rollen und Aufgabenbereiche eingenommen und ausgelotet, Konflikte entstehen und werden schließlich beigelegt (Storming). Erst am Ende dieses Kennenlernens, wenn sich die Gruppe des gemeinsamen Ziels bewusst wird, entsteht ein wirkliches Team, in dem die Stärken und Eigenschaften der Einzelnen wahrgenommen und angenommen werden (Norming). Die Intensität und Dauer der einzelnen Phasen unterscheiden sich von Gruppierung zu Gruppierung. In der Performing-Phase kann das Team am effektivsten die gestellten Aufgaben meistern und mit möglichen Konflikten umgehen. Die Motivation ist riesig. Es entsteht ein ungeheurer Flow. Daher sollte diese Phase am längsten dauern. Sobald das Projekt endet, löst sich das Team häufig auf. Die Mitglieder können somit eine Art Verlust empfinden (Adjourning).

… und das durch möglichst stabile Teams!

In den letzten beiden Jahren war ich – zufällig – mit einigen anderen Kollegen über mehrere Projekte Teil eines stabilen Kernteams. Dank günstiger Umstände wurden wir als Entwicklungsteam am Ende eines Projekts nicht auf andere Projekte verteilt oder als neue Teams zusammengesetzt. Sondern wir wurden als etabliertes Team auf das nächste Projekt und eine neue Aufgabe angesetzt.

Die Beobachtungen aus dieser Phase haben mir klar gezeigt, worauf es bei einem richtig guten Team ankommt – gerade im Projektgeschäft:

• Der initiale Aufwand bei der Teambildung, der sich normalerweise durch die Phasen Forming, Storming und Norming ergibt, verringert sich auf ein notwendiges Minimum
• Bereits von Anfang an herrscht Vertrauen im Team. Dieses Vertrauen kann man nicht postulieren. Es muss normalerweise aufgebaut werden, sich entwickeln. Und das kostet Zeit.
• Dieses Vertrauen führt zu eingespielter Kommunikation. Daraus folgt höhere Transparenz. Das Team identifiziert schneller Probleme oder Impediments. Es kann diese dann lösen oder gar nicht erst entstehen lassen.
• Das Team ist ein sicheres Umfeld, um Dinge auszuprobieren und Fehler oder Unkenntnisse zu kommunizieren.
• Eine gemeinsame Sicht auf die Dinge ist für die Kommunikation mit Stakeholdern und Projektmanagement unabdingbar. Alle Beteiligten sind so in der Lage, den aktuellen Projektstatus genau einzuschätzen.
• Agile Methoden, Praktiken und Herangehensweisen sind bereits tief verankert und gut eingeübt. Dies führt von Anfang an zu einem hohen Grad an Selbstorganisation.
• Das Team hat bereits ähnliche Ansprüche an Qualität und eine Vorstellung davon, was gute Software ausmacht. Ansprüche kann man kommunizieren. Besser ist, sie vorleben zu können, sonst macht man das gegenseitige Vertrauen zunichte.
• Werte und Praktiken, angelehnt an das Agile Manifest [2], Software Craftsmanship [3] oder der DevOps-Kultur [4] werden auf hohem Niveau gelebt. Diese Werte schweißen zusammen. Dies schafft ein gemeinsames Mindset.
• Konkrete Spezialisierungen von Anfang an braucht es mitunter nicht. Intensiver Austausch durch stetiges Wechseln der Programmierpartner reicht. Dies fördert den Wissensaustausch. Man lernt die Fähigkeiten der Anderen kennen.
• Auch wenn die ursprünglichen Fähigkeiten im Team nicht alle Anforderungen der Aufgabenstellung abdecken, löst ein selbstorganisiertes Team umfassende Probleme durch klarere Kommunikation äußerst effizient. In unserem Fall war das zum Beispiel Enterprise-Technologie-Stack, der den meisten Team-Mitgliedern unbekannt war, inklusive Programmiersprache, Frameworks und Bibliotheken. Der Cloud-Plattform-Anbieter war Neuland; ebenso viele Infrastruktur- und Operations-Tätigkeiten. Dieses Know-how musste im Team erst noch aufgebaut werden. Da alle betroffen waren, konkretisierte sich dies unter anderem in gelebtem DevOps ohne explizite Rollen. Jeder im Dev-Team musste sich mit der Infrastruktur auseinandersetzen.
• Die Entwicklung erfolgte von Anfang an als Pair-Programming und (manchmal auch) als Mob inklusive Prozess für Code Quality und Testautomatisierung. Auch hier verstand sich das Team in seiner ganzheitlichen Ausrichtung.
• Die Retrospektiven wiesen schon in den ersten Iterationen einen hohen Grad an Selbstreflexion und Lösungsfokussierung auf.

Stabile Teams sind ein Schlüssel

Man könnte es auch so formulieren: Bringe nicht das Team zum Projekt, sondern das Projekt zum Team!

Diese Denkweise konkretisiert sich beispielsweise auch in der MaibornWolff-Teambox [5] und so darf an dieser Stelle der Hinweis darauf nicht fehlen. Das Teambox-Format erlaubt es, die Digitalisierungsideen unserer Kunden durch explizit reservierte Teams und enge Zusammenarbeit zielgerichtet umzusetzen.

Für mich fühlt sich ein Team richtig gut an, wenn etwas von diesen drei Entwicklungen eintritt:

• Ein gutes Team ist in der Lage, sich selbst zu helfen. Jedes Teammitglied bringt unterschiedliche Fähigkeiten und Kompetenzen mit, die zur Lösung der Aufgaben beitragen. Es empfiehlt sich, hier eine ausgewogene Mischung aus Generalisten mit Fokus auf einen Teilaspekt zu haben, wie beispielsweise Testautomatisierung. Somit verkürzt sich der zeitliche Aufwand, den das Team als Ganzes braucht, um sich bestimmte Themen anzueignen. Ein Team ausschließlich aus Spezialisten ist hier eher hinderlich.
• Ein gutes Team teilt das Ziel. Jede*r hat es vor Augen. Jede*r weiß, wie sie/er zur Erfüllung des Gesamtziels beitragen kann.
• Ein gutes Team lebt im Miteinander Werte wie Vertrauen, Transparenz, Offenheit, Anspruch an Qualität oder Verantwortung.

Damit das eintreten kann, braucht es ein paar Rahmenbedingungen: Emotional stabile Teams brauchen Zeit. Sie entwickeln sich über einen längeren Zeitraum. Teams sollten daher nicht nur für die Dauer eines Projekts zusammen sein, sondern über Projektgrenzen hinweg.

Selbstverständlich kann auch dies ins Gegenteil umschlagen. In diesem Fall: Vorsicht vor allzu stabilen Entwicklungsteams, die betriebsblind sind. Das heißt, wenn diese ihre Entscheidungen nicht mehr hinterfragen oder etablierte Praktiken guter Softwareentwicklung vernachlässigen.

Und natürlich sollte es auch möglich sein, dass sich Teams über die Zeit weiterentwickeln. Bei Bedarf sollen Personen das Team auch verlassen können, um anderen Interessen nachzugehen und sich neue Fähigkeiten anzueignen.

Wie seht ihr das denn? Welche Eigenschaften muss ein richtig gutes Team eurer Meinung nach haben?

Links

[1] Tuckman’s stages of group development: englischsprachige Wikipedia oder project-management.com

[2] Manifesto for Agile Software Development

[3] Manifesto for Software Craftsmanship

[4] DevOps Culture

[5] Teambox von MaibornWolff

---

Über den Autor