Meine größten Learnings zur Selbstorganisation in Scrum Teams

0 Kommentare

Selbstorganisation

Das agile Framework Scrum spricht von sogenannten selbstverwaltenden Teams. Aus früheren Scrum Guide Versionen und dem allgemeinen Sprachgebrauch, findet sich nach wie vor der Begriff der Selbstorganisation in Scrum. Scrum als Framework bietet eine Organisationsstruktur, die Teams hilft, Produktivität und Effizienz zu optimieren, und gleichzeitig Flexibilität und Kreativität zulässt. Selbstorganisation spielt bei diesem Ansatz eine wichtige Rolle, die es dem Team ermöglicht, kreative Lösungen für Herausforderungen zu finden, denen sie auf dem Weg begegnen. In diesem Artikel werfen wir einen Blick auf einige meiner eigenen, größten Erkenntnisse zur Selbstorganisation innerhalb eines Scrum Teams. Erfahre welche Komponenten die selbstorganisierten Teams in Leistung und Agilität ausbremsen können, indem sie ein Umfeld des Vertrauens und der Zusammenarbeit zerstören und so die einzigartigen Fähigkeiten zum Erfolg zur Nichte machen.

Hört auf in Konzernen von Selbstorganisation zu sprechen, wo ihr sie nicht geben könnt oder wollt

Ich arbeite als Certified Team Coach (CTC) in vielen unterschiedlichen Organisationen. Große wie kleine, allerdings sind die meisten schon größer. Zwar müssen das nicht immer die größten Konzerne sein, sind es aber oft. Kein Konzern (und großer Mittelstand) hat das Konzept von Selbstorganisation verstanden. Klingt hart und ich bin auch kein Freund pauschal "kein" zu sagen, muss ich aber so feststellen. Es wird immer davon ausgegangen, dass eine Gruppe von Menschen zusammengewürfelt wird und dann Scrum praktiziert. Kann man machen, dann wirst du früher oder später aber immer und immer wieder an den gleichen Problemen scheitern. Ich finde es fair zu sagen, man steht noch nicht da, wirkliche Agilität oder Selbstorganisation zu leben. Ich finde es aber nicht in Ordnung Menschen in Strukturen zu werfen, die nicht passen - die Kultur folgt immer der Struktur.

Das Ziel fehlt

Wenn Scrum Teams kein gemeinsames, geteiltes Ziel haben, dann wird das auch nichts mit Selbstorganisation. "Wir arbeiten halt zusammen" ist kein Ziel und sexy ist es auch nicht. Es motiviert nicht und gibt keine Ausrichtung für das Team. Vielen Führungskräften aber auch Teams selbst fällt es schwer, ein solches Ziel überhaupt zu formulieren. Aus Produktsicht hilft es von der Vision über Produkt Ziele bis zu Sprint Zielen zu denken.

Möglicher Lösungsansatz:

Klares Verständnis über das Produkt / die Aufgaben schaffen. Eine Vision ableiten, verstehen wie die Arbeit des Teams eine Auswirkung darauf hat und wie der Impact ist.

Ein Team ist keine Gruppe von Menschen

Selbstorganisation ist ein wichtiger Bestandteil eines jeden Scrum Teams. Es ermöglicht dem Team effektiv, effizient und autonom zu arbeiten. Meine Erfahrung mit der Arbeit mit vielen Scrum Teams hat mir viele unschätzbare Erkenntnisse darüber gebracht, wie man diese Art von Team am besten führt und vor allem, wie sich Menschen selbst führen wollen - oder eben auch nicht. Nur weil eine Abteilung 20 Leute hat, bedeutet das nicht, dass ich diese Anzahl von Menschen einfach durch die Zahl im Scrum Guide für optimale Teamgrößen teilen kann und dann meine Teams habe.

Nicht jeder Mensch möchte überhaupt in einem (agilen) Team arbeiten, was auch absolut in Ordnung ist. Nur dann müssen wir (in Unternehmen) auch ehrlich sein und solche Menschen nicht in Teams stecken. Diese Konsequenz wird aber nicht gegangen.

Typische Dysfunktionen:

