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.
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 - insbesondere im Hinblick auf die Frage, wie man sich agile Softwareentwicklung vorstellt - bewegen. Aber 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 Gesinnungstäter für die Vision des Produkts heraus. Es gibt, an sich wenig überraschend, punktuell wenig motivierte Mitarbeiter, Mitläufer, fleißige Arbeiter, mehr oder weniger fachlich gefestigte Kollegen, kreative, aber unstrukturierte Spezialisten. Die Liste lässt sich nahezu beliebig fortsetzen. Softwareentwickler zu sein setzt bestimmte Dispositionen voraus, führt aber nicht zu einer Normierung der charakterlichen Eigenschaften.
Die besonderen Dispositionen von Softwareentwicklern überdecken sich auch im allgemeinen Fall nicht vollständig mit den Anforderungen, die an sie in einem agilen Team gestellt werden.
Hier muss der Softwareentwickler fachlich breit aufgestellt sein (über die eigentlichen Softwareentwicklung hinaus z.B. im Hinblick auf automatisiertes Testen und Deployment), er muss kommunikativ sein, er muss Kompromissbereitschaft zeigen, Kritikfähigkeit besitzen, seine Ergebnisse darstellen, 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 ich also nicht erwarten. Wie kann ich dann aber 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.
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 den hohen Passgrad?
Der Lead-Entwickler ist in der Lage, aus der Diversität des Teams Kreativität erwachsen zu lassen. Er gibt ziellosen Diskussionen eine Richtung, er ist kommunikatives Vorbild, 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.
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, Entscheidungen fälschlicherweise nach außen - als Impediment zum Scrum Master -delegiert. Die Fortschrittsgeschwindigkeit bleibt niedrig und es ist sichergestellt, dass technologisch und methodisch keine neuen Wege gesucht werden, die die Zielerreichung womöglich früher und effizienter ermöglichten. Und wenn dies doch der Fall sein sollte, besteht die Gefahr, dass der Treiber eher der „Coolness“-Faktor der neuen Technologie und weniger das Selbstvertrauen im Umgang damit ist.
Auch wenn sich in einem solchen Team eine Hackordnung ausbildet, bei der von außen der Eindruck entstehen könnte, dass so etwas wie ein Lead-Entwickler das Heft in die Hand genommen hat, so wird dieses Bild eher durch größere Extraversion einzelner hervorgerufen, als durch echte, 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.
So gelingt es also, die Zusammensetzung eines leistungsstarken, agilen Team mit real existierenden Menschen: 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.
Keine Kommentare:
Kommentar veröffentlichen