Performance-Boost im Scrum Team – Ein Erfahrungsbericht

Bei allen agilen Software-Projekten, die ich in den letzten vier Jahren bei codecentric erlebt habe, wurde immer mit Scrum gearbeitet. Es gab u.a. die typischen Scrum Events (Sprint, Daily, Review, Retro, Planning) sowie zusätzlich ein oder mehrere Backlog Refinements während des Sprints. Die Tickets haben wir mit Storypoints geschätzt. Soweit, so gut. Normalerweise klappt das immer recht gut und selten wurde etwas am Prozess geändert.

Trotzdem hatte ich besonders als Entwickler immer wieder mit folgenden „Problemen“ zu tun:

• Der Product Owner (PO) wollte wissen, warum ein Ticket so lange gedauert hat, obwohl es doch nur mit einer „3“ geschätzt wurde. Als Entwickler muss man sich dann rechtfertigen. Meistens gab es unvorhergesehene Dinge, die den Aufwand erhöht haben.
• Aus der Schätzung in Storypoints (= relative Komplexität) wurde über die Zeit immer mehr eine Schätzung der Umsetzungsdauer der Tickets. Je mehr Erfahrung man als Entwickler im Projekt sammelt, desto besser wird das Bauchgefühl wie groß ein Ticket ist (= wie lange es dauert). Storypoints und Dauer haben aber wenig miteinander zu tun und es erhöht sich die Chance daneben zu liegen.
• Zum Sprintende staute sich eine große Menge an Tickets, die darauf warteten, gereviewed und dann gemerged zu werden. Das erzeugte häufig Stress vor dem Sprintwechsel, weil sich der Stau nicht so schnell auflösen ließ wie gewünscht.
• Die Velocity mehrerer Sprints glich mehr einer Achterbahnfahrt als einem stabilem Verlauf, weil Tickets von einem Sprint in den nächsten genommen wurden und die Story Points dann im Folgesprint zu Buche schlugen.

Das sind alles keine Probleme, die das Projekt gefährden, aber es sind Aspekte, welche die Stimmung im Team beeinflussen und hin und wieder Unzufriedenheit und Stress erzeugen. Deswegen haben wir Anpassungen an unserem Prozess vorgenommen, die ich im Folgenden beschreibe.

Das sind die Ergebnisse

Bevor ich beschreibe, was wir genau geändert haben, hier erst einmal die nackten Zahlen, die wir nach 6 Sprints á 2 Wochen beobachten konnten (im Vergleich zu den letzten 14 Sprints vor der Umstellung):

Also wenn diese Zahlen das PO-Herz nicht höher schlagen lassen 🙂

Neben diesen Zahlen hat sich aber auch aus Entwickler-Sicht eine entscheidende Sache geändert: Der Sprint verläuft viel entspannter als vorher. Das klingt im ersten Moment widersprüchlich, ist es am Ende aber nicht.

Kanban to the Rescue

Also was steckt hinter diesem Performance Boost? Red Bull?

Nein, es sind ein paar Elemente aus Kanban, die wir ohne Änderungen am bisherigen Scrum-Prozess hinzugefügt haben. Das ist auch ein wichtiger Punkt: Scrum selbst ist nicht das Problem und kann genau so bleiben, wie es war. Der wirkliche Knackpunkt ist der Fokus auf den Flow der Tickets von links nach rechts auf dem Ticket Board. Übrigens heißt die Zeit von ToDo bis Done im Kanban „Cycle Time“.

Unser Fokus lag also darauf, die Zeiten, die ein Ticket auf dem Board verbringt zu reduzieren. Das bringt kleine aber feine Änderungen im täglichen Doing mit sich. Man kümmert sich z.B. eher darum, einem Kollegen bei seinem Ticket zu helfen, als selbst ein neues Ticket anzufangen.

Um die Zeit überhaupt reduzieren zu können, muss man sich den typischen Lifecycle eines Tickets klarmachen. Es gibt Zeiten, an denen am Ticket gearbeitet wird und Zeiten, bei denen das Ticket rumliegt und auf den nächsten Schritt wartet:

In dieser Grafik sieht man ein Beispiel, in dem die Wartezeit satte 40 % ausmacht. Häufig ist das Verhältnis sogar noch größer und geht laut Statistiken eher in Richtung 85 % Wartezeit, 15 % Arbeitszeit! Es macht also enorm Sinn, sich eher auf die Reduktion der Wartezeiten zu fokussieren als auf die der Arbeitszeit. Zudem braucht die Arbeit am Ticket soviel Zeit wie sie nunmal braucht. Das heißt, man kann den Entwicklungsprozess nicht wesentlich beschleunigen, ohne die Qualität der Lösung negativ zu beeinflussen.

Ein wichtiger Punkt, der die Wartezeiten negativ beeinflusst, ist die Anzahl der Tickets, die gleichzeitig in Bearbeitung sind. Je mehr Tickets gleichzeitig von einer Person bearbeitet werden, desto …

• öfter muss man den Kontext wechseln und sich neu reindenken (das kostet Zeit).
• eher können Abhängigkeiten von aufeinanderfolgenden Tickets entstehen (manchmal ist es auch nur die CI-Pipeline, die hier ausbremst).
• länger dauert es insgesamt, bis ein Ticket fertig wird.
• eher sind die Kollegen nicht erreichbar, weil sie in einem komplett anderen Kontext arbeiten.

