Agile Irrtümer #1: „Commitment ist ein Leistungsversprechen“

In unseren Projekten begegnen uns immer wieder agile Missverständnisse, die sich teilweise hartnäckig halten und die sich häufig zu folgenschweren Fallstricken entwickeln – ein guter Anlass für unsere neue Blog-Serie „Agile Irrtümer“! Den Auftakt macht die weit verbreitete Auffassung, dass Sprint-Commitments als Leistungsversprechen des Teams zu verstehen sind.

Commitment im Scrum-Alltag

Üblicherweise legt das Scrum-Team im Sprint Planning fest, welche Aufgaben es sich für den kommenden Sprint vornimmt. Die Aufgaben werden detailliert heruntergebrochen und auf Basis vorangegangener Erfahrungswerte (Velocity) kann das Team gut einschätzen, was im anstehenden Sprint realistisch ist und formuliert ein Sprintziel. In älteren Scrumguide-Versionen gibt es noch die Formulierung, dass das Team „ein Commitment für dieses Sprintziel abgibt“. Treten während des Sprints unvorhersehbare Probleme auf, die sich auf das Erreichen des Sprintziels auswirken, heißt es dann schnell: „Aber ihr habt euch doch committet, XY zu liefern!‘ Spätestens hier zeigt sich, wie fatal dieser agile Irrtum sein kann – dazu später mehr.

Was bedeutet Commitment eigentlich?

Das Wörterbuch bietet die Übersetzungen „Verpflichtung“, „Engagement“, „Versprechen“, „Einsatz““, „Bekenntnis“, „Einstandspflicht“, „Zusage“ usw. Analysiert man die deutschen Entsprechungen genauer, fällt auf, dass es deutliche Unterschiede zwischen den verschiedenen Übersetzungsmöglichkeiten gibt: Unter „Zusage“ und „Versprechen“ verstehen wir, dass sich jemand darauf verlassen kann, dass etwas genau so eintreffen wird – in unserem Fall das Erreichen des Sprintziels. Mit „Verpflichtung“, „Engagement“ oder „Einsatz“ meinen wir hingegen, dass sich jemand darauf verlassen kann, dass wir alles in unserer Macht Stehende tun werden, um das Ziel zu erreichen.

Heute besteht ein Konsens darüber, dass Softwareentwicklung niemals hundertprozentig vorhersehbar bzw. planbar ist. Es gibt zu viele Unbekannte, die sich erst während des Entwicklungsprozesses ergeben. Woher sollte ein Team beispielsweise wissen, dass sich ein bisher unerkannter Fehler im System befindet, der erst während der Implementierung einer neuen Funktion zufällig entdeckt wird und behoben werden muss, damit die neue Funktion funktioniert. Oder es stellt sich heraus, dass alternative Lösungswege gefunden werden müssen, um die geforderte Performance zu erreichen. Ähnlich unbeherrschbar sind die Entwicklungen im komplexen VUKA-Umfeld digitaler Transformationsprojekte.

Natürlich hat jeder durch unvorhergesehene Probleme verursachte Aufwand Einfluss auf das Erreichen des Sprintzieles. Es ist also absurd, das Commitment für ein Sprintziel als Versprechen des Teams für eine termingerechte Lieferung zu interpretieren, geschweige denn einzufordern – was ganz nebenbei auch nicht agil wäre im Sinne der gewünschten Anpassungsfähigkeit agiler Teams!

Die Folgen falsch verstandener Commitments

Leider erleben wir in unseren Projekten trotzdem immer noch, dass von den Teams ein Leistungsversprechen gefordert wird. Das Problem: Dieser agile Irrtum hat unweigerlich negative Auswirkungen auf die Kultur und damit auf die Leistungsfähigkeit des Teams. Denn was wird ein Team tun, dass sich mehrfach dafür rechtfertigen musste, dass es nicht vorhersehbare Überraschungen nicht vorhergesehen hatte (Sie erkennen die Paradoxie)? Ganz einfach: Das Team wird künftig deutlich vorsichtigere Sprintziele definieren und wirklich nur so viele Aufgaben in den Sprint nehmen, die selbst unter widrigen Umständen das Sprintziel nicht gefährden. Die Folge ist, dass durch diese übervorsichtige Haltung wertvolles Potenzial verschenkt wird. Es wäre deutlich mehr machbar – aber das Team traut sich nicht mehr, ehrgeizige Ziele zu formulieren.

Den Schaden hat letztendlich die Organisation, denn die Leistungskurve sinkt. Die logische Reaktion ist die Forderung „Aber da geht doch noch was!“ und das Team wird gedrängt, den Sprint optimistischer zu planen. Ein Teufelskreis beginnt, der am Ende zur Demotivation im Team und zur Unzufriedenheit im Management führt.

Realistische Sprintplanung

In meinen Projekten ermutige ich meine Scrum-Teams, den Sprint nach aktuellem Wissensstand realistisch zu planen. Außerdem erkläre ich dem Team UND Außenstehenden (z.B. dem Management) die oben genannten Zusammenhänge. Eine gesunde Sprintplanung ist für mich auch dann gegeben, wenn nur in vier von fünf Sprints die Sprintziele vollständig erreicht werden! Wichtig ist, dass im anschließenden Sprint Review gemeinsam mit den Stakeholdern reflektiert wird, was erreicht wurde, welche Überraschungen aufgetreten sind und wie das Team versucht hat, bestmöglich mit diesen veränderten Bedingungen umzugehen.

So entwickelt sich zwischen Team, Product Owner und Stakeholdern ein Vertrauensverhältnis, das sich positiv auf die Kultur und die Motivation auswirkt. Das Team hat keine Angst, sich anspruchsvolle Sprintziele zu setzen, da es sich darauf verlassen kann, dass im Falle einer Nichterreichung nicht nach Schuldigen gesucht, sondern sachlich sondiert wird, was aus den Überraschungen für die kommenden Sprints gelernt werden kann.

Fazit

Wenn von „Commitment“ im Zusammenhang mit Sprintzielen die Rede ist, geht es also um ein Team, das Verantwortung für seine Arbeit übernimmt und das mit vollem Einsatz dabei ist, um beim Schätzen und Erfüllen seiner Ziele immer besser zu werden.

In der nächsten Folge beschäftigen wir uns mit dem Irrtum „Der Scrum Master ist dein Freund!“ – lesen Sie doch mal wieder rein!