Notfälle oder langfristige Ziele zuerst?

Was kommt zuerst, der Notfall oder das langfristige Ziel?

Ungefähre Lesedauer: 10 Minuten

Kommt Ihnen dieses Problem bekannt vor:

Ihr agiles Team durchläuft eine Reihe von Sprints mit den vom Product Owner am höchsten priorisierten Items. Nach diesen Sprints schauen Sie sich an, was Ihr Team geschafft hat, und das ist nicht besonders zufriedenstellend. Alles, was das Team scheinbar tat, war einen Notfall nach dem anderen zu beheben.

Das Team hat natürlich viel Arbeit erledigt, aber am Ende kommt dabei nicht viel heraus.

Was ist passiert? Sie sind in die Falle getappt, die Priorisierung anhand dessen vorzunehmen, was am Anfang des Sprints am dringendsten erscheint – eine häufige Nebenwirkung der iterativen und inkrementellen Arbeit in Agile. Aber da gibt es einen besseren Weg.

Die agile Priorisierungsfalle:  Die Arbeiten am Anfang des Sprints auswählen

Am Anfang jeder Iteration die Arbeit für den jeweiligen Sprint auszuwählen, kann suboptimal sein. Es kann dazu führen, dass Product Owner die Priorisierung der Arbeiten immer nach der tagesaktuellen Krise ausrichten, sei es

  • ein brennendes Support-Problem
  • etwas, das das Unternehmen am Vortag einen Verkauf gekostet hat, oder
  • die neueste Laune eines wichtigen Stakeholders.

Auch wenn dies vielleicht im Moment die wichtigsten Dinge sind, an denen gearbeitet werden sollte, sind es meistens keine strategisch wichtigen Arbeiten. Wenn der Product Owner sich entscheidet, an etwas zu arbeiten, wonach am lautesten verlangt wird, verzichtet er damit auf die Möglichkeit, mit einem größeren, wichtigeren oder strategischeren Punkt voranzukommen.

 Sie wollen mehr über Sprint erfahren? Besuchen Sie unsere Trainings  Zu den Trainings
Die Priorisierung ohne konkretes Ziel ist wie die Besteigung eines Berges ohne Karte

Wir in Colorado sind stolz auf unsere 53 „Fourteeners”. Das sind Berge, die mindestens 14.000 Fuß (4.267 Meter) hoch sind.

Es gibt zwei Möglichkeiten, zur Spitze eines solchen „Fourteeners” zu gelangen:

1) Der erste Ansatz ist, einfach zum Fuße des Berges zu fahren und auf den höchsten Punkt, den man sieht, zuzulaufen. Das wird in den meisten Fällen aber nicht der eigentliche Gipfel sein – es sieht nur so aus, da er den wahren Gipfel hinter sich verbirgt.

Aktuelle Herausforderung vs. Gesamtziel

Wenn man nur auf die aktuellsten Herausforderungen schaut…

Wenn Sie den vermeintlichen Gipfel erklommen haben, können Sie plötzlich noch einen höheren erkennen. Wenn Sie glauben, dies sei der echte Gipfel, werden Sie ihn vielleicht erreichen und merken, dass auch dies nicht der richtige Gipfel des Berges ist.

So machen Sie immer weiter, bis Sie endlich doch noch den wahren Gipfel sehen können. Jedoch befindet sich zwischen Ihnen und dem Gipfel eine tiefe Schlucht und um diesen 14.000er zu erklimmen, müssen Sie erst 10.000 Fuß hinabklettern, um dann auf der anderen Seite wieder hinaufzuklettern.

Das ist ganz eindeutig keine gute Art und Weise, einen von Colorados „Fourteeners” zu bezwingen.

2) Die zweite Möglichkeit wäre, eine topografische Karte zu kaufen. Mit dieser Karte können Sie dann eine viel effizientere Route zum Gipfel des Berges planen, als irgendwo hinauf und wieder hinunterklettern zu müssen, um schließlich erneut 10.000 Fuß den Berg hochzuklettern.

Das große Ganze sehen: Die Product Owner Map

Für den Product Owner ist das Äquivalent zu einer solchen topografischen Karte ein größeres Ziel, das sich über mehrere Iterationen erstreckt. Ohne ein solches Ziel klettert der Product Owner lediglich von einem falschen Gipfel zum nächsten. Der Product Owner und sein Team kommen dann zwar vielleicht irgendwann auch an ihrem endgültigen Ziel an, allerdings häufig erst nachdem sie sich erst einmal durch das 10.000 Fuß tiefe Tal kämpfen mussten.

