Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Analyse

Große agile Teams: Verderben zu viele Entwickler den Brei?

(Foto: Shutterstock)

Stellt euch vor, ihr seid ein mittelständisches, junges Unternehmen. Ihr hört von einer spannenden Ausschreibung. Super! Ihr baut einen Prototyp mit einem kleinen Team und ihr bekommt den Zuschlag. 

Ein Jahr Laufzeit und der Kunde hat konkrete Vorstellungen bei welchen wichtigen Terminen die Software bereits einsetzbar sein sollte. Kein Problem, ihr wollt ja sowieso agil vorgehen und immer ein lauffähiges Stück Software ausliefern. Ihr braucht allerdings ein größeres Team.

Zu Projektbeginn besteht unter anderem die Herausforderung, ein passendes Team zu bilden. Wie viele Personen werden gebraucht, damit das Projekt den zeitlichen Rahmen einhalten kann, aber dennoch wirtschaftlich bleibt? Nehmen wir an, ihr habt festgestellt, dass ihr mindestens 15 Entwickler braucht, um das Projektziel zu erreichen. Können diese 15 Entwickler dann wirklich in einem großen Team zusammenarbeiten? Schon im Scrumguide von Jeff Sutherland und Ken Schwaber wird eine deutlich kleinere Teamgröße von bis zu neun Teammitgliedern empfohlen. Wie findet in größeren Teams also ein sinnvoller Austausch statt? Und wie kann dies effizient funktionieren?

Kontinuierlicher Wissenstransfer als Erfolgsfaktor

Vielmehr sollte das Wissen kontinuierlich und verteilt im Team weitergegeben werden.

Neben der Größe spielen in einem modernen Arbeitsumfeld auch Faktoren wie unterschiedliche Arbeitszeitmodelle, unterschiedliche Wissensstände und insbesondere die Work-Life-Balance eine wichtige Rolle. Ein Schritt in die richtige Richtung ist die Vermeidung von Truckfaktoren und Wissensinseln. Dies wird durch einen stetigen Wissenstransfer erreicht. Im agilen Manifest steht geschrieben: „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation“. Dabei ist es wenig sinnvoll, auf eine einzige Wissensquelle zuzugreifen. Vielmehr sollte das Wissen kontinuierlich und verteilt im Team weitergegeben werden.

Eine Methode, um einen solchen Austausch zu realisieren, ist das Pair Programming, das seinen Ursprung in Xtreme Programming (XP) hat. Dabei arbeiten zwei Entwickler gemeinsam an einer Aufgabe. Auf diese Weise wird bei wechselnden Pairing Partnern das Wissen kontinuierlich im gesamten Team verteilt.

Die Retrospektive hilft großen agilen Teams

Scrum selbst bringt auch einige Kern-Elemente zur Synchronisation eines Teams mit. Doch reichen diese sogenannten Ereignisse aus, um ein großes agiles Team lebendig und produktiv zu halten? Ein zentraler Bestandteil der Scrum-Spielregeln ist die Retrospektive. Sie ist vielleicht die einzige Möglichkeit, sich selbst als Team kritisch zu durchleuchten und weiterzuentwickeln. Sie bietet Gelegenheit zum direkten Austausch und auch für Kritik: Was lief super und was lief gar nicht gut? Vor allem aber auch: Wo fühlt es sich für einzelne Teammitglieder nicht gut an?

Die Retrospektive bietet zudem Raum, diese Dinge aktiv zu ändern, Methoden auszuprobieren und sie möglicherweise wieder zu verwerfen – wirklich agil eben. So kann eine Retrospektive weitere Wege und Mittel zum Vorschein bringen, die ein großes agiles Team braucht, um zum Beispiel den Wissenstransfer zu gewährleisten. Es lohnt sich, Themen zu identifizieren, für die dem Team mehr Zeit eingeräumt werden muss. Dabei soll aber trotzdem der Kommunikations-Overhead möglichst gering gehalten werden.

Ein solches Thema ist zum Beispiel die Konzeption von User-Stories. Hier hilft eine explizite Konzeptionsphase. Ein Treffen zu Beginn des Sprints, bei dem in kleineren Gruppen User-Stories so weit konzipiert werden, dass sowohl fachlich als auch technisch eine gemeinsame Richtung in der Entwicklung bekannt ist. Die Gruppen stellen die Konzepte den restlichen Teammitgliedern im Anschluss vor. So erhält das gesamte Team den Blick für die große Vision, aber nicht jeder muss jedes kleinste Detail kennen.

Architekturpflege für mehr Durchblick

Bedarf für weitere Maßnahmen kann es auch an anderen Stellen geben: Beispielsweise ist die Architektur der Software in einem großen Team aktiv zu pflegen. Um technische Schulden zu vermeiden und bestehende Probleme frühzeitig zu beseitigen, muss der Softwarearchitektur besondere Aufmerksamkeit geschenkt werden. Gerade in Teams mit zum Teil unerfahrenen Entwicklern kann ein uneinheitliches Verständnis der Architektur schnell zu schmerzhaften, langfristigen Problemen führen. Hier kann eine Architekturbesprechung pro Sprint helfen. Bei diesem Termin werden Lösungen gemeinsam entwickelt und grundsätzliche Architekturvorstellungen im gesamten Team verankert. Unserer Erfahrung nach haben sich – über die beschriebenen Termine hinaus – zum Beispiel auch regelmäßige Designbesprechungen bewährt.

Bitte beachte unsere Community-Richtlinien

Eine Reaktion
Christian

Einem vielversprechendemTitel folgt ein Text aus Quellen zusammengeschrieben ohne auch nur den roten Faden zu erkennen zu können.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.