Von selbstorganisierenden zu selbstmanagenden Scrum-Teams – Was ist der Unterschied?

Selbstorganisierende, selbstmanagende Scrum Teams - Was ist der Unterschied

Der Scrum Guide 2020 hat einige Änderungen gebracht. Die meisten sind gut verständlich und deren Sinn und Nutzen ist klar erkennbar. Eine Anpassung ist aber nicht so einfach erklärbar und der Nutzen nicht unbedingt ersichtlich. Self-organizing wurde durch Self-managing ersetzt. Kennen Sie den Unterschied zwischen diesen zwei Organisationsformen? Dieser Artikel zeigt Ihnen was der Unterschied ist und wie sich dieser auf die Arbeitsweise des Scrum-Teams auswirkt. Habe ich Sie neugierig gemacht? Dann lesen Sie schnell weiter!

Scrum Teams managen sich neu selbst

Von allen Änderungen im neuen Scrum Guide 2020 wirft vermutlich die Änderung von self-organizing team zu self-managing team am meisten Fragen auf in der agilen Gemeinschaft. Schon seit den 1960er Jahren gibt es selbstorganisierende Teams. In meinem Artikel: Was sind selbstorganisierende Teams in agilen Projekten, habe ich bereits ausführlich über diese Organisationweise geschrieben.

Im Scrum Guide 2017 steht folgendes:

„Scrum-Teams sind selbstorganisierend und funktionsübergreifend. Selbstorganisierende Teams wählen, wie sie ihre Arbeit am besten erledigen, anstatt von anderen außerhalb des Teams geleitet zu werden. Funktionsübergreifende Teams haben alle Kompetenzen, die benötigt werden, um die Arbeit zu erledigen, ohne von anderen, die nicht Teil des Teams sind, abhängig zu sein.”

Im Scrum Guide 2020 lesen Sie neu folgendes:

„Scrum-Teams sind funktionsübergreifend, d.h. die Mitglieder verfügen über alle notwendigen Fähigkeiten, um bei jedem Sprint Werte zu schaffen. Sie sind auch selbstmanagt, d.h. sie entscheiden intern, wer was, wann und wie macht.“

Was Selbstmanagement für Scrum Team genau bedeutet wird dann wie folgt beschrieben:

„Das Scrum-Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholdern, Überprüfung, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert. Das Arbeiten in Sprints mit einer nachhaltigen Geschwindigkeit verbessert den Fokus und die Kontinuität des Scrum Teams“.

Es hat sich nur ein Wort geändert aber nicht wie das Team arbeitet

Auch schon vor dem neuen Scrum Guide haben sich die Team-Mitglieder abgestimmt: Wer macht Was und wann und wie machen wir es. An der „Arbeitsorganisation“ im Team hat sich nichts geändert. Es wird vermutlich nur versucht nach außen klarer zu machen, wie das Team agiert und in welchem Grad das Scrum-Team verantwortlich ist.

Der Begriff „Selbstorganisation“ war Ken Schwaber und Jeff Sutherland vermutlich zu „schwammig“, denn jedes System ist in einem gewissen Grad selbstorganisiert. Personen organisieren sich grundsätzlich selbst, ob sie dies gerichtet tun oder chaotisch. Aber ein weiterer Hinweis, wie die beiden Herren zu „self-managing“ kamen ist, sie haben sich vermutlich mit der Authority Matrix von Richard Hickman befasst. Was steckt dahinter? Lesen Sie weiter und erfahren Sie mehr dazu.

Die Authority Matrix von Richard Hackman

John Richard Hackman, PhD (1940-2013) war ein führender Experte für Teams und leistungsorientierte Gruppen in Organisationen. In seinem 2012 erschienenen Buch “Leading Teams: Setting the Stage for Great Performances” hat er seine Autoritätsmatrix dargestellt und vier Ebenen der Autoritätsvergabe an Teams beschrieben. Schauen wir uns Hackmans vier Ebenen der Teamautorität mal an, beginnend mit Teams mit der geringsten Autorität:

  • Manager-geführte Teams (Manager-led teams) überlassen den Teammitgliedern nur die Autorität für die Aufgabenausführung, während die Manager die Arbeitsprozesse überwachen und steuern, den Kontext gestalten und die Richtung vorgeben. Expertengruppen in funktionalen Silos sowie herkömmliche Projektteams sind praktische Beispiele für diese Konstellation.
  • Selbstmangende Teams (Self-managing teams) übernehmen nicht nur die Verantwortung für die Aufgabenausführung, sondern managen auch den Fortschritt. Innerhalb der IT gibt es viele Kanban- und Scrum-Teams, die diesen Ansatz anwenden und sich entweder auf Teamaufgaben oder auf teamübergreifende Wertströme konzentrieren.
  • Selbstgestaltende Teams (Self-designing teams) geben den Mitgliedern die Autorität, das Design ihres Teams und/oder Aspekte des organisatorischen Kontexts, in dem sie arbeiten, zu verändern. Die meisten echten Management-Teams befinden sich in dieser Position, ebenso wie einige Scrum-Teams, besonders wenn Lean/Agile skaliert wird.
  • Selbstverwaltende Teams (Self-governing teams) haben die Verantwortung für alle vier Kernfunktionen, wie es bei Unternehmensvorständen, Arbeitergenossenschaften oder Start-ups der Fall ist.
