Ist ein Mitglied eines Scrum-Entwicklungsteams „committed“ zum Sprint Goal?


Cambridge Dictionary – “commitment”: “willingness to give your time and energy to a job, activity, or something that you believe in”.

Banale Frage! Dachte ich. Kürzlich bei einer Diskussion zum Thema reichten die Reaktionen von „ja klar!“ bis hin zu „auf keinen Fall!“. Also Anlass ein paar Gedanken zu sortieren.
Bei unseren Vierbeinern ist es einfach – einen Hund muss man nicht zum Jagen tragen – „commitment“ ist sein natürlicher Zustand, wenn es darum geht, eine Katze zu jagen. Er wird auch nicht unterwegs nach einer Entschuldigung Ausschau halten für den Fall, dass er die Katze nicht erwischt. Wenn ein echtes Team sich ein Ziel selbst gesteckt hat, ist der natürliche Zustand, dass alle Mitglieder des Teams das Ziel mit aller Kraft erreichen wollen, sofern nicht irgendwelche Rahmenbedingungen dagegensprechen. Menschen haben einen natürlichen Drang an etwas Bedeutsamen teilzuhaben, das über ihre eigenen Interessen hinaus geht. Da Scrum Teams sich aber im Unterschied zu unseren Vierbeinern in einem komplexen sozialen Umfeld mit vielen Abhängigkeiten und kulturellen Parametern bewegen, rentiert es sich hier einmal näher hinzusehen und den Scrum Guide dazu zu beleuchten.

Laut Scrum Guide ist es klar: „commitment“ ist einer der fünf Werte, und bezüglich der Ziele des Scrum Teams heißt es wörtlich:

“People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum-Team.“

Also laut Scrum Guide ein eindeutiges „Ja“, da ein Sprint Goal ganz sicher zu den Zielen des Scrum Teams gehört. Interessant ist: der Scrum Guide beschränkt das nicht nur auf das Sprint Goal, andere Ziele des Scrum Teams sind ebenso gemeint, z.B. die Entwicklung des Teams, um nur eines zu nennen. Aber das nur nebenbei.

– Wie ist nun aber „commitment“ zu interpretieren? –
– Warum lehnen manche das lieber ab? –

Je nach Unternehmen ist der Begriff „commitment“ unterschiedlich geprägt. Diese Prägung entsteht durch die vorherrschenden Denkweisen und Organisationsstrukturen. Das jeweilige Verständnis hängt dabei von vielen Faktoren ab, ob beispielsweise eine Vertrauenskultur herrscht, oder nicht. Ob die Mitarbeitergehälter von Zielerreichung abhängen oder nicht. Und vieles mehr… 

– Wie die harte Tour gespielt wird… –

Bei einem Frühstück mit Ei und Speck, sind die Schweine „committed“, die Hühner nur beteiligt (involved)“. Die Entwickler sind in diesem Fall die „armen Schweine“, denen echte Konsequenzen drohen. Die „Hühner“, also alle anderen Beteiligten, sind einigermaßen fein raus. Nicht besonders respektvoll würde ich sagen und damit auch nicht agil. Eine Sichtweise, welche vermutlich nicht den offenen Umgang mit Fehlern, Lernen, Vertrauen, Selbstverantwortung und Selbstorganisation fördern wird. Früher war diese Metapher im Scrum Guide enthalten, um den unbedingten Willen zur Zielerreichung zu unterstreichen, wurde aber bewusst aus dem Scrum Guide entfernt, da sie eben zu solchen Missverständnissen geführt hat.

– Wie anders? –

Die Wortwahl und kleine Details, welche im Scrum Guide leicht übersehen werden, geben über den zugrunde liegenden Geist, das Menschenbild und die Führungsphilosophie Aufschluss. Im Scrum Guide wird nicht vom Teammitglied oder Team gesprochen, sondern von „people“ und „everyone“. Nicht nur der einzelne Entwickler, nicht nur das Entwicklerteam ist angesprochen, nicht einmal beim Scrum-Team wird hier Halt gemacht, sondern es geht um alle, die irgendwie ein Interesse am Ergebnis haben, einschließlich aller sonstigen Stakeholder wie Management und Kunden. Das heißt, es geht um das gemeinsame Wirken an einem Ziel, bei dem jeder seine Verantwortung erkennt und lebt. Dies eröffnet einen deutlich größeren Horizont. Jeder Beteiligte ist „committed“, unterstützt nach besten Kräften und trägt seinen Teil bei.

Der zweite Aspekt wird in der deutschen Übersetzung des Scrum Guides deutlich. Hier wird „commitment“ mit „Selbst-Verpflichtung“ übersetzt. Das Entwickler-Team wird also nicht von außen „ver-pflichtet“ sondern folgt der eigenen Verpflichtung, das gemeinschaftlich gesteckte bzw. verhandelte Sprint Goal zu erreichen. Das wiederum ist eine wichtige Grundlage für die Selbstorganisation und kontinuierliche Verbesserung.

– Booster für Effektivität und Spaß: „commitment“ im Wandel … –

