Veröffentlicht von Habt ihr Backlogs und sind diese jemals kleiner geworden?
Mit dieser Frage fängt ein Artikel von Lucas F. Costa and und diesen fand ich sehr inspirierend. Ihr könnt diesen Artikel hier finden und ich empfehle sich diesen im Ganzen durch zu lesen.
Wer sich mit Englisch schwer tut, dem möchte ich hier eine Übersetzung anbieten. Dies geschieht mit Freigabe von Lucas F. Costa.
Erinnert ihr euch daran, dass das Backlog jemals kleiner wurde?
Nein, natürlich nicht. Backlogs werden nie kleiner.
Backlogs werden nie kleiner, weil die Liste der Dinge, die wir irgendwann erledigen wollen, nie kleiner wird, und das ist es, was Backlogs sind: ein Haufen unwichtiger Aufgaben, die wir irgendwann erledigen werden, aber nicht heute.
Wichtige Aufgaben kommen nie in den Backlog. Wir erstellen sie, wir arbeiten an ihnen und wir liefern sie aus. Du glaubst mir nicht? Frag deinen Produktmanager, wann er das letzte Mal etwas aus dem Backlog nehmen musste, weil ihm die Aufgaben ausgegangen sind. Ich bin mir sicher, dass die Antwort ein schallendes „nie“ sein wird.
Die Wahrheit ist, dass wir immer wissen, welche Aufgabe am wichtigsten ist, und wir arbeiten daran, bis sie erledigt ist. Wenn du oder dein Team nicht wissen, was die wichtigste Aufgabe ist, wird ein Backlog das Problem nicht lösen. Die gemeinsame Nutzung des Kontexts und die Anpassung der Organisation schon. Alles andere ist nur ein grimmiges Theater, um zu signalisieren, dass du hart genug arbeitest.
In diesem Blogbeitrag erkläre ich, warum es Rückstände gibt und warum sie nie schrumpfen. Dann werde ich erläutern, warum sie schädlich sind. Zum Schluss zeige ich, wie man ohne Rückstände arbeiten kann, und erkläre, warum das viel produktiver ist.
Warum gibt es Backlogs, und warum werden sie nie abgebaut?
Backlogs gibt es, weil sie eine gute Möglichkeit sind, schwierigen Gesprächen aus dem Weg zu gehen und die Schuld vom Produkt auf die Technik zu schieben.
Wenn jemand einen Produktmanager zum Beispiel um eine neue Funktion bittet, ist es viel einfacher zu sagen: „Du fügst sie dem Backlog hinzu“, als eine Stunde lang zu erklären, warum der Vorschlag irrelevant ist.
Diese Strategie ist großartig, denn sie erweckt die Illusion, dass die Aufgabe irgendwann erledigt wird, obwohl die Entwickler wissen, dass das nicht der Fall ist. Manchmal wissen sogar die Anforderer selbst, dass die Aufgabe nicht erledigt werden wird, aber sobald sie sie in den „Rückstand“ gebracht haben, ist plötzlich jemand anderes dafür verantwortlich.
Was passiert wenn die Backlog’s nicht abgearbeitet werden?
Aber „was ist, wenn sie nicht erledigt wird?“, fragt der scharfsinnige Leser, „werden sie sich beschweren?“. Nein, das werden sie nicht. In einem Monat werden sie ihren Vorschlag vergessen haben. Falls sie vor Ablauf der dreißig Tage noch Fragen stellen, sagst du einfach: „Es ist im Rückstand“, und sie werden lächeln, nicken und gehen.
Mit Backlogs lassen sich nicht nur schwierige Gespräche vermeiden, sondern sie sind auch eine gute Möglichkeit für Produktmanager/innen, nicht gefeuert zu werden. Denn lange Backlogs erwecken den Eindruck, dass der Produktmanager das Produkt „managt“, indem er Tickets zum Backlog hinzufügt, sie mit Details füllt und sie ständig nach oben und unten verschiebt.
In Wirklichkeit besteht die Aufgabe eines Produktmanagers nicht darin, so viele Tickets wie möglich zu erstellen, sondern so viele wie möglich zu löschen und unnötige Arbeit um jeden Preis zu vermeiden.
Mit anderen Worten: Die Aufgabe eines Produktmanagers ist es, rücksichtslos Prioritäten zu setzen, und ein langer Backlog ist alles andere als eine gute Prioritätensetzung.
Außerdem ist ein Backlog eine gute Möglichkeit, alle Schuld auf die Entwickler abzuwälzen. Solange es genug Arbeit gibt, ist es die Schuld der Entwickler, wenn sie nicht früher fertig werden.
Warum sind Backlogs schädlich?
Eine Fabrik, die Autos schneller produziert, als sie sie verkaufen kann, produziert keine Autos. Sie produziert Verschwendung.
Umgekehrt produziert ein Produktmanager, der mehr Aufgaben erstellt, als seine Entwickler abliefern können, ebenfalls Verschwendung.
Der einzige Unterschied zwischen den beiden ist, dass die erste Art von Verschwendung leicht zu erkennen ist: Es gibt viele rostende Autos in der Fabrikhalle. Die zweite Art von Verschwendung sind dagegen nur Bytes auf einer Festplatte – oder Aufgaben in einem Rückstand.
Ähnlich wie die rostenden Autos verrotten auch diese Aufgaben. Das liegt daran, dass der Rückstand schneller wächst, als das Team ihn abarbeiten kann.
Daher verlängern sich die Durchlaufzeiten. Wenn dann ein Entwickler eine Aufgabe abholt, ist sie wahrscheinlich schon „verrottet“, es sei denn, ein Produktmanager hat viel Zeit darauf verwendet, sie auf dem neuesten Stand zu halten, bis sie abgeholt wird.
Ein langes Backlog erzeugt nicht nur Verschwendung und verlangt vom Produktteam einen erheblichen Aufwand, um auf dem neuesten Stand zu bleiben, sondern verursacht auch Störungen und verringert die Sichtbarkeit. Beides ist schlimm, wenn man bedenkt, dass diese Aufgaben nie erledigt werden.
Wie hilft uns ein Priorisierungspuffer?
Außerdem bedeutet ein langer Rückstand, dass eine schnelle und billige Bearbeitung gegen eine langsame und teure getauscht wird. Wenn das Produkt seine Aufgabe, den Auftragsbestand zu schützen, nicht erfüllt, ist die Inputrate des Teams größer als die Outputrate, so dass sich die Aufgaben anhäufen. Das passiert, weil es teurer ist, eine Aufgabe zu verfeinern und umzusetzen, als die Aufgabe aufgrund einer guten Priorisierung und Zielausrichtung nicht zu erledigen.
Wenn hingegen ein Priorisierungspuffer vor der „Aufgabenliste“ des Teams liegt, erfolgt die Priorisierung auf einer höheren Abstraktionsebene und damit viel schneller. Es ist schneller, Aufgaben abzulehnen, weil sie nicht mit den Geschäftszielen übereinstimmen, als zuzulassen, dass sie in den Prozess des Teams gelangen und von einem Entwickler umgesetzt werden. Auf diese Weise kann der Produktmanager teure Ressourcen schonen und das Team die Aufgabe schneller bearbeiten. Im Grunde ist das nichts anderes, als zwei Teile des Prozesses so aufeinander abzustimmen, dass der Engpass dorthin verlagert wird, wo er billiger ist.
Durch das Hinzufügen eines Puffers vor der „Aufgabenliste“ des Teams wird der Engpass dorthin verlagert, wo er billiger ist. Das liegt daran, dass es schneller und einfacher ist, Aufgaben auf einer höheren Abstraktionsebene abzulehnen, als sie umzusetzen.
Die einzige Möglichkeit, ein Backlog noch schädlicher zu machen, ist, von den Entwicklern zu verlangen, die Aufgaben im Backlog zu „verfeinern“. Auf diese Weise verschwendest du die Zeit von Produktmanagern und Entwicklern und sorgst dafür, dass alles zum Stillstand kommt, indem du die Inputrate des Systems erhöhst, während du die Outputrate reduzierst.
Warum hilft uns eine Roadmap, wo Backlog Items es nicht tun?
Ein weiterer Grund, warum Backlogs einen unüberwindbaren Overhead verursachen, ist, dass sie auf der falschen Abstraktionsebene erstellt werden. Es ist viel einfacher, ein Unternehmen zu führen, wenn du auf eine übergeordnete Roadmap blickst, als wenn du dich durch tausend Tickets in JIRA kämpfst.
Das liegt daran, dass die Backlogs zu viele Details enthalten, anstatt die übergeordneten Ziele und wichtigen Ergebnisse für das Unternehmen zu verdeutlichen. Auf diese Weise wird es viel schwieriger, neue Prioritäten zu setzen, Informationen auf einen Blick zu erhalten und Aufgaben zu verschieben.
Die geringe Transparenz führen zu viel schlimmeren Konsequenzen, weil sie es Gründern und Führungskräften erschweren, Entscheidungen zu treffen. Wenn diese Leute merken, wie weit ein Team mit dem Rückstand ist, kann es zu spät sein, etwas dagegen zu tun.
Wenn Backlogs schlecht sind, was sollte ich stattdessen tun?
Führe keinen Rückstand ein, es sei denn, es handelt sich um den Rückstand deiner nächsten Arbeitswochen.
Wenn du mehr als zwei oder drei Wochen brauchst, um alles in deinem Backlog abzuarbeiten, planst du zu weit voraus und auf der falschen Abstraktionsebene.
Alles, was weiter als zwei oder drei Wochen entfernt ist, sollte in eine übergeordnete Roadmap aufgenommen werden. Du solltest diese Roadmap regelmäßig überprüfen, und die Produktmanager sollten sie mit den Entwicklern teilen und ihnen erklären, warum jeder Punkt wichtig ist. Auf diese Weise können die Produkt- und Entwicklerteams eine Strategie entwickeln, wie sie diese Punkte angehen können, um technische Belange und geschäftliche Ziele in Einklang zu bringen.
Wenn du Bugs nirgendwo anders nachverfolgen kannst, ist es in Ordnung, sie in deinem Backlog aufzubewahren, solange du sie herausfiltern kannst, wenn du schnell sehen willst, was in deiner Pipeline ist. Außerdem sollten keine Bugs älter als ein paar Monate sein. Wenn ein Bug länger als drei Monate im Backlog ist, ist er bereits ein Feature. Deshalb solltest du regelmäßige Bug-Cleanup-Sitzungen einplanen, um den Fehler sofort zu beheben oder zu löschen.
Wenn ein Fehler im Backlog einen bestimmten Schwellenwert überschreitet, solltest du ihn in deinem Aufgabenverwaltungssystem rot markieren und in deinem täglichen Stand-up-Meeting entscheiden, ob du ihn sofort abschließen kannst, z. B. indem du seinen Umfang reduzierst oder alle Blocker entfernst.