Sprintziele im RZ-SCRUM

Einleitung

Im modernen Sprint (sprich: “nicht nach Lehrbuch”) wird häufig auf mindestens ein Sprintziel hingearbeitet. Dieses wird üblicherweise im Sprintplanning zusammen mit dem Product Owner festgelegt. Für die Teams des Rechenzentrums ist es häufig sehr schwierig ein konkretes Sprintziel zu formulieren. Deshalb ist der Umgang mit diesen bei uns oft nicht intuitiv. Weil wir nicht auf das Sprintziel verzichten wollten, haben wir uns überlegt, wie wir die Methodik fit für unseren RZ-Sprint machen können!

Dieser Artikel soll als Dokumentation, Wissensaustausch und Inspiration dienen! Vielleicht habt ihr noch nie von Sprintzielen gehört oder ihr kennt das Prinzip aber wendet es nicht an. In jedem Fall kann der Artikel euch hoffentlich dazu anregen, das Vorgehen zumindest in Erwägung zu ziehen! Disclaimer: Es hilft sicherlich, grundlegendes Wissen über Scrum zu haben!

Was ist ein Sprintziel?

Ein Sprint ist eine zeitlich definierte Iteration im Scrum Framework. In unserem Fall erstreckt sich ein Sprint über 2 Wochen. So ein Sprint hat fünf feste Termine und ein Sprintbacklog. In diesem Verzeichnis kommen die Arbeitsitems zusammen, welche sich das Team für den nächsten Sprint vornimmt. Um das Verzeichnis zu füllen, trifft sich das Entwicklerteam und der Product Owner kurz vor Sprintbeginn zum sogenannten Sprint-Planning.

Ein Sprintziel sollte das im Planungsmeeting geschnürte Arbeitspaket, also die nun im Sprint-Backlog liegenden Items, beinhalten. Ein Sprintziel soll vor allem abbilden, WARUM die Arbeit im Sprint einen Mehrwert bietet.

Auf ein gut formuliertes Sprintziel können sich alle Entwickler im Scrum-Team mit gutem Gefühl verpflichten, da sie wissen, WAS zu tun ist, FÜR wen sie die Arbeit machen, und WELCHEN MEHRWERT die Arbeit bietet. Dadurch, dass sie konkrete Ziele sind, verbunden mit einer direkten und positiven Auswirkung für die Stakeholder, können sie ein Entwicklerteam motivieren. Die Fokussierung auf ein gemeinsames Ziel sorgt meist auch für eine Performanceverbesserung.

Soweit zumindest die Theorie…

Das Problem

Sprintziele sind eigentlich ein fester Bestandteil eines Scrum-Sprints. Im Rechenzentrum leben wir dies aber nicht wirklich und das hat verschiedene Gründe:

1. Wir bedienenen mehrere Produkte und/oder Projekte gleichzeitig. Das bedeutet, dass man sich oft für mehrere Items verschiedener Projekte verpflichtet. Hin und wieder ist die Arbeit hier kleinteilig und jeder arbeitet an unterschiedlichen Zielen. Die Auswirkung - oft ist das “warum” nicht klar zu sehen, da diverse Arbeiten an diversen Features in einem Sprint zusammengelegt werden.

2. Es gibt viele Themen, welche von der Natur eher an das technische Backlog erinnern - und somit nicht immer klar ersichtliche Kunden besitzen. Das erschwert es einen “Mehrwert für den Kunden zu beschreiben.”

3. Wir haben schlicht keinen festen Platz für die Formulierung der Sprintziele eingeräumt. Dies stammt daher, dass es nicht standardmäßig zur hauseigenen Scrum-Variation gehört.

4. Da die Formulierung der Sprintziele nicht zum RZ-Scrum-Alltag gehört, ist dies auch nicht fester Teil des Sprintplannings und das Team nicht dazu verpflichtet, Sprintziele aufzustellen.

Das Ziel vor Augen

