cartoon_highperformanceteamsAktuell liest man wieder sehr viel zu dem Thema, wie man aus durchschnittlichen Teams echte High-Performance-Teams machen kann. Einiges dabei liest sich wie eine Anleitung für den aufstrebenden Fabrikbesitzer aus den Zeiten der industriellen Revolution, anderes wie eine Anleitung für einen Räucherstäbchen- und Trommelkreis. Wo liegt denn jetzt die Wahrheit?

Die ganz kurze Antwort: wahrscheinlich irgendwo dazwischen, aber nicht unbedingt auf halber Strecke. Als Google seine Findings aus dem Projekt Aristoteles veröffentlicht hatte, in dem sie danach geforscht hatten, was ein hochperformantes Team ausmacht, schienen alle von den Erkenntnissen vollkommen überrascht, was ich nicht wirklich verstehen kann. Nichts an diesen Dingen ist wirklich neu. Die Psychologier weiß schon seit längerer Zeit um die Bedeutung von Psychological Safety, was jedoch nicht bedeutet, dass die Arbeit von Google an dieser Stelle nicht wichtig gewesen sein soll. Ganz im Gegenteil: es ist ihnen gelungen, diese wichtigen Punkte der Teamentwicklung einem breiten Publikum zugänglich zu machen. Allein dafür gebührt ihnen mein tiefster Respekt und meine Dankbarkeit.

Wenn ich mir die Frage stelle, wie ein Team hochperformant werden kann, muss ich mir zunächst natürlich im klaren darüber sein, was ich damit eigentlich meine. Gefragt ist also eine Begriffsdefinition von »hochperformant«. Der Duden kennt diesen Begriff nicht. Andere Quellen nennen es ein »Unwort«, eine Übertreibung von leistungsfähig.

Wonach suchen wir also? Nach besser als gut? Nach leistungsfähiger als leistungsfähig? Schwierig. Noch schwieriger, wenn ich mich frage, wonach ich dieses nicht existierende Attribut bewerten soll. Was ist meine Vergleichsgröße?

Bevor Sie sich jetzt fragen, was ich für komische Pilze gegessen habe, dass ich Ihnen plötzlich mit einer so schrägen Begriffsdefinition und der Kritik daran komme, breche ich das lieber ab. Unter »hochperformant« werden oftmals Teams gelistet, die in sie gesetzte Erwartungen übererfüllen. Lassen wir es vorerst darauf beruhen, auch wenn uns klar sein sollte, dass dann nach kurzer Zeit die Erwartungen soweit ansteigen dürften, bis das Team nicht mehr überperformt (dieses Wort ist so schrecklich, dass ich schon vom Tippen Gänsehaut bekomme).

Beschränken wir uns also der Einfachheit halber auf die Frage, wie es uns gelingen kann, unsere Teams besser und leistungsfähiger zu machen. Die Vergleichsgröße ist das Team selbst. Wir vergleichen es nicht mit anderen, wir vergleichen es mit sich selbst zu einem anderen Zeitpunkt. Ein Indikator (aber bittebittebitte nicht der einzige) kann dabei die Velocity sein. Ich würde allerdings auch dringend dazu raten, weitere weiche Faktoren hinzuzuziehen, z.B. die Komplexität der gelösten Probleme oder die Effizienz der In-Team-Kommunikation (reden wir endlos, um irgendwann zu einer Lösung zu kommen?). Ich halte die Bewertung eines Teams allein nach der Velocity für sehr schwierig, auch wenn das sicherlich ein wichtiger Aspekt ist. Arbeite ich an einer hochkomplexen Problemstellung, die viel Recherche, Abstimmung und Refinement erfordert, geht die Velocity in den Keller. Das ist ganz natürlich und auch vollkommen in Ordnung. Dennoch kann in gerade diesen anspruchsvollen Phasen das Team hocheffizient zusammenarbeiten, während es in anderen Phasen, in denen mehr Fleißarbeit gefragt ist, kaum in irgendeiner Weise hervorstechen kann. Auch dysfunktionale Teams können bei einfachen Aufgaben viel schaffen, weil wenig Abstimmung und Kommunikation notwendig ist.

