Wie Scrum Autonomie fördert

  • Wie Scrum Autonomie fördert

Wie Scrum Autonomie fördert

Die Entwickler von Scrum legen großen Wert darauf, dass das im Scrum Guide definierte Rahmenwerk exakt so umgesetzt wird, wie es dort beschrieben wird. Trotz allem begegnen mir immer wieder Menschen, die der Ansicht sind, dass Scrum ja nur „allgemeine Richtlinien“ enthalte.

Tatsächlich gibt es kaum ein Regelwerk, das mit lediglich 19 Seiten auskommt und dem es zeitgleich gelingt, sowohl wichtige Säulen für agiles Arbeiten zu etablieren als auch jedem größtmögliche Freiheiten bei der Umsetzung einzuräumen. Scrum kennt lediglich 3 Rollen, 4 Events, und 3 Artefakte – mehr nicht! Den Rest kann jeder bei der Umsetzung so frei wie es nur irgend denkbar ist, ausgestalten. Und trotzdem fühlen sich stets einige Auserwählte Menschen dazu berufen, Anpassungen oder Modifikationen an Scrum vorzunehmen, damit es in ihr Unternehmen „passt“.

Vielleicht ist es gerade die Kürze des Scrum Guides, die manch einen die Präzision des Rahmenwerks übersehen lässt. Vielleicht ist der eine oder andere auch nicht zufrieden, wenn er einem so offenen Rahmenwerk nicht durch eine mutwillige Verschlimmbesserung eine persönliche Note aufdrücken kann.

In dieser Blogserie möchte ich deshalb einmal aufzeigen, wie das Scrum-Regelwerk auf den drei Säulen für MotivationAutonomie, Flow und Gemeinschaft – aufbaut und diese verwirklicht. Vielleicht hilft das dem einen oder anderen, zu verstehen, warum es so wichtig ist, nicht an den Grundprinzipien Scrums zu rütteln und es so umzusetzen, wie es gedacht ist. In diesem Artikel geht darum zu zeigen, wie Scrum Autonomie fördert.

Vier Autonomie-Elemente

Edward Deci hebt in seinem Meisterwerk Why we do what we do hervor, wie wichtig es für unsere Motivation und unser Engagement ist, dass wir uns als autonom erleben. Wenn wir uns genauer anschauen wollen, wie Scrum Autonomie erzeugt, ist es hilfreich, Dan Pinks Unterscheidung zwischen Team, Task, Technique und Time zu Grunde zu legen. Denn dadurch wird deutlich, dass zwar ein Scrum Team als Ganzes vollkommen autonom arbeitet, aber diese vier Elemente nicht auf jede einzelne der drei Rollen verteilt wird. (Warum das so wichtig ist, werde ich in einem späteren Artikel noch einmal aufzeigen.)

Technique (Wie)

Die Entwickler eines Scrum-Teams genießen größtmögliche Freiheit bei der Umsetzung eines Sprintziels. Der Scrum Guide garantiert ihnen vollkommene Autonomie, welchen Weg sie beschreiten möchten:

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; (Scrum Guide, Seite 7)

Solche Sätze treiben einem klassischen Projektmanager wahrscheinlich direkt den Schweiß auf die Stirn. Und sicherlich ist die Umsetzungsfreiheit des Entwicklerteams auch einer der Gründe dafür, warum es die Rolle des Scrum Masters gibt. Zu groß ist oft das Bedürfnis von Managern und Führungskräften sich in die Arbeitsweise eines Teams einzumischen. Und sicherlich ist es auch genauso häufig der Grund dafür, warum einige sagen, dass Scrum „bei ihnen nicht umsetzbar sei.“ Weil man glaubt, dass die eigenen Mitarbeiter, nicht in der Lage wären, selbstorganisiert und selbstverantwortlich zu arbeiten.

Doch das Gegenteil ist der Fall: Mitarbeiter können keine Verantwortung für ihre Arbeit übernehmen, wenn man ihnen nicht die Möglichkeit dazu gibt, das wirklich zu tun. Wenn eine Organisation einem Mitarbeiter Verantwortung entzieht (z. B. durch einen Vorgesetzten), dann kann ein Mitarbeiter auch keine Verantwortung übernehmen. Denn die Verantwortung wird ja über die Spielregel „Der Vorgesetzte hat die Verantwortung“ definiert.

