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:

FRAGE: Warum macht ihr eigentlich kein SAFe®?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe®?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?

FRAGE: Was kostet eine agile Transformation?
Boris Gloger

FRAGE: Was kostet eine agile Transformation?

FRAGE: Welche Rolle spielt Training?
Boris Gloger

FRAGE: Welche Rolle spielt Training?

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?
Boris Gloger

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

FRAGE: Was sind die Hauptunterschiede zwischen klassischen Beratungen und borisgloger?
Boris Gloger

FRAGE: Was sind die Hauptunterschiede zwischen klassischen Beratungen und borisgloger?

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?
Boris Gloger

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

FRAGE: Habt ihr Beispiele für konkrete Situationen, in denen ihr Kunden bei einer schwierigen Herausforderung geholfen habt?
Boris Gloger

FRAGE: Habt ihr Beispiele für konkrete Situationen, in denen ihr Kunden bei einer schwierigen Herausforderung geholfen habt?

FRAGE: Welche Vorteile bietet es uns, wenn wir borisgloger beauftragen, anstatt die Transformation mit Internen voranzutreiben?
Boris Gloger

FRAGE: Welche Vorteile bietet es uns, wenn wir borisgloger beauftragen, anstatt die Transformation mit Internen voranzutreiben?

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?
Boris Gloger

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

FRAGE: Warum sollten wir mit borisgloger arbeiten?
Boris Gloger

FRAGE: Warum sollten wir mit borisgloger arbeiten?