Folgt man den Grundideen von Scrum, stellt sich das Entwicklungsteam als eine soziale, extrem leistungsfähige Struktur dar, in der es weder eine hierarchische noch eine laterale Führung gibt. Dies wird sogar als wesentlich betrachtet.

Führt man sich die Herkunft von Scrum vor Augen, so ist das auch nachvollziehbar. Jeff Sutherland, einer der Urväter von Scrum, stammt – wie er auch gerne in seinen Vorträgen betont – aus militärischer Schule. Die Teammitglieder in einem Scrum-Team werden, vergleichbar mit militärischen Eliteeinheiten, als erstklassig ausgebildete Spezialisten betrachtet, deren Kompetenzprofile so aufeinander abgestimmt sind, dass sie ideal miteinander harmonieren.

Die Teammitglieder – ausschließlich aneinander gebunden durch die Vision dessen, was sie gemeinsam aufbauen sollen – stehen jeder für sich und wirken trotzdem konstruktiv und sich gegenseitig ergänzend auf das gemeinsame Ziel hin. Ohne Eitelkeiten, Grabenkämpfe, Frontenbildungen.

Aber lässt sich das in einem Unternehmen wirklich abbilden? Die Antwort ist ganz eindeutig: Nein!

Heterogenität ist unvermeidbar

Wenn die Entwicklungsorganisation eine Größe von ein bis zwei Dutzend Mitarbeiter nicht überschreitet und das Wachstum der Organisation bis zu dieser Grenze langsam und kontinuierlich war, ist es möglich, dass die Teammitglieder sich durch einen handverlesenen, zentralisierten Auswahlprozess noch auf einem relativ homogenen Kompetenzstand und einem vergleichbaren Verständnis von der Kultur des Unternehmens bewegen – insbesondere im Hinblick auf die Frage, wie man sich agile Softwareentwicklung vorstellt. Aber mit zunehmender Unternehmensgröße es tritt zwangsläufig der kritische Punkt ein, an dem sich Heterogenität in die Mitarbeiterschaft einschleicht.

Setzt man nun Teams zusammen, muss man unterschiedlichste Charaktere einbinden – denn nicht jeder Softwareentwickler stellt sich als Gesinnungstäter für die Vision des Produkts heraus. Es gibt punktuell wenig motivierte Mitarbeiter, Mitläufer, fleißige Arbeiter, mehr oder weniger fachlich gefestigte Kollegen, kreative, aber unstrukturierte Spezialisten usw. Die Liste lässt sich nahezu beliebig fortsetzen.

Software-Entwickler zu sein setzt zwar bestimmte Fähigkeiten voraus, führt aber nicht zu einer Normierung der charakterlichen Eigenschaften. Zudem überdecken sich die Fähigkeiten von Software-Entwicklern auch im allgemeinen Fall nicht vollständig mit den Anforderungen, die an sie in einem agilen Team gestellt werden.

Die Anforderungen sind hoch

Im agilen Kontext muss der Software-Entwickler über ein breites Fachwissen verfügen (über die eigentliche Entwicklung hinaus z.B. im Hinblick auf automatisiertes Testen und Deployment), er muss kommunikativ sein, er muss Kompromissbereitschaft zeigen, Kritikfähigkeit besitzen, seine Ergebnisse darstellen können, kundenzentriert denken (in Abgrenzung zu einer Technikzentrierung) und Eigenverantwortung übernehmen. Die Anforderungen sind extrem hoch und kaum durch die Mehrheit aller Mitarbeiter abzudecken.

Einen Fundus an Entwicklern, die diesem Idealbild entsprechen, darf man also nicht erwarten. Wie lässt sich aber dann ein erfolgreiches agiles Team bilden?

Wenn ich das Ideal mit der Realität in der Teambildung vergleiche, so ist es wie bei dem Computerspiel Tetris: Ich habe als herunterfallende Steine nur homogene, rechteckige Blöcke (meine perfekten Softwareentwickler) zur Verfügung. Dann ist es einfach meine Zielstruktur (das erfolgreiche Team) zu bilden. In der Realität sind es jedoch vielfältig geformte Elemente (die real existierenden Softwareentwickler), die zu meiner Zielstruktur kombiniert werden müssen. Und die Erfahrung zeigt (auch bei Tetris): Manche Elemente sind flexibler kombinierbar als andere und finden sich nahezu zwangsläufig als Teilelement in jeder Zielstruktur wieder.

Das flexible Element: der Lead-Entwickler

Kehrt man von diesem Bild zurück in die Realität, gibt es eine Entsprechung zu dem Element, welches flexibler kombinierbar ist als die anderen und sich in nahezu jeder (erfolgreichen) Zielstruktur wiederfindet: dies ist der Lead-Entwickler. Was zeichnet ihn aus, wodurch gewinnt er diese hohe Passgradgenauigkeit?

Der Lead-Entwickler ist in der Lage, die Diversität des Teams zu nutzen, um kreative Lösungen zu finden. Er gibt ziellosen Diskussionen eine Richtung, er ist kommunikatives Vorbild und er verfügt über eine höhere, intrinsische Motivation. Er bildet sich permanent fort und hat so auch ein hohes fachliches Ansehen im Team.

Junge Entwickler orientieren sich am Lead-Entwickler und profitieren von seinem Wissen. Finale Entscheidungen über Architektur und Vorgehen fallen in letzter Instanz ihm zu – nicht weil er deklariert, sondern weil er am Ende Verantwortung übernimmt. Gleichzeitig akzeptiert er das Spezialistentum der anderen Teammitglieder und bindet es erfolgreich zur Erreichung des gemeinsamen Ziels ein.

Warum ein Leitwolf wichtig ist

Aber warum ist er so wichtig für ein erfolgreiches Team? Dies erklärt sich durch Abgrenzung: Fehlt ein solcher Charakter, verliert das Team an Dynamik. Diskussionen werden nicht abschließend geführt und Entscheidungen fälschlicherweise nach außen – als Impediment zum Scrum Master – delegiert. Die Fortschrittsgeschwindigkeit bleibt folglich niedrig und es ist sichergestellt, dass technologisch und methodisch keine neuen Wege gesucht werden, um Ziele früher und effizienter zu erreichen.

Auch wenn sich in einem solchen Team eine Hackordnung ausbildet, bei der von außen vielleicht der Eindruck entstehen könnte, dass bei einer bestimmten Entscheidung so jemand wie ein Lead-Entwickler das Heft in die Hand genommen hat, so entsteht dieses Bild eher durch das größere Geltungsbedürfnis einzelner Teammitglieder als durch eine real vorhandene laterale Führungskompetenz. Im Ergebnis reagieren die anderen Teammitglieder hierauf mit inneren Widerständen, was zu Spannungen innerhalb des Teams führt und damit die Fortschrittsgeschwindigkeit zusätzlich reduziert.

Als kleine Faustregel für die Zusammensetzung eines leistungsstarken, agilen Teams lässt sich also festhalten: Man achte auf die Zusammensetzung und füge immer einen Lead-Entwickler hinzu! Damit ist ein wichtiger Baustein für den Erfolg des Teams bereits gelegt.