Gründe, warum Scrum Teams auf Sprint-Ziele verzichten – und die Vorteile, wenn sie es doch nicht tun

Es vergeht kein Scrum Training, an dem nicht darüber diskutiert wird…

Die Rede ist von Sprint-Zielen.

Oder besser: Warum Sprint-Ziele nicht funktionieren.

Dabei wiederholen sich die Gründe, die angeführt werden:

5 Gründe, warum Sprint-Ziele nicht funktionieren

• Wir arbeiten nicht an einem Produkt, sondern an (mehreren) Projekten.
• Während des Sprints kommt es zu unvorhergesehener Arbeit. Ein Sprint-Ziel beraubt uns der Flexibilität, darauf zu reagieren.
• Unsere Arbeit hat viele Abhängigkeiten zu anderen Teams. Wir können erst mit unserer Arbeit beginnen, wenn das andere Team fertig ist.
• Das Team hat Angst, sich auf nur eine Sache zu verpflichten, da die Stakeholder auch noch andere Dinge von uns erwarten.
• Sprint-Ziele sind für Scrum Teams optional.

Du wirst mir zustimmen, dass diese Gründe eine Herausforderung für Scrum Teams darstellen.

Bis auf den letzten Punkt. Der klingt für mich eher nach einer Ausrede. Denn bereits in der Version des Scrum Guides von 2010 wird das Sprint-Ziel erwähnt:

„Nach der Auswahl des Product Backlogs wird ein Sprint-Ziel erstellt. Das Sprint-Ziel ist ein Ziel, das durch die Umsetzung des Product Backlogs erreicht wird. Es handelt sich um eine Aussage, die das Team darüber informiert, warum es das Inkrement erstellt.“

Es ist nur so: Im gleichen Satz, in dem mir die Gründe genannt werden, warum Sprint-Ziele in diesem Unternehmen nicht funktionieren können, werden mir Probleme genannt, die das Team hat.

Hier eine Aufzählung der häufigsten Probleme, die ich in diesem Zusammenhang höre:

• Das Daily Scrum gleicht einem Statusbericht-Meeting. Jeder Entwickler berichtet, woran er gestern gearbeitet hat.
• Der Product Owner beklagt sich, dass er keine Kontrolle darüber hat, was im Sprint fertig wird.
• Der Erfolg unseres Teams wird nur daran gemessen, ob die Velocity steigt.
• Unser Unternehmen ist nicht agil. Es geht nur darum, einen Plan abzuarbeiten.

Lass uns die Punkte gemeinsam betrachten, und ich gebe dir meine Einschätzung, warum dies mit der Verwendung eines Sprint-Ziels verhindert werden hätte können.

Das Daily Scrum gleicht einem Statusbericht-Meeting. Jeder Entwickler berichtet, woran er gestern gearbeitet hat.

Das Daily Scrum soll die Zusammenarbeit fördern.

Es soll den Entwicklern nicht nur ermöglichen, zurückzuschauen, welche Arbeiten sie bereits erledigt haben, sondern sich darauf zu konzentrieren, was heute wichtig sein wird.

Im Daily Scrum zeigt ein Sprint-Ziel den Entwicklern die Richtung auf.

Wenn du nach unterschiedlichen Formaten suchst, wie du das Daily Scrum gestalten kannst, sodass die Zusammenarbeit im Vordergrund steht, dann wirf einen Blick auf dieses Video. Darin erkläre ich ausführlich meine 5 bewährten Daily-Scrum-Formate:

Der Product Owner beklagt sich, dass er keine Kontrolle darüber hat, was im Sprint fertig wird.

Im Gegensatz zum Product Backlog besitzt das Sprint Backlog keine Reihenfolge.

Das Sprint Backlog stellt weniger eine priorisierte Liste dar, sondern mehr einen Plan, wie die Arbeit im Sprint erledigt werden soll. Den Entwicklern steht es frei, wie sie die Arbeit im Sprint Backlog priorisieren wollen. Häufig geschieht dies daher nach Gesichtspunkten wie der günstigsten Bearbeitungsreihenfolge oder Architekturüberlegungen. Durch die Setzung eines Sprint-Ziels kann der Product Owner Einfluss darauf nehmen, an was als Erstes gearbeitet werden sollte.

Mit dem Sprint-Ziel behält der Product Owner auch die Kontrolle im Sprint über das, was im Sprint am wichtigsten ist.

Der Erfolg unseres Teams wird nur daran gemessen, ob die Velocity steigt.

Besitzt ein Sprint kein Ziel, woran können wir dann den Erfolg messen?