Menschen werden in "Teams" eingeteilt und werden als Teams bezeichnet, sie sind es aber nicht. Der Begriff des Teams wird inflationär benutzt. Was nicht passt, wird "passend" gemacht.

Möglicher Lösungsansatz:

Ich finde es ganz praktisch, sich mit visuellen Tools an das Thema zu arbeiten. Ich habe mir die Rollen von Belbin ausgedruckt und nutze diese, um zu schauen, ob alle Typen in einem Team vorhanden sind. Somit schaffe ich ein Bild und lasse das "Team" dann schauen, ob sie sich vollständig fühlen und was es noch braucht.

Nein, wir können eben nicht alle Menschen "mitnehmen"

Es gibt Menschen, die möchten gar nicht in agilen Umgebungen arbeiten, andere machen gerne 9-to-5 und interessieren sich nicht für andere Kollegen und wieder andere arbeiten einfach nur, damit sie sich das Leben leisten können. Diese Menschen werden nie in einem agilen Team funktional sein. Nicht, weil es schlechte Menschen sind, sondern weil ich für agile Teams einen bestimmten Menschenschlag brauche. Damit meine ich nicht den Work-a-holic und den absoluten Everybody's-Darling. Doch es gibt sie, die meistens sogar ehrlich sagen, was sie wollen (und das es das "agile" nicht ist) - aber so etwas dann oft nicht gehört und berücksichtigt. Und eben dann kann ich mir alles andere sparen.

Hier sollte man immer unterscheiden - zwischen einem Wollen und einem Können. Wir können Menschen entwickeln, wenn sie es wollen. Wenn Menschen aber nicht wollen, dann läufst du faktisch immer in ein Problem. Der positive Aspekt ist, dass dieses oft nur die Ausnahme ist. Die meistens Menschen können und wollen und wenn sie das Können noch nicht haben, existiert meist das Wollen!

Typische Dysfunktionen:

Egal, ob Menschen in das Unternehmen passen oder nicht, sie "müssen" durchgeschleift werden. HR hat meistens keine klare Perspektive darauf, wer in Teams benötigt wird und wer nicht. Es werden Menschen eingestellt, "weil wir jetzt einstellen müssen" oder "weil sonst der Arbeitsmarkt keine Menschen mehr bietet",...

Möglicher Lösungsansatz:

Ich mag die Vergleiche zu englischen Unternehmen nicht, möchte dazu trotzdem auf Netflix verweisen. Im Buch "Keine Regeln" kommt schön raus, dass ich mir als Unternehmen auch Gedanken machen muss, was mit Mitarbeitern passiert, die eben nicht passen. Diesen Fakt kann man nun gesellschaftlich, unternehmerisch und auch sozial betrachten. Fakt ist auch: Mitarbeiter die nicht passen, können nicht von allen über die Ziellinie getragen werden.

Entscheiden wer entscheidet

Leider wollen die wenigsten Führungskräften wirklich entscheiden. Es wird verzögert, sich abgesichert und Verantwortungen sind nicht klar. Auf der anderen Seite wollen Teams und andere Personen gerne möglichst, dass viele Entscheidungen (auch von Führungskräften) getroffen werden. Das kollidiert früher oder später. Es kommt zu Konflikten, die oft auf mangelnder Transparenz beruhen.

Typische Dysfunktionen:

Führungskräfte sprechen von Selbstorganisation und "entscheidet als Teams", behalten sich aber laufend Änderungen vor oder bremsen Entscheidungen aus. 

Möglicher Lösungsansatz:

Mit Delegation Poker und meiner Entscheidungsvorlage kannst du dir helfen. Diese Vorlage ist ein Tipp in meinem Newsletter "Scrum Tipps". 

Mangelndes Vertrauen im Team

Vertrauen ist leider auch schon so zu einem Hype-Wort verkommen. Aber Vertrauen und emotionale Sicherheit sind eben wichtig. Natürlich sollte ich (auch als Führungskraft) nicht immer blind vertrauen - aber bei allem kritisch sein und immer misstrauisch durch die Welt zu gehen, hat noch nie geholfen und macht etwas mit deinen Menschen im Umfeld. Schaue dir dazu meinen Artikel zum Agile Leadership genauer an.

