Meilensteine und Scrum

Um ihren Produktentstehungsprozess planbar zu machen, setzen viele Unternehmen eine Form von Meilensteinplanung ein. Im Detail gibt es hier viele Unterschiede, aber das Prinzip ist immer das gleiche: Die Meilensteine sind Punkte entlang einer zeitlichen Achse, zu denen das Entwicklungsprojekt intern evaluiert wird. Die Zeiträume zwischen den Meilensteinen bilden häufig die Entwicklungsphasen nach dem V-Modell ab. In solchen Fällen folgt auf eine Machbarkeitsstudie die Konzeptionsphase, gefolgt von Design-, Verifikations- und Validationsphasen. Um einen Meilenstein zu "passieren", wird anhand von festgelegten Dokumenten und Reviews überprüft, ob die vorangehende Phase erfolgreich abgeschlossen wurde.Zugleich entscheiden sich immer mehr produktentwickelnde Unternehmen (längst nicht mehr nur in der Softwareentwicklung) für den Einsatz agiler Rahmenwerke wie Scrum. Hier kommt dann sehr schnell die Frage auf, ob und wie Scrum mit einer Planung in Meilensteinen "vereinbar" sei oder zumindest "kompatibel" gemacht werden könne. Aus meiner Erfahrung beruht allein schon diese Wortwahl auf der falschen Vorstellung, dass Scrum und Meilensteine zwei Prozessvarianten seien. Wenn das so wäre, müsste man sich für eines von beidem entscheiden - oder eben einen Kompromiss finden, der ein wenig von dem einen und ein wenig von dem anderen realisiert (was auch immer das dann konkret bedeutet).Scrum ist eine Methode. Scrum sagt, dass Produkte iterativ (in regelmäßig wiederkehrenden Sprints) und inkrementell (Feature für Feature) entwickelt werden, damit die Organisation nicht erst zum Ende des Projektes, sondern kontinuierlich lieferfähig ist. Meilensteinpläne schreiben vor, welche Dokumentation wann im Laufe eines Projektes erzeugt und freigegeben werden muss. Scrum ist darauf ausgerichtet, die Entwicklung am Bedarf des Marktes auszurichten. Meilensteine sind hingegen interne Revisionsmechanismen, um Projekte auf der Spur zu halten.In meinem aktuellen Projekt sind wir zum Start folgendermaßen vorgegangen:

  • Zunächst sind wir die Bausteine der Meilensteinplanung einzeln durchgegangen und haben uns jeweils gefragt, ob diese für eine erfolgreiche Produktlieferung zwingend erforderlich sind.
  • Jene Bausteine, die für eine erfolgreiche Produktlieferung zwingend erforderlich sind (z.B. Risikoanalyse, Produktvalidierung, Test der elektromagnetischen Verträglichkeit - EMV), kommen in unsere Definition of Done. Darin klären wir, auf welcher Ebene (Story, Sprint, Release) wir sie einhalten können und wen wir dafür wann heranziehen müssen (z.B. QA beim Schreiben von Testfällen in der Sprintplanung).
  • Das hat in der Regel zur Konsequenz, dass die erforderlichen Bausteine deutlich früher geliefert werden, als sie nach der Planung in Meilensteinen gefordert wären.
  • Die Bausteine, die für eine erfolgreiche Produktlieferung nicht zwingend erforderlich sind (z.B. Erstellung Lasten- und Pflichtenheft), lassen wir außen vor und betrachten sie nicht weiter.

Zusammenfassend: Es wäre naiv, Meilensteinpläne komplett zu ignorieren. Manche der dort vorgeschriebenen Deliverables sind sehr wohl für eine erfolgreiche Produktlieferung wesentlich. Genauso naiv aber wäre es, die Vorschriften 1:1 umzusetzen, nur weil es der Plan so besagt. Vor allem bietet Scrum die Chance, die starre Abarbeitung von Meilensteinen dadurch überflüssig zu machen, indem die kritischen Projektaspekte schon zu Beginn angegangen werden, so dass der Zweck der Meilensteinplanung - die Projektabsicherung - ohnehin erfüllt wird.

Projektmanagement
Agile Toolbox
Scrum
bgloger-redakteur
November 10, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen