Was 9 von 10 Scrum Mastern übersehen:
Sie sehen Sprintziele nur als Regel.
Doch eigentlich sind sie auch ein Werkzeug. Was meine ich damit? Mir wird immer wieder gesagt: „Simon, Sprintziele funktionieren bei uns nicht.“ Ich verstehe das. Sich Ziele zu setzen und konsequent darauf hinzuarbeiten, ist nicht einfach – selbst für Einzelpersonen. Als Team gemeinsam ein Ziel zu definieren und zu verfolgen, ist umso schwieriger. Doch genau darin liegt die Aufgabe eines Scrum Masters. Viele vergessen: Nach Scrum zu arbeiten, sich als Team also ein Ziel zu setzen, bedeutet für viele Teams eine völlig neue Art der Zusammenarbeit. Und die neue Arbeitsweise heißt nicht, Scrum Regeln blind zu befolgen. Vielmehr geht es darum:
Die Regel nutzen, um als Team besser zu werden.
In diesem Sinne sind Sprintziele auch ein Werkzeug.
Sprintziele zeigen auf, wo es im Team noch hakt und wo Verbesserungen möglich sind. Als Scrum Master kannst du dieses Werkzeug gezielt zur Ursachenforschung nutzen. Hier sind 5 Ursachen, auf die ich in über 10 Jahren Scrum Erfahrung immer wieder gestoßen bin.
Beginnen wir mit der ersten Ursache:
Ursache #1: Koordination statt Zusammenarbeit? Warum Abstimmung nicht gleich Teamwork ist
Was unterscheidet Koordination von Zusammenarbeit?
Am Beispiel meines Lieblingssports, Basketball, lässt sich das gut veranschaulichen.
Der Trainer nimmt eine Auszeit. Er ruft die Spieler zu sich und skizziert auf dem Klemmbrett den Plan für den nächsten Spielzug. Im Anschluss kennt jeder Spieler seine Laufwege. Jeder weiß, wann er wo sein muss, an wen der Ball abgegeben werden soll und wer letztendlich auf den Korb wirft.
Das ist ein Beispiel für Koordination.
Zurück zum Beispiel: Der Schiedsrichter pfeift, die Auszeit ist vorbei, das Spiel geht mit dem Einwurf weiter. Jeder Spieler folgt dem Plan und läuft seine Wege. Bis auf einmal etwas passiert, was so nicht geplant war. Obwohl es für einen Spieler vorgesehen war, den Ball noch einmal weiterzupassen, steht er frei und hat perfekte Sicht auf den Korb. Soll er nun passen, wie es vorgesehen war, oder doch seine Chance mit einem Wurf auf den Korb nutzen?
Zusammenarbeit erfordert spontanes Reagieren.
Zusammenarbeit geht über bloße Koordination hinaus. Es ist eine interaktive Form der Arbeit, bei der Ideen, Fähigkeiten und Ressourcen gemeinsam genutzt werden, um Probleme besser zu lösen.
Erfolgreiche Teams arbeiten zusammen.
Das gilt nicht nur im Basketball. In Scrum Teams erkennst du den Unterschied etwa daran, wie Code-Reviews durchgeführt werden. Finden die Code-Reviews im „Pair-Programming“ statt, wird eng zusammengearbeitet. Die Entwickler treffen gemeinsam Designentscheidungen und geben sich gegenseitig Tipps, wie Bugs vermieden werden können oder neue Funktionen effizienter geschrieben werden können.
Dann ist das Zusammenarbeit.
Arbeitet ein Programmierer seinen Task ab, der ihm im Sprint-Planning zugewiesen wurde, und schiebt das Ticket im Anschluss auf „im Test“, damit der Tester weitermachen kann, dann ist das eher ein Beispiel für reine Koordination von Arbeit.
Sprintziele helfen Scrum Teams, zusammenzuarbeiten.
Eine Ursache, warum Sprintziele für dein Team problematisch sein könnten, ist, dass dein Team Koordination als eine Art der Zusammenarbeit versteht.
Ursache #2: Zu großes Team? Warum jeder beschäftigt ist – aber kein gemeinsames Ziel entsteht
Was ist die optimale Größe des Teams?
Der Scrum Guide gibt hierzu eine Empfehlung. Lass sie uns gemeinsam nachlesen:
„Das Scrum Team ist klein genug, um flink zu bleiben, und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen.“
Viele lesen nun „10 Personen“ und stellen sich dann die falsche Frage:
„Genügen 10 Personen, um alle Tätigkeiten des Teams abzudecken?“
Sie befürchten, dass 10 Personen nicht ausreichen werden, um alle Handgriffe abzudecken, die nötig sind, um das Produkt zu entdecken, zu entwickeln, zu liefern und zu betreiben. Da jede Person nur eine Fähigkeit hat – ein Designer kann nur designen, ein Entwickler kann nur entwickeln, ein Tester kann nur testen –, entsteht zwar ein interdisziplinäres Team, aber es besteht aus mehr als 10 Mitgliedern.
Und jetzt kommen wir zum Problem:
Versucht das Team dann, ein gemeinsames Sprintziel zu definieren, kann es passieren, dass der Designer daran nicht beteiligt ist. Vielleicht wird auch der Entwickler oder Tester nicht benötigt. Da aber Designer, Entwickler und Tester alle im Sprint beschäftigt sein wollen, kommt das Team zum Schluss:
Sprintziele funktionieren bei uns nicht.
Die Ursache ist die falsche Frage nach der optimalen Größe des Teams. Denn die bessere Frage lautet:
„Wie wenige Personen können alle Tätigkeiten des Teams abdecken?“
Betrachten wir hierzu ein Beispiel. An dieser Fähigkeiten-Matrix kannst du ablesen, dass fünf Teammitglieder nötig sind, um alle acht Fähigkeiten abzudecken.
Was wäre, wenn Susi auch „UX-Writing“ und die technische Dokumentation übernehmen könnte? Dann wären nur noch vier Teammitglieder nötig, um alle Handgriffe abzudecken.
Und jetzt kommt es:
Wäre ein Sprintziel, das keine „Technische Dokumentation“ erfordert, ein Problem für das Team? Würde sich im Sprint-Planning jemand beschweren, dass er oder sie nichts zu tun hat, weil keine Dokumentation zu erstellen oder kein UX-Research durchzuführen ist?
Wahrscheinlich nicht.
Ursache #3: Zu viele Prioritäten? Warum es deinem Team an Fokus fehlt
Wer kennt die folgende Situation im Sprint-Planning nicht?
Ein Entwickler erinnert daran, dass die technischen Schulden unbedingt behoben werden müssen. Der Kunde hat sich bereits beschwert, dass die Deadline für die neue Bezahlfunktion gerissen wurde. Ein wichtiger Stakeholder möchte, dass unbedingt am neuen Compliance-Feature gearbeitet wird. Es gibt eine Reihe kritischer Fehler, die dringend behoben werden sollen. Der Scrum Master ermahnt das Team, noch an die Verbesserungen aus der letzten Sprint-Retrospektive zu denken. Und Tom vom Kundensupport hat schon angekündigt, dass er bei einigen Anfragen nicht auf die Hilfe der Entwickler verzichten kann.
Worauf soll sich das Team deiner Meinung nach konzentrieren? Was wäre ein lohnenswertes Ziel für den Sprint?
Soll sich das Team darauf konzentrieren, endlich die Bezahlfunktion fertigzustellen? Was wird der Kundensupport dazu sagen, wenn kein Entwickler ihm im Support helfen kann? Sollte das Team sich nicht lieber um die Compliance-Anforderung kümmern? Wird diese nicht umgesetzt, könnte das eine empfindliche Strafe für das Unternehmen nach sich ziehen.
Unter uns: Eigentlich sollte das nicht unser Problem sein. Dafür gibt es den Product-Owner. Die Verantwortung des Product-Owners ist es, genau diese unangenehme Entscheidung in dieser Situation zu treffen. Er gibt vor, worauf sich das Team in diesem Sprint konzentrieren soll.
So die Scrum Theorie.
In der Praxis habe ich bisher leider wenige Product-Owner kennengelernt, die das Rückgrat haben und eine klare Richtung vorgeben. Die sagen, welche Sache in diesem Sprint Priorität hat und – noch wichtiger – welche Sachen nicht.
Die Ursache hierfür?
Nach meiner Erfahrung fehlt es an einem übergeordneten Ziel. Einem Ziel, das das Team langfristig erreichen soll, das so wichtig für das Unternehmen ist, dass Stakeholder nicht bereit sind, kurzfristige Kundenwünsche höher zu priorisieren. Ein Ziel, das für die Strategie des Unternehmens eine wichtige Rolle spielt und nicht leichtfertig für die Behebung von Fehlern oder die Erledigung von Supportanfragen übergangen wird. In Scrum nennen wir ein solches Ziel:
Produktziel.
Eine Ursache dafür, dass ein Scrum Team Schwierigkeiten hat, ein Sprintziel zu formulieren, könnte sein, dass den Teammitgliedern ein Produktziel fehlt, das die langfristige Richtung vorgibt. Und dass sie sich im Sprint-Review deshalb nicht erklären müssen, wenn sie mehreren Dingen ihre Aufmerksamkeit gewidmet haben, aber nichts wirklich abgeschlossen wurde.
Ursache #4: Kein echtes Team? Wenn jeder nur sein eigenes Ding macht
In einem meiner ersten Mitarbeitergespräche hat mir mein Vorgesetzter diese Frage gestellt:
„Simon, was glaubst du eigentlich, was meine Aufgabe als Leiter der Entwicklungsabteilung ist?“
Ich war lange genug in der Berufswelt unterwegs gewesen, um zu wissen, dass es besser ist, diese Frage nicht zu beantworten. Also habe ich es gelassen. Deshalb fuhr mein Chef fort:
„Jeder Entwickler hat eine Unmenge von Ideen, woran er arbeiten will. Das Business hat auch Ideen, woran die Entwickler arbeiten sollten. Mein Job ist es, dafür zu sorgen, dass das Business nicht leer ausgeht.“
Um ehrlich zu sein, habe ich lange nicht verstanden, was er mir damit sagen wollte. Ich dachte: „Hey, Gmail wurde auch aus der Laune heraus von einem Entwickler bei Google nebenbei entwickelt.“
Mittlerweile verstehe ich besser, was er meinte. Unterm Strich sind Entwickler Profis. Professionalität bedeutet zum einen, besondere Fähigkeiten zu haben, um bestimmte Probleme zu lösen. Es heißt aber auch, seine Fähigkeiten in den Dienst des Unternehmens zu stellen. Dafür bekommt man schließlich sein Gehalt.
Es geht also darum, Probleme für das Unternehmen zu lösen – und nicht „Königreiche“ für sich zu erschaffen. Ich denke, das wollte er mir damit sagen.
Woran erkennst du, ob die Mitglieder im Team professionell arbeiten?
Daran, wie schwierig es ist, ein gemeinsames Sprintziel zu finden. Denn wenn jeder im Team nur an seinem „Ding“ arbeitet, kann das eine Ursache dafür sein, dass dein Team kein gemeinsames Sprintziel formulieren kann.
Ursache #5: To-do-Listen statt Sprintziele? Warum es auf das Wozu ankommt
Gleicht das Sprintziel einem echten Ziel oder einer To-do-Liste?
Woran erkennst du eine Sprintziel-To-do-Liste? Schlimmstenfalls lautet das Sprintziel: „Alle Einträge des Sprint-Backlogs fertigstellen.“ Allerdings können wir einer To-do-Listen-Mentalität auch noch versteckt begegnen. Achte mal darauf, ob sich im Sprintziel Kommas oder das Wort „und“ verstecken. Also: „Wir stellen Eintrag X, Eintrag Y und Eintrag Z fertig“ – das wäre ein solches Beispiel.
Warum ist das ein Problem?
Sprintziele, die als To-do-Listen formuliert sind, beschreiben das „Was“. Was soll am Produkt geändert werden? Aber gibt es nicht für die Beschreibung dessen, „was“ am Produkt verbessert werden soll, das Sprint-Backlog? Ist das Sprintziel dann nicht eigentlich überflüssig? Könnte das der Grund sein, warum sich dein Team schwertut, ein Sprintziel zu definieren?
Deshalb sollte das Sprintziel nicht das „Was“ beschreiben, sondern das „Wozu“. Oder anders ausgedrückt: Was soll mit der Änderung am Produkt erreicht werden? Um diese Frage zu beantworten, stelle ich im Sprint-Planning deshalb immer folgende Frage:
„Was soll nach diesem Sprint für die Nutzer des Produkts anders sein?“
In der Antwort findest du das „Wozu“.
Suchst du weitere Hilfe mit Sprintzielen?
Dann besuche das nächste „Professional Scrum Master – Advanced“-Training. Dort zeigen Marc Kaufmann und ich viele Werkzeuge, mit denen du als Scrum Master dein Scrum Team unterstützen kannst.
Über 271 Scrum Master sind unserer Empfehlung bereits gefolgt, haben sich das Professional-Scrum-Master-II-Zertifikat gesichert und sind den nächsten Schritt in ihrer Karriere gegangen.