Studie: Agiles Team­work ist erfolg­rei­cher als klas­si­sche Zusam­men­ar­beit

Ein Team ist nicht mehr als die Summe seiner einzelnen Mitglieder, oft sogar viel weniger. Dass Team­ar­beit fälsch­li­cher­weise heroi­siert wird zeigen diverse Studien, etwa die berühmte Unter­su­chung „The Romance of Teams“ aus dem Jahr 2004. Danach behin­dert Team­ar­beit den Infor­ma­ti­ons­fluss, die Krea­ti­vität und fördert außerdem noch die sehr lästige Selbst­be­stä­ti­gungs­ten­denz, der schon Indi­vi­duen verfallen (man sucht in allem Bestä­ti­gung für die eigene Über­zeu­gung und blendet andere Infor­ma­tionen aus). Über das gefähr­liche Groupt­hink hat neulich Spiegel Online in “Gemeinsam sind wir dumm” geschrieben.

Für unsere Anfang nächsten Jahres erschei­nende “Team­bibel” war ich auf der Suche nach Beweisen, dass agile Tech­niken einige der schlimmen Auswir­kungen mildern oder gar ins Gegen­teil verkehren können und bin fündig geworden. Ich bin auf eine Studie gestoßen, die ich Ihnen nicht vorent­halten möchte. Sie ist schon etwas älter, von 2008, und heißt „Making Soft­ware Teams Effec­tive: How Agile Prac­tices lead to Project Effec­ti­ve­ness through Socio-psycho­­lo­­gical mecha­nisms“. Kurz gesagt, die Studie belegt, dass die inten­sive und struk­tu­rierte Kommu­ni­ka­tion im agilen Umfeld den Wissens­zu­wachs im Team und damit den Projekt­er­folg stei­gert. Dazu muss man wissen, dass eines der größten Probleme bei der Team­ar­beit das unge­teilte Wissen ist, das heißt in Meetings reibt man norma­ler­weise nur die gemein­samen Schnitt­stellen aneinan. Der est geht über Bord — und versinkt.

Was aber passiert da bei der agilen Team­ar­beit? In der Bera­tung habe ich öfter Kunden aus der Soft­ware­branche und bin faszi­niert über die Art und Weise, wie hier Zusam­men­ar­beit prak­ti­ziert wird. Sie unter­scheidet sich funda­mental von der Team­ar­beit in anderen Bran­chen. Eckpunkte sind abso­lute Fehler­to­le­ranz, itera­tives Planen und so genanntes „Pair programming“, also ein paar­weises Program­mieren, bei der erfah­rene Program­mierer ihr Wissen an weniger erfah­rene weiter­geben. Allein letz­teres ist bemer­kens­wert, wenn ich immer noch Aussagen wie diese höre:

„Unser Chef achtet darauf, dass genü­gend Konkur­renz unter­ein­ander besteht, auch indem extra nicht alle Infor­ma­tionen auf den Tisch kommen. Er hat das auf einem Führungs­se­minar gelernt.“

Trainer, die so etwas lehren, gehören meiner Meinung nach einge­sperrt 😉

Ein weiteres Charak­te­ris­tikum sind so genannte Standup-Meetings, die nach einem festen Plan ablaufen. Sie dauern 15 Minuten und finden im Stehen statt. Jeder gibt Auskunft darüber, was er seit dem letzten Meeting getan hat, was er plant zu tun und was ihn bei der Arbeit behin­dert. Sich daraus erge­bender weiterer Gesprächs­be­darf wird in Einzel­ge­sprä­chen geklärt. Agiles Team­work ist also gekenn­zeichnet durch klare und vorge­ge­bene Kommu­ni­ka­ti­ons­struk­turen, die den Infor­ma­ti­ons­aus­tausch fördern, und es nicht zulassen, dass einer domi­niert, ausschert oder blockiert.

Zur Studie: Sie analy­siert die posi­tiven Auswir­kung agiler Prak­tiken auf den Wissens­zu­wachs, das Verhalten und die Kommu­ni­ka­tion im Team. Nach der Ziel­set­zungs­theorie von Locke und Latham aus dem Jahr 2002 wird die Ziel­er­rei­chung wesent­lich durch die Ziel­bin­dung, also durch Commit­ment bestimmt. Die Studie zeigt, dass durch agile Prak­tiken das Commit­ment steigt. Die Bereit­schaft zur Koope­ra­tion erhöht den Wissens­zu­wachs, der wiederum den Projekt­er­folg mitbe­stimmt.

Ich finde hieraus lassen sich einige Punkte ableiten, die nicht nur für Soft­ware­teams rele­vant sind:

• Fehler­to­le­ranz ist die Grund­lage für Denk-Krea­­ti­­vität. Menschen können nur neue Wege beschreiten, wenn sie sich dabei irren dürfen. Ist in Ihrem Team keine offene Fehler­kultur vorhanden, gilt es diese zu schaffen. Einzel­per­sonen können an Ihrer eigenen Fehler­to­le­renz arbeiten, indem Sie einfach mal mit einer neuen unbe­kannten Soft­ware üben: Klicken, Fehler machen, sich NICHT ärgern, lernen… Diese Vorge­hens­weise fördert meta­ko­gni­tive Prozesse (verein­facht ausge­drückt die Selbst­re­flek­tion) und wirkt positiv auf den Umgang mit eigenen Fehlern.
• Der struk­tu­rierte Wissens­aus­tausch sollte zum Team­alltag gehören. Jour Fixes einmal die Woche sind zu wenig. Lieber kurze Bespre­chungen. Diese im Stehen abzu­halten, ist keine schlechte Maßnahme. Und die klare Struktur in drei Teilen wie oben beschrieben, hilft zu verhin­dern, dass man sich fest­quatscht.
• Wer Erfah­rung weiter­geben kann, fühlt sich oft stolz und sinn­voll. Nur in Umge­bungen, die Konkur­renz und Angst schüren, wird Erfah­rung gehortet. Eine der wich­tigsten Maßnahmen ist also die Einstel­lung zu ändern. Ist dies passiert, kann „pair programming“ auch Vorbild für andere Branche sein.

Wer mehr über Teams erfahren will, lese unser unro­man­ti­sches E‑Book “Ich hasse Team­ar­beit” — oder warte auf die Team­bibel. Und wo wir beim MINT-Thema sind, möchte ich auf das Inter­view mit Susanne Kaiser von Just Soft­ware hinweisen. Dort wird auch agil geteam­workt. Last not but least, empfehle ich agilen Inter­es­senten meinen Beitrag über Netz­werk­or­ga­ni­sa­tionen.