Die Spielregeln des Unternehmens oder eines Teams müssen es möglich machen, Verantwortung zu übernehmen. Der Wert „Verantwortung übernehmen“ muss sich also in irgendeiner Form in einer Mechanik wiederfinden. Bei Scrum ist das durch den obigen Satz verwirklicht.

Time (Wann)

Auf den ersten Blick scheint der Scrum Guide ziemlich streng zu sein, was die zeitliche Organisation der Arbeit angeht. Alle Events sind exakt definiert: das Wörtchen time-boxed begegnet uns ziemlich oft. „Sprints dürfen maximal einen Monat lang sein“, „Ihre Länge darf nicht verändert werden“, „Das Daily Scrum soll maximal 15 Minuten lang sein“ etc. Aber diese Fixpunkte dienen in erster Linie dazu, Transparenz zu erzeugen und das Scrum Team in einen Rhythmus zu bringen. Außerdem sind diese zeitlich fixierten Events wichtig, um Flow zu erzeugen.

Sieht man aber von den vier Scrum-Events (Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective) einmal ab, genießen die Entwickler eines Scrum Teams innerhalb des eigentlichen Sprints absolute zeitliche Freiheit. Es obliegt den Entwicklern des Scrum Teams zu entscheiden, wann und wie lange sie sich den Aufgaben im Sprint Backlog zuwenden möchten.

Selbstverständlich sind sie zeitgleich dafür verantwortlich, dass sie zum Ende des Sprints ein fertiges Increment vorweisen können. Auf der einmonatigen Reise dorthin dürfen und sollen sie jedoch absolute Hoheit über ihre aufgewendete Zeit haben. Da ist es nur logisch, dass niemand Überstunden anordnen kann, wenn sich abzeichnet, dass ein Scrum Team das Sprintziel nicht erreichen wird, sondern stattdessen der Umfang des Sprintziels auf den Prüfstand kommt.

Team (Mit wem)

Darüber, wie ein Scrum Team entsteht (oder geformt wird), verliert der Scrum Guide tatsächlich kein einziges Wort. Auf den ersten Blick scheint es also denkbar, dass Vorgesetzte oder irgendwelche Manager ein Scrum Team auf dem Reißbrett definieren können. Man würfelt einfach ein paar Menschen zusammen, von denen man der Meinung ist, dass sie sich in ihren Fähigkeiten gut ergänzen (Stichwort cross-functional) und fertig ist das Scrum Team.

Zusätzlich gibt es auch verschiedene Diskussionen darüber, ob beispielsweise ein Scrum Master die Befugnis habe, einen Entwickler aus einem Scrum Team „herauszunehmen“, wenn es zu fortdauernden Konflikten führt und das Team nicht (mehr) funktioniert. (Wenn Du in diese Diskussion tiefer einsteigen willst, empfehle ich Dir übrigens den lesenswerten Artikel Myth: The Scrum Master can’t remove people from the Scrum Team von Christiaan Verwijs, immerhin Professional Scrum Master Curriculum Steward bei Scrum.org) In solchen Situationen stehen sich Scrum Werte gegenüber und sorgen für Schwierigkeiten bei der Lösung des Problems.

Wenn wir von solchen Extremsituationen aber einmal absehen wollen, steht bei Scrum Autonomie in der Teamkonstellation ebenfalls  im Vordergrund:

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. (Scrum Guide, Seite 6)

Als Teil der Selbstorganisation ist es also einerseits Aufgabe der Entwickler, Konflikte innerhalb des Teams oder mit anderen außerhalb des Teams selbst zu lösen. (Bei Bedarf natürlich auch mit Unterstützung des Scrum Masters.) Nicht umsonst ist ja gerade (gegenseitiger) Respekt einer der fünf Grundwerte von Scrum:

Scrum Team members respect each other to be capable, independent people. (Scrum Guide, Seite 5)

