Der Wald und die Bäume: was sieht man nicht wegen was?

Autor: Peter Götz

Datum:

Ich geb es ja zu, das ist kein Wald und die Sträucher sind auch keine Bäume. Aber ki-frei und unkompliziert ist das als Symbolbild gut zu gebrauchen, weil man sieht wenigstens den Parkplatz und die Bundesstraße vor lauter Bäumen nicht.

So ging es mir letzte Woche mit dem Team, das ich gerade unterstützen darf. Vor lauter Backlog Items war nicht mehr klar, was eigentlich geschafft werden solle. Aber langsam und der Reihe nach…

Vom Ziel zur Aufgabe

“Zielorientiert geht nicht, weil wir zu viel unterschiedliche Arbeit haben, die fertig werden muss.”

Das habe ich letzte Woche zum Beginn eines einstündigen Refinements als Begründung dafür gehört, dass das Team keine Sprintziele hat. Wir haben also eine (für mich) beliebige Menge an Backlog Items kurz angeschaut, andiskutiert und bei ein paar sogar über Größe diskutiert und ge-planning-pokert.

Bei jedem Backlog Item war die Frage, für wen das eigentlich relevant ist und was man alles berücksichtigen soll. Da es kein übergreifendes Thema gab, war scheinbar nicht nur ich ein wenig verloren und das hat sich so geäußert, dass eigentlich nur die Hälfte der Anwesenden aktiv teilgenommen hat. Die Anderen waren dabei, aber aber nicht wirklich beteiligt.

Der spannende Punkt ist passiert, als das Team bereits eine halbe Stunde eine gute handvoll an Backlog Items diskutiert hatte. Einer der fachlich ausgerichteten Team-Mitglieder meinte plötzlich: “Das bringt doch alles gerade nichts. Eigentlich ist doch ganz einfach. Im nächsten Sprint müssen wir X machen, im Sprint darauf mit Y weitermachen, um dann im dritten Sprint Z so weit zu bringen, dass das Release sinnvoll ist.”

Er hat also mit wenigen Worten die Ziele der nächsten drei Sprints skizziert und erläutert, warum diese Ziele wichtig sind. Genau so funktioniert zielorientiertes Arbeiten allgemein und Produkt- sowie Sprintziele im Speziellen: Wir müssen nicht mühsam ein Ziel finden, das zu unserer Arbeit passt, sondern wir wollen Dinge erreichen und definieren dafür die Arbeit, die erledigt werden muss.

Ab diesem Zeitpunkt hatten wir eine komplett andere Diskussion über das Backlog. Weg von “was ist hier gemeint und was genau müssen wir tun” und hin zu “was müssen wir tun, damit X / Y / Z passieren kann”.

Die Voraussetzung hierfür ist aber, dass zumindest einer im Team erkennt, wozu das alles gut und wichtig ist, das wir machen sollen. Es war also kein Zufall, dass der Kollege mit der meisten Ahnung der Fachlichkeit die Ziele skizziert hat. Von dieser fachlichen Expertise profitieren dann alle anderen Mitglieder im Team, da sie nicht nur verstehen, was gemacht werden soll, sondern auch wozu.

Den Überblick behalten

Und ab dem Moment war Bewegung im Team. Das Refinement war zwar zu Ende, aber im kleineren Kreis haben wir das bestehende Backlog noch eine ganze Weile diskutiert. Das Hauptproblem ist, dass zu viele Aufgaben im Backlog sind und verwaltet werden müssen. Jedes Mal, wenn man ein Item öffnet, um zu beurteilen, ob es langsam wichtig genug ist für die Umsetzung, investieren wir Arbeitszeit und damit kostbare Kapazität, die nicht für die Wertschöpfung zur Verfügung steht.

Das Ziel ist also, das Backlog überschaubar zu halten. Im vorliegenden Fall war das mit ein paar hundert Einträgen, die noch zu bearbeiten sind (alle wichtig natürlich!) schwer bis nicht möglich. Die einzige Lösung ist ein radikaler Schritt: wegwerfen

Viele Teams scheuen sich vor diesem Schritt, weil schon so viel Arbeit in die Backlog Items geflossen ist. Und irgendwann sollen sie ja erledigt werden, deshalb müsste man die Arbeit dann ja noch mal machen. Meine Erfahrung zeigt: wenn Einträge im Backlog zu alt werden, muss man eh noch mal von vorne anfangen, um zu verstehen, was gefordert wird und zu skizzieren, wie die Lösung aussehen kann. Die Arbeit hat man also in der Regel nicht gespart, wenn man ein Backlog Item monate- oder jahrelang aufhebt. Zusätzlich wird aber kontinuierlich Arbeit in die Verwaltung der Einträge gesteckt, die nicht wertschöpfend ist.

Fazit

Der Frühling kommt und damit die Zeit des Frühlingsputzes. Putz doch mal Euer Backlog und räum den Kram, der älter ist als ein Quartal (von mir aus auch ein halbes oder ganzes Jahr), auf. Am besten, indem Du die Sachen löschst. Falls Dir das zu krass ist, dann mach sie anders unsichtbar (tagging, verschieben, …). Wichtig ist, dass sie nicht im Weg umgehen.

Dann überleg Dir, was Du im laufenden und nächsten Monat oder Quartal oder bis Ende des Jahres alles erreichen möchtest. Keine Featureliste, sondern eine handvoll Überschriften. Das sind Deine Ziele.

Jetzt beschreib die Arbeit, die als nächstes wichtig ist, um dem Ziel näher zu kommen. Diskutiere diese Arbeit mit Deinen Kolleg:innen und bearbeite sie im Sprint.

Da Capo ad libitum.

Und falls Du mir nicht glaubst, hier noch die Meinung von Dan Vacanti, der ins gleiche Horn stößt: What Problem Are We Solving With Prioritization?