Und doch ist es so verlockend, sich stattdessen all den akuten Krisen zu widmen, die viel dringender erscheinen.

Erstens gibt es dem Product Owner das Gefühl, etwas erledigt zu haben: Etwas wurde fertiggestellt und kann von der To-Do-Liste gestrichen werden. Zweitens besänftigt es natürlich denjenigen, der um diese kurzfristige Lösung seines Problems gebeten hat. Die meisten von uns wollen andere Menschen zufriedenstellen, was häufig unsichtbare und unbewusste Auswirkungen auf das größere, langfristigere und normalerweise wichtigere Ziel hat.

Was dringend ist, ist selten wirklich wichtig

Schon US-Präsident Eisenhower wusste, dass es essentiell ist, zwischen wichtigen und dringenden Angelegenheiten zu unterscheiden. Obwohl es keine historischen Belege dafür gibt, wird er häufig mit folgendem Satz zitiert:

Was wichtig ist, ist selten dringend, und was dringend ist, ist selten wichtig.

Wie auch immer er es formulierte, Eisenhower war der Meinung, dass diese dringenden Krisen, denen wir alle geneigt sind, den Vorzug zu geben, meist nicht wichtig dafür sind, unsere übergeordneten Ziele zu erreichen.

Ein guter Product Owner wird darauf achten, sowohl die Wichtigkeit als auch die Dringlichkeit von Product Backlog Items bei der Priorisierung der Arbeit für das Team zu berücksichtigen.

Product Owner sollten vierteljährlich ein wichtiges übergeordnetes Ziel festlegen

Wenn ein Product Owner nicht weiß, was wichtig ist, wird das Dringliche immer gewinnen. Und das führt zu einer Reihe von unbefriedigenden Sprints, wie ich sie am Anfang dieses Beitrags beschrieben habe. Wenn ein agiles Team von einem dringenden Problem zum nächsten springt, verblasst die unmittelbare Zufriedenheit schnell, da das Team und die Stakeholder erkennen, dass sie den wichtigeren Zielen nicht wirklich näher gekommen sind.

Das bedeutet, dass es essenziell ist für einen Product Owner, ein wichtiges und bedeutsames Ziel zu haben. Mehr Infos dazu:

Ich finde, dass die besten dieser Ziele in ca. drei Monaten von einem Team umgesetzt werden sollten.

Ein Ziel über mehr als nur eine Iteration zu setzen, ist wichtig, weil sich das Team so auf ein längerfristiges Ziel konzentrieren kann. Das heißt, dass dieses bedeutsame Ziel ein wichtiges Geschäftsergebnis sein sollte, wie etwa das Migrieren eines Teils des Systems zu einer neuen Technologie; das Hinzufügen eines großen, wichtigen Features; oder ähnliches.

Was auch immer es ist, es sollte bedeutsam sein. Im Falle eines neuen Produkts könnte es die Erstellung eines Minimum Viable Products (MVP) sein. Bei einem bereits existierenden Produkt ist es vielleicht das Hinzufügen eines Minimum Marketable Features (MMF). Manche Organisationen nennen dies auch gerne WIG: Wildly Important Goal (frei übersetzt: wahnsinnig wichtiges Ziel).

Ausgerüstet mit einem bedeutsamen Ziel – egal ob MVP, MMF oder WIG – wird der Product Owner besser in der Lage sein, dringende Bedürfnisse bewerten zu können. Wenn die Lösung eines dringenden Problems wichtiger ist, als an dem übergeordneten Ziel weiterzuarbeiten, dann sollte das Team sich auch auf jeden Fall darauf konzentrieren.

Fazit

Der Sinn der Erschaffung eines wichtigen, übergeordneten Ziels ist nicht das blinde Fokussieren auf ein iterationsübergreifendes Ziel. Vielmehr soll damit ein Mechanismus geschaffen werden, der dem Product Owner bei seinen Priorisierungsentscheidungen hilft.

Wenn es kein wichtiges Ziel gibt, mit dem man die Wichtigkeit von dringenden Problemen vergleichen kann, werden die dringenden Dinge immer gewinnen. 

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.