Die Highlander-Anforderung

Irgendetwas ist faul mit der Priorisierung von Anforderungen. Der Gedanke beschleicht mich mit jedem (agilen) Team mehr, das ich sehe. Denn die allerwenigsten agieren in der wunderbaren Welt der Vorstellung, dass es einen echt kompetenten, entscheidungswilligen und -befugten und auch noch präsenten Kunden (bzw. Stellvertreter) gibt.

So ein Kunde mag wünschenswert sein. Ja, sehr sogar. Er spielt die wichtigste Rolle in der Softwareentwicklung. Ohne einen "energischen" Kunden fehlt schlicht Energie und Kohärenz. Das Resultat: zuckende oder schlaffe Entwicklung.

Aber, ach!, so ein Kunde ist so selten zu sehen. Stattdessen: der Versuch, über ritualisierte Handlungen aus dem agilen Werkzeugkasten irgendwie doch flüssig voranzukommen.

Ein Beispiel dafür: die Priorisierung der Anforderungen. Periodisch wird darüber entschieden, welche Anforderungen als nächstes in welcher Reihenfolge angegangen werden sollen. Das klingt ja auch plausibel, oder? Erstmal einen Plan machen, bevor man loslegt. Denn nichts anderes ist ein priorisierte Liste von Anforderungen; in Scrum heißt die Sprint Backlog.

Nur leider gibt es mit so einer Liste immer wieder Konflikte. Ich weiß, das soll nicht sein. Ist die Liste verabschiedet, soll sie innerhalb einer Iteration in Ruhe abgearbeitet werden. So soll es sein – und wer das nicht schafft, der hat das mit der Agilität noch nicht begriffen. Oder?

Irgendwie schon. Doch wenn das immer wieder so schwierig ist in der Realität... dann glaube ich, sollte mal der agile Plan überdacht werden. Dann sind die Teams womöglich nicht zu beschränkt, um es richtig zu machen. Vielmehr könnte es sein, dass das schöne Rezept nicht zu ihrem Kontext passt.

Ja, vielleicht ist das bedauernswert und der Kontext sollte verändert werden. Doch das braucht Zeit. Was also in der Zwischenzeit tun?

Wie wäre es mit einem Blick ins Orakel der Agilität, dem Manifest? Da steht: Responding to change over following a plan.

Ok, also weg mit dem Plan! Zumindest probeweise. Weg mit der priorisierten Anforderungsliste!

Schauen wir genau hin: Was ist denn das Wichtigste, der Kern, die Motivation bei der ganzen Priorisierung? Es ist der Gedanke, stets das als nächstes zu tun, was bei begrenzten Mitteln den größten Effekt verspricht. Wie das beurteilt wird, lasse ich mal dahingestellt. Irgendwelche Kriterien gibt es und mit denen wird entschieden, dass die Anforderungen A, B, C, D in der Reihenfolge C, A, D, B umgesetzt werden sollten.

Aber jetzt noch genauer hingeschaut:

• Diese Liste der priorisierten Anforderungen gilt nur im Moment der Entscheidung. Sobald neue Informationen ins Team fließen, können sich die Prioritäten schon wieder verändern.
• In dieser Liste ist eigentlich nur eine Anforderung wirklich relevant: die am Anfang der Liste. Es kann zu jedem Zeitpunkt nur eine Anforderung geben, die als nächstes umgesetzt werden sollte. Ich nenne sie die Highlander-Anforderung. Sie erinnern sich an den Film Highlander - Es kann nur einen geben? (Oder genauer: Falls mehrere Anforderungen sinnvoll gleichzeitig angepackt werden können, dann kann es auch mehrere Highlander geben. Aber der Einfachheit halber spreche ich im Weiteren nur von einer.)

Wenn man diese beiden Punkte nicht im Blick hat, dann wird aus dem Sprint Backlog schnell ein Plan, der im Zweifelsfall wichtiger ist als die Reaktion auf Veränderungen.

