Mach mal Teamwork: Ein Klima für mehr Zusammenarbeit schaffen

In Scrum steht die Teamleistung über der Einzelleistung. Unter dem Leitbild des Teamerfolgs werden tiefe, in uns verankerte Abwehrmechanismen aktiv, die der Idee widersprechen und den Einzelkämpfer in uns bestärken. Wie wird ein Teamwork-förderndes Klima geschaffen, ohne gleich die Welt des Arbeitens revolutionieren zu wollen?

Einzelkämpfer und Teamplayer

crowdIn der agilen Entwicklung, insbesondere nach Scrum, steht die Teamleistung über der Einzelleistung. Es geht nicht darum, wer wie viele User-Stories in einem Sprint geschafft hat. Ferner geht es auch nicht darum, wer wie viele Stories Implementation-Done gebracht hat, wer wie viel abgenommen hat und wer wie viel davon in das finale Release gemerged hat.

Die entscheidende Frage am Ende des Sprints ist, ob das Team dem PO eine lieferbare Version in die Hand gegeben hat, in der – bestenfalls – alle Stories enthalten sind, die zu Beginn des Sprints zugesagt wurden.

Unter diesem Leitbild des Teamerfolgs werden tiefe, in uns verankerte, erlernte Abwehrmechanismen aktiv. Sie widersprechen diesem Leitbild und bestärken den Einzelkämpfer in uns. Die Gedanken drehen sich um die Fragen „Welches Verhalten ist richtig, um der Idee gerecht zu werden? Und welches Verhalten ist für mich richtig?“

Richtig und falsch

Erziehung, Schule und Ausbildung haben uns gelehrt, man solle sich selbst profilieren. Man müsse im Wettkampf gegenüber anderen überlegen sein, weiter kommen, aus der Menge herausstechen, auffallen. Im Job ginge es darum, befördert zu werden – und es könne schließlich nicht jeder befördert werden. Viele dieser und ähnlich erlebter Ereignisse, Phrasen und Belehrungen prägen unser Urteilsvermögen über richtig und falsch.

Mit der erlangten und vielleicht über Jahre trainierten Fähigkeit, Anwendungen zu entwickeln, komplexe Software-Systeme zu erstellen, Anforderungen in intuitive Oberflächen zu übersetzen… Diese individuellen Fähigkeiten, die jemanden – scheinbar – im beruflichen Kontext einzigartig und besonders machen (für viele auch über den beruflichen Kontext hinaus), diese Fähigkeiten sollen nun nicht (mehr) mit voller Leistung auf die Straße gebracht werden?

Übersetzt auf die Sprints würde das bedeuten, nicht mehr eine Story nach der anderen zu ziehen und voll und ganz seiner Profession nachgehen: Lines of Code erzeugen.

Ich und Wir

pairingUnd nun soll das falsch sein, lautet der Anspruch vom Einzelkämpfer doch: „Was kann ich mit meinen besonderen Fähigkeiten tun, damit ich möglichst viel schaffe?“.

Auch der Teamplayer hat einen Anspruch an sich selbst. Er könnte wie folgt lauten: „Was kann ich dazu beitragen, damit wir das Ding zum Fliegen bekommen?“

Beide Ansichten verfolgen das gleiche Ziel. Dennoch unterscheiden sie sich gravierend darin, wie dieses Ziel erreicht wird.

Der Einzelkämpfer konzentiert sich auf seine Kernfähigkeiten, seine besonderen Fähigkeiten, die er, idealerweise, zu 100% geltend machen will. Es soll ihm nicht unterstellt werden, dies geschiehe nicht zum Wohle des Großen-Granzen. Auch er leistet seinen Beitrag dazu. Er bestätigt sich damit, komplizierte Aufgaben mit seinen eigenen Fähigkeiten gemeistert zu haben.

Der Teamplayer dagegen stellt, anders als der Einzelkämpfer, nicht seine Kernfähigkeiten ins Zentrum. Er sieht sich gesamthaft als fähiger Mensch. Er achtet stets auf Lücken in seinem Wirkungsradius, in denen er unterstützen kann. Er wird in seinem Handeln bestätigt, nicht wenn er „seine Aufgabe“ geschafft hat, sondern wenn das ganze Produkt (-Inkrement) vor ihm steht und realisiert ist.

Ein Klima für Teamwork schaffen

Eine Führungskraft kann sich nun damit beschäftigen, ob Teamplayer oder Einzelkämpfer besser oder schlechter sind, oder was von beiden in welchen Umgebungen besser geeignet ist.

Zuerst muss sie sich aber eine viel einfachere Frage stellen: „Was will ich eigentlich?“.

  • Soll jeder Entwickler ständig beschäftigt sein und das machen, was er am besten kann: Lines of Code erzeugen?
  • Oder soll das Team in kurzen Abständen laufende Software produzieren?

Ok, dann macht jetzt mal Teamwork!

environmentWie bereits erwähnt, sind viele von uns vorbelastet durch Schule, Ausbildung, Erziehung und durch die vorherigen Jobs mit deren Vorgesetzten. Menschen mit solchen Erfahrungen verspüren intuitiv den Drang, sich profilieren, sich hervorheben zu wollen. Wie es vereinzelt ausfällt, obliegt dem Urteil des Empfindens von richtig und falsch.

Diesen individuellen Entscheidungsapparat zu verändern gelingt nicht dadurch, indem man fordere, man solle jetzt Teamplayer sein.