Während unser Traineephase im Rechenzentrum haben wir in einem Subteam von 3 Entwicklern, einem Product Owner und einem Scrum Master an einem Traineeprojekt gearbeitet - eine GUI Anwendung zum beschreiben von USB Sticks mit verschlüsselten Zertifikaten. Diese wird von Mitarbeitern aus einer Verwaltungsabteilung genutzt. Innerhalb dieses Projekts habe ich das erste Mal von Sprintzielen gehört - damals haben wir versucht Scrum so “rein” wie möglich aufzusetzen - bevor wir in die Rituale des RZ-Scrums eingeweiht wurden. In diesem Projekt hatten wir als Team die Möglichkeit, vor jedem Sprint ein klar definitieres Sprintziel zu formulieren. An diesem Sprintziel haben wir unseren Sprinterfolg gemessen und auf dieses Sprintziel konnten wir uns gegenseitig berufen - schließlich hatten wir uns dazu verpflichtet. Damals waren natürlich alle Gegebenheiten vorhanden - ein einzelnes Projekt, Features mit deutlicher Auswirkung für die Kunden, eine regelmäßige Review mit und einen kurzen Weg zu den Kunden bzw. Nutzern.

Der richtige Arbeitsalltag sieht wie oben beschrieben natürlich nicht so lehrbuchhaft aus - so ist das Sprintziel in Vergessenheit geraten.

Wieso also jetzt die Wiederbelebung der Sprintziele? Die Antwort ist so individuell wie unsere Sprintziele. Für mich ist es das Plus an Motivation, welches ich dadurch erhalte, ein klar formuliertes Ziel vor Augen in einem dicht besiedelten Sprint zu haben. Auch hilft es dabei Sinn in der täglichen Arbeit zu finden - da man sich darüber Gedanken gemacht hat, welchen Mehrwert die Arbeit am Ende des Sprints bietet. Zuletzt ist es die Verantwortung an der eigenen Arbeit gegenüber unseren Kunden.

Eventuell zieht man noch etwas Anderes aus einem Sprintziel, es könnte eine Organisationsstütze sein, oder es erinnert einen daran, den eigenen Code nicht nur aus der eigenen Perspektive zu sehen.

Anpassungen

Wir machen uns also auf, Sprintziele wiederzubeleben - zuerst in einer Art Alphaphase im kleinem Rahmen von zwei Personen, die darauf Lust hatten. Unser Ziel ist es dabei, den Prozess reifen zu lassen und Mängel auszubessern, wo sie auftreten. Wir wissen von vornherein, dass wir unter den Gesichtspunkten unseres jetzigen Arbeitsalltags Sprintziele nicht einfach so formulieren können, wie wir es früher “unter Laborbedingungen” getan haben. Daher entscheiden wir uns für einigen Anpassungen:

• Jeder formuliert seine eigenen Sprintziele für die persönlichen Arbeitsebene.
• Wir versetzen uns in die Sicht anderer Stakeholder und versuchen das “WHY” für jedes Item zu finden.
• Wir fassen Items zusammen, wenn es möglich ist.
• Wir schreiben nicht alles auf, sondern konzentrieren uns auf eine übersichtliche Anzahl an Zielen (ca. 3-5 sollten realistisch sein).
• Wir bringen das “WARUM” und/oder das “WIE” unter.

Um das ganze besser zu verstehen, ein paar Beispiele aus meinem ersten Sprintziel-Sprint:

“Ich beteilige mich mit Tatendrang an den Workshops “Prozesse entkoppeln”! Die Ergebnisse gebe ich ans Team leicht verdaulich weiter!"

Auffällig: An dieser Stelle hat das WIE eine größere Rolle eingenommen als das WARUM. Diese Modusformulierung hilft mir, mich selbst zu kontrollieren und sollte erreichen, dass ich in dieser Workshopreihe meine Zeit nicht nur absitze!

Ich erstelle eine API für den RuB Prototypen. Für diese erstelle ich ein Nuget Paket zur weiterverwendung! Dies muss geschehen, damit die anderen Items sinnvoll weitergeführt werden können!

Hier führt das WARUM und zeigt mir auf, dass dieses Item grundlegend für die Weiterentwicklung des restlichen Projekts ist.

Inspect and Adapt

Der erste Sprint verlief relativ erfolgreich - wenn auch nicht ohne Stolpersteine. Wir stellten für uns fest, dass uns die Sprintziele tatsächlich den erhofften Motivationsboost geben. Es stellt ein tolles Erfolgserlebnis dar, über seine geschafften Ziele zu reden - und zu reflektieren, weshalb man andere nicht schaffte. Trotzdem haben wir einiges an Verbesserungspotential gesehen.

Warum manche Sprintziele besser sind als andere

Nicht alle von uns formulierten Zielen ließen sich so schaffen wie wir es gerne gehabt hätten. Aus der gesammelten Erfahrung zeigt sich, dass ein Sprintziel ein paar sinnvolle Merkmale aufweisen sollte. Diese will ich hier mithilfe von ein paar Imperativen beschreiben:

