menu Navigation
Es gibt kein Commitment in Scrum

Projektmanagement

Es gibt kein Commitment in Scrum

15. Juli 2011

photocaseu7txkhnx52381261-heller-150x150

„Zum Ende der Sprintplanung gibt das Team sein Commitment gegenüber dem Product-Owner ab.“ Eine Aussage in dieser oder ähnlicher Form habe ich schon oft gehört. In Blogs, in Büchern und vor allem im Rahmen von Trainings und Coachings fallen Sätze wie dieser. Ist man dann beim Thema „Commitment“, geht es weiter mit:

„Das Team will kein Commitment abgeben, weil ihnen die Anforderungen zu unklar sind, was tun?“ oder „Was tun wir als Team, wenn wir uns commiten und das dann nicht einhalten können?“ oder auch „Was kann ich tun, wenn das Team sich auf zu wenig Arbeit commitet?“.

Nun habe ich gerade gemeinsam mit einem Kollegen unser Professional Scrum Training aktualisiert und wir haben nochmal sichergestellt, dass die Teilnehmenden auch alles mitbekommen, um gut auf die Professional Scrum Master Zertifizierung vorbereitet zu sein. Das ist für uns natürlich auch immer eine klasse Übung, weil sie einen zwingt sich noch mal ganz genau mit einem Thema auseinander zu setzen und zu prüfen, wovon man überzeugt ist, das es so wäre und was tatsächlich irgendwo geschrieben ist. Beim Thema Commitment war der Auslöser die Frage, wann denn das Team sein Commitment eigentlich genau abgibt. Also Scum-Guide aufgemacht und nach Commitment gesucht… mmh… irgendwie …

„Das Commitment“ habe ich im Scrum-Guide nicht gefunden, dafür ein „Committed Team“. Das macht für mich ein wesentlichen Unterschied.

Das Commitment würde ich, für sich stehend, erstmal als ein Versprechen übersetzen und im Kontext vieler Organisation, insbesonders in den eher „nicht-agil“ geprägten, wird daraus auch schnell ein Vertrag. Am besten wird das Commitment auch  formal dokumentiert, damit der Product Owner am Ende des Sprints mit Hilfe des Scrum Masters die Versäumnisse ansprechen kann.

Wenn ich von einem „Committed Team“ höre, habe ich ein anderes Bild. Es ist das Bild eines Teams, welches Verantwortung für seine Arbeit übernimmt und daran arbeitet, verbindliche Aussagen treffen zu können. Wenn sich das Team dann zu einem Sprint-Ziel und der Realisierung von Backlog-Einträgen „committed“, dann bedeutet das, dass das Team sorgfältig prüft, was aus seiner Sicht realistisch ist und dafür sorgt, das bei Problemen z.B. der Product Owner rechtzeitig eingebunden wird, um eine Lösung zu finden. In diesem Bild ist es auch möglich, sich auf Backlog-Einträge zu committen welche unklar sind. Entscheidend ist, dass das Team dies sichtbar gegenüber den Beteiligten macht und klärt, wie damit umgegangen wird.

Und weil das Team die Verantwortung nimmt, verlässliche Aussagen zu treffen, wird es auch kontinuierlich an seiner Fähigkeit arbeiten, im Treffen und Einhalten von Aussagen besser zu werden. Und das schließt das gesamte Scrum-Team mit ein, also auch Product-Owner und Scrum-Master.

Daher mein Appell an alle Scrum-Teams: „Hört auf mit dem Commitment und fangt an Euch zu commiten!“