Sprints sind erfolgreich, wenn das Ziel erreicht wurde. Wird aber kein Ziel für den Sprint vorgegeben, dann wird das Abarbeiten des Sprint Backlogs häufig zum Ziel. Und der Erfolg des Scrum Teams wird daran gemessen, wie viele der vorhergesagten User-Stories das Team tatsächlich umgesetzt hat oder ob mehr als im letzten Sprint gefertigt wurden. Das Kriterium für Erfolg und Misserfolg ist dann die Prognosegenauigkeit oder die Velocity des Teams. Sprints geraten dadurch zu Projekten, bei denen die Befolgung des Plans im Vordergrund steht.

Sprint-Ziele verhindern dies, indem sie ein klares Erfolgskriterium symbolisieren.

Unser Unternehmen ist nicht agil. Es geht nur darum, einen Plan abzuarbeiten.

Dies steht im klaren Widerspruch zum Agilen Manifest:

„Das Reagieren auf Veränderung steht über dem Befolgen eines Plans.“

Allerdings, wenn das Team keinen Plan befolgen soll, wie kann dann sichergestellt werden, dass das Team Fortschritte macht? Die Antwort: Sprint-Ziel. Ein Sprint-Ziel gibt die Richtung für den Sprint vor und legt fest, auf welche Arbeiten sich das Team konzentrieren soll. Gleichzeitig lässt es noch genug Flexibilität, um auf Veränderungen zu reagieren. Beispiele, die eine Reaktion erfordern, sind kritische Fehlermeldungen auf dem Produktivsystem, erkrankte Teammitglieder oder die längere Dauer der Implementierung eines Features als geschätzt.

Sprint-Ziele helfen Unternehmen, agil zu bleiben.

Seit 10 Jahren arbeite ich mit Scrum Teams und meine Erfahrung bestätigt mir, dass Sprint-Ziele diese vier Probleme beheben können.

Es gibt zwei weitere Gründe, warum Scrum Teams keinesfalls auf Sprint-Ziele verzichten sollten:

• Sprint-Ziele fördern die Motivation im Team.
• Sprint-Ziele fördern das „Wir-Gefühl“ im Team.

Betrachten wir die Vorteile im Detail:

Vorteil 1: Sprint-Ziele fördern die Motivation im Team

Bis zum Beginn des 20. Jahrhunderts wurde Motivation als eine Frage der richtigen externen Belohnung oder Bestrafung angesehen.

Dieser vorherrschende Managementansatz, basierend auf den Theorien Taylors, betonte die rigorose Messung der Leistung der einzelnen Arbeitnehmer und befürwortete den Einsatz von externen Belohnungen oder Bestrafungen zur Leistungssteigerung.

Dies änderte sich in den letzten Jahrzehnten. Moderne Managementtheorien betonen die Rolle der intrinsischen Motivation auf die Leistung von Menschen und Teams. Edwin Locke und Gary Latham entwickelten dazu die Goal-Setting-Theorie, basierend auf einer Vielzahl von Studien. Ihre Forschung ergab, dass anspruchsvolle Ziele Teams und Einzelpersonen stärker motivieren als unklare oder gar keine Ziele. Ergänzt wurde ihre Forschung durch die Arbeiten von Kanfer, Frese und Johnson, die 2017 feststellten, dass die motivierendsten Ziele herausfordernd, klar und mit häufigem Feedback versehen sein sollten.

Wir können also festhalten:

Teamziele fördern die Motivation sowohl von Teams als auch von Einzelpersonen und sollten daher herausfordernd, klar und mit häufigem Feedback für den Fortschritt versehen sein.

Vorteil 2: Sprint-Ziele fördern das „Wir-Gefühl“ im Team

Was unterscheidet Sportteams und ihre Fans von Teams in Unternehmen?

Amateur-Sportteams oder ihre Fans sind häufig bereit, viel mehr für die gemeinsame Sache zu geben, und erhalten dafür nicht einmal Geld, im Gegensatz zu „Teams“ in Unternehmen. Wie kann das sein?

Die Antwort: Gruppenkohäsion.

So bezeichnen Forscher das „Wir-Gefühl“ in Gruppen. Eine Gruppe gilt als kohäsiv, wenn ihre Mitglieder von der Idee ihrer Gruppe angezogen werden. Das bedeutet, dass die Mitglieder die Idee mögen, Teil dieser Gruppe zu sein, und sie identifizieren sich selbst als Mitglieder der Gruppe. Dies sieht man stark bei Sportteams und deren Fans, aber weniger häufig bei Scrum Teams.

Die Forschung hat herausgefunden, dass Menschen in kohäsiven Gruppen dazu neigen, bessere Leistungen zu erbringen und besser mit Stress und Druck umzugehen. In der Praxis bezeichnen wir eine solche kohäsive Gruppe als ein wirkliches Team und die Arbeit, die es leistet, als „Teamarbeit“. Wenn die Vorteile eines echten Teams mit einer Identität auf der Hand liegen, wie können wir dann solche Teams fördern?