In einer agilen Transformation müssen, je nach bestehender Unternehmenskultur, selbst Begriffe wie „commitment“ einen Wandel erfahren. Falsch verstanden, kann das großen Schaden für das agile Mindset bedeuten. Dann versucht jeder möglichst nicht die Deckung zu verlieren, auf Fragen wie z.B. „wie gerate ich möglichst nicht in eine Schusslinie“ wird viel Zeit und Energie verschwendet. Solche Fragen werden keine Relevanz haben, wenn aus dem „Du“ ein „Wir“ wird, wenn alle ihr Bestes geben (Product Owner, Entwickler-Team und alle irgendwie am Resultat interessierten), für das Sprint Goal zusammenwirken, weg von einem in Stein gemeißelten „Vertrag“. Und es eröffnet sich die Möglichkeit zu lernen, sich zu entwickeln, als Einzelner, als Team, als Organisation. Und das Beste: das bringt auch noch Spaß!

—- © Henrik Ginzkey 2020 —-

Was meint Ihr dazu?

Schwächen in der agilen Struktur mit Selbstorganisation heilen?

Selbstorganisation klingt nach Autonomie und Freiheit: Selbstbestimmung und mehr Möglichkeiten für die Teams und Abgabe der Verantwortung durch die bisher „Verantwortlichen“ an die, welche die eigentliche Wertschöpfung betreiben. Also in jedem Fall eine tolle Sache, oder?

Neulich im Büro…


Was Ist passiert?

(1) Ein Teil des Frameworks wurde weggelassen. Es gab auch einen „guten“ Grund dafür: Hier war es in der ersten Betrachtung die Effizienz, die häufig wie ein Mantra in unseren Unternehmen verwendet wird. Dahinter steht eine Denkweise, die aus den Anfängen des Industriezeitalters stammt.

Kommt Euch das so oder ähnlich bekannt vor?

Und weiter…

(2) Der Gedanke „wir haben doch selbst-organisierende Teams“ kam auf. Verlockende Idee, im ersten Reflex die Verantwortung für die Abstimmung an die Teams abzugeben.

Die Effizienz-Falle bei der Adaption eines agilen Frameworks:

Effizienz bedeutet allgemein, mit wenig Aufwand zu gewünschten Ergebnissen zu kommen und ist im ökonomischen Bereich ein Maß für die Wirtschaftlichkeit, beinhaltet also konsequentes Kosten-Nutzen Denken.

Effizienz= Ergebnis / Aufwand

Voraussetzung dafür ist ganz allgemein, dass es sich um wohlbekannte Prozesse handelt die im Wesentlichen linear ablaufen, also wenig Komplexität beinhalten. Da sieht man sich einfach die einzelnen Schritte an und versucht diese zu optimieren.

Angewendet auf ein komplexes agiles Framework führt dies aber oft nicht zum Erfolg. Greife ich einen Teil heraus, laufe ich Gefahr eine lokale Optimierung zu machen, welche sich jedoch auf das Gesamtsystem negativ auswirken kann.

Im Scrum Guide heißt es beispielsweise: „Das Scrum-Rahmenwerk besteht aus Scrum-Teams und den zu ihnen gehörenden Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.“ Dies gilt genauso für skalierende Frameworks wie LeSS, SAFe, Scrum@Scale, Nexus, etc.

Die einzelnen Komponenten bestehend aus Rollen, Ereignissen, Artefakten und Regeln bilden ein Gesamtsystem und hängen wie ein mehrdimensionales Netz zusammen. Schön veranschaulicht wird das in einem mechanischen Tensegrity Modell, dessen einzelne Komponenten flexibel miteinander verbunden sind. Wenn man an einer Stelle zieht oder drückt, ändert sich die komplette Struktur.

Tensegrity Modell

Kann ich denn hier nicht auf Selbstorganisation zählen?

Wenn Mechanismen fehlen, die den Teams in der übergreifenden Zusammenarbeit helfen, dann ist die Misere vorprogrammiert: Die Teams sollen zu ihrer bisherigen oft übergroßen Last sich selbst und übergreifende Themen organisieren und
möglicherweise auch noch mangelnde Priorisierung kompensieren, wozu sie kaum in der Lage sein werden. Dann bilden sich Kommunikationstunnel, Einzelpersonen oder Grüppchen reden miteinander, andere nicht, ein Team versucht etwas anzuschieben, wird aber nicht unterstützt – letztendlich chaotische Zustände. Schließlich habt ihr fehlerhafte übergreifende Features, unvollständig, unkoordiniert implementiert, die nicht getestet werden können etc.

Selbstorganisation – ein unbedingtes „ja!“, aber …

… eben nicht als Ausgleich für fehlende Struktur. Wenn die richtigen Strukturen vorhanden sind, in denen Selbstorganisation stattfinden kann ja, ansonsten Finger weg!

Selbstorganisation in der Gruppe benötigt einen förderlichen, stabilen Rahmen, in dem sie stattfinden kann. Fehlt dieser, dann findet auch eine Art „Selbstorganisation“ statt, dies aber auf eine chaotische Weise. Das skalierende agile Framework muss also sauber eingeführt sein – zusammen mit allen Mechanismen, welche die Selbstorganisation der Teams erst ermöglichen. Lasst euch mit der Adaption des Frameworks viel Zeit, um Erfahrung zu sammeln, um zu spüren wie sich das als Gesamtes anfühlt. Bis Ihr schließlich auch merkt, wo ihr Schwierigkeiten habt und warum bzw. wo die wirklichen Ursachen liegen, und was Selbstorganisation eigentlich genau bedeutet. Erst dann könnt Ihr langsam anfangen, an den Stellschrauben zu drehen.

Viel Spaß beim ausprobieren und Erfahrung sammeln!