Im Rahmen einer Scrum-Einführung in Unternehmen hat man gelegentlich gegen Vorurteile zu kämpfen. Ich habe eine Reihe von “Killerphrasen gegen Scrum” gesammelt, um zur Diskussion anzuregen und Vorbehalte auszuräumen. Mittlerweile sind so viele Argumente zusammengekommen, dass ich mich entschlossen habe, eine Serie auf unserem Blog zu starten.
In dieser Folge geht es um Planung, Controlling, Termintreue und Kundenintegration.
Keine Planung
“Es gibt in Scrum keine Planung.”
Manche Manager vertreten die Ansicht, es gäbe bei Scrum keine Planung. Zumindest böte Scrum Schutz und Rechtfertigung bei vager Planung. Aus diesem Grunde genießt Scrum bei ihnen kein allzu gutes Ansehen.
Mit Scrum wird weniger weit in die Zukunft und weniger tief ins Detail geplant, das ist korrekt. Die Pläne jedoch, die in “klassischen Projekten” erstellt wurden, unterliegen im Softwareentwicklungsprozess ständigen Änderungen. Man kann die Entwicklung komplexer Systeme einfach nicht genau vorausplanen. Die unausweichlichen Änderungen an Fachkonzepten, Lasten- und Pflichtenheften kennen wir als “Change Requests”, die zum Ende eines Projektes immer mehr zunehmen und dabei Dauer und Kosten in die Höhe treiben. In Scrum werden die nächsten 2, 3, vielleicht 4 Sprints detaillierter geplant, diesen Horizont kann man gut einschätzen. Alles, das weiter in der Zukunft liegt, wird zunächst nur grob geplant. Wichtig hierbei ist jedoch, die für spätere Sprints geplanten Stories eventuell veränderten Anforderungen anzupassen, und zwar möglichst in jedem Sprint Review. Welche Stories passen nicht mehr zur Vision? Welche Stories müssen aufgrund neuer Anforderungen entfernt werden, um Termin und Budget einzuhalten? Diese iterativ-inkrementelle Planung ist wesentlich genauer und realitätsnaher als beim “klassischen” Vorgehen. Ferner wird die Verschwendung von Zeit und Geld für später oftmals hinfällige, vorab erstellte Pläne vermieden.
Vision versus Controlling
“Die Verantwortlichkeit der fachlichen Vision zusammen mit dem Projektcontrolling in die Hand des Product Owners zu geben, stellt keine glückliche Situation dar.”
Scrum fordert, diese Verantwortlichkeiten in der Rolle des Product Owner zu vereinen.
Manche behaupten, es fände hier nicht die erforderliche Reibung zwischen fachlichem Bedarf und Projektrahmenparametern wie Terminen und Kosten statt. Das Resultat sei folglich eine fachlich gehemmte Vision.
Eine Vision muss sich meiner Meinung nach immer an ihren Kosten messen lassen. Der Visionär wird sich letztlich immer vom Controller bremsen lassen müssen. Hinsichtlich des angestrebten Return on Investment ist es sinnvoll, die beiden Blickwinkel in einer Person zu vereinen, um somit das Entstehen ausufernder, unrealistischer Visionen zu verhindern und auf der anderen Seite zu wissen, wann es sich lohnt, mal etwas mehr als sonst zu investieren. Natürlich muss auch erst einmal ein Product Owner gefunden werden, der diese unterschiedlichen Sichtweisen mit sich bringt.
Wir werden in einem anderen Teil dieser Serie detaillierter auf die Rolle des Product Owner eingehen.
Aufgaben und Termine
“Wenn ich die Aufgaben und Termine nicht direkt zuweise, werden sie ja nie fertig.”
Bisher oblag es Projektleitern, den Entwicklern bestimmte Aufgaben inklusive ihrer Fertigstellungstermine vorzugeben. Mit Scrum läuft es anders, denn hier entscheidet das Team selbst über seine Aufgaben und deren Bearbeitungsdauer. Als Argument gegen Scrum führen manche Projektleiter daher an, die Entwickler würden für die Umsetzung zu viel Zeit benötigen, wenn sie sich die Aufgaben selbst aussuchen und über deren Bearbeitungsdauer bestimmen können.
Bei Scrum setzt sich das Team selbst ein Ziel, und dies motiviert mehr, als eines vorgegeben zu bekommen. Zudem kann das Team selbst am allerbesten einschätzen, wie lange es für die Bearbeitung von Tasks benötigen wird. Die Aufgaben werden somit sehr wohl erledigt, möglicherweise sogar – bedingt durch den Scrum-Prozess – schneller als vorher. Die Kontrolle über die zu erledigenden Aufgaben erfolgt indirekt über die priorisierte Liste der Anforderungen, die umzusetzen sind. Die Entwickler müssen spätestens zum Sprintende die für den Sprint eingeplanten Tasks und Stories fertig haben. Der Rhythmus von gleichlangen Sprints trägt zur Termintreue bei, diese steigt im Laufe eines Projektes. Des weiteren hat der Product Owner während der Sprintplanung die Möglichkeit, auf Stories hinzuweisen, die unbedingt noch im kommenden Sprint umgesetzt werden müssen.
Kundenintegration
“Scrum klingt in der Theorie toll, aber unser Kunde spielt da niemals mit, der will sich nicht um die Software kümmern.”
Dieses Zitat stammt von einem Leser des ersten Teils dieser Serie. Mir selbst ist dieses Kundenverhalten ebenfalls gelegentlich aufgefallen. Der Kunde möchte am liebsten einfach sein Lastenheft beim Softwarelieferanten abgeben, sich völlig zurückziehen, um dann nach 1,5 Jahren sein Werk abzuholen. Somit empfindet er Scrum als unangenehm, da er hier stärker in den Entwicklungsprozess involviert wird.
Es erfordert in solchen Fällen einiges an Überzeugungsarbeit, dem Kunden klarzumachen, dass er mit dieser Einstellung auf keinen Fall eine zufriedenstellende Lösung erhalten kann. Seine Anforderungen und Prozesse sind häufig im Vorfeld noch nicht ganz klar, Details kristallisieren sich erst während der Entwicklung heraus. Je mehr er sich also einbringt, je enger er mit dem Softwaredienstleister zusammenarbeitet, desto besser wird am Ende das Ergebnis ausfallen.
Welche dieser vermeintlichen Killerargumente habt ihr in der Form oder ähnlich schon mal gehört oder entsprechen sogar eurer eigenen Überzeugung?
[Teil 1]
