Wie Faulheit viel effizienter sein kann

Vor einiger Zeit wurde das Product Owner Team eines unserer Auftraggeberprojekte umstrukturiert. Dies hatte zur Folge, dass ich Teil des Product Owner Teams wurde.

Was? Product Owner Team? Für Product Owner gilt die Highlander-Regel: Es kann nur einen geben!

Doch, es kann ein Team geben. Es ist sogar vollkommen okay, wenn es ein Team gibt. Der Scrum Guide sagt zwar, dass es nur einen Product Owner geben darf, damit ist aber nicht die Zahl 1 gemeint.

Viel mehr meint der Scrum Guide, dass es eine Instanz geben muss, die eine Entscheidung trifft. Diese Instanz darf sich selbst nicht blockieren. Wie die Entscheidungsfindung stattfindet (diktatorisch, demokratisch, meritokratisch etc.), ist nicht definiert. Zumindest ist das meine Interpretation der Zahl 1. Aber zurück zum Thema.

In neue Projekte einsteigen ist immer aufregend. Neues System, neue Kollegen, neuer Auftraggeber, neues Umfeld. Das alles war bei mir nicht gegeben. Das System kannte ich schon (weil ich es selbst mit programmiert habe), die Kollegen kannte ich auch. Umfeld und Auftraggeber waren mir bereits bekannt. Viel interessanter war das Backlog.

Das Backlog war das einzige, was für mich in diesem Projekt wirklich neu war. Tatsächlich hatte ich noch nie eines mit so vielen Items gesehen – aus verschiedenen Perspektiven, verschiedenen Projektphasen, in verschiedenen Formaten und Schreibstilen. Also: Was kann man als einer der neuen POs des Projekts tun?

Items noch und nöcher

Dies ist einer der Hauptgründe, warum wir als Product Owner gebraucht werden. Und wem die Aufgabe nicht so recht gefällt, ist möglicherweise für einen anderen Beruf besser geeignet. Ganz einfach: Wenn wir mit einem vollen Backlog konfrontiert sind, steckt unsere Hauptaufgabe in der Priorisierung. Ein PO muss sich durch die ganze Noise durcharbeiten und herausfinden, was wichtig ist und was nicht. Wir sind hier, um den Zug auf den Schienen zu halten.

Im aktuellen Projekt bestand der erste Schritt darin, diesen riesigen Berg an Items rigoros in zwei disjunkte Stapel aufzuteilen:

• Stapel 1 beinhaltete alles, was wir innerhalb der nächsten 2-3 Monate gebrauchen könnten.
• Stapel 2 war der Rest, den man guten Gewissens fürs erste ignorieren kann.

Die Arbeit geht nun erst einmal an Stapel 1 weiter. Da steckt noch viel drin – manch einer würden sagen, es ist immer noch viel zu viel – aber zumindest kann man damit gut weiterarbeiten.

Items aus verschiedenen Projektphasen

Wer das Vergnügen hatte, Geschichte studieren zu dürfen, wird mir hoffentlich beipflichten: Jedes Ereignis muss in seinem historischen Kontext interpretiert werden. Wir können Karl den Großen nicht für den Langobardenfeldzug verurteilen, auch wenn uns aus heutiger Sicht eine militärische Intervention nicht mehr zeitgemäß erscheint. Damals hat Kalle einen vollkommen legitimen Weg beschritten.

Zurück zum Backlog: Ein Ticket, dass zwei Jahre im Backlog liegt, ist obsolet. Das ist ein Fakt, den man akzeptieren muss. Seine Informationen stimmen vermutlich nicht mit der aktuellen Situation überein. Die Anforderungen an die Applikation haben sich verändert. Das Design ist ein anderes. Vermutlich sind neue Edge Cases hinzugekommen oder müssen nicht mehr betrachtet werden. Oder das Problem wurde schlichtweg anderweitig gelöst.

Nun stellt sich die Frage: Was machen wir mit Tickets, die so lange Bärte haben wie Methuselah?

Grundsätzlich gibt es für mich nur zwei mögliche Strategien: Neu schreiben oder löschen. Neu schreiben ist echt aufwändig. Man muss wieder an die Stakeholder herantreten, muss mit Entwicklern sprechen, muss die geänderte Situation neu einschätzen. Auf das Neuschreiben von Tickets möchte ich nicht weiter eingehen, da dies eine Wissenschaft für sich ist.

Und was ist mit Löschen? Löschen ist einfach. Löschen ist einfach, sobald man sich dazu durchringt.

Löschen, löschen, löschen?

Die Furcht vor dem Löschen ist unter Datenhortern weit verbreitet. Die Angst, etwas Wesentliches zu verlieren, ist urzeitlich, sie sprudelt in uns hoch und nagt an unserer Fähigkeit, rational zu denken: Was wäre, wenn dieser eine Satz doch wichtig war? Was ist mit dem Akzeptanzkriterium? Ist dort vielleicht noch ein Edge-Case versteckt, den wir alle vergessen werden? Streiche ich vielleicht nur das Feature, mit dem das Produkt den Markt revolutionieren wird? Nun, Realitätscheck: Das ist keine Denke, die zu großartigen Ergebnissen führen kann.