Und genau hier komme ich auf den wichtigsten Punkt: Kommunikation. Wir erkennen ein gut funktionierendes Team immer daran, wie die Personen miteinander sprechen, und wie oft sie miteinander sprechen. Genau hier finde ich meinen Ansatzpunkt, der immer der richtige und wichtige ist, wenn es darum geht, ein Team besser zu machen. Stellen Sie sich das aber nicht zu einfach vor, Kommunikation hat unverschämt viele Apekte.

Der größte Quatsch, den ich in den letzten Wochen gehört habe, war die Aussage, dass man als Scrum Master lediglich darauf achten müsse, dass alle Teammitglieder den gleichen Anteil an Redezeit hätten. Ich habe überhaupt kein Problem damit, wenn einige mehr sprechen als andere. Wenn ich versuche, den introvertierten Junior-Kollegen so sehr zu pushen, dass er ebenso viel quatscht wie der extrovertierte Supersenior, dann versuche ich die Persönlichkeit eines Menschen zu ändern und nicht mehr nur sein Verhalten. Warum das eine blöde Idee ist, erkläre ich hier nicht mehr. Das sprengt den Rahmen eines einzelnen Blogbeitrags. Außerdem: wo liegt der Sinn, wenn ich Input erzwinge, wo wenig Input kommen kann? Blödsinn. Vergessen wir das einfach.

Wichtiger als der Anteil an Redezeit in gemessenen Sekunden ist doch vielmehr, dass sich jeder im Rahmen seiner Möglichkeiten beteiligt und sich nicht aus Angst oder Vorsicht selbst ausschließt. Das ist es, was ich unter »Psychological Safety« verstehe.

Natürlich bedeutet das, dass wir als Scrum Master, einige Personen ziehen und andere bremsen müssen, dabei geht es jedoch nicht um harte Regeln, sondern um ein Klima des gegenseitigen Respekts. Wir schreiten ein, wenn jemand einen anderen herunterputzt oder eine Idee als Blödsinn abkanzelt, weil wir vermeiden wollen, dass diese Dinge einreißen. Wir möchten, dass jeder Input gleichwertig betrachtet wird, egal woher er kommt. Jede Meinung zählt gleich, jede Idee ist erst einmal gut genug, ernsthaft darüber zu sprechen.

Ein guter Scrum Master schafft das mit viel Fingerspitzengefühl, schließlich können nicht nur andere Entwickler der vermeintliche Auslöser der »Beteiligungsangst« sein, auch ein zu rigoroser Scrum Master kann durch sein Auftreten dafür sorgen, dass er seine Kollegen hemmt, indem er zu schnell und zu vehement eingreift.

Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen

Psychological Safety (wovorn wir auch nur einen kleinen Teilaspekt beleuchtet haben) ist seinerseits aber auch nur ein kleiner Teilaspekt des breiten Felds Kommunikation. Ganz wichtig ist auch die Verteilung von Know-how im Team. Wie oft können wir beobachten, dass Wissensinseln ganz unbewusst gehegt und gepflegt werden? Einer kümmert sich um ein Thema, weil er sich eben ganz besonders gut damit auskennt, was dazu führt, dass wir niemals dazu kommen, dass sich auch andere mit diesem Thema auskennen? Wir wollen nicht unbedingt, dass alle in allem Experten werden. Das ist auch nicht möglich, aber wir wollen, dass alle alles verstehen, um denjenigen, der sich am Ende darum kümmert, auch unterstützen zu können. Pair Programming ist ein Weg zum Ziel. Gemeinsame kleine Sessions, in denen man mehrere Optionen kurz im Team bespricht sind eine weitere Option.

Wir haben also immer die Wahl zwischen der Möglichkeit, dass sich einer eine Anforderung schnappt, allein losläuft, weil er sich in der Materie recht gut auskennt, allein eine Lösung erarbeitet und diese dann umsetzt, um das Ergebnis dann im Rahmen des Refinements den anderen zu präsentieren, und der Option, dass sich einer eine Anforderung schnappt und sich kurz mit den Kollegen abstimmt, was das beste Vorgehen ist. Ein gemeinsamer Task-Breakdown ist da in jedem Fall hilfreich.

