Ein wesentlicher Begriff im Scrum ist der des Commitment, also einer Verpflichtungserklärung. Hiermit verpflichtet sich das Team, die zu Beginn eines Entwicklungszyklus – des Sprints – angenommenen Tätigkeiten auch tatsächlich bis zum Ende des Zyklus vollständig und in der zugesagten Qualität abzuschließen. Doch in welcher Form und mit welchen Konsequenzen kann und soll eine solche Verpflichtungserklärung abgegeben werden?
Und warum ist es überhaupt wichtig ein Commitment abzugeben? Kann man nicht einfach dem Artikel 2 des Rheinischen Grundgesetzes folgen: “Et kütt wie et kütt”?
Nein!
Letztendlich wird mit Beginn eines Sprint ein Pakt zwischen dem PO und dem Team geschlossen: Der PO verspricht dem Team den Umfang und die Priorität der Anforderungen für die Zeit des Sprint fix zu halten (und dies auch gegenüber dem Management zu vertreten), dafür bekommt er von dem Team die Zusage, dass die geplanten Inhalte auch tatsächlich geliefert werden. Nur wenn beide Seiten dieses Paktes eingehalten werden, dann können sich die die Beteiligten auf ihre Aufgaben konzentrieren. Hält der PO das Versprechen nicht und ändert die Anforderungen während des Sprint, dann wird das Team nur Stückwerk geringer Qualität abliefern können. Hält das Team das Versprechen nicht, dann verliert der PO das Vertrauen in die Planbarkeit des Verfahrens und wird zunehmend ins Mikromanagement verfallen.
Aus diesem Grund ist ein Commitment zu Beginn eines Sprints sehr wichtig, und sollte vom Team entsprechend ernst genommen werden. Das Team sollte ein Commitment nur dann abgeben wenn es sich sicher ist, dass die Realisierung der Anforderungen in der gegebenen Zeit auch realistisch ist. Gleichzeitig sollte das Team aber vom Wunsch getrieben werden möglichst viel umzusetzen (“viel Feature, viel Ehr’”) – im Zweifel wird ein guter PO aber auch versuchen das Mögliche aus dem Team herauszukitzeln.
Weil das Vertrauensverhältnis zwischen Team und PO so wichtig ist, halte ich die vor einiger Zeit im Scrum Guide von Ken Schwaber und Jeff Sutherland vorgenommene Anpassung des Begriffs Commitment in den sehr viel relativeren Begriff Forecast für kritisch. Ein unverbindliches “na ja, wir werden mal sehen was sich so machen lässt” führt zur Erosion des Willens im Team, das gesteckte Ziel auch wirklich zu erreichen. Das klassische Commitment macht die Entscheidung des Teams, die Herausforderungen des vor ihm liegenden Sprints anzunehmen, zu einer bewussten Willenserklärung.
Aber ist ein Commitment nicht genau so wenig oder viel Wert wie ein Forecast, da die Konsequenzen einer “Verfehlung” die gleichen sind? Und was sind überhaupt die Konsequenzen.
In einem idealen Team ist die wesentliche Konsequenz tatsächlich die Enttäuschung des PO und des Teams selbst über das nicht erreichte Ziel. Insbesondere sollte dem Team klar sein, dass es den PO in eine unangenehme Situation gebracht hat. Dieser muss nämlich dem Management eine Verschiebung des betroffenen Features mitteilen. Und auf lange Sicht ist die tragische Konsequenz der geschilderte Vertrauensverlust zwischen Team und PO sowie der daraus folgende Herauswurf aus dem Paradies der ungestörten Entwicklung.
Wenn das Team aber kein ideales Team ist? Nun, dann ist es die Aufgabe des ScrumMaster, mittel- bis langfristig aus dem Team ein ideales zu formen, das Stolz auf die eigene Leistungsfähigkeit ist und ein starkes Ehrgefühl entwickelt.
Gefährlich ist es allerdings, das Commitment in eine Metrik zu wandeln (“wir zählen, wie oft das Commitment nicht eingehalten wurde”) und im Extremfall disziplinarische Konsequenzen zu fordern. Das Team wird in diesem Fall schnell dazu übergehen die Gründe für das Versagen nicht bei sich selbst, sondern in den – ohne Frage immer vorhandenen – externen Einflussfaktoren zu suchen, möglichst wenig in einem Sprint zuzusagen, und darüber hinaus bei der Qualität zu schummeln um die gesetzten Ziele zu erreichen.
Und damit ist letztendlich niemandem gedient.