ASPEKTE DER TEAMBILDUNG¶

Das GRPI-Modell nach Richard Beckhard [68] 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 [69].

Das GRPI-Modell erlaubt, diese gezielt einzusetzen:

• G – Goals (Welche Ziele werden angestrebt und wie werden diese vermittelt?)
• R – Roles (Rollenfestlegung und -beschreibung – wer ist wofür zuständig?)
• P – Processes (Welche Prozesse finden statt und wie sind die Abläufe?)
• I – Interpersonal (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 ist 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 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 [70]). Dabei sollte sich jedes Teammitglied seiner Rolle bewusst sein 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 [71] 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 Austausch von Inhalten gibt es Verantwortlichkeiten:

1. Verantwortungen des Senders: Sicherstellen, dass die Botschaft richtig angekommen ist – durch Nachfragen. Gegebenenfalls wiederholen lassen.
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.

Ein wesentliches Element der Arbeit eines Scrum Masters ist die Kenntnis, welche Stadien Gruppen durchlaufen, bis die Developer optimal aufeinander abgestimmt sind (Teambildung). Es gehört zu seinen Aufgaben, zu erkennen, ob es Probleme gibt und falls dem so ist, die Developer durch die verschiedenen Phasen zu begleiten. Dieses Modell (Forming, Storming, Norming and Performing) wurde 1965 von Bruce Tuckman [72] entwickelt und 1977 um den fünften Schritt (Adjourning) erweitert [73].

Agile Teams sind interdisziplinär (cross-functional), das heißt, alle wesentlichen technischen Kompetenzen sind vorhanden, um das Projekt optimal bearbeiten zu können [74][75][76].

Die Developer sollten möglichst während der Projektlaufzeit beisammenbleiben, Mitglieder sollten nicht ausgetauscht werden. Dies ist notwendig, um ein sog. „Performing Team“ [77] zu erhalten und eine möglichst optimale Velocity zu erreichen (siehe Velocity). Dabei obliegt dem Scrum Master der Job des Facilitators (Moderator) im Scrum Projekt, während der Product Owner sich um das Management der Stakeholder kümmert.

Handelt es sich um ein großes Scrum Projekt, können verschiedene Teams von Developern unter der Leitung verschiedener Product Owner arbeiten, die Gesamtverantwortung trägt in diesen Fällen der übergeordnete Chief Product Owner.

Die Stadien der Teambildung:¶

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 der Förderung von Scrum im Unternehmen oder der 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 austauschen, da ansonsten möglicherweise frühere Phasen der Teambildung erneut durchlaufen werden müssen. Etwaige Versuche aus der Linie, in die Teamzusammensetzung einzugreifen, werden als Störungen bewertet und müssen vom Scrum Master angegangen werden.

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.

Das „Performing Team“¶

Das Performing Team – was ist darunter zu verstehen? Worauf genau sollte der Scrum Master achten, wenn er sein Team coacht? Und woran erkennt man gute Performance?

In der Literatur werden teilweise sehr unterschiedliche Konzepte diskutiert, wie diese Frage zu beantworten ist. Motivation und Arbeitszufriedenheit haben in der Regel die folgenden Voraussetzungen [78][79]:

• Teams und die Mitglieder im Team haben das Gefühl, eine wichtige und wertvolle Aufgabe und Arbeit zu leisten.
• Die Verantwortung ist weitgehend an sie übertragen.
• Sie haben Entscheidungsfreiheit.
• Es besteht kein Mikromanagement durch Vorgesetzte.

Unter hoher Performance ist die grundsätzlich die erfolgreiche, zielgerichtete Erfüllung einer Aufgabe oder eines Prozesses zu verstehen. Performing Teams liefern gute Arbeitsergebnisse aus und sind bei ihrer Zusammenarbeit erfolgreich. Überträgt man dieses Kriterium auf Scrum, so wären die Faktoren unter anderem [80][81]:

• Erfolg in der Umsetzung gesetzter Ziele und Aufgaben innerhalb der Sprints.
• Effektive Lösung von Problemen bei der Erarbeitung der Aufgaben (Tasks).
• Gemeinsam geteiltes Verantwortungsbewusstsein und effiziente Selbstorganisation.
• Zufriedenheit des Kunden oder Auftraggebers (in einem Scrum Team: Product Owner oder auftraggebende Instanz(en) im Unternehmen).

Welche Eigenschaften haben diese Teams und auf welche Faktoren sollte der Scrum Master bei der Teamentwicklung achten[82]?

• Effektive Entscheidungsfindung durch Anwendung eine Mischung rationaler, intuitiver und auch kreativer Methoden.
• Zielorientierter Umgang mit und Lösung von Konflikten innerhalb des Teams.
• Erfolgreiche und zielgerichtete Selbstorganisation.
• Offenes und konstruktives Kommunikationsverhalten.
• Hoher Grad an gegenseitigem Vertrauen.
• Konstruktive und positive Atmosphäre.

Grundsätzlich gilt, dass im Team keine Führungsrollen, oder jedwede andere Art von Rollen (leitender Entwickler o.ä.) vergeben werden. Das Team ist in allen Belangen gemeinschaftlich für den Arbeitserfolg verantwortlich. Allerdings können sich die Teammitglieder untereinander differenzieren, was auch von den unterschiedlichen Persönlichkeiten abhängen kann. So bilden sich nach einer gewissen Zeit – zwischen der Storming- und der sich dann abzeichnenden Normingphase (siehe Teamentwicklung [83][84]) – auch informelle Rollen heraus.

Es existieren unterschiedliche Persönlichkeitsmodelle (z. B. die Teamrollen nach Belbin [85] oder das Enneagramm [86]), welche je nach Situation eingesetzt werden können.