In der Softwareentwicklung ist es üblich, dass wir eine Aufgabe bekommen, und noch bevor diese erfüllt ist, sollen wir mit einer neuen Aufgabe anfangen. Man kann sich das vorstellen, wie einen Stack, einen Kellerspeicher. Nach und nach wächst der Stapel, der aus lauter teilweise erledigten Dingen besteht, aber nur gelegentlich wird eine Sache fertig, nämlich dann, wenn wir es zufällig schaffen, vor der nächsten neuen Aufgabe die gerade bearbeitete zu erledigen. Wenn wir unsere gleichzeitige Arbeit (Work in progress, WIP) nicht limitieren, werden wir am Ende nur sehr wenig fertig bekommen, und wir verrichten viel Arbeit ohne Ergebnis. Das ist nicht nur frustrierend, sondern auch ökonomisch suizidal.
Wollen wir dem entgegenwirken, ist ein WIP-Limit ein sinnvolles Werkzeug, solange es respektiert wird. Wir fangen keine neue Aufgabe an, bis eine andere erledigt ist, und garantieren dadurch einen Wertzuwachs des Systems. So die Theorie. Voraussetzung dafür ist, dass wir auch die richtigen Dinge tun, also die Aufgabe erledigen, die dem System tatsächlich einen Wertzuwachs bieten kann. Die Theorie impliziert eine sinnvolle Priorisierung der Aufgaben.
In der Praxis können wir beobachten, dass gerade die Prioritäten oft die größten Schwierigkeiten bereiten. Sonst könnte, sinnvolle Kommunikation vorausgesetzt, nur in echten Notfällen die Situation entstehen, dass halb erledigte Arbeiten verworfen werden, weil etwas anderes plötzlich wichtiger geworden ist. Aus dem Ärger über die Verschwendung meiner Arbeitskraft auf diese Art und Weise habe ich in einem Unternehmen, in dem ich gearbeitet habe, den Begriff „Prioritätengeschwindigkeit“ geprägt. Eine genaue Definition habe ich damals nicht geliefert. Vielleicht gelingt es mir heute. Gemeint ist die Geschwindigkeit, mit der sich die Prioritäten verändern, schlimmstenfalls vollständig umkehren.
Eine Geschwindigkeit ist eine Veränderung, gemessen über die Zeit. Die Zeit zu messen, ist kein Problem, das konnten wir schon vor ein paar Jahrtausenden, und genauer als ein paar Stunden müssen wir im aktuellen Zusammenhang (hoffentlich) nicht werden. Schwierig gestaltet sich jedoch das Mass für die Veränderung von Prioritäten. Nur wenn ich mehrere Aufgaben habe, muss ich entscheiden, welcher ich den Vorzug gebe, Prioritäten sind relativ. Um nun unabhängig von der Anzahl der Aufgaben eine sinnvolle Größe für die Veränderung von Prioritäten zu finden, muss ich mich auf eine bestimmte Anzahl beschränken, am besten die Mindestanzahl, also zwei. Damit gibt es auch nur eine mögliche Veränderung, nämlich die Umkehrung der bestehenden Priorität der beiden Aufgaben. Für unsere zu definierende Maßeinheit ergibt sich also: „Die Zeit, die benötigt wird, um die Priorität zweier Aufgaben zu tauschen.“
Haben wir mehr als zwei Aufgaben, könnte es aber sein, dass die Prioritäten nicht tauschen, sondern sich beliebig verändern. Wir sind also noch nicht fertig. Die Priorität welcher Aufgaben muss sich also ändern, damit es sich zu messen lohnt? Was wollen wir denn genau wissen? Wesentlich ist in unserem Zusammenhang, ob die Aufgabe mit der höchsten Priorität plötzlich weniger wichtig ist, als eine andere, also ob wir möglicherweise mit der aktuellen Aufgabe zugunsten einer anderen aufhören müssen. Und das halte ich für die korrekte Definition der Prioritätengeschwindigkeit: „Die Veränderungen der Aufgabe mit der höchsten Priorität gemessen über die Zeit.“
Auch wenn die Definition jetzt erfolgreich ist, gefällt mir die Maßeinheit nicht, denn wir messen damit etwas Negatives. Ich meine nicht, dass wir negative Zahlen erreichen (obwohl? mal nachdenken… wird die Zahl negativ, wenn wir eine Aufgabe erledigen, ohne dass eine andere Aufgabe auf Platz eins gewandert ist?), sondern dass wir die Organisation schlechter bewerten, je höher der Wert ist. Eine hohe Prioritätengeschwindigkeit heißt, dass die Organisation eine geringe Reife besitzt, wenn wir uns an CMMI oder so etwas orientieren. Folglich wollen wir eigentlich den umgekehrten Wert haben, also die Zeit, über die die Top-Prio stabil bleibt. Je höher dieser Wert ist, desto besser die Organisation. Diese positive Aussage finde ich schon viel angenehmer. Nennen wir die Größe also „Prioritätenstabilität“ und die Maßeinheit soll vorerst „Zeit pro Prioritätenänderung heißen“.
Nun ist es jedoch unrealistisch anzunehmen, dass allein die Organisation Einfluss auf die Prioritätenstabilität hat. Äußere Einflüsse, gegen die wir uns gar nicht wehren können, bestimmen ebenfalls darüber, was wir zuerst tun müssen. Ich habe jahrelang im Gesundheitswesen gearbeitet, und rückwirkend verabschiedete Gesetze mit einer Vorlaufzeit von weniger als einem Monat sind keine Seltenheit. Eine niedrige Prioritätenstabilität ist also nicht zwingend ein Zeichen schlechter (unreifer) Organisation, sondern kann ebenso gut fremdbestimmt sein. Wir müssen also damit rechnen und darauf reagieren können, dass Prioritäten sich ändern. Das ist einer der Kernpunkte des Agilen Manifests, nämlich dass das Reagieren auf Veränderungen wichtiger ist als das befolgen eines Plans.
Damit wissen wir jetzt, dass die Stabilität von Prioritäten die Arbeit erleichtert. Auch wenn wir uns nicht gegen die äußeren Einflüssen wehren können, müssen wir zumindest in dem Bereich, den wir bestimmen können, für eine möglichst hohe Stabilität sorgen. Dazu brauchen wir ein Werkzeug. Sehen wir mal, was es denn so gibt.
Wenn es in meinen Workshops Aufgaben zu priorisieren gibt, lasse ich die Gruppe entscheiden. Ich fange mit einer nahezu beliebigen Aufgabe an, die ich als Zettel in die Mitte einer Pinnwand hänge. Für jede weitere Aufgabe frage ich, ob sie wichtiger oder weniger wichtig ist, als die Aufgabe, die schon an der Wand hängt. Ist sie wichtiger hänge ich den neuen Zettel über den vorhandenen, andernfalls darunter. So geht es weiter, bis die Aufgaben eine klare Reihenfolge haben. Das ist eine Art demokratischer Priorisierung. Sie garantiert uns ein gewisses Einverständnis, und die Chance, dass die Priorisierung stabil bleibt ist hoch.
Habe ich aber keine Gruppe von Leuten zur Verfügung, mit denen ich die Prioritäten vereinbaren kann, muss ich einen Weg finden, die Dinge möglichst objektiv in eine sinnvolle Reigenfolge zu bringen. Dabei helfen mir Metriken. Eine sicher tendenziell subjektive, aber einfache Metrik bietet die Eisenhower-Matrix, bei Wikipedia auch unter „Eisenhower-Prinzip“ zu finden. Pro Aufgabe werden sowohl Wichtigkeit als auch Dringlichkeit auf einer binären Skala bestimmt. Dinge, die wichtig und dringend sind, erledigt man sofort. Nur wichtige Dinge erledigt man mit Termin selbst, dringende Sachen werden delegiert und wenn etwas weder wichtig noch dringend ist, kann man es getrost auch weglassen.
Ein interessanter Vortrag zum Thema „Priorisierung des Backlog“ kommt von Mike Cohn aus dem Jahr 2008. Mit Hilfe geschickter Fragestellung von zwei Perspektiven und einer Antwortskala, die für beide Fragestellungen gleich ist, erstellt er eine Antwortmatrix, deren Elemente eine Bewertung des in Frage gestellten Features (oder was auch immer beurteilt wird) darstellen. Mit Hilfe dieser Bewertung werden die Features kategorisiert und mit Quoten für die einzelnen Kategorien priorisiert.
Es gibt noch viele andere Möglichkeiten, Prioritäten zu bestimmen. Am Ende laufen alle auf eine klare Entscheidung hinaus, welche Aufgabe wichtiger ist als eine andere, und damit, welche Aufgabe im Zweifelsfall weggelassen werden muss. Im Zweifelsfall! Der Normalfall sollte ja sein, dass man beides erledigen kann, aber eben nacheinander.