Selten entscheidet der individuelle Apparat unabhängig und objektiv. Er wird gespeist durch die Richtig-/Falsch-Kriterien des Systems, in dessen Wohlwollen er eine Entscheidung treffen soll. Kurz: die Umgebung hat die Entscheidung bereits für uns getroffen.

Oftmals wird dieser abstrakte Aspekt wie folgt interpretiert: honoriere das System die Einzelleistung, werde auch jeder dazu verleitet.

Die Diskussion ist interessant und sie ist nicht neu. Schnell wird sie auf eine gesellschaftsweite, Arbeitswelt-reformierende Ebene gehoben, auf der über horizontale Karriereentwicklung, hierarchielose Organisationsstrukturen und für Generation-Y attraktive Live-Balance Gestaltungsfreiräume heftigst diskutiert wird.

Wie gut und auch notwendig diese Diskussion ist, sie darf die Eingangsfrage nicht mit einer, in ferner Zukunft zu realisierender, Gesellschaftsutopie beantworten: Wie wird ein Teamwork-förderndes Klima geschaffen?

Kleine Gesten statt große Visionen

Ich sehe das nicht so schwarz/weiß. Viele Veränderungen beginnen im Kleinen. Je mehr man sich der Größe kleiner alltäglichen Dinge bewusst wird, desto einfacher finden sich ganz konkrete Anwendungen.

Oft höre ich die Empfehlung, man solle die Einzelleistung nicht loben, sondern die des Teams. Meine Meinung ist, die Einzelleistung muss sogar honoriert werden, schließlich besteht das Team (so hilfreich diese Abstraktion in vielen Fällen auch erscheinen mag) letztlich aus einzelnen, unterschiedlichen Menschen. Und einige Menschen brauchen direkte Bestätigung, Feedback, für das, was sie gemacht haben.

Die Frage darf also nicht lauten: „ob oder ob nicht“. Ich stelle die Frage, worin welche Einzelleistung honoriert wird. Ich möchte dies anhand einer einfachen Alltagssituation darstellen: Der Product-Owner spricht am Ende des Sprint-Reviews ein Lob aus.

Situation 1

Im Sprint-Review bedankt sich der Product-Owner vor versammelter Mannschaft (namentlich) bei einem Entwickler für seinen exorbitant herausragenden Einsatz. Er habe viele Stories angepackt und somit dieses Release ermöglicht. Es ist wichtig, solche Performer im Team zu haben.

Situation 2

Im Sprint-Review bedankt sich der Product-Owner beim ganzen Team für die exorbitant herausragende Leistung.

Situation 3

Im Sprint-Review bedankt sich der Product-Owner beim ganzen Team für die exorbitant herausragende Leistung. Insbesondere möchte er sich bei einem Entwickler bedanken. Er habe bei vielen Stories unterstützt und gemeinsam mit den Kollegen die begonnenen Stories fertiggestellt. Seine Initiative hat das Team zum Erfolg geführt.

Worin unterscheiden sich diese 3 Danksagungen, oder anders gefragt: Wem wird gedankt und für was wird gedankt?

Situation 1 hebt deutlich die Einzelleistung eines Mitarbeiters hervor. Es wird der direkte Beitrag seiner Leistung dem Produkt, dem Arbeitsergebnis, gutgeschrieben. Der Mitarbeiter wird auf seine Kernfähigkeit reduziert und darin bestärkt. Motivation für den betroffenen und Motivation für seine Kollegen, dieses Verhalten beizubehalten: Am Produkt arbeiten, Kollegen ausblenden, dann schaffe ich viel.

In Situation 2 wird dem ganzen Team gedankt. Es ist nicht erkennbar, für was gedankt wird. Vielleicht, weil das Team viele Stories geschafft hat? Weil es eine lieferbare Version gab? So gut gemeint diese Dankesreden sind, kommen sie beim Team platt, erzwungen und nicht ehrlich gemeint an: Man sage dies, weil es in einem Handbuch für Mitarbeiter Motivation stand.

In Situation 3 wird auch zuerst dem ganzen Team gedankt. Dem Product-Owner ist nicht entgangen, dass sich ein Entwickler besonders stark dafür gemacht hat, dass das Team zusammenarbeitet. Er dankt dem Entwickler nicht für seine Leistung am Produkt, sondern für den Beitrag, den er in das Team gesteckt hat. Wie dieses Signal auch bei den Kollegen ankommt, es kommt an.

Teamwork ist ein Projekt

kundenWer aufmerksam durch die Büroräume läuft, wird viele weitere Anwendungen finden, mit denen er Teamwork fördern kann. Oftmals sind es kleine Änderungen in der eigenen Sprache und ein Empfinden für Wertschätzung gegenüber Leistungen, die über das eigentliche Produzieren hinausgehen.

Soll Teamwork offen und ehrlich gefördert werden, muss dies als Entwicklung betrachtet werden. Der Entscheidungsapparat für richtig und falsch, der in jedem Kopf sitzt, lässt sich nicht per Firmware-Update umprogrammieren. Er wird durch die Richtig-/Falsch-Kriterien der Umgebung gespeist. Wenn er entscheidet, welches Verhalten in einer konkreten Situation richtig ist, muss er immer und immer wieder die Erfahrung machen, dass sein errechnetes Ergebnis zur Überraschung führt – für seinen Besitzer, dem Teamplayer.

Quellenangaben
Laszlo Prising/shutterstock.com
ChiccoDodiFC/shutterstock.com
Vasilev Evgenii/shutterstock.com
danm12/shutterstock.com
Jackiso/shutterstock.com