Jedes agile Team braucht einen Lead-Entwickler

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.

Jedes agile Team braucht einen Lead-Entwickler

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.

Wir empfehlen zum Thema Agile
3 x 4 Stunden
07.11.2024
1.295,00,-
User Story Mapping - Die Nutzer im Blick mit der Produkt-Landkarte

Stellen Sie Kundenanforderungen – ohne endlose Dokumentationen – strukturiert dar und behalten Sie mit diesem Seminar die Kontrolle über den gesamten Entwicklungsprozess. Mit vielen Praxisübungen und direkt anwendbar. Mehr Infos

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.

Für jeden Bedarf die passende Mitgliedschaft

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (3)

Guest

Der Realismus tut gut. Als jemand, der 1967 immatrikuliert hat und die 68-iger, Flower-Power, Gruppendynamik etc. miterlebt und mitgemacht hat, stehe ich jeder selbststeuernden Organisation nach wie vor positiv gegenüber, aber auch hier ist zuviel an Prinzipienorientierung schädlich. Wenn es hierchiefrei gut funktioniert, super, aber wenn nicht muss jemand den Mut haben, einzugreifen. Dafür werden Manager engagiert und bezahlt. Als Kunde kann ich erwarten und fordern, dass ein Unternehmen zuverlässig und daher wiederholbar funktioniert. Der Lösungsansatz eines Lead-Entwicklers bzw. einer Lead-Entwicklerin (hier muss gendern sein ;-) ist sehr vernünftig.

 

Guest

Letztlich nur ein Argument von vielen, wieso Scrum in der Realität angeblich nicht funktioniert (und lässt man das selbstorganisierte Team weg, ist's kein Scrum mehr). Dass das Militär etwas kann, was Unternehmen nicht können, scheint mir eine etwas verklärte Sicht auf's Militär zu sein. Auch dort ist nicht alles voller Eliteeinheiten. Um ein Team zu bilden kann man auswählen und üben. Das ist in Unternehmen auch nicht anders. Hat man unqualifiziertes Personal an Bord, hilft auch ein Lead-Entwickler nicht. Wie soll er (oder sie) das ausgleichen? Vielleicht in Nachtarbeit? Bildet ein Team eine "Hackordnung" ist es längst kein Team mehr. Und wenn man sich mit "Eitelkeiten", "Grabenkämpfen" und "Frontenbildungen" beschäftigt, kriegt man auch nichts mehr fertig. Teaminterne Hierarchien, die von außen installiert werden (z.B. Lead Entwickler) dürften das befördern. Dass es in Scrum keine laterale Führung gibt, ist übrigens falsch. Der Scrum Master hat die Rolle des servant leader und coach. Das Hauptproblem dürfte allerdings sein, dass es den hier beschriebenen Lead Entwickler gar nicht gibt (hohe intrinsische Motivation für was genau bitte?). Er ist ein Wunschbild des Autors, das man nicht recruiten kann. Dafür ist Teamdynamik viel zu komplex. Nimmt man via Lead Entwickler den anderen Teammitgliedern die Verantwortung ab, werden die sich dankend aus dem Mitdenken verabschieden. Was dann vermutlich als charakterliche Schwäche ausgelegt wird. Gott bewahre mich davor, dass ich mal in ein Team gerate, in dem es "normierte charakterliche Eigenschaften" gibt. Das ist ja von vornherein zum Scheitern verurteilt. Fazit: Management 0.8 beta.

 

Guest

Welche Charaktere braucht ein gutes Team? Die besten Ergebnisse erzielt ein Team, in dem neun verschiedene Rollen (?)besetzt sind: gemäss ZEIT Wissen Nr. 03/2015 "Welche Charaktere braucht ein gutes Team?" / "Wie muss ein gutes Team denn nun sein? Für Heterogenität spricht: je bunter die Gruppe, desto unterschiedlicher das Know-how, desto besser die Leistung. Für Homogenität spricht: Gleich und gleich gesellt sich gern, und wer sich wohlfühlt, übernimmt Verantwortung und engagiert sich für sein Team. Die Meinungen der Forscher gehen jedoch auseinander. Denn zunächst müssen Homogenität und Heterogenität in zwei Bereiche eingeteilt werden, sagt Eric Kearney, Professor für Führung, Organisation und Personal an der Universität Potsdam. Zum einen in rein demografische Spezifika, wie Alter, Geschlecht und Nationalität. Zum anderen in Persönlichkeitsmerkmale. "Man kann zumindest sagen, dass es Eigenschaften gibt, die in einer Gruppe unterschiedlich stark vertreten sein sollten." Sind zum Beispiel zu viele Teammitglieder extrem extrovertiert, also sehr dominant, kann das eine gute Zusammenarbeit ebenso verhindern wie zu viele introvertierte Personen im Team. "Gewissenhaftigkeit hingegen sollten alle Mitglieder gleichermaßen haben", sagt Kearney." > Die Ergebnisse sind in der Studie Reading the Mind in the Eyes or Reading between the Lines? nachzulesen. Wie sich Gruppen in Extremsituationen verhalten, beschreibt die Studie National Diversity Under Pressure: Group Composition and Expedition Success in Himalayan Mountaineering. Teams aus heterogenen Kulturen und aus homogenen Kulturen traten im Experiment von Eliot Sherman und Jennifer Chatman gegeneinander an, um die Bergspitze zu erreichen.<