Das Backlog ist ein anti-pattern. Schon lange denke ich so und erinnere mich an ein Telefonat im Rahmen einer Kundenanfrage, in dem der Anrufer klagte, man werde des Backlogs mit 3000+ Einträgen nicht mehr Herr.
Ja, wie soll denn das auch gehen? 3000+ backlog items…?😱 Mein Rat damals war: Löschen! Einfach komplett wegwerfen. Verbrennen. “Nuke the backlog!”, empfiehlt Allan Kelly.
Aber warum so radikal?
Weil ein Backlog Energie verschwendet und eine Bringschuld etabliert. Das ist das Letzte, was ein Softwareteam braucht.
Energieverschwendung: Ein Backlog ist per definitionem nicht übersichtlich. Es braucht Energie, um festzustellen, ob es einen Eintrag schon gibt, bevor man einen neuen anlegt. Dann kostet es Zeit, den Eintrag so zu formulieren, dass man auch noch in Wochen oder Monaten, gar Jahren versteht, was damit gemeint war. (Tatsächlich, backlog items können ein so hohes Alter erreichen!) Schließlich ist die Energie für die allermeisten Einträge verschwendet, weil sie ohnehin nicht (zeitnah) realisiert werden. Die Zugangsfrequenz für backlog items ist immer höher als die Entnahmefrequenz. D.h. das Backlog wächst vor allem; seiner Größe ist keine Grenze gesetzt. Das belastet zunehmend die Gemüter aller Beteiligten, weil es einen Berg darstellt, dessen Gipfel nicht zu erreichen ist. Schlechte Gewissen stellt sich ein; Konflikte entstehen bei Nachfragen, warum denn dieses oder jenes seit Wochen und Monaten nicht umgesetzt worden ist.
Bringschuld: Mit einem Backlog ist ein Team gewissermaßen ständig erreichbar, um Wünsche einzukippen. “Klar, ich weiß, dass ihr damit nicht sofort beginnen könnt. Aber tragt das mal ins Backlog ein.” Es macht dadurch das Verhältnis zwischen Kunde und Softwareteam asymmetrisch — wie es schon der Anrufbeantworter und all die anderen modernen Inboxes tun. Den Kunden kostet es nichts, sich über das Backlog zu entlasten; anschließend ist der Ball im Spielfeld des Softwareteams. Das hat die ganze Last, das Backlog verlässlich umzusetzen. Denn ein Eintrag im Backlog ist aus Sicht des Kunden wie ein Versprechen. Ein Backlog führt also zu Projekt-Spam.
Ich verstehe, dass ein Backlog aus der Ferne wie eine gute Idee aussieht. Für Kunde wie Softwareteam ist es ein Eingeständnis, dass nicht sofort alles umgesetzt werden kann. Es signalisiert ganz bewusst Offenheit für Ideen. Statt Wünsche abzulehnen, zeigt sich das Softwareteam aktiv: ein Eintrag im Backlog bedeutet “fast schon umgesetzt”. Und wenn nicht heute, dann bestimmt bald. Der Eintrag signalisiert “Du bist uns wichtig, Kunde!”
Und vielleicht steckt auch etwas Positives darin, einen backlog item zu formulieren. In dem Prozess können sich beide Seiten darüber klar werden, was eigentlich gemeint ist. Die Formulierung erzwingt frühzeitig eine gewisse Präzision.
Doch nicht alles, was verführerisch aussieht und in kleinen Dosen nicht schadet, sollte auch angenommen oder gar skaliert werden.
Ein Backlog als “kleiner Notizzettel” in einem Projekt, in dem selten etwas dazu kommt und viel, viel mehr abgearbeitet wird, mag ja nützlich sein. Doch so ist das Backlog nicht gedacht. In der Realität ist es immer ein Haufen. Von mir aus ist es auch ein “gekämmter” Haufen, wenn mal wieder backlog grooming betrieben wurde. Haufen jedoch bleibt Haufen.
Ein Backlog ist schlicht kein Plan. Es ist eine Beruhigungspille, die durch ständigen Gebrauch an Wirkung verliert und zunehmen selbst zum Problem wird. Da hilft kein besseres Backlog; da hilft nur “Nuke the backlog!”
Im Backlog herumkramen ist deshalb nicht besser als dumpster diving. Vielleicht findet sich bei langer Suche etwas Nützliches — doch die Quelle ist im Grunde Verrottetes. Zumindest ist das Haltbarkeitsdatum abgelaufen
Denn das steht im Kern des Backlogs: Die irrige Vorstellung, dass alle Einträge nicht nur heute heute, sondern auf alle Zeit höchsten Wert haben. Doch das ist Bullshit. Alle Einträge haben ein Verfallsdatum, das immer früher liegt, als man glaubt. Meistens ist es sogar schon abgelaufen, bevor eine Umsetzung auch nur in Betracht gezogen werden kann. Das gilt nicht nur für Features! Auch Bugs, die es nur ins Backlog schaffen, haben ein baldiges Verfallsdatum.
Ein Backlog entfremdet beide Seiten — Kunden wie Softwareteam — einfach von der Realität einer ständig in Bewegung befindlichen Projektsituation. Das ist nicht zielführend.
Ich plädiere daher für eine radikale “Schuldumkehr”: Nicht das Softwareteam ist in der Bringschuld. Nicht das Softwareteam muss ein Backlog pflegen, den Überblick über Wünsche des Kunden behalten und ständig überlegen, was als nächstes dran sein könnte, um möglichst wenig Ärger hervorzurufen.
Nein, ganz im Gegenteil: Der Kunde hat eine Holschuld. Wenn er etwas haben möchte, dann muss er es sich vom Softwareteam holen, vielleicht muss er sogar mehrfach vorsprechen:
Kunde: “Mir liegt das Feature X auf dem Herzen? Wann könntet ihr das umsetzen?”
Softwareteam: “Wir sind mit den akzeptierten Features und Bug noch die nächsten 3 Wochen beschäftigt.”
Kunde: “Oh, schade. Na gut, dann lasst es uns ins Backlog aufnehmen.”
Softwareteam: “Es gibt kein Backlog. Wenn du willst, dass wir X umsetzen, komm’ in 2 Wochen wieder vorbei. Dann besprechen wir X — oder vielleicht ist dir X auch nicht mehr wichtig und wir besprechen Y.”
Damit bleibt der Ball beim Kunden. Der Kunde muss sich dessen aktiv erinnern, was ihm wichtig ist. Der Kunde muss priorisieren. Der Kunde muss immer wieder ans Softwareteam herantreten und um Umsetzung bitten. Dadurch bekommt er Flexibilität — Er kann ständig ändern, was er möchte, solange es kein Commitment zur Umsetzung gibt — und er bekommt zu spüren, was die Pflege von Wunschlisten für einen Aufwand bedeutet. Das wirkt vielleicht dämpfend auf seine Attitüde. Softwareentwicklung ist ein ernstes Geschäft, das Sprunghaftigkeit und Trotzhaltung von 3jährigen nicht verträgt.
Verzicht auf ein Backlog birgt viel Potenzial, Laufruhe in die Umsetzung zu bekommen. Es gibt nur das, was unmittelbar ansteht und wofür es ein Commitment gibt. Alles andere ist außerhalb des Softwareteams.
Ab dem Zeitpunkt eines Commitments läuft die Uhr. Zunächst stehen Einträge in der Prioritätsliste in einer Queue, bis der erste Handschlag daran getan wird. Ab dann befinden sie sich In Process. Während der Umsetzung gibt es mehr oder weniger Touch Time und Wartezeit. Was angefangen wird, wird aber garantiert und möglichst zügig fertiggestellt. Schließlich sind Einträge umgesetzt.
Solange ein Eintrag nicht begonnen wurde, kann seine Priorität in der Liste verändert werden. Die Prioritätsliste ist flexibel. Wurde er hingegen begonnen, steht er nicht mehr in der Liste.
Die Prioritätsliste kann auch jederzeit erweitert oder ausgedünnt werden. Allerdings machen mehr Einträge als in einem überschaubaren Zeitraum umsetzbar sind, darin keinen Sinn in der Softwareentwicklung. Dass der starr auf 1, 2, 3 Wochen festgelegt werden müsste, sehe ich auch nicht. Dass die Prioritätsliste nur selten verändert werden dürfte — z.B. an einem Sprint-Beginn —, halte ich auch für überflüssig. So wird Flow behindert.
Der Umgang mit der Prioritätsliste ist schlicht von der Volatilität der Kundenwünsche abhängig. Sind die stabil, kann die Liste länger sein; wechseln die ständig, sollte sie kürzer sein.
Darüber hinaus im Softwareteam aber noch ein Backlog zu führen, ist völliger Unsinn. Das Softwareteam braucht keine Beschäftigungstherapie. Pflege und Umsetzung der stets aktuellen Prioritätsliste reichen völlig aus. Wenn der Kunde gern einen Haufen weiterer Anforderungen auftürmen will, darf er das gern für sich daheim machen.
Also:
Burn the Backlog!
Es gibt nur, was unmittelbar dran ist. Die Gegenwart zählt. Dran bleiben an dem, was jetzt wichtig ist. Das ist:
Fertigstellung dessen, was begonnen wurde.
Aktuell halten einer überschaubaren Prioritätenliste, aus der stets von oben in die Fertigung gezogen wird, die Highlander-Anforderung.
Vorbereitung des nächsten Eintrags für die Prioritätenliste.
Alles andere ist Wunschdenken und deshalb belastend.1
Was irgendwer für sich persönlich auf irgendwelchen (digitalen) Zetteln sammelt, um es nicht zu vergessen oder als brain dump, ist davon unbenommen. Die Arbeitsweisen der Menschen sind verschieden. Jeder darf da, wie er will. Nur hat das keinen offiziellen Status. Daraus kann nichts von niemandem als Verpflichtung abgeleitet werden.