Was eine Icebox auf einem Kanban-Board verloren hat

👋 Schön, dass Du hier bist! Bitte beachte, dass dieser Artikel bereits einige Jahre auf seinem Buckel hat. Seitdem haben sich nicht nur die Welt, sondern auch meine Wissenslücken, Erfahrungen und Ansichten geändert. Dennoch stehe ich hinter den Aussagen, die ich damals getätigt habe. Selbst dann, wenn ich sie mittlerweile anders tätigen würde. Bitte behalte dies beim Lesen im Hinterkopf. Danke. Und viel Vergnügen!

Warum ich denke, dass Aufgaben in einer Icebox keine gute Idee sind - im Sommer, wie im Winter. Und was man dagegen unternehmen kann.

Was ist eine Icebox? #

Vor einigen Jahren stieß ich zufällig zu einem Gespräch mehrerer Softwareentwickler. Sie redeten gerade über eine Icebox. Es war Sommer, es war heiß. Mir war heiß. Und ich also: “Eis! Geniale Idee! Danke.” Auf den Blick, den sie mir daraufhin zugeworfen haben, kam ich mir wie ein kleiner Junge vor. Wie ein dummer kleiner Junge. Also lasst uns zuerst ein wenig über die Theorie reden und dann schauen, wie diese mit der Realität zusammenpasst. Was ist eine Icebox? (Außer der natürlich, in der ich Eiscreme und kalte Getränke aufbewahren kann.)

Wenn eine Organisation damit beginnt, Kanban oder eine agile Methode, wie zum Beispiel Scrum, einzuführen, sind die Dinge meist und hoffentlich neu und aufregend. Anforderungen werden in User Stories und Tasks geschnitten. Und diese Tasks beginnen nun, über das neue glänzende Whiteboard zu wandern. Von der To Do-Spalte / -Reihe / -Pipeline / -Schritt / -welchen-toll-klingenden-Namen-auch-immer-Euer-Scrum-Coach-dem-gegeben-hat, über Work in Progress, final nach Done. Nach einiger Zeit, kommen die meisten Teams drauf, dass eine Testspalte durchaus Sinn macht. Gute Teams realisieren außerdem, dass die Reise eines Tasks nicht endet, nachdem dieser auf “Done” gestellt wurde, und fügen eine Spalte für Released hinzu. So weit, so gut.

Die hard #

Tut mir leid, dass ich schon wieder mit Filmreferenzen beginne. Das war das erste und zugleich letzte Mal in diesem Artikel. Versprochen. Also, wir haben unser Kanbanboard und unsere Tasks. Und alles läuft super. So lange, bis unsere alten Gewohnheiten beginnen, sich in unsere neue agile Welt einzuschleichen. Customer Value ist doch nicht immer so einfach zu erkennen, wie es uns in unserer Schulung erklärt wurde. Prioritäten sind manchmal nicht so einfach zu entscheiden. (Egal, ob das jetzt eine Person, oder mehrere machen.) Und also beginnen die unabgearbeiteten Anforderungen, sich zu stapeln. Und irgendwann hat dann jemand die <zynismus>großartige</zynismus> Idee, doch ein Plätzchen auf unserem Whiteboard einzurichten, wo alle diese Anforderungen ein neues, temporäres Zuhause finden können. Et voilà, die Icebox.

Also ist eine Icebox in unserem Zusammenhang eine Liste von Anforderungen und Themen, an denen in absehbarer Zeit keiner arbeiten wird. Aufgaben mit niedriger Priorität, kleine Bugs. Funktionalitäten, die immer wieder mal angefragt werden, die aber kaum Wert repräsentieren. Also ist so eine Icebox eine Art Parkplatz für Aufgaben. In der Theorie.

Immer diese Praxis #

Und in der Theorie hört sich das ja auch nach einer richtig guten Idee an. Aber hört Ihr das Geräusch? Hier kommt gerade die Realität und tritt unserer Theorie die Türe ein. Denn lasst uns einmal ehrlich sein: im echten Leben ist dieses Zuhause nicht temporär, sondern für immer. Es ist kein Parkplatz, sondern ein Friedhof. Task Sematary. (Könnt Ihr Euch noch erinnern, wie ich vorhin versprochen habe, mit Filmanspielungen aufzuhören? Nun… tschuldigom!) Diese Tasks werden nie erledigt werden. Warum? Meiner Erfahrung nach, hat das zwei Gründe:

1. Ihre Priorität ist zu nieder. Das ist einer meiner Kritikpunkte an agilen Vorgehensweisen. Stillstand durch Priorisierung. Wenn immer ausschließlich die aktuell wichtigsten Dinge umgesetzt werden - wer kümmert sich dann um die richtigen Dinge?
2. Die Welt dreht sich weiter. Schnell. Und damals, als jemand diese Anforderung aufgenommen hat, hatte sie sicher ihre Existenzberechtigung, ihren Customer Value, ihre raison d'être. Wenn sie dann aber längere Zeit am Whiteboard herumhängt, haben sich die Rahmenbedingungen mit hoher Wahrscheinlichkeit geändert. Und mit ihnen auch die Notwendigkeit dieses Tasks.