Es steckt doch so viel schöne Mühe in der priorisierten Liste. Die kann man doch nicht bei jedem Zucken des Kunden über den Haufen werfen, oder? Da sage ich nur, "Achtung, Denkfalle!": Sunk Cost Fallacy.

Außerdem braucht man doch mal auch ein bisschen Ruhe bei der Arbeit, oder? Klar, Ruhe wäre schön. Und ich meine auch nicht, dass eine neue Anforderungswetterlage dazu führen sollte, etwas in Arbeit befindliches abzubrechen. Nein, ganz klar, erstmal fertigmachen, was angefangen wurde. Doch warum muss anschließend das getan werden, was auf einer Tage oder Wochen alten Liste steht?

Meine Haltung ist insofern inzwischen diese: Es braucht keine Liste von priorisierten Anforderungen. Es braucht nur wiederkehrend bzw. bei Bedarf eine Priorisierung dessen, was noch zu tun ist. Und das Ergebnis der Priorisierung ist nur 1 Anforderung: die Highlander-Anforderung. Nicht mehr.

Alles andere führt entweder zum Klammern an überholten Entscheidungen oder zur einer vorzeitigen Optimierung im Hinblick auf Anforderungen weiter unten auf der Liste, weil man die ja schon im Blick hat. Oder das Team beginnt zu viel Work-in-Progress, weil man ja, wenn etwas stockt, schnell den nächsten Punkt auf der Liste beginnen kann.

Der Algorithmus zur Priorisierung, der dem entgegenwirkt, ist ganz einfach:

1. Wähle eine Anforderung aus dem Backlog.
2. Wähle eine zweite Anforderung aus dem Backlog.
3. Entscheide, welche der beiden Anforderungen eine höhere Priorität hat. Das ist die aktuelle Highlander-Anforderung.
4. Lege die andere Anforderung beiseite. Sie spielt während der weiteren Priorisierung keine Rolle mehr.
5. Gehe solange zurück zu 2., bis du genügend Anforderungen betrachtet hast.

Die Auswahl in Schritt 1. und 2. kann auch aus einer Untermenge des Backlog erfolgen; ich nenne sie mal die Highlander-Kanidaten. Es spricht nichts dagegen, so einen Pool ständig im Hintergrund zu pflegen. In den kann jederzeit auch eine ganz neue Anforderung einfließen, die von der Seite reingrätscht. Dass Kunde oder Management einen tollen Einfall haben, ist ja nichts Besonderes, oder?

In jedem Fall ist das Ergebnis der Priorisierung lediglich 1 Anforderung: der Highlander. Nur genau diese Anforderung wird nach der Priorisierung umgesetzt. Alle anderen Anforderungen haben keine relevante Priorität mehr. Wann sie drankommen, steht bei der nächsten Priorisierung zur Disposition.

Wann sollte die nächste Priorisierung stattfinden? Wenn abzusehen ist, dass die Umsetzungsressourcen wieder freie Kapazität haben werden. Nicht früher, nicht später.

Bis dahin kann sich viel an den Projektbedingungen ändern. Das alles kann eingehen in die nächste Priorisierung. Kein Plan wird dann gestört. Es herrscht maximale Reaktionsfähigkeit in Bezug auf Veränderungen (responding to change).

Für mich ist eine Liste von priorisierten Anforderungen ein Relikt aus Tagen vor der Agilität. Da hat sich selbst Scrum nicht getraut, echt agil zu sein. Es gibt keine Not für ein Sprint Backlog. Genauso gibt es keine Not für Sprints, die in aller Ruhe Listen von Anforderungen abarbeiten. Solche Pläne sind für die Umsetzung von Anforderungen durch Programmierer kontraproduktiv. Sie erzeugen trügerische Gewissheit. Sie führen zu unnötigen Diskussionsaufwänden, wenn sich die Situation ändern sollte. Sie führen zu überschießendem WIP.

Dabei ist die Lösung so einfach: Kunden bzw. ihre Stellvertreter müssen sich nur auf 1 Anforderung konzentrieren. Mit einer Highlander-Anforderung wird es für alle Beteiligten leichter.