Selbstorganisation - Wie man sie am besten kaputtmacht und Wege aus der Misere

Oft zitiert und viel gelobt wird im Kontext von agiler Produktentwicklung das Thema Selbstorganisation. Ein Scrum Team soll selbstorganisiert und eigenverantwortlich arbeiten. Und auch so manchem nichtagilen Team würde eine Portion Selbstorganisation nicht schaden.
Doch was ist das eigentlich – Selbstorganisation?

Der Duden sagt dazu: „Spontane Entstehung, Bildung aus sich selbst heraus, ohne von außen wirkende Faktoren“

Und auf Wikipedia steht zum Thema Selbstorganisation in der Systemtheorie Eingangs: „Selbstorganisation ist das spontane Auftreten neuer, stabiler, effizient erscheinender Strukturen und Verhaltensweisen (Musterbildung) in offenen Systemen.“

Soweit so gut – aber wie schaffen wir es, diese spontanen, stabilen Strukturen in unsere Scrum Teams zu bekommen? Oder vielmehr – wie befähigen wir unsere Teams diese Strukturen selbst(!) zu schaffen?

Um zu verstehen was Selbstorganisation ist, müssen wir betrachten welche Rahmenbedingungen für die Entstehung dieser vorhanden sein müssen, welche Faktoren bei der Entstehung eine Rolle spielen und wie sie sich gegenseitig beeinflussen:

Alignment oder Ausrichtung bedeutet die Orientierung an ein Ziel. Diese Ziele können sehr konkret formuliert sein, wie beispielsweise Umsatzzahlen oder -steigerungen in einem Währungsbetrag oder in Prozent. Aber auch grobe Ziele wie z.B. eine Unternehmensvision zählen hier. Wichtig hierbei ist, dass diese Ziele den Teams in Frage auch bekannt sind und von ihnen verstanden und akzeptiert werden.

Autonomy bezieht sich auf den Freiheitsgrad, der während und zur Erreichung der formulierten Ziele gewährt wird. Dabei ist dies sowohl im Sinne von Freiheiten die zum Erreichen der Ziele gewährt werden gemeint, als auch im Sinne von einschränkenden Rahmendbedingungen die zu beachten sind. Dabei reicht die Skala vom formulieren konkreter Befehle/Anweisungen bis hin zur reinen Ergebnisorientierung. In einem Umfeld mit viel Alignment und wenig Autonomie gehen beispielsweise die Anweisungen bereits in Richtung Tätigkeitsbeschreibung. Im Extremfall wird dabei nicht einmal mehr das übergeordnete Ziel vermittelt. Andersherum, bei einem hohen Grad von Autonomie ohne oder mit nur wenig Alignment hat ein Team zwar alle Freiheiten, wird aber ohne kommuniziertes Ziel nur durch Zufall ein für die Organisation werthaltiges Ergebnis liefern.

Wie so oft liegt die „Ideale Lösung“ also in der goldenen Mitte – Teams brauchen die richtige Mischung aus Alignment – ein gemeinsames Ziel – sowie einen sinnvollen Grad an Autonomie um das Ziel auch erreichen zu können.

In obenstehender Matrix (angelehnt an die Spotify Engineering culture) wird das Zusammenspiel von Alignment und Autonomie verdeutlicht.

Nun verspricht die Überschrift, dass wir lernen, ebenjene Selbstorganisation zu zerstören. Also los!

Was wir in vielen Organisationen, mit und in denen wir arbeiten, beobachten können ist, dass um die agil arbeitenden Scrum Teams herum ein Organisationsmodell mit weiteren Rollen gebaut wird (zum Beispiel aus einem Skalierungsframework heraus). Auf die möglichen Gründe zur Schaffung dieses Rollenkonstrukts möchte ich hier nicht näher eingehen. Fakt ist, dass die dadurch geschaffene Komplexität Probleme verursacht, mit denen wir oft konfrontiert sind, sobald wir beginnen in einer Organisation oder einem Projekt zu arbeiten. Ein Beispiel für ein solches Rollenmodell sieht wie folgt aus:

Das Scrum Team ist umgeben von weiteren Rollen und Bedarfsträgern, die mit ihren jeweiligen Bedürfnissen und Problemen auf das Scrum Team oder einzelne Rollen/Personen innerhalb dieses zugehen und eine Lösung einfordern. Je mehr dieser externen Rollen vorhanden sind und je komplexer die Rahmenbedingungen der Organisation, in der die Teams arbeitet sind, mit desto mehr dieser Forderungen muss sich die Teams auseinandersetzen. Dies führt über kurz oder lang dazu, dass ein Team in eine rein reaktive Position gedrängt wird – es arbeitet nur noch Aufgaben ab. Mögliche Folgen dieser Situation sind die Vermischung des Product Backlogs mit Aufgaben aus der Organisation, die gar nichts mehr mit der eigentlichen Produktentwicklung zu tun haben oder die Aufnahme von „Storys“ ins Backlog, die dort in dieser Form nichts zu suchen haben. Je mehr die Teams aufgrund dieses Drucks von außen in die Defensive gerät, desto höher wird die Menge an Zugriffen von außerhalb.

So gerät die tatsächlich werthaltige Arbeit am Produkt immer weiter ins Hintertreffen. Ein Team, das nur noch auf Trigger von außen reagiert verlieren den Fokus auf das vereinbarte Ziel, das Produkt und den Kunden und schließlich auch die Motivation und Lust an der Arbeit.

Wie durchbrechen wir diesen Teufelskreis und sorgen dafür, dass unsere Teams wieder selbstorganisiert und proaktiv ihre Produkte entwickeln? Die einfache Antwort ist: Wenn all diese Rollen außerhalb der Scrum Teams ein berechtigtes Interesse an der Mitwirkung  der Erstellung des Produktes haben und über notwendige, nicht im Team vorhandenen Fähigkeiten verfügen, sollten wir sie in die Teams integrieren. So können sie mit ihren Fähigkeiten direkt mit auf das Ziel und Produkt mit einzahlen.

Da dies in vielen Organisationen jedoch nicht ohne weiteres möglich ist, brauchen wir eine andere Lösung. Wir müssen unseren Teams einen stabilen Rahmen schaffen, in dem sie selbstbestimmt und ‑organisiert arbeiten können. Außerdem müssen die umliegenden Rollen und Funktionen darauf sensibilisiert werden, sich selbst als Diener und Partner der Scrum Teams wahrzunehmen. Es sind die Scrum Teams, die die umliegenden Rollen mit Aufgaben vor sich hertreiben, die sich aus der Notwendigkeit in der Entwicklung des Produktes ergeben und nicht vom Team selbst gestemmt werden können. Die umliegenden Funktionen arbeiten in diesem Modell den Scrum Teams zu. Sie unterstützen beim Refinement des Backlogs, der Einbettung der Produktarchitektur in die Makroarchitektur der Organisation, sie schaffen die Rahmendbedingungen und den Freiraum den das Team braucht um das bestmögliche Produkt zu entwickeln.

 In diesem Modell drehen sich die Pfeile aus obenstehender Grafik um:

Die Scrum Teams sind nun die Treiber im Prozess, sie fordern proaktiv Leistungen von ihrer Umgebung ein, die sie wirklich brauchen und sind befähigt die Entwicklung ihres Produktes selbstorganisiert voranzutreiben.

Wenn Dir der Artikel gefallen hat, Du Feedback zum Artikel hast oder Deine Erfahrungen zu dem Thema mit uns austauschen möchtest, kontaktiere uns gerne über marketing@mid.de oder schreibe direkt an b.stange@mid.de, wir freuen uns auf Deine Nachricht!