Also haben wir nach einiger Zeit Anforderungen, die nicht mehr die Wichtigkeit repräsentieren, die sie vielleicht einmal hatten. Und bis vor ein paar Jahren war es auch normal für Aufgaben, richtig alt zu werden. Denk nur an all die Gremien, Arbeitsgruppen, Hierachieebenen, die so eine Anforderung zu durchlaufen hatte. Immer noch zu durchlaufen hat. In den Firmen, die den Druck zur Veränderung noch nicht allzu fest spüren. Und in diesen Fällen ist es zwar nicht unbedingt gut, aber auch nichts Schlechtes, sich Zeit zu nehmen. Aber in Umgebungen, die sich stetig und vor allem schnell ändern (und in diesen Zeiten sehen wir einen ganzen Haufen Umgebungen, die sich stetig und vor allem schnell ändern), ist dieser Stillstand tödlich. Also lasst mich den Satz umformulieren: Also haben wir nach einiger Zeit Anforderungen, die nicht mehr den Wert repräsentieren, den sie vielleicht einmal hatten.

Eine Icebox in einer Icebox #

Ich hoffe, dass wir alle übereinstimmen, dass wir diesen Typ Anforderung nicht in der Nähe unseres Boards haben wollen. Und da gibt es für mich auch noch eine Situation, die dieser sehr ähnlich ist: “geparkte” User Stories oder Tasks in einem Backlog. Ok, nicht ähnlich. Viel schlimmer eigentlich. Eine Icebox ist wenigstens eine Art Signal. Innerhalb eines Product Backlogs erhöhen diese “geparkten” Tasks nur die Unklarheit. Wald und Bäume und so. Und das reduziert die Wartbarkeit und vor allem - noch viel schlimmer - die Transparenz dieses Backlogs. (Und ja, ich denke, manchmal ist das vielleicht sogar gewollt. Und wenn das gewollt ist, dann ist eine Icebox natürlich nicht unser Hauptproblem. Aber das ist eine andere Geschichte.) Also sollten wir einen Backlog, mit dem wir arbeiten, nach genau diesem Typ User Story durchschauen. Und da ist es vollkommen egal, ob unsere Rolle Projektmanager, Scrum Master, Product Owner, oder was auch immer heißt. Denn diese Aufgaben sind eine Icebox in einer Icebox. Und doppelter Schmerz ist im Normalfall keine tolle Sache.

Wie man mit diesen Anforderungen umgeht #

Ich denke, es hängt sehr viel vom Umfeld und dem Team und der Kultur ab, wie man mit solch “geparkten” Aufgaben umgeht. Ich habe viel positive Erfahrungen mit Schimmelpunkten gemacht. Jeden Tag in der Früh klebt Ihr so einen kleinen runden Sticker auf jede Aufgabe auf Eurem Board, die nicht während dieses Sprints gezogen wurde. Ihr könnt die Zettel natürlich auch mit einem Filzstift markieren. Und wenn diese Punkte sich dann vermehren (wie Schimmel eben), werdet Ihr irgendwann den Punkt (verzeiht das Wortspiel) erreichen, an dem Ihr nicht mehr lesen könnt, worum es bei dieser Anforderung geht. Und in genau dem Moment, könnt Ihr sie vom Brett entfernen.

Wenn Ihr das digitale Äquivalent eines Kanban- oder Scrumboards verwendet, funktioniert das natürlich nicht. (Es ist viel zu mühsam, die Punkte wieder vom Bildschirm herunter zu bekommen. Badumm-Tss.) Hier müsst Ihr also diese vor sich hin gammelnden Tasks transparent machen. Und ich weiß, das ist anstrengend. Es ist nicht leicht, die Lästwanzen zu sein, die jedes harmonische Daily Meeting mit der immer gleichen Frage stört: “Gibt es Neuigkeiten zu dieser User Story?” Aber in meinen Augen ist es das wert. Ein aufgeräumter Backlog erhöht die Effektivität eines jeden Teams.

Das Beste kommt zum Schluß #

Für mich gibt es zwei Möglichkeiten, mit einer Anforderung umzugehen: entweder, sie generiert genügend Customer Value, um eine entsprechend hohe Priorität zu haben, um umgesetzt zu werden. Dann setzt sie um. Wenn nicht: werft sie weg.
Und hier ist die in meinen Augen einzig positive Sache an so einer Icebox. Die “geparkten” Anforderungen sind bereits identifiziert und an einem Ort gesammelt worden. Also könnt Ihr das ganze Ding nehmen und wegwerfen. Zeit für ein Eis.

#agilität #anforderungsmanagement

Vielen Dank für Deine Zeit! Du kannst den Artikel gerne teilen. Und ich freue mich immer, von Euch zu lesen. Bilder von Brooke Lark auf Unsplash.

← Vorheriger Artikel: Warum im Projektmanagement so viel über fernöstliche Philosophie geredet wird
→ Nächster Artikel: Riskiest Asumption Tests als Alternative zum Minimum Viable Product

Veröffentlicht am 05 Jul 2019