Nudge am 22.06.2012

Scrum: Die verdammte Priorisierung

in Projektmanagement | Tags: Priorisierung, Projektmanagement, Scrum

Ich weiß nicht genau, ob Euch es genau so geht. Aber ich finde es schwierig, einem Kunden oder Auftraggeber eine saubere Priorisierung abzuringen.

Zunächst gilt: Alles ist immer wichtig, auf Prio A, super-wichtig (A+) und auch mal super-super-wichtig (A++). Nach A+5 gehen einem die Plusse in der Magnetkiste aus. Oder aber es ist dringend. Und dadurch auch ganz wichtig. Und nicht zu vergessen: Dieses Feature hier, das ist zwar eigentlich Nice-to-have, aber ein gewisser Benutzer, der braucht das unbedingt. Das muss also sofort gemacht werden, am besten gestern. Ist aber an sich nicht ganz so wichtig.

Wenn man solche Sätze hört, da bekommt man schon mal kurz Ausschlag, 180er Puls oder gleich beides zusammen. Das ist weder strukturiert noch motivierend oder zielführend. Womöglich denkt der Auftraggeber noch, durch diesen Druck wäre das Projekt schneller fertig. Weit gefehlt, diese Bauernschläue kann er sich gleich an den Nagel hängen.

Jetzt könnte jemand sagen: Haha, das kann dir ja mit Scrum nicht passieren, denn dort ist ja das Backlog einfach eine geordnete Liste. Der PO kann ja nicht zwei Einträge gleichzeitig nach ganz oben schieben. Aber was passiert denn, wenn die Priorisierung der Liste einfach glatt verweigert wird? Dann konzipiert man meist doch alle Use Cases fertig. Oder man priorisiert die Liste nach bestem Wissen und Gewissen und erntet als Dank noch die nette Antwort: Den wichtigen Use Case hier unten, den wollen Sie wohl nicht umsetzen? Ich hatte doch gesagt, der ist wichtig. Hören Sie mir überhaupt zu (Denkblase: Sie geistesumnebelter Projektwurm!?)?

Jetzt könnte man den guten alten Trick anwenden und sagen: Natürlich, lieber Kunde, die sind ALLE GANZ WICHTIG! Und wir machen ALLES, wie immer SOFORT und beginnen GLEICHZEITIG AN ALLEN PUNKTEN. Dann schaut der Kunde sicherlich zufrieden, und wenn er die Bauernschläue-Plus gebucht hat, dann guckt er im zweiten Blick etwas verunsichert. Nach 3 Wochen meldet man dann ERSTE KLEINE ZEITLICHE PROBLEME und verschleppt das Projekt wie üblich. Die Laune ist dann wieder auf dem Nullpunkt, der Kunde etwas darunter und man selbst hat noch etwas Halsschmerzen vom ständigen Kopfschütteln. Nicht zu vergessen: Der Kunde hat das Backlog wahrscheinlich auch so groß gemacht, damit er in der Zwischenzeit für dämliche Fragen nicht erreichbar sein muss (erst Messe, dann Urlaub), die Entwickler haben ja erstmal zu tun.

Eigentlich geht es nicht anders, man muss in solchen Situationen eskalieren. Vor dem Projekt. Am besten gleich bei Weigerung zur Priorisierung. Dann müsste man gleich sagen: Wir weigern uns, diese Anforderungen umzusetzen, wenn Sie nicht in der Lage sind, mit uns zu kooperieren und Ihre Pflicht im Projekt zu erfüllen. Das wäre das ehrlichste und zielführendste, was man tun könnte. Und das Schonendste für das Budget den Kunden. Aber vermutlich eskaliert dann der eigene Chef einen auf eine andere Umlaufbahn. Ein trauriges Dilemma.