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.

Posted in Deutsche Beiträge and tagged , .

2 Comments

  1. Hallo Ralf,
    ich denke, ein Teil der Ursachen für das von dir beschriebene Problem liegt im Umfang einer Anforderung. Ich sehe immer wieder, dass in Backlogs zu feingranular zerlegte Aufgaben stehen. Damit steigt dann auch der Druck, bereits zu viel Lösung vorauszuplanen. Und dann ist man sofort bei den von Dir beschriebenen Effekten. Gerade bei „technisch vorbelasteten“ Kunden bzw. Stakeholdern oder auch Product Ownern scheint mir das zu feine Backlog häufig vorzukommen. Siehst Du das ähnlich und wie vermeidest du das Problem?

  2. Hallo, Uwe!

    Ein zu feines Backlog in dem Sinne, dass die einzelnen Einträge sehr klein, gar zu klein sind, habe ich noch nicht gesehen. (Prämisse: Im Backlog stehen natürlich nur Inkremente.) Vielmehr beobachte ich fast durchgehend eine Skepsis bis Unfähig, Inkremente wirklich fein zu schneiden. Mit „wirklich fein“ meine ich, dass ein Feedback max. 16 Zeitstunden in der Zukunft liegt.

    Was ich allerdings sehe, das sind Backlogs, die deutlich gröbere Anforderungen enthalten – davon aber sehr, sehr viele und auch durchaus sehr alte.

    Das halte ich für einen Übelstand. So ein Backlog ist Symptom für Unzuverlässigkeit und/oder Verschwendung.

    Was ich in meinem Artikel über Priorisierung gesagt habe, ich für mich jedoch orthogonal zu Anzahl und Granularität der Backlogeinträge. Bei gegebener Zahl und Granularität, von denen ich annehme, dass sie angemessen sind, bleibt immer noch die Frage, ob es eine Liste (!) von priorisierten Einträgen geben sollte.

    Darauf meine Antwort: Nein. Denn jede Liste ist ein Plan. Und jeder Plan drängt danach, eingehalten zu werden. Planeinhaltung ist eine Optimierung: Es soll eine Effizienz hergestellt werden, die ohne Plan nicht vorhanden wäre. Wie viel solcher Optimierung zuträglich ist, hängt von der Stabilität der Umwelt ab. Und da sehe ich tendenziell viel weniger Stabilität, als die Planerfüllung einer priorisierten Anforderungsliste rechtfertigen würde.

    Ein umfangreiches Backlog wie eine Liste von priorisierten Anforderungen sind Aussagen über die Zukunft. „So soll es werden…“ Damit wäre ich sehr, sehr vorsichtig.

    Für mich hat ein Backlog Einträge sehr unterschiedlicher Größe: wenige sehr feine, einige mehr gröbere und wieder wenige sehr grobe. Auf jeder Granularitätsebene kann es eine Highlander-Anforderungen geben. Bei den sehr groben Anforderungen würde ich das vielleicht „strategischen Fokus“ nennen.

    Die sehr feinen Anforderungen stellen den Pool dar, aus dem immer wieder der nächste Highlander gewählt wird. Wenn der Pool droht auszutrocknen, werden gröbere Anforderungen fein geschnitten, um ihn aufzufüllen. Droht der Pool der gröberen Anforderungen auszutrocknen, werden sehr grobe zerlegt.

    Solche schrittweise Verfeinerung folgt der Entwicklung des Verständnisses und der Anforderungsstabilität.

    Ein Backlog, wie du es vor Augen hast, ist – so vermute ich – das Ergebnis eines übertrieben zuversichtlichen PO (er überschätzt die Stabilität von Anforderungen) und/oder eines PO, der Angst davor hat, untätig auszusehen (lokale Auslastungsoptimierung).

    Wie kann man ein umfangreiches Backlog vermeiden? a) Grenzen (WIP-Limit) für die mindestens 3 Granularitätsstufen definieren; sind die erreicht, werden keine weiteren Anforderungen zerlegt. b) Dem PO klar machen, dass es noch andere Arbeit gibt, als das Backlog zu füllen. Da wären zu nennen: mehr Gespräch mit der Entwicklung bei der Findung des Highlanders und mehr aktive Präsenz bei der Entwicklung während der Umsetzung des Highlanders und sorgfältige Abnahme des Highlanders.

    Die Highlander-Anforderung selbst ist natürlich auch schon ein WIP-Limit.

Comments are closed.