Der zentrale Gedanke, den man im Auge behalten sollte, ist: Wenn etwas wichtig wäre, wäre es schon erledigt. Wer Market-Disrupting-Features im Backlog hortet, sollte seine Priorisierung überdenken. Akzeptanzkriterien aus den frühen 2000ern spielen heute keine Rolle. Und Edge Cases: Keine Sorge  –  die tauchen ganz von alleine auf, wenn’s soweit ist.

Die Löschstrategie allein funktioniert nicht allzu gut, da die Angst, etwas zu verlieren, immer wieder auftritt. Als Workaround kann man sich auf einen de-facto Löschstatus einigen: Wir verschieben die Items in ein besonderes Backlog — in den Limbus. Im Limbus können sie vor sich hin schmoren. Und ich freue mich über weniger Noise im Product Backlog. Ich bin zufrieden, weil ich mehr Durchblick habe. Und vor allem sind alle am Projekt Beteiligten auch zufrieden, weil sämtliche Informationen bei Bedarf noch immer zugänglich sind.

Je weniger Noise im Backlog liegt, desto leichter fällt es, sich auf die wichtigen Dinge zu konzentrieren. Das gilt für Stakeholder, Product Owner und die Devs.

Nach so vielen gelöschten Tickets, fast gelöschten Tickets und neu geschriebenen Tickets kann ich mich beruhigt zurücklehnen – zumindest für den Moment. Das Backlog ist wieder lesbar und kann von einem menschlichen Gehirn verarbeitet werden. Diesen Zustand möchte ich natürlich bewahren.

Hört auf, Zeit zu verschwenden (und macht Arbeit, die einen Wert hat)

Ich habe wirklich viel Zeit und Mühe aufgewendet, um zu einem sauberen Product Backlog zu gelangen, mit dem man effektiv arbeiten kann. Damit bin ich sehr zufrieden und den Status Quo würde ich gerne beibehalten.

Natürlich bleibt der Status quo nicht lange der Status quo. Neue Tasks können und werden entstehen, egal wie sauber das Backlog ist. Auch hier kommt es darauf an, die richtigen Prioritäten zu setzen. Wenn man das Gesamtbild des Projekts im Auge behält, was ist wichtig und was weniger wichtig?

Kleine Items (z.B. das Entfernen von Leerzeichen in einer E-Mail, das Verschieben eines Buttons um einige Pixel nach rechts usw.) können schnell bearbeitet werden. Aber der Gesamtwert der Lösung kleiner Probleme ist in den meisten Fällen minimal. Oder um es auf den Punkt zu bringen: Auch wenn ich nur ein bisschen meiner Zeit verschwende, so verschwende ich dennoch Zeit!

Auch wenn ich nur ein bisschen meiner Zeit verschwende, so verschwende ich dennoch Zeit!

Bei der Festlegung von Prioritäten ist es entscheidend, sich nicht dazu hinreißen zu lassen, Dingen, die es nicht verdienen, hohe Priorität einzuräumen. Wichtigen Tasks sollten direkt angegangen werden, kleinere Probleme werden später gelöst. Tatsächlich teilen die meisten Stakeholder diese Ansicht, wenn ihnen die Lage richtig schildert.

Wenn das Team an einem kritischen Ziel arbeitet, wie zum Beispiel der Entwicklung eines neuen Marktes, ist es meine Aufgabe, die Dinge in den größeren Zusammenhang zu rücken. Wenn es um scheinbar weniger wichtige Aufgaben geht, stelle ich gerne die Frage: Bringt uns die Beseitigung des Leerzeichens in einer E-Mail im Hinblick auf unser aktuelles kritisches Ziel voran? Manchmal lautet die Antwort ja. Meistens nicht.

Ich kann nicht genug betonen, wie wichtig es ist, Unternehmensziele zu definieren, die als Leitplanken durch die Phasen eines Projekts führen. Das große, geschäftskritische Ziel bewahrt uns davor, in die kleine, kleine Welt der Lösung weniger kritischer Punkte abzudriften. Und in der Tat können wir unsere Zeit in Dinge investieren, die eine hohe Wirkung und einen hohen Wert für das Unternehmen haben.

An dieser Stelle möchte ich klarstellen: Natürlich kann ich nicht einfach jedes Item abschmettern. Hin und wieder bin ich tatsächlich gezwungen, Arbeit zu verrichten. In diesem Fall lege ich nur eine Item-Hülse an und erkundige mich, wo das Item in der Roadmap platziert wird.

Schlusswort

Das Team arbeitet nach Scrum und kümmert sich um die Items, die derzeit den größten Wert für die Stakeholder haben. Genau so arbeite ich als Product Owner auch. Je weiter hinten ein Item ist, desto niedriger ist sein Wert. Also: Warum sollte ich wertvolle Zeit darin investieren, Items bis ins kleinste Detail vorzubereiten, die so vielleicht nie umgesetzt werden? Wozu soll ich Entwickler Plans of Attack erstellen lassen, wenn das Ticket nicht attacked wird? Wozu sollte ich mehr Noise im Backlog generieren und meine tolle Übersicht verlieren? Nee, das ergibt alles keinen Sinn. Ich gehe Kaffee trinken.

Damit kann man wenigstens nichts verschlechtern.