Formuliere nicht zu konkret!

Die Softwareentwicklung ist sehr komplexes Tätigkeitsfeld. Dies bedeutet für uns, dass es öfter zu unerwarteten Komplikationen kommt, als uns lieb ist. Formulieren wir ein Sprintziel zu genau, zieht es nicht immer potentielle Komplikationen in Betracht. Das führt möglicherweise zu einem Sprintziel, welches wir in seiner Formulierung nicht erfüllen können.

Formuliere nicht zu allgemein!

Ein zu allgemeines Sprintziel führt zu Ziellosigkeit - also quasi genau dem Zustand, den wir mit der ganzen Übung entgehen wollten! Versuche deine Ziele mindestens so zu formulieren, dass sich eine Arbeitsanweisung daraus formulieren lässt.

Nimm dir nicht zu viel vor!

Sich viele Ziele zu setzen funktioniert nur, solange man diese Ziele auch realistisch schaffen kann. Ja, es fühlt sich gut an, viele Ziele zu schaffen! Wenn du dir aber tendentiell sehr viele Ziele setzt, läufst du immer wieder Gefahr nicht alle zu schaffen. Schätze dich und deine Zeit im Sprint also realistisch ein. Stell dir als Beispiel zwei Sprints vor. In einem setzt du dir zu viele Ziele, in einem anderen trittst du ein wenig kürzer. Auch wenn du in beiden Sprints die gleiche Anzahl an Zielen schaffst, wenn du so tickst wie ich, wird es für dich befriedigender sein, den Sprint zu absolvieren, in dem du keine Ziele auf der Strecke lässt.

Nimm dir nicht zu wenig vor!

Der letzte Punkt bedeutet natürlich nicht, dass du dir nur noch so wenige Sprintziele setzen sollst, dass du alles schaffst, weil du nur halb so viel planst wie du schaffen kannst. Aus fehlender Herausforderung folgt eben auch keine Genugtuung.

Belohnung muss sein

Als zusätzlichen Ansporn planen wir ein Belohnungsritual für geschaffte Sprints. Unsere Idee ist es eine Art Ritual zu erschaffen, indem wir einen geschafften Sprint richtig zelebrieren können. Als erste Idee setzen wir hierfür ein gemeinsames Freitag-nachmittags Bier (natürlich nach Feierabend ;)) an. Wichtig ist nur, dass man etwas wählt, was man sich sonst nicht gönnen würde. So sollte es vielleicht auch nicht die Haus-Biermarke sein, sondern eine besondere, die man ausprobieren möchte. Das Bier kann natürlich bei Belieben gegen etwas Anderes ausgetauscht werden, was in euch Freude auslöst. Im Rahmen dieses Sprint-Ende-Rituals tragen wir in der Runde offen unsere Ziele vor und berichten ob wir erfolgreich waren oder nicht. Wenn nicht, dann wird überlegt, woran der Misserfolg liegt. Daran können wir dann unsere persönlichen und teambezogenen Vorgehensweisen reflektieren und besser anpassen.

Das nächste Problem: im RZ enden unsere Sprints leider nicht am Freitag, sondern an Dienstagen. Da wir Wert darauf legen, das Sprint-Ende-Ritual am Freitag stattfinden zu lassen, überlegten wir uns, dass ein Sprint als geschafft zählt, wenn er realistischerweise am nächsten Arbeitstag schaffbar ist. Das wären bei uns als 1 bis 2 übrige Story Points.

Fazit

In den ersten Phasen des Selbstversuchs hat sich jetzt schon ein sehr positiver Effekt mit der Anwendung von Sprintzielen für mich abgezeichnet. Besonders motivierend sind die persönliche Verpflichtung und die eigene Zielsetzung - aber auch die stetige Fremdkontrolle durch das Offenlegen der Ziele sind sehr hilfreich für mich. Wichtig ist allerdings auch, dass man am Ball bleibt, der Prozess trotzdem anregend bleibt. Dazu würde ich zum Beispiel empfehlen die Sprintbelohnungen öfters auszutauschen. Das Vorgehen bedurfte einiger Gedanken und Anpassungen im Voraus, um es an unsere internen Gegebenheiten anzupassen. Mit einem offenen Mindset und dem Wissen, dass Anpassungen auch später immer noch möglich sind, ist das aber gar kein Problem.

Falls ihr jetzt inspiriert seid, aber immer noch nicht genau wisst, wie ihr mit Sprintzielen anfangen wollt, freue ich mich jederzeit auf einen regen Austausch!