Die Authority-Matrix von Hackman beschreibt self-managing teams in Scrum (Scrum Guide 2020)
Die Authority-Matrix von Richard Hackman

Wo passt nun Selbstorganisation hin?

In Hackmans Autoritätshierarchie würden selbstorganisierende agile Teams als Selbstmangende Teams (Self-managing teams) klassifiziert werden. Agile Teams managen ihre Arbeit selbst (welches Teammitglied soll welche Aufgabe erledigen? Wann? Und wie?). Agile Teams sind jedoch nicht selbst-gestaltend oder selbst-verwaltend. Mit anderen Worten: Ein selbstorganisierendes agiles Team hat Autorität über seine Arbeit und den Prozess, den es verwendet, aber nicht darüber, wer z. B. im Team ist oder was das Ziel des Teams ist.

Ist es nun also selbstorganisierend oder selbstmanagt?

Im Einleitungstext habe ich Sie gefragt: Kennen Sie den Unterschied? Aus meiner Sicht können Sie es so oder so nennen. Für mich macht das keinen Unterschied. Ich persönlich bevorzuge selbsorganisierend weil:

Self-organizing wurde im ersten veröffentlichten Artikel über Scrum (1986 Harvard Business Review: The New New Product Development Game) so beschrieben. Die Autoren dieses Artikels, Takeuchi und Nonaka, betrachteten Selbstorganisation als eine der sechs Eigenschaften, die notwendig sind, um einen “schnellen, flexiblen Prozess” zu schaffen. Auch gibt es Self-organizing oder Self-directed Work Team (SDWTs) schon seit den 1960er Jahren – haben also schon eine lange Geschichte.

Wäre nicht auch Selbstgestaltend möglich?

Niemand hindert ein Team daran zu wachsen und mehr Verantwortung zu übernehmen. Das Unternehmens-Management fragt sich natürlich: Wie viel Selbstorganisation wollen wir bei uns überhaupt haben? Soll ein Team sogar seine eigenen Team-Mitglieder selber bestimmen dürfen oder Mitglieder entlassen? Wäre das denn nicht schon ein Self-desgining Team? Ich finde ein Scrum-Team sollte dies können oder mindestens ein relevantes Mitspracherecht diesbezüglich haben.

So, jetzt sind wir am Schluss dieses Artikels und Sie fragen sich vielleicht: “so viel Text, nur wegen zwei Wörtern”? Ja, das hat mich auch erstaunt! Selbstorganisation ist ein zentrales Element bei Scrum und im agilen Projektmanagement. Deshalb war dieser Text vermutlich doch sinnvoll.

Literatur zu diesem Artikel:

Hier gibt es noch mehr Wissen

Dies war eine Übersicht, was selbstorganisierende und selbstmanagende Teams in Scrum sind. Was sind Ihre Erfahrungen mit solchen Teams?  Stimmen Sie mit meinen Aussagen überein oder haben Sie eine andere Ansicht oder Ergänzungen? Teilen Sie Ihre Erfahrung den Lesern unten im Kommentarfeld mit, damit wir alle eine weitere Sicht kennenlernen. Danke!

Möchten Sie mehr erfahren, wie Sie Ihre Projekte mit agilem Projektmanagement und Scrum noch erfolgreicher machen? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!

Kennen Sie jemanden, den dieser Artikel auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn. Danke!

HAT DIR DIESER ARTIKEL GEFALLEN?

Erhalte monatlich meine Blog-Updates und mein kostenloses eBook: Projektplanung

E-Mail Adressen werden vertraulich behandelt und nie weitergegeben

Posted in Agiles Projektmanagement.

Leave a Reply

Your email address will not be published. Required fields are marked *