Nicht nötig ist das bei absoluten Routineaufgaben, über die alle gut genug Bescheid wissen, dass sie jeder selbst machen könnte. In dem Fall läuft einer los und erledigt die Aufgabe – fertig. Darüber müssen wir nicht diskutieren, und wir müssen auch nicht künstlich eine Diskussion einfügen, wo keine nötig oder sinnvoll wäre. Bei allen anderen Themen, die für irgendeinen im Team neu sind, sollten wir sprechen. Das kann auf so viele Arten geschehen. Die Routineaufgabe, die für den Junior neu für alle anderen aber ein alter Hut ist, kann ganz wunderbar im Pair Programming erledigt werden. Der Neue ist danach auf Stand, und es ist nicht immer zwingend das gesamte Team beteiligt.

Andere Dinge, die viel Hirnschmalz erfordern kann man gemeinsam angehen. Das muss nicht immer das gesamte Team sein. Es können auch ebensogut zwei Personen die Köpfe zusammenstecken und vorweg gehen, um die anderen dann später abzuholen. Vollkommen in Ordnung.

Wir müssen dabei nicht immer alles lange vorbereiten, Termine festlegen, Leute einladen, einen Raum buchen, eine Agenda vorbereiten usw., ich fördere in all meinen Teams immer die spontane Kommunikation. Im Daily spricht man darüber, dass man jetzt mit einer Anforderung beginnen will, und man sagt kurz, dass man sich da noch über das Wie klar werden müsse. Ein anderer Entwickler kann anbieten, direkt im Anschluss kurz dazu zu kommen, um gemeinsam auf die Sache zu sehen. Die beiden ziehen sich in die Ecke zurück oder stellen sich gemeinsam vors Whiteboard, um ihre Überlegungen kurz zu skizzieren und sich auszutauschen. Dann macht einer weiter, recherchiert, probiert aus oder was auch immer, ein wenig später kommt man wieder kurz zusammen und bespricht die neuen Erkenntnisse. Eine kurze Absprache »Wann hast Du mal eben Zeit, Dir das mit mir anzusehen?« genügt dann. Die Antwort »Ich will das noch eben fertigmachen, aber in einer halben Stunde komme ich rum« ist dann ganz wunderbar. Wenn wir diese Dinge im Daily und über den tag verteilt erleben, dann sind wir auf einem sehr guten Weg, weil ich dann nahe an dem Punkt bin, dass ich das gesamte Potential des Teams ausnutze, weil nicht immer nur einzelne Personen einzelne Probleme betrachten, sondern immer mehr Hirne mit einem Thema beschäftigt sind, sich gegenseitig ergänzen und befruchten. Das ist es, was ich unter einem hochperformanten Team verstehe, weil die Ergebnisse dann immer besser sein werden, als würden Einzelkämpfer ihre Sachen für sich bearbeiten. Es ist ganz einfach: wir haben ein Team geschaffen, wenn die Personen oft und offen miteinander sprechen, um sich so zu ergänzen.

Ein Scrum Master kann das nicht erzwingen, aber er kann dafür sorgen, dass dieses Verhalten gefördert und gewollt wird. Wenn die Kollegen ein paar mal die Früchte ihrer Bemühungen geerntet haben, werden sie schon aus eigenem Antrieb das Gespräch mit den Kollegen suchen. Wir Scrum Master müssen das initialisieren, die Vorteile aufzeigen, nachfragen und dieses Verhalten begünstigen. Ist es einmal etabliert, sorgen die Kollegen schon von sich aus dafür, weiter so vorzugehen.

Natürlich kann das auch einschlafen, aber das bemerkt man recht schnell. Wenn es zu oft zu still im Teamraum ist, sollten wir das einfach thematisieren, um das Bewusstsein wieder zu wecken.

Und das waren nur die Punkte Psychological Safety und Kommunikation. Persönliche Motivation, die Klarheit von Strukturen, Verlässlichkeit haben wir noch nicht einmal angerissen.

Es bleibt also noch genug, worüber ich beim nächsten mal sprechen kann.

Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr