Zum Inhalt

Theorie "Teambildung"

Der Erfolg eines Projektes hängt in hohem Maße von der Auswahl der Teammitglieder ab. Bei der Zusammenstellung eines Teams von Developern oder eines agilen Teams sollten daher einige Dinge beachtet werden. Neben der technischen Kompetenz, die zweifellos eine wichtige Rolle spielt, sollten die zwischenmenschlichen Kompetenzen nicht außer Acht gelassen werden. Wenn Sie für die Teamzusammensetzung verantwortlich sind, sollten Sie zum einen darauf achten, dass Sie Menschen mit unterschiedlichen Eigenschaften, Kenntnissen und Fähigkeiten zusammenbringen, da sie sich gut ergänzen. Auf diese Weise stellen Sie sicher, dass das Team auf fachlicher Ebene in der Lage ist, alle Aufgaben (z. B. aus dem Product Backlog oder vom Kanban-Board) umzusetzen. Sie sollten aber auch die Wünsche der künftigen Teammitglieder berücksichtigen, da sie diejenigen sein werden, die im Team zusammenarbeiten müssen. Darüber hinaus gibt es einige zwischenmenschliche Eigenschaften, die von Vorteil sind, wenn die Teammitglieder sie mitbringen:

  • Fähigkeit zur Kommunikation

  • Initiative, Engagement, Begeisterung, Motivationsfähigkeit

  • Kontaktfreudigkeit, Offenheit

  • Sensibilität, Selbstkontrolle, Fähigkeit zur Wertschätzung

  • Loyalität, Solidarität, Hilfsbereitschaft

  • Konfliktlösungsfähigkeit, Argumentationskultur, Fairness

Sobald das Team zusammengestellt ist - ob mit selbst gewählten oder vorgegebenen Mitgliedern - muss es zusammenarbeiten. Das wird wahrscheinlich nicht von Anfang an gut funktionieren, sondern erst mit der Zeit. Nicht umsonst wird ein Team, das schon lange besteht, als eingespielt bezeichnet. Auch wenn sich das Team selbstständig entwickeln muss, kann der Scrum Master oder der Projektleiter, wenn nicht Scrum, sondern eine agile Methode angewendet wird, einige Maßnahmen zur Unterstützung des Teams ergreifen. Es hat sich beispielsweise bewährt, dass gemeinsame Spielregeln festgelegt werden, die befolgt werden müssen. Wenn der Scrum Master bzw. der Verantwortliche feststellt, dass offene oder versteckte Konflikte auftreten, dann sollte er helfen, diese ggf. zunächst aufzudecken und (anschließend) zu lösen. Dazu sollte auch eine Streitkultur geschaffen werden. Bei Scrum ist, wie Sie bereits aus den vorangegangenen Kapiteln wissen, die Hauptaufgabe des Scrum Masters, das Team von äußeren Einflüssen abzuschirmen - auch das hilft dem Team, sich zu entwickeln und gut zusammenzuarbeiten, denn Developer, die nicht gestört werden, arbeiten am produktivsten, was ihre Motivation steigert und ihnen eine positive Einstellung gibt.

Die Stadien der Teambildung nach Tuckman

Wie bereits erwähnt, muss sich ein Team entwickeln, um letztendlich gut zusammenarbeiten zu können. In den 1960er und 70er Jahren entwickelte Bruce Tuckman ein Modell, das die Phasen der Teamentwicklung widerspiegelt. Wie bei jedem Modell kann die Praxis von der Theorie abweichen, aber das Modell hat sich als erste Einführung in das Thema der Teamentwicklung und zum Verständnis grundlegender Verhaltensweisen bewährt.

Zum besseren Verständnis werden im Folgenden die Schritte der Teamentwicklung am Beispiel eines Scrum Teams erläutert. Diese Schritte können selbstverständlich auch auf andere (agile) Teams übertragen werden.

1. Schritt - Forming

Das Team aus interdisziplinären (cross-functional) Developern wird durch den Scrum Master in Abstimmung mit der Stammorganisation - und gegebenenfalls dem Product Owner - gebildet. Es sollen alle Kompetenzen und Kenntnisse für die Bewältigung des Projektes vorhanden sein. In diesem Stadium treffen sich die Teammitglieder zu Beginn des Projektes. Möglicherweise kennt man sich bereits von vergangenen Projekten oder aus dem Unternehmen selbst, möglicherweise kommen auch neue Mitglieder hinzu.

2. Schritt - Storming

Ab jetzt ist es die Aufgabe des Scrum Masters, ein potenzielles Chaos frühzeitig zu verhindern. Hierfür bietet sich ein Teambildungsworkshop an. Alle formellen Anliegen des agilen Projektes können hier thematisiert werden. Es soll aber auch genügend Raum für soziale (informelle) Belange der Developer (Kennenlernen, Teamentwicklung, Wertschätzung für erbrachte Leistungen etc.) vorhanden sein. Möglicherweise ist in dieser Phase auch die Kompetenz des Scrum Masters gefragt, mit Konflikten umgehen zu können und zu schlichten - oder als Mediator tätig zu werden. Durch Identifizierung mit dem Projekt und teambildende Maßnahmen soll die tägliche Arbeit zunehmend verbessert werden. Aber auch jetzt können noch Konflikte auftauchen, die angegangen werden müssen.

3. Schritt - Norming

In dieser Phase nimmt die mögliche Frequenz der Konflikte zwischen den Developern ab, man beginnt, sich aufeinander einzustellen. Aus verschiedenen Teammitgliedern muss zügig ein "Performing Team" werden! Die Identität der Developer ist auf das Projekt ausgerichtet und geschaffen.

4. Schritt - Performing

Im "Performing Team" kann sich jeder auf jeden verlassen, Aufgaben und Rollen sind klar und bedürfen keiner Diskussion. In dieser Phase organisiert sich das Team selbst, der Scrum Master kann sich um andere Belange kümmern (etwa um die Förderung von Scrum im Unternehmen oder um die Bewältigung von Konflikten mit der Linienorganisation). Die Velocity bei der Bearbeitung der Sprints hat einen relativ stabilen und vorhersagbaren Wert erreicht (Bearbeitung einer bestimmten Anzahl von Story Points pro Sprint). Wichtig ist jetzt, dass die Developer ihr Team nicht gegenseitig auseinanderreißen oder Teammitglieder ausgetauscht werden, da ansonsten möglicherweise frühere Phasen der Teambildung erneut durchlaufen werden müssen. Etwaige Versuche aus der Linie, z. B. eines Linienvorgesetzten, in die Teamzusammensetzung einzugreifen, werden als Störungen bewertet und müssen vom Scrum Master angegangen werden.

Was passiert, wenn eine Neubesetzung unerlässlich ist?

Wenn einzelne Teammitglieder das Team verlassen und neue Mitglieder hinzukommen, zum Beispiel, weil Personen das Unternehmen verlassen oder versetzt werden, dann ist eine Veränderung im Team nicht zu vermeiden. Das Scrum Team muss sich an dieser Stelle bewusst sein, dass die Produktivität kurzfristig negativ beeinflusst werden kann. Nun beginnt der gesamte Prozess womöglich wieder mit der ersten Phase. Es ist ratsam, die Fluktuation so gering wie möglich zu halten. Leistungsstarke Teams kehren schnell zu einem zuvor erreichten Leistungsniveau zurück.

5. Schritt - Adjourning

Neigt sich das Projekt dem Ende zu, ist es nach dem Projektabschluss an der Zeit das Team aufzulösen. Hierbei ist wichtig, dass alle Mitglieder ihre Aufgaben beendet haben und die Rollen sowie die Verantwortlichkeiten der Teammitglieder zurückgegeben wurden.

GRPI-Modell nach Richard Beckhard

Neben dem Modell nach Tuckman, welches sich mit dem Teamentwicklung beschäftigt, gibt es noch das GRPI-Modell nach Richard Beckhard. Dies ist ein Vorgehensmodell zur Steigerung der Effektivität der Teamentwicklung und zur Verbesserung des Managements im Allgemeinen. Der Erfolg eines agilen Projektes hängt stark von den Soft Skills der Beteiligten und den Rahmenbedingungen des Projektes selbst ab.

Das GRPI-Modell erlaubt, diese gezielt einzusetzen:

  • G oals: Welche Ziele werden angestrebt und wie werden diese vermittelt?

  • R oles: Rollenfestlegung und -beschreibung - wer ist wofür zuständig?

  • P rocesses: Welche Prozesse finden statt und wie sind die Abläufe?

  • I nterpersonal: Wie steht es um die zwischenmenschlichen Beziehungen?

Goals (Zielentwicklung)

Ziele müssen entwickelt und vermittelt werden. Im Scrum sollten die Developer in vollem Umfang über die geplanten Projektziele informiert werden, sobald das Product Goal erarbeitet wurde und die erste Version des Product Backlogs erstellt worden ist. Dies gilt generell auch für das Umfeld und die Stakeholder. Projekte geraten häufig in Schieflage, weil nicht alle Beteiligten wissen, was geplant ist oder weil Geplantes nicht kommuniziert wird. Daher sollten sowohl Scrum Master als auch Product Owner in ihrem jeweiligen Umfeld sicherstellen, dass die Developer in der Lage sind, auf das gemeinsame Ziel zuzusteuern.

Roles (Rollenfestlegung)

In einem Entwicklungsteam wird zunächst festgelegt, wer welche Aufgaben hat und wofür er zuständig ist (Entwicklung, Test, Architektur, etc.). Bei Problemen oder Fragestellungen ist es ebenfalls eine Teamentscheidung, wer anderen Teammitglieder gegebenenfalls bei ihren Aufgaben hilft (z. B. Tester erklärt Test-Driven Development oder erfahrener Entwickler erklärt Entwicklungsvorgänge bei Pair bzw. Mob Programming). Dabei sollte sich jedes Teammitglied seiner Rolle bewusst und auch bereit sein, diese auszufüllen. Im Scrum ist bei Konflikten der Scrum Master als Moderator oder auch als Coach gefragt.

Processes (Prozesse)

Ein wichtiger Bestandteil ist die Klarstellung, dass Scrum als Framework einen Rahmen vorgibt und damit die Regeln und Abläufe festlegt. Sie müssen eingehalten werden, damit das Vorgehensmodell auch funktioniert. Um das zu gewährleisten, müssen sie entsprechend kommuniziert und untereinander vereinbart werden.

Interpersonal (Zwischenmenschliches)

Zwischenmenschliche Beziehungen sind durch die Fähigkeit geprägt miteinander zu kommunizieren, sich aufeinander einzustellen und in den anderen hineinversetzen zu können. Eine wichtige Hilfe gibt das Sender-Empfänger-Prinzip der Kommunikationslehre: Grundsätzlich besteht jede Kommunikation darin, dass Botschaften gesendet und empfangen werden. Auch besagt das Modell, dass es nicht möglich ist, nicht zu kommunizieren. Denn auch ein Abbruch oder die Verweigerung jedweden Kontaktes sendet ein Signal.

Beim Kommunizieren gibt es Verantwortlichkeiten:

  1. Verantwortungen des Senders: Sicherstellen, dass die Botschaft richtig angekommen ist - durch Nachfragen. Lassen Sie das Gesagt von Ihrem Gegenüber ggf. wiederholen.

  2. Verantwortung des Empfängers: Sicherstellen, dass alles richtig verstanden wurde. Möglichkeiten sind: Botschaft in eigenen Worten wiederholen oder ebenfalls nachfragen, um sicherzustellen, dass alles verstanden wurde.