Diese Forderung ist nicht neu. Man möchte agil vorgehen aber dennoch bereits zu Projektbeginn den Leistungsumfang und genauen Releasetermin verbindlich vereinbaren. Möchte man da nicht zwei Dinge miteinander vereinbaren, die eigentich unvereinbar sind, oder gibt es doch einen Weg, genau das zu erreichen? Ein Versuch in dieser Richtung ist Reliable Scrum, aber ist das der einzige Weg?
Ganz kurz zusammengefasst möchte Reliable Scrum die einem Agilen Vorgehen eigenen Unsicherheiten eliminieren und es den Beteiligten ermöglichen, bereits zu Projektbeginn den genauen Leistungsumfang und einen konkreten Fertigstellungstermin zu definieren. Dazu ist es natürlich notwendig, bereits vor Projektbeginn die Features durchzuplanen. Dem Releaseplan wird ein Zeitpuffer zugefügt, der in jedem Sprint mit ausgewertet wird, so dass man weiß, wieviel von dieser zeitlichen Sicherheitszugabe bereits verbraucht sind.
Bitte verzeihen Sie mir, dass ich hier nur eine extrem kurze Zusammenfassung von Reliable Scrum gebe. Ich möchte lediglich einen Eindruck darüber vermitteln, was es bedeutet, diesen Weg zu gehen. Letzten Endes ist ein System wie Reliable Scrum eine Rolle rückwärts, da Sie wieder gezwungen sind, zum Projektbeginn eine umfassende Planung durchzuführen, in der Sie versuchen, alle Unsicherheiten zu eliminieren.
Nun ist es jedoch notwendig, dass wir die Zielsetzung betrachten. Das Ziel von Reliable Scrum ist es nicht, ein Vorgehen zu etablieren, dass dem Agilen Manifest entspricht. Das Ziel ist es vielmehr, in einer klassischen Kunde-Dienstleister-Beziehung einige der Vorteile eines Agilen Vorgehens zu nutzen (z.B. die schlanke Verwaltung und den weitestgehend optimierten Entwicklungsprozess). Wenn unser Ziel jedoch weiterhin ein Agiles Vorgehen ist, welche Möglichkeiten haben wir dann, Termintreue und Leistungsumfang zu garantieren?
Zunächst müssen wir eine Einschränkung vornehmen: Definieren wir zu Projektbeginn ein detailliertes Featureset, das während der Projektentwicklung keinen Freiraum mehr lässt, würde ich nicht mehr von einem Agilen Vorgehen sprechen. Einigen wir uns jedoch (wie es eher üblich ist) auf einen groben Leistungsumfang (also eher auf die Epics als auf die einzelnen Anforderungen), und entwickeln die Anforderungen während des Proejktfortschritts im Detail, dann kann man sicherlich noch von Agilität sprechen.
Selbstverständlich müssen wir wissen, wozu unser Team in der Lage ist. Dazu können Sie entweder die Velocity bestimmen oder auf Erfahrungswerte zurückgreifen, wenn das Team bereits länger zusammenarbeitet. Gerade zu Projektbeginn ist die Bestimmung der Velocity schwierig. Auch ein eingespieltes und erfahrenes Team muss sich mit jedem neuen Projekt an neue Dinge anpassen und gewöhnen. Das kann eine neue Entwicklungsumgebung sein, neue Testzyklen, neue Technologien oder was auch immer. Schon allein deswegen ist es notwendig, die Entwicklungsgeschwindigkeit immer wieder zu überprüfen.
Es ist eigentlich egal, ob Sie Punkte nutzen und eine Velocity ermitteln (auch wenn ich kein großer Fan davon bin, wie Sie vielleicht bereits wissen), oder ob Sie mit konkreten Zeiten arbeiten, die Sie gemeinsam mit den Entwicklern ermitteln. Wichtig ist, dass Sie bei der Erstellung des Releaseplans kontinuierliche Meilensteine mit Hilfe der Epics setzen, die bereits grob definiert sind. So schaffen Sie Timeboxes für jedes einzelne Mainfeature. Hierfür ist viel Erfahrung notwendig. Ein sehr junioriges Team wird Sie dabei nur schwer unterstützen können. Sie benötigen die Expertise von mindestens einem (besser zwei) sehr erfahrenen Softwareentwicklern, auch wenn die einzelnen Epics noch nicht im Detail ausgearbeitet sind.
Das weitere Vorgehen ist jetzt nicht mehr von Sprint zu Sprint sondern von Epic zu Epic und damit von einem Meilenstein zum nächsten. Während Sie mit Ihrem Team an einem Epic arbeiten, werden die Anforderugen für das Folgende vollständig und detailliert ausgearbeitet und geschätzt. Damit überprüfen Sie, ob Ihre ursprüngliche Meilensteinschätzung realistisch war, können frühzeitig gegensteuern und ggf. den Leistungsumfang der einzelnen Epics anpassen, ohne den gesamten Leistungsumfang der Software zu stark zu beeinflussen. Bei diesem Vorgehen sehen Sie auch frühzeitig, wenn das Projekt im ganzen zeitlich nicht mehr der ursprünglichen Planung genügt.
Im Prinzip teilen Sie also ein größeres Projekt in kleinere Einzelprojekte auf. Dadurch teilen Sie auch die Planung in kleinere Einheiten, in denen Sie sehr genau vorgehen können. Auf diese Weise erhalten Sie eine hohe Planungssicherheit in komplexen Projekten bei hoher Fexibilität. Innerhalb der Timebox Epic haben Sie viele Freiheiten, die sich nicht auf die Gesamtheit auswirken.