Hierzu gibt es einige Faktoren und ich bin mir sicher, einen hast du bereits erraten: gemeinsame Ziele.

Genau. Ein Faktor für echte Teamarbeit ist Kohärenz oder Koordination. Dies ist der Fall, wenn die Mitglieder einer Gruppe ihre Aktivitäten aktiv koordinieren, um gemeinsame Ziele zu erreichen. Etwa wenn sich die Mitglieder gegenseitig über die nächsten Schritte informieren, sich gegenseitig um Hilfe bitten und sich häufig über ihre gemeinsamen Fortschritte austauschen.

Oder anders formuliert: Teamziele helfen, aus Zusammenarbeit echte Teamarbeit zu machen.

Für Sprint-Ziele ist dies sogar nachgewiesen. Whitworth und Biddle fanden 2007 heraus, dass in agilen Teams das Engagement für Teamziele den Zusammenhalt, die Teameffektivität, den Wissensaustausch und die Feedback-Prozesse erhöht.

Die Vorteile von Sprint-Zielen rechtfertigen den Aufwand bei der Einführung. Hier sind 4 Tipps, wie du sie einführst.

Wenn für dich die Vorteile von Sprint-Zielen die Herausforderungen bei der Einführung überwiegen, dann habe ich noch einige Tipps für dich.

Diese Tipps haben mir bisher immer geholfen, wenn ich Scrum Teams dabei unterstütze, mit Sprint-Zielen zu arbeiten.

Tipp 1: Nur einen Product-Backlog-Eintrag wählen

Wählt nur einige Einträge als Ziel aus, an denen das Team als Erstes arbeiten kann. Hierbei hilft dir die Frage: „Wenn wir nur einen Eintrag des Product Backlogs in diesem Sprint fertigstellen könnten, welcher wäre das?“ Diese Frage ist besonders in Situationen hilfreich, in denen das Team an mehreren Projekten oder unterschiedlichen Themen gleichzeitig arbeitet.

Tipp 2: Etwas Luft im Sprint Backlog lassen

Plant im Sprint Planning nicht den gesamten Sprint, sondern lasst Raum für ungeplante Arbeiten. Nicht alle Arbeiten müssen im Sprint Backlog zu Beginn des Sprints geplant werden und für Support oder Bugfixing ist das auch nicht möglich. Lasst dafür Kapazitäten übrig und wählt als Sprint-Ziel die Arbeiten aus, die ihr für diesen Sprint planen könnt, mag es noch so ein geringer Anteil der gesamten Arbeit sein.

Tipp 3: Sprintlänge hinterfragen

Wenn ständig Unvorhergesehenes eintritt oder an vielen Projekten gleichzeitig gearbeitet wird, warum nicht die Sprintlänge auf eine Woche reduzieren? Generell ermöglichen kürzere Sprints mehr Anpassung und minimieren das Risiko, zu lange ohne Feedback in eine Richtung zu entwickeln. Eine kürzere Sprintlänge kann allerdings auch dazu führen, dass sich nur auf eine Sache konzentriert wird.

Tipp 4: Stellt die Sprint-Ziel-Gegner vor die Wahl

Bietet den Stakeholdern eine Wahl:

Variante 1: Wir werden an drei Themen gleichzeitig arbeiten. Ihr werdet keine Kontrolle darüber haben, was zuerst geliefert wird. Wir werden alle drei Themen später abschließen.

Variante 2: Wir werden uns jeweils auf nur ein Thema konzentrieren und das zu unserem Ziel für den Sprint machen. Ihr habt die Kontrolle darüber, was zuerst geliefert wird, da ihr entscheiden dürft, welches Thema unser Ziel für den ersten Sprint ist.

Diese Wahlmöglichkeit ist besonders effektiv in Situationen, in denen das Team an mehreren Projekten oder unterschiedlichen Themen gleichzeitig arbeitet.

Scrum wird deine Probleme nicht lösen. Kein Prozess kann das! Auf Sprint-Ziele zu verzichten, wird die Probleme nur verschleiern.

Oder in den Worten von Ken Schwaber:

„Denke daran, dass Scrum einfach ist und seine Anwendung situationsabhängig ist. Es ist nicht dazu gedacht, dir zu sagen, wie du es anwenden oder umsetzen sollst. Es sagt dir nicht, wie du deine Arbeit machen, ein Produkt entwickeln oder mit anderen zusammenarbeiten sollst. Das musst du selbst herausfinden.“

Wenn du von Sprint-Ziel nicht genug bekommst, dann merke dir den 22. Februar vor. Um 16:00 biete ich zusammen mit Scrum.org ein kostenloses Webinar an. 

Hier geht es zur Anmeldung: Scrum Pulse: 4 Tipps, wie du Sprint-Ziele einführst.