Um diesem Problem zu begegnen, gibt es in Kanban das WIP Limit (Work in Progress Limit). Wir haben das so hoch gewählt, wie die Anzahl der Personen im Team ist (bei uns sind wir zwei Entwickler), sodass jeder eigentlich nur 1 Ticket gleichzeitig pro Spalte auf dem Board bearbeiten darf.

Apropos Board … die nächste wesentliche Änderung waren die Spalten im Board.
Vorher sah das Board so aus:

Kompakt und übersichtlich würde man sagen. Allerdings ist diese kompakte Form ungeeignet, wenn man seinen Flow optimieren möchte, denn man sieht einfach zu wenig, wo die meiste Zeit verloren geht.

Das neue Board sieht so aus:

Hier sind folgende Änderungen wichtig:

• Wenn ich fertig bin mit meiner Arbeit, schiebe ich das Ticket in eine „Done“-Spalte, sodass das System (bei uns JIRA) tracken kann, wie lange ein Ticket in dieser wartenden Position verharrt.
• Mehr Spalten heißt hier mehr Transparenz. Ich kann nach ein paar Sprints genau sehen, wo die meiste Wartezeit entsteht und diese dann gezielt mit Maßnahmen angehen.
• Jede Spalte hat ein WIP Limit. Somit wird verhindert, dass zu viele Tickets gleichzeitig bearbeitet werden.

Die Spalten sind von Team zu Team natürlich unterschiedlich und sollten einfach immer genau den Prozess widerspiegeln, der auch tatsächlich gelebt wird. Das Kanban Board ist ein Instrument und kein Selbstzweck. Es dient dazu, Wartezeiten aufzudecken und so den Flow der Tickets zu fördern (= niedrige Cycle Time). Das heißt auch, dass wir in der Retro darauf schauen müssen, wo die meiste Zeit verbraucht wird.

Was haben wir nicht geändert?

Wie schon vorher erwähnt: Den Scrum-Prozess haben wir nicht angefasst. Oft hört man ja vom sog. „Scrumban“, bei dem man einzelne Elemente von Scrum und Kanban nimmt und daraus ein individuelles Format erzeugt. Dabei wird meistens das Arbeiten in festen Sprint-Zyklen mit vorher definierten Sprint-Umfängen zugunsten eines kontinuierlichen Ziehens von Tickets aus einem priorisierten Backlog ersetzt.

Wir hingegen machen nach wie vor alle Scrum-Events und wir schätzen weiterhin in Storypoints. Wir haben die Größe der Tickets und die Art der Schätzung nicht willentlich verändert (die genauen Zahlen sagen, wir schätzen die Tickets durchschnittlich um 7 % größer als vorher, also im Mittel 1,9 SP statt 1,7 SP). Es gibt bei uns sowohl 1er Stories als auch max. 8er Stories. Wir versuchen so gut es geht, die Tickets zu splitten, damit sie schneller bearbeitet werden können. Aber auch das haben wir vorher schon so gemacht.

Wo müssen Entwickler umdenken?

Der wohl wichtigste Erfolgsfaktor in unserem Team ist jedoch die Zusammenarbeit der Entwickler. Neben dem Daily schauen wir mehrmals am Tag, ob wir uns Hilfe von einem Kollegen holen können und machen sehr viel häufiger kurze Pair Programming Sessions. Das bringt den Vorteil, dass die Arbeitszeit am Ticket meist verkürzt wird, weil sowohl die Implementierung als auch das Review schneller gehen.

Sehr oft hab ich es bislang erlebt, dass Entwickler ein Ticket nach dem anderen implementieren und in die nächste Spalte schieben oder sich den halben Sprint lang an einem Ticket festbeißen und nicht zum Ende kommen. Beides ist der Killer für die Performance im Team, weil der Flow fehlt und Staus entstehen.

Fazit

Auf den Punkt gebracht, sind es nur wenige Änderungen gewesen, die wir gemacht haben: Detailliertes Kanban Board mit WIP Limits und mehr Kollaboration im Team sowie Fokus auf Flow. Aber die Auswirkungen haben uns sogar selbst überrascht.

Und was sich neben der reinen Performance noch viel besser anfühlt, ist die entspannte Arbeitsweise während des Sprints. Anstatt immer wieder etwas Neues anzufangen und „beschäftigt“ zu sein, machen wir mehr Pausen und warten z.B. auf Tickets bzw. helfen dem Kollegen, um die WIP Limits nicht zu überschreiten. Es klingt paradox, aber dieses langsame und fokussierte Arbeiten hat uns schneller gemacht.

Perspektivisch könnten wir sogar ohne Schätztermine auskommen, davon müssen wir nur noch den PO überzeugen 🙂 Denn statt der Storypoints kann der PO jetzt die Metriken Throughput und Cycle Time für den Forecast der Sprints nutzen. Somit sparen wir noch mehr Zeit beim Refinement bzw. der Sprintplanung.

Zum Abschluss noch ein lustiges und zugleich anschauliches Video, warum die Erhöhung der Auslastung von Personen das Gegenteil von Flow und Performance erzeugt: https://www.youtube.com/watch?v=CostXs2p6r0