„Wir machen uns um Onkel Henry furchtbare Sorgen. Er denkt, er sei ein Huhn.“
„Na, warum schicken Sie ihn denn nicht zum Arzt?“
„Naja, das würden wir ja. Aber wir brauchen die Eier.“
— Douglas Adams: Der lange dunkle Fünfuhrtee der Seele: Dirk Gently’s Holistische Detektei
Agile Methoden setzen auf das Team, nicht auf die Individuen. Alles soll das Team entscheiden, alles soll das Team gemeinsam machen. Von Pair über Mob Programming, die meisten Dinge lasten auf mehr als einem paar Schultern. Als Metapher hat man sogar den Bus-Faktor gefunden: Wie viele Leute aus dem Team muss ich mit dem Bus überfahren, bis die Software nicht mehr weiterentwickelt werden kann?
Einzelkämpfer bevorzugt
Trotzdem haben wir sehr gerne Einzelkämpfer in unseren agilen Teams. Das hat mehrere Gründe:
- Klassische Arbeitsorganisationsstrategien steuern über klare, verbindliche und individuelle Aufgaben: Verantwortung wird nur da übernommen, wo jemand sie aktiv bekommen und auch angenommen hat. Man hofft nicht darauf, dass eine Aufgabe aus Versehen erledigt wird, sie braucht eine Adresse, an der sie gut aufgehoben ist. Ich kenne das gut aus der eigenen Arbeit: „Da muss jemand den Hut aufhaben, sonst passiert da nichts.“ Meist hat man sogar die Erfahrung, dass bei unklarer Verantwortlichkeit lieber stillgehalten als proaktiv gestaltet wird.
- Wir Entwickler sind da nicht besser: Wir mögen den individuellen Erfolg und das daraus resultierende Ansehen, es ist uns wichtig. Das wurde uns von Dan Pink legitimiert – natürlich streben wir nach Autonomy, Purpose und Mastery – und die kann man am besten alleine machen, denn sobald Kollegen dabei sind, verwässert es. Und viele Strukturen in Ingenieursorganisationen orientieren sich an meritokratischen Konzepten: Gebe die Verantwortung demjenigen, der in der Vergangenheit schon gezeigt hat, dass er es gut kann.
- Es freut auch den betrieblichen Optimierer. Denn wer macht eine Aufgabe am schnellsten? Der, der sich am besten damit auskennt. Andere Leute setze ich nur dann an die Aufgabe, wenn es noch keinen Spezialisten gibt, der sich darum kümmern kann. Und durch diesen Fokus habe ich am Ende eine Organisation, bei der jeder genau das macht, was er am besten kann.
… trotzdem sagt uns das Agile Manifest, dass die besten Ergebnisse aus einem selbstorganisierten Team stammen.
Eine Frage der Qualität
Wer selbst seit langem Software macht, dem ist klar, warum es so sein muss:
Software ist zu groß für ein Gehirn alleine; ich kann nicht alle Abhängigkeiten überblicken. Trotzdem arbeite ich mit ihnen. Ich bin davon abhängig, was die Kollegen machen und wirke auf das, was sie in Zukunft machen werden.
In solchen Welten ist es offensichtlich, dass durch die Vernetzung die Qualität steigt, wenn man nicht alleine agiert. Pair Programming erzeugt mehr Funktionalität auf Zeit als zwei Personen, die parallel entwickeln. Ein High-Performance-Team kann bequem das Zehnfache des Durchsatzes einer gleich großen Gruppe von Leuten schaffen.
… aber wir brauchen die Eier.
Dennoch findet man in vielen Teams und vielen Firmen noch Einzelkämpfer.
Die außerhalb des Sprints arbeiten. Die Spezialaufgaben bekommen. Die alleinverantwortlich für Bereiche sind. Deren Code nicht angerührt werden darf, weil nur sie verstehen, was dort passiert. Deren Wort für bestimmte Themen gilt, ohne dass es angefochten oder diskutiert werden darf.
Und immer, wenn man mit den Personen, den Kollegen und den Vorgesetzten redet, bekommt man gute Gründe, warum es ist diesem Fall sinnvoll ist.
„Natürlich könnten wir das auch im Team machen. Aber wir brauchen die Eier.“
[smartblock id=“7056″]Unsere Serie Agile Missverständnisse
Schreibe einen Kommentar