Möglicher Lösungsansatz:

Im Team besprechen, was Vertrauen bedeutet und wie es hergestellt wird. Was sind die Erwartungen, wie wird es zerstört?

Konflikte werden gescheut und es gibt nur positives Feedback

Viele Menschen (ich bin auch oft so) sind eher konfliktscheu. Und wenn ich Menschen ein offenes und ehrliches Feedback geben soll, dann kann ich als Mensch mit einer Tendenz Konflikte nicht anzusprechen, dieses eher in den Hintergrund stellen. Und dann kommen die Konflikte nicht raus. Sie werden nicht besprochen, sie werden nicht mal transparent und damit nie angesprochen und gelöst. Das ist für Selbstorganisation und Menschen nicht gut.

Möglicher Lösungsansatz:

Eine Kombination von öffentlichem und privaten Feedback Mechanismen regelmäßig etablieren, um sich mehr und mehr zu verbessern und lernen, damit umzugehen.

Metriken sind für unreife Teams immer fördernd

Ich muss sagen, ich mag Metriken. Sie müssen aber gut sein und wir wissen alle, dass wir uns systemintelligent verhalten, wenn wir wissen, wie wir gemessen werden. Das Zitat "Sag mir, wie du mich misst und ich sage dir, wie ich mich verhalte" von Goldratt drückt es recht gut aus. Allerdings stelle ich immer und immer wieder fest, wenn Teams noch nicht reif sind, brauchen sie in der Regel mehr Struktur als reife Teams. Zu dieser Struktur gelange ich aber nur, wenn ich mich gegen irgendwas messe.

Typische Dysfunktionen:

"Wir wissen schon, was wir machen" - oft überschätzen sich Menschen, wie das System und das Verhalten gerade aussieht.

Möglicher Lösungsansatz:

Gemeinschaftlich über sinnvolle Metriken sprechen und überlegen, wie diese dem Team helfen können. Dabei sollte die Metriken einfach sein und alle auch einbezogen werden. Immer besser: Menschen nie direkt bewerten, sondern auf Arbeit oder Rahmenparameter eingehen.

Rollen - der Anfang vom Ende

Rollen können etwas positives bewirken. Aber auch genau das Gegenteil. Eine Rolle "Architekt" führt unweigerlich gleich dazu, dass es Aufgaben auf dieser Rolle zentriert und klar macht, dass andere diese Aufgaben eben nicht haben. Das kann durchaus helfen und auch behindern. Behindern tut es immer dann, wenn Menschen Rollen nutzen, um eine Verantwortung abzuschieben. Es ist ja immer leicht zu sagen: "Ich bin kein Architekt, das ist nicht mein Thema". Auf der anderen Seite kann ich auch nicht von jedem erwarten diese Aufgaben zu überblicken. 

Typische Dysfunktionen:

Sobald ich mit Verantwortlichkeiten oder Aufgaben nicht mehr weiter weiß, erstelle ich eine neue Rolle. 

Möglicher Lösungsansatz:

Ich habe hier tatsächlich keine wirkliche Lösung. Mir gefällt der Ansatz aus dem Scrum Guide nur von einer Rolle Entwickler zu sprechen. Das hilft unreifen Teams aber leider meistens recht wenig. Auch das ist ein Change zu einer neuen Form, den ein Team erstmal schaffen muss.

Fazit: Selbstorganisation meistern ist ein langer Weg

Selbstorganisation ist der Schlüssel zu einem erfolgreichen Scrum Team, und im Laufe der Jahre hatte ich die Gelegenheit, mit vielen verschiedenen Teams zusammenzuarbeiten, von denen jedes seine eigenen einzigartigen Ansätze zur Selbstorganisation hatte. Ich bin dankbar für die Eindrücke und Ansichten jedes einzelnen Menschen. Meine Zusammenfassung ist subjektiv, aber ich denke darin ein absolut typisches Muster bei vielen Organisationen erkennen zu können.

About the author 

Sebastian Schneider

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>