6 Antworten zu “Es gibt kein Commitment in Scrum”

  1. Bernd Oestereich sagt:

    … und jetzt noch mal auf Deutsch?

    LEO übersetzt „to make a commitment“ mit „sich festlegen“ – hier ginge es dann nur darum, dass das Team eine Entscheidung trifft, sich einigt, was es leisten kann. Das Wort mit „Haftung“ oder „Einstandspflicht“ zu übersetzen ist auch möglich, passt aber eben nicht zum agilen Kontext.

    „Hört auf mit dem Commitment und fangt an Euch zu commiten!“ hilft meiner Meinung nach aber auch nicht weiter, denn die Unterscheidung Substantiv oder Verb ändert hier die Bedeutung nicht zwingend und erlaubt ebenfalls zu viele Bedeutungszuschreibungen.

    Das eigentliche Problem ist doch, dass eine sprachliche Tilgung existiert, die mit den W-Fragen aus der Sesamstraße identifiziert werden kann („… wer nicht fragt, bleibt dumm“). In diesem Fall die Frage nach dem „was“: zu WAS verpflichtet sich das Team? WAS legt das Team fest?

    Eine vertragliche, einklagbare, für den Product Owner absolut verlässliche Zusage zu bestimmten Ergebnissen?

    Oder eine (weniger verbindliche) Absicht, bestimmte Ergebnisse zu liefern?

    Oder eine Aussage, welche Ergebnisse es für möglich/realistisch/wahrscheinlich hält?

    Die Frage nach Verb oder Substantiv wird dann unwichtig:

    Die Aussagen „Das Team legt den beabsichtigten Lieferumfang gegenüber dem Product Owner fest“ und „Das Team gibt eine Festlegung des beabsichtigten Lieferumfanges gegenüber dem Product Owner“ unterscheiden sich inhaltlich wenig.

    Also mein Fazit: erst einmal sprachliche Tilgungen finden und heilen.

    Davon abgesehen glaube ich ja auch, dass Übersetzen hilft (es verlangt nämlich vom Übersetzer Entscheidungen und stößt ihn oft mit der Nase auf die Tilgungen).

    Bernd

  2. Jan Gentsch sagt:

    Hallo Bernd,

    übersetzen hilft definitiv. Das Poblem mit Übersetzungen ist dann aber wiederum, das Sprache sich vor einem kulturellen Hintergrund abspielen und dann noch in einem inhaltlichen Kontext steht. Das Wort Commitment taucht im Scrum-Guide (englisches Original, der Deutsche ist unlesbar) auch gar nicht auf, insofern hast Du den „falschen“ Begriff rausgesucht. Das ist aber eine naheliegende Falle, da im Deutschen dieser Begriff gerne verwendet wird, vermutlich weil er gut klingt und halt nicht so ganz klar wird, was man dahinter verstecken will.

    Im Scrum-Guide taucht die Verb- und die Adjektiv-Form auf und wenn Du die raussuchst bekommst Du bei LEO neue Übersetzungsmöglichkeiten vorgeschlagen. Mit nun ca. 50 Übersetzungsmustern gilt es eine Entscheidung zu treffen, welche Botschaft ich vermitteln möchte und mit welchen Sprachmitteln ich das tue. Dazu habe ich dann auch noch mal geschaut, was Ken Schwaber als einer der Autoren, denn noch so für Aussagen zu trifft, bzw. auch welche Botschaften er durch die Auswahl und die Zusammenstellung der Zertifiierungsfragen sendet.

    Was bei mir am Ende übrig bleibt, ist dann auch genau nicht die Frage nach dem ZU WAS, sondern die nach dem WIE. Wie arbeitet das Team mit dem Product Owner zusammen, wie trifft es Vereinbarungen und mit welcher Ernsthaftigkeit übernimmt es Verantwortung für seine Aufgabe.

    Das Thema ist denke ich ähnlich schwer zu vermitteln, wie das der Selbstorganisation (oder auch nur das eines Teams?). Mein Gefühl ist, das wir das mit Worten alleine nicht schaffen werden. Ich sehe es als meine Aufgabe als Trainer und Coach, das als ganze Person vorzuleben und erfahbar zu machen. Das macht für mich auch den oose-Unterschied aus, dass wir unzufrieden sind wenn wir nur Worte und Techniken haben, aber nichts ganzes und lebendiges.

    Liebe Grüße

    Jan

  3. Und passend zu dieser Diskussion erscheint gerade der aktualisierte Scrum-Guide 2011, so dass wir zumindest die Frage: „Wie ist es denn bei Scrum von den Erfindern gedacht?“ beantworten können.

    Zitat aus dem Scrum Update 2011: „Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.“

    Also kein Commitment des Entwicklungsteams.

    Unabhängig davon bleibt das Prinzip: „Nachdenken statt die Scrum-Bibel (oder andere Bibeln) runter zu beten.“ ein hoffentlich weiterhin gelebtes Prinzip bei oose :) (ganz im Sinne von Alistair’s Eid).

  4. Gerade da ich beim letzten Mal, als ich einen Blog-Beitrag von Herrn Gentsch kommentert hatte, eine um 90 Grad verdrehte Position hatte, möchte ich zu diesem Blog-Beitrag und der dort gefundenen Darstellung des Sachverhalts gratulieren und der Aussage voll zustimmen.

    Alles Gute wünscht

    … Michael Hönnig

  5. Puff Diddi sagt:

    Weiter so – immer schön ganzheitlich!

  6. Oliver Zeigermann sagt:

    Dieses Commitement gab es in der 2010 Version des Scrum Guides noch. In der aktuellen Version gibt es dann nur noch forecast.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.