Andererseits lässt sich Autonomie eines Scrum Teams auch durchaus so verstehen, dass ein existierendes Team selbst entscheiden kann (und sollte), wer Teil des Scrum Teams ist und wer nicht. Es ergibt schlichtweg keinen Sinn, von „außerhalb“ zu bestimmen, wer Entwickler in einem Scrum Team werden soll und wer nicht. Deshalb denke ich, dass jeder Product Owner, Scrum Master (oder auch Projekt Manager) gut beraten ist, den Entwicklern eines Scrum Teams mindestens ein Mitspracherecht bei der Aufnahme neuer Teammitglieder einzuräumen. Wenn nicht sogar volle Autonomie.

Aber auch im Kleinen haben die Entwickler während des Sprints die Entscheidungsfreiheit, mit wem sie bestimmte Aufgaben bewältigen und lösen möchten. Niemand kann einem Entwickler sagen: „Erledige diese Aufgabe gemeinsam mit Entwickler Meier!“ Ein Entwickler entscheidet selbst, mit wem er eine Aufgabe lösen möchte.

Task (Was)

Auch das Was wird durch den Scrum Guide klar definiert. Scrum Teams kennen nur einen einzigen Quell der Wahrheit: das Product Backlog. Und es steht unter der absoluten Hoheit des Product Owners.

It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. (Scrum Guide, Seite 15)

und weiter:

For the Product Owner to succeed, the entire organization must respect his or her decisions. (Scrum Guide, Seite 6)

Während also bei den Entwicklern eines Scrum-Teams der Schwerpunkt auf dem Autonomie-Wie liegt (unter anderem in Form des Sprint Backlogs), repräsentiert das vom Product Owner verwaltete Product Backlog das Autonomie-Was. 

Würde man das übrigens nun so verstehen, dass der Product Owner ins Product Backlog hineinschreiben kann, was er will, ohne auf die Wünsche und Bedürfnisse von Kunden und Stakeholdern einzugehen, verwechselt man Autonomie mit Unabhängigkeit! Natürlich ist der Product Owner nicht vollkommen unabhängig. Ganz im Gegenteil: Seine Aufgabe ist es ja gerade, den Wert des Products zu maximieren. Und was wertvoll ist und was nicht, definiert in der Regel der Kunde und andere beteiligte Stakeholder.

  • Wenn Du mehr zum Unterschied zwischen Autonomie und Unabhängigkeit wissen möchtest, empfehle ich Dir meinen Artikel Autonomie verstehen.

Fazit

An dieser Stelle kommt die dritte Säule für Motivation – Gemeinschaft – ins Spiel, auf die ich in einem späteren Artikel eingehen werde. Hier und jetzt können wir abschließend festhalten, dass Scrum Autonomie dadurch fördert, dass alle von Dan Pink genannten Elemente (Technique, Time, Team und Task) in die Hände des gesamten Scrum Teams gelegt werden. Die Spielregeln des Scrum Guides sind an jeder erdenklichen Stelle darauf bedacht, die Autonomie des Scrum Teams zu verwirklichen (und zu schützen).

Wenn wir also durch Scrum Autonomie erzeugen wollen, sind genau das die Grundsätze, die wir befolgen müssen. Ändern wir diese Spielregeln, geht Autonomie verloren.

Mehr Infos

Scrum & Agiles Projektmanagement

Du möchtest Scrum in Deinem Unternehmen oder Deiner Abteilung einführen, weißt aber nicht wie Du vorgehen sollst? Ich berate Dich gerne!

Mehr Infos
Von |2018-07-08T18:53:30+00:003. Juli 2018|Kategorien: Motivation, Scrum|Tags: , , |1 Kommentar

Über den Autoren:

Ich glaube an eine Arbeitswelt, in der Menschen darauf brennen, am Montag endlich wieder zur Arbeit gehen zu dürfen. Deshalb inspiriere ich Menschen, Unternehmen und Organisationen, Arbeitsumgebungen so zu gestalten, dass sich Motivation und Engagement entfalten können.

Ein Kommentar

  1. […] Wie Scrum Autonomie fördert […]

Hinterlasse einen Kommentar

Diese Website benutzt Cookies und anderes Teufelswerk. Näheres dazu findest Du auf unserer Datenschutz-Seite. Verwalte hier Deine Einstellungen Einverstanden

Angebote von Drittanbietern

Hier kannst Du auswählen, welche Angebote von Drittanbietern Du während Deines Besuches auf dieser Webseite erlauben möchtest und welche nicht.