Ich nehme in meinen Projekten regelmäßig wahr, dass Teammitglieder die eigene Freiheit und Selbstverwirklichung in der Selbstorganisation schätzen und darin einen großen Vorteil für die eigene Arbeit und Zufriedenheit sehen. Häufig nehme ich aber auch wahr, dass wenn es um die Erreichung eines Teamzieles oder einfach nur die Erfüllung einer Aufgabe geht, die einem persönlichen Bedürfnis im Wege steht (private Interessen / Termine, früher Feierabend, etc.), die persönlichen Interessen höher priorisiert werden als die des Teams. Kann Selbstorganisation unter solchen Bedingungen gelingen, oder ist es nach Eurer Erfahrung notwendig, dass man als Teil eines Teams die Team- oder Organisationsziele im Zweifel höher priorisieren muss?
2 Antworten
Ich würde sogar noch einen Schritt weiter gehen. Nicht nur persönliche private Interessen, sondern auch persönliche Aufgaben stehen oft im Fokus des einzelnen Teammitgliedes und eben nicht das Teamziel. So zumindest die äußerliche Wahrnehmung.
Ich lasse mich beim Herangehen an solche Herausforderungen insbesondere von den Erkenntnissen von Patrick Lencioni (5 dysfunctions of a team) inspirieren. Demnach ist das Zurückstellen eigener Interessen zugunsten der Teaminteressen nicht etwas, das eingefordert werden muss (geschweige denn kann), sondern etwas das insgesamt mit der Teamreife des Teams zu tun hat.
Für effektive Teamarbeit (= die sogenannten high performance teams) müssen einerseits die sozial-dynamischen Gegebenheiten des Teams selbst UND die äußeren Einflussfaktoren auf das Team zusammenpassen.
Mit Ersterem ist gemeint, dass sich die Teammitglieder in allererster Linie gegenseitig vertrauen. Das bedeutet, man traut sich Missstände im Team offen anzusprechen. Das ist keine Selbstverständlichkeit und kann auch nicht über Nacht erreicht werden. Vielmehr geht jedes Team durch die bekannten 4 Teamphasen nach Tuckman. Diese brauchen Zeit und (wichtig zu wissen) beginnen mit JEDER Teamveränderung von vorne. Unter anderem leitet sich daraus ab, dass die Teambesetzung über einen längeren Zeitraum stabil sein muss, damit das Team die Chance hat, sich durch diese 4 Phasen hindurch zu entwickeln. Der Scrummaster kann hier dem Team in der Eigenreflexion helfen, wo man sich gerade befindet und passende Maßnahmen anbieten, die diesen Prozess beschleunigen. Z.B. in einer anonymen Betrachtung, wie man sich gegenüber Teamkollegen verhält, wenn man mit irgendetwas unzufrieden ist, was die Teamkollegen gerade tun. Scheut man den Konflikt, weil man nicht unhöflich erscheinen mag? Oder spricht man den Missstand offen an? Ist das Team geübt darin, gegenseitiges wertschätzendes Feedback zu geben? Auch das lässt sich üben, z.B. in einer Retrospektive für jedes Teammitglied die beiden Fragen zu beantworten: Was schätze ich an Dir? Und was wünsche ich mir von Dir?
Hinsichtlich der äußeren Einflussfaktoren ist es besonders wichtig darauf zu achten, was die zu erreichenden Ziele des Teams sind? Sind es Einzelaufgaben, die parallel von verschiedenen Teammitgliedern abgearbeitet werden und die darüberhinaus in losem business-Zusammenhang stehen? Dann wird mit hoher Wahrscheinlichkeit kein echtes Team entstehen, sondern nur ein Gruppe von Co-Workern. Haben die Teammitglieder hingegen ein gemeinsames Ziel und sind darüberhinaus gegenseitig abhängig (d.h. sie brauchen einander, um das Ziel zu erreichen) kann daraus viel wahrscheinlicher ein echtes Team werden. Besonders schön ist das in der Grafik von Stefan Lindbohm und Viktor Cessan dargestellt:
Insofern geht es gar nicht so sehr darum, OB die Teammitglieder ihre eigenen Interessen den Teaminteressen unterordnen, SONDERN darum zu verstehen, welche Wirkung haben die äußeren Kräfte auf das Team. Idealerweise eben sind die äußeren Kräfte so hoch, dass die Teammitglieder ihre eigenen Interessen FREIWILLIG dem Teamziel unterordnen und nicht, weil es irgendjemand von ihnen fordert.
Was sich als besonders hilfreich herausgestellt hat, ist den Teams keine Aufgaben zu bringen, sondern ein Problem (des Kunden), dass das Team lösen soll. Zu oft sehe ich noch, dass Backlog-Items bereits vorgedachte Lösungsideen sind. Besser ist es, die Backlog-Items als Liste zu lösender Kundenprobleme zu verstehen und auch so zu beschreiben. Indem sich das Team eines Problems annimmt, ist es aufgefordert gemeinsam an einer möglichen Lösung zu arbeiten. Nachdem es das erreicht hat, geht es darum die Lösung umzusetzen, um das Problem zu lösen. Mit allem was dazu notwendig ist. Und wenn es das 'Rausbringen des Mülls' ist, damit das Problem zu 100% gelöst ist.
In Scrum ist dies besonders leicht zu erreichen, indem der Product Owner anspruchsvolle Probleme zum Team bringt. Es ist seine Aufgabe, dem Team das externe Kundenproblem sichtbar und greifbar zu machen, damit das Team versteht, welche Wirkung (Impact) die gefundene Problemlösung für den Kunden hat. Kein Teammitglied möchte bewusst einen Kunden enttäuschen, indem es dessen Probleme ignoriert. Das macht es jedem Teammitglied leichter, die Teamziele den eigenen Interessen voranzustellen.
Henrik Kniberg drückt das in der Spotify-Engineering-Culture mit dem Ausdruck 'Alignment enables Autonomy' aus. Grafisch dargestellt hier:
Das heißt, erst das starke äußere Alignment schafft den nötigen Rahmen, damit ein Team wirklich autonom (= selbstorganisiert) arbeiten kann. Prinzipiell findet Selbstorganisation immer statt. Man kann sie nicht machen. Es ist so ähnlich wie der Flurfunk. Diesen kann man auch nicht machen. Er passiert einfach.
Eine kollaborative Kultur (wie in der Grafik von Henrik Kniberg dargestellt) und damit eine Teamkultur, die die Teamziele höher einstuft als die eigenen Interessen ist also vielmehr eine Folge der äußeren Faktoren. Auf diese gilt es besondere Aufmerksamkeit zu legen. Arbeit am System, nicht am Menschen!
Aus meiner Sicht, ist das was du beschreibst, genau die Krux am Thema Selbstorganisation. Nur, wenn man im Team ein ausreichend hohes Committment schafft, dass Selbstorganisation wertvoll und gewollt ist, mit all ihren Konsequenzen, kann sie auch gut funktionieren. Es zum einen auf der sachlichen Ebene zu verstehen, was Selbstorganisation bedeutet ist, häufig schon nicht gegeben. Was dürfen wir eigentlich selbst entscheiden und wo müssen wir uns unterordnen oder einfügen? Der Rahmen in dem sich ein selbstorganisiertes Team bewegt, ist also oft schon nicht klar genug für alle Beteiligten definiert. Oft hört man Dinge wie "Das dürfen wir nicht", "Das können wir daher so nicht", "Das kommt von oben", "Das liegt nicht in unserer Hand". Das macht ein Committment seitens des Teams natürlich schwierig, wenn das Team sich orientierungslos und fremdgesteuert fühlt. Auch Verantwortung zu übernehmen fällt nicht jedem leicht und ist nicht von jedem gewollt. Und ja, dann gibt es auf der anderen Seite auch noch die emotionale Ebene, die persönliche Bedürfnisse auch manchmal mit Teambedürfnissen in Konflikt stellt. Damit sich jeder im Team gut fühlt, dürfen die persönlichen Bedürfnisse nicht vollständig vernachlässigt werden. Dennoch muss das Team im Vordergrund stehen. Es ist also schwierig eine entsprechende Balance zwischen persönlichen und Teambedrüfnissen zu finden. Dafür ist das Team verantwortlich und je nach Zusammensetzung ist das schwerer oder leichter, bis das Team sich findet. Teamplayer haben es in der Regel leichter sich in eine Selbstorganisation einzufügen. Viele ihrer persönlichen Bedürfnisse stimmen mit denen des Teams überein. Meiner Erfahrung nach haben Teamplayer ein hohes Bedürfnis an Harmonie und Gleichberechtigung bzw. Fairness. Persönliche Bedürfnisse, die auch gleichzeitig Teambedürfnisse sind spielen Selbstorganisation also in die Hände. Nun hat man in Teams allerdings auch Mitglieder, die keine Teamplayer sind, sondern nur ihre eigenen Interessen verfolgen und auch Teamplayer, haben natürlich persönliche Interessen. Es muss aus meiner Sicht also für jeden einzelnen ein learning stattfinden, dass ein gut funktionierendes, selbstorganisiertes Team einen Mehrwert auch für jeden einzelnen bedeuten kann, sodass die Teambedürfnisse, zu den eigenen werden. Denn wenn jeder einzelne Mitarbeiter den Mehrwert der Selbstorganisation für sich selbst versteht, ist sein Interesse auch hoch, diese zum laufen zu bringen und schafft eine höhere Bereitschaft, eigene Interessen auch mal zurückzustellen. Wie mit vielen Dingen ist meiner Erfahrung nach eine gute Mischung entscheidend. Klare Strukturen, serveant Leadership und einen Mehrwert für jeden einzelnen schaffen, ist aus meiner Sicht daher der Schlüssel einer guten Selbstorganisation. Das Ziel sollte also nicht sein, im Zweifel das eine oder andere höher zu priorisieren, sondern eine Balance zwischen den Bedürfnissen zu schaffen, die Team und persönliche Interessen vereint.
Ergänzend möchte ich noch die system-theoretischen Erkenntnisse hinzufügen. Appelle an Mitarbeiter, ihre eigenen Ziele zurückzustellen, insbesondere für diejenigen Menschen, die es bisher nicht gewohnt waren in interdisziplinarischen, interdependent Teams zu arbeiten sind in der Regel kaum bis gar nicht wirksam. Zumindest habe ich in der realen Welt kaum eine positive Wirkung diesbezüglich gesehen.
Die Systemtheorie lehrt uns, dass das Verhalten von Menschen viel wirksamer durch den Kontext beeinflusst werden kann. Was also ist nötig, damit sich Nicht-Teamplayer zu Teamplayern verwandeln?
2 Dinge sind für mich hier essentiell:
a, ein (sehr) starkes Teamziel, das vom Kunden her motiviert ist. Z.B. könnte das sein, dass ein Softwareprodukt zu einem bestimmten Zeitpunkt für eine Messe zur Verfügung stehen muss. Ja richtig gehört, Milestones. Denn die Erfahrung lehrt, dass sich Arbeit in dem Maße ausdehnt, wie Zeit zur Verfügung steht. Dies steht in keinerlei Widerspruch zu Agilität, ganz im Gegenteil. Denn durch den extern referenzierten Druck, sind Menschen angehalten kluge Lösungen für knifflige Ziele zu finden. Meistens resultiert dies in Entscheidungen was nun wirklich, wirklich wichtig ist und was eben nicht und jetzt weggelassen wird. Also die wertgetriebene agile Denkweise.
Solch ein Ziel fordert und fördert das Teamplay jedes einzelnen Teammitgliedes. Denn NIEMAND, auch nicht die Nicht-Teamplayer möchte der-/diejenige sein, an dem die Zielerreichung letztlich scheiterte.
b, soziale Dichte. Das bedeutet Teammitglieder müssen 1. das gleiche Ziel haben, 2. interdependent sein. Der Beitrag jedes Einzelnen muss so wichtig sein, dass der Nicht-Beitrag zum Scheitern des zu erreichenden Zieles führt. Interdependency kann erreicht werden, indem z.B. im Sprint Planning genau aufgeschlüsselt wird, was zu tun ist und idealerweise Aufgaben dabei sind, die an den Nicht-Teamplayern hängen. Dies ist in der Realität gar nicht so schwierig erreichbar. Denn aus meiner Erfahrung sind gerade die Heros in einem Unternehmen, also die Allwissenden oft die, die am wenigsten teamfähig sind. Wenn von deren Spezialwissen der Erfolg des Teams abhängt, wird der soziale Gruppendruck dazu führen, dass diese ihr Verhalten ändern müssen, damit das Team gewinnen kann. Deshalb soziale Dichte als zweite wichtigste Zutat zur Selbstorganisation.
Das war jetzt alles sehr abstrakt, aber ich hoffe, die Zusammenhänge sind klar geworden und was man von außen (also am Kontext) ändern kann, damit Selbstorganisation gefördert wird.
Persönlich würde ich neben den beiden Zutaten Starkes externes Teamziel und soziale Dichte noch Leadership hinzufügen. Teams, in denen niemand Erfahrung mit Leadership haben (z.B. ein Team, das nur aus junioren Entwicklern besteht) werden sich schwer tun ihre eigenen Prozesse und Strukturen innerhalb des Teams zu finden. Es reicht bereits, wenn zumindest einer im Team dabei ist, der servant leadership skills hat. Ist dem nicht der Fall, muss das servant leadership unbedingt von außen hinzugefügt werden, z.B. durch den Support des Scrummasters, der dann aber sehr eng am Team sein muss, also Vollzeit für das Team zur Verfügung stehen muss.
Die Systemtheorie lehrt uns, dass das Verhalten von Menschen viel wirksamer durch den Kontext beeinflusst werden kann. Was also ist nötig, damit sich Nicht-Teamplayer zu Teamplayern verwandeln?
2 Dinge sind für mich hier essentiell:
a, ein (sehr) starkes Teamziel, das vom Kunden her motiviert ist. Z.B. könnte das sein, dass ein Softwareprodukt zu einem bestimmten Zeitpunkt für eine Messe zur Verfügung stehen muss. Ja richtig gehört, Milestones. Denn die Erfahrung lehrt, dass sich Arbeit in dem Maße ausdehnt, wie Zeit zur Verfügung steht. Dies steht in keinerlei Widerspruch zu Agilität, ganz im Gegenteil. Denn durch den extern referenzierten Druck, sind Menschen angehalten kluge Lösungen für knifflige Ziele zu finden. Meistens resultiert dies in Entscheidungen was nun wirklich, wirklich wichtig ist und was eben nicht und jetzt weggelassen wird. Also die wertgetriebene agile Denkweise.
Solch ein Ziel fordert und fördert das Teamplay jedes einzelnen Teammitgliedes. Denn NIEMAND, auch nicht die Nicht-Teamplayer möchte der-/diejenige sein, an dem die Zielerreichung letztlich scheiterte.
b, soziale Dichte. Das bedeutet Teammitglieder müssen 1. das gleiche Ziel haben, 2. interdependent sein. Der Beitrag jedes Einzelnen muss so wichtig sein, dass der Nicht-Beitrag zum Scheitern des zu erreichenden Zieles führt. Interdependency kann erreicht werden, indem z.B. im Sprint Planning genau aufgeschlüsselt wird, was zu tun ist und idealerweise Aufgaben dabei sind, die an den Nicht-Teamplayern hängen. Dies ist in der Realität gar nicht so schwierig erreichbar. Denn aus meiner Erfahrung sind gerade die Heros in einem Unternehmen, also die Allwissenden oft die, die am wenigsten teamfähig sind. Wenn von deren Spezialwissen der Erfolg des Teams abhängt, wird der soziale Gruppendruck dazu führen, dass diese ihr Verhalten ändern müssen, damit das Team gewinnen kann. Deshalb soziale Dichte als zweite wichtigste Zutat zur Selbstorganisation.
Das war jetzt alles sehr abstrakt, aber ich hoffe, die Zusammenhänge sind klar geworden und was man von außen (also am Kontext) ändern kann, damit Selbstorganisation gefördert wird.
Persönlich würde ich neben den beiden Zutaten Starkes externes Teamziel und soziale Dichte noch Leadership hinzufügen. Teams, in denen niemand Erfahrung mit Leadership haben (z.B. ein Team, das nur aus junioren Entwicklern besteht) werden sich schwer tun ihre eigenen Prozesse und Strukturen innerhalb des Teams zu finden. Es reicht bereits, wenn zumindest einer im Team dabei ist, der servant leadership skills hat. Ist dem nicht der Fall, muss das servant leadership unbedingt von außen hinzugefügt werden, z.B. durch den Support des Scrummasters, der dann aber sehr eng am Team sein muss, also Vollzeit für das Team zur Verfügung stehen muss.