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?

Lerne jetzt in unserem Videokurs die Grundlagen der Agilität kennen!

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.

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.

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.

Eine weitere wichtige Voraussetzung für den Erfolg eines großen Teams ist – neben einer reibungslosen Arbeitsorganisation – auch die die Schaffung einer angenehmen Arbeitsatmosphäre. Großraumbüros sind ein Weg, den Austausch untereinander zu fördern. Allerdings bergen diese bei unterschiedlichen Persönlichkeiten auch einige Herausforderungen. Unterschiedliche Vorstellungen von Lautstärke oder der optimalen Temperatur können so zum alltäglichen Problem werden. Um Missverständnisse frühzeitig aus dem Weg zu räumen und Lösungen zu finden, muss eine gemeinsame Ebene gefunden werden. Da jedes Team individuell ist, gibt es aber leider keine allgemeingültige Formel, wie Probleme am besten gelöst und Kompromisse verhandelt werden können. Auch hier ist die Retrospektive ein geeignetes Mittel, um Lösungen zu erarbeiten. Auf diese Weise lassen sich Scrum und andere agile Vorgehensweisen perfekt auf das Team maßschneidern.

Viele Entwickler verderben also keineswegs den Brei, wenn eigene Wege und Mittel gefunden werden, um einen effizienten Austausch zu gewährleisten.

Ebenfalls spannend:

• Mehr als nur Preisgeld: Diese Gründerwettbewerbe solltest du kennen
• Diese 5 Soft-Skills steigern deine Erfolgschancen in der digitalen Arbeitswelt
• Digital Leadership: Mit OKRs Agilität erzeugen