Das Defizit von Scrum liegt darin, dass es das Verhältnis zur Organisation ausspart. Das zeigt sich schon, bevor der erste Sprint losgeht. Es gibt eine Unzahl von Vorstellungen über die Rahmenbedingungen; darf es z.B. einen Sprint Zero geben? Doch warum experimentiert man hier mit mehr oder weniger Organisations-Knowhow wild herum? Es gibt doch Methoden des Projektmanagements, die seit Jahrzehnten am Markt sind und sich mit solchen Fragen beschäftigen. Ich möchte in diesem Blogbeitrag diskutieren, ob PRINCE2 diesen Rahmen setzen kann.

AXELOS hat vor zwei Jahren PRINCE2 Agile auf den Markt gebracht, das de facto ein eigenständiger Projektansatz ist. Die Möglichkeit, Scrum "einfach so" mit einer Projektstruktur einen guten Rahmen zu geben, ist nicht wirklich dabei.

Bei der Einführung der neuen Version von PRINCE2, dem 2017 UPDATE, wurde behauptet, PRINCE2 komme agilen Ansätzen jetzt noch weiter entgegen. Und es gibt innerhalb der Community die Position, Prince2 sei immer schon agil gewesen (siehe zu dem Update auch "Was ist neu am neuen PRINCE2?").

Also schauen wir uns das genauer an. Schnell entdeckt man einige Gemeinsamkeiten von SCRUM und PRINCE2, die nahelegen, dass man die beiden verbinden können sollte. Doch hält dieser Eindruck einer näheren Überprüfung stand?

Value und Nutzen

Value, also Wert für den Kunden, ist zentraler Bestandteil und Orientierungspunkt für Scrum: Es geht nicht darum, Arbeitspakete sinnlos abzuarbeiten, sondern um "valuable products". Fast deckungsgleich ist das Konzept des Benefits (Nutzen) bei PRINCE2. Das "warum?" des Projekts, also die geschäftliche Rechtfertigung, muss immer klar vor Augen sein. In PRINCE2 arbeitet der Projektleiter kontinuierlich mit dem Business Case und dem Nutzen, den das Projekt mit seinen Produkten stiften will.

Produktorientierung wird großgeschrieben

Beide Ansätze sind in hohem Maße produktorientiert. Ein Projekt beginnt jeweils damit, das Projekt-Produkt zu verstehen und die Erwartungen an das Produkt zu fassen. Ähnlich wie der Product Owner mit verschiedenen Stakeholdern arbeitet, um sein Backlog zu entwickeln, arbeitet der Projektleiter mit dem Nutzervertreter und anderen Stakeholdern, um die Projektproduktbeschreibung zu erstellen.

Weder ein PRINCE2- noch ein Scrum-Projekt würde man mit einer Aktivitätsplanung beginnen. Bei PRINCE2 werden einzelne Aktivitäten erst viel später betrachtet und bei Scrum (in der klassischen Form) ist dies allein Aufgabe des Entwicklungsteams.

Change included

Sowohl Scrum als auch PRINCE2 sind change-friendly. Sie kennen das: "Planung ersetzt den Zufall durch den Irrtum". Kein Scrum-Projekt wird zu Beginn komplett durchgeplant; stattdessen verändern sich Anforderungen und Lösungen im Laufe der Zeit. So weit geht PRINCE2 nicht, will aber Änderungen nicht verhindern, nur steuern. Dafür wurde in PRINCE2 ein eigenes Änderungsmanagement (Issues) in die normalen Managementprozesse eingebaut. Änderungen sind in PRINCE2 daily business und kein eigener Prozess, wie das "Management von Projektdiskontinuitäten".

Sprints und Managementphasen

Das Konzept der Sprints erlaubt kurzfristige Planung, laufende Fortschrittskontrolle, rasches Regieren auf Änderungen und gewonnene Erfahrungen und regelmäßiges Feedback vom Nutzer. Die Managementphasen bei PRINCE2 machen ähnliches: Sie erlauben es, das Projekt nur grob und mit viel Toleranzen zu planen, denn die Detailplanung erfolgt auf Phasenebene und nur für die kommende Phase.

So ist das Projekt offen für Änderungen und das kontinuierliche Wachsen von Erfahrung n. Die Umsetzung ist ein wenig anders, doch die Grundidee ist dieselbe: Wir planen nur so weit voraus, wie es sinnvoll ist. Dazu erlaubt die Steuerung nach dem Ausnahmeprinzip bei PRINCE2 den Handlungsspielraum des Projektleiters und der Teammanager transparent festzulegen.

PRINCE2 gibt den Entwicklern Raum

Man kann es als Schwäche sehen, kombiniert mit Scrum ist es eine Stärke: PRINCE2 beschäftigt sich ausschließlich mit dem MANAGEMENT von Projekten, also den Tätigkeiten, die viele Projektleiter zusätzlich am Abend oder am Wochenende tun. PRINCE2 hat keine Vorstellungen oder Vorschriften, wie die "Lieferanten" arbeiten (also die Experten in den einzelnen Teams)!

Arbeitspaket ist nicht gleich Arbeitspaket

Bei PRINCE2 klärt der Vertrag zwischen Projektleiter und Teammanager die Rahmenbedingungen der Arbeit des Teammanagers bzgl. Zeit, Kosten, Einschränkungen, Regeln für Eskalation und Problembehandlung, etc. Was genau entwickelt werden soll, steht hier auch nicht, dafür gibt es eine Produktbeschreibung. Von Aktivitäten ist hier schon gar nicht die Rede, das ist ganz Sache der Lieferanten/Entwickler. Diese werden behandelt, wenn der Teammanager mit dem Team den Teamplan erstellt. Sollten Sie an dieser Stelle an Dinge denken wie das Backlog des Product Owners, oder Sprint Planning 1 und 2, dann sind Sie auf dem richtigen Dampfer: Bei Scrum definieren die Entwickler die einzelnen Aktivitäten.

PRINCE2 hat, was Scrum braucht

Den immensen Vorteil von PRINCE2, dass sich der Projektleiter aus der Detailarbeit des Teams raushält, begleitet ein zweiter Vorteil: PRINCE2 ist "King of Governance" unter allen Projektmanagement-Ansätzen. PRINCE2 beschäftigt sich damit wie Entscheidungen gefällt werden, wer wem berichtet, wie eskaliert wird und wer auf welcher Ebene welche Verantwortlichkeit hat. Das Framework ist hervorragend darin, seinen eigentlichen Zweck zu erfüllen: Projekte im Sinn der Strategie des Unternehmens gut zu steuern. Wenn Scrum mit seiner Dynamik der Motor ist, dann ist PRINCE2 die Kupplung zur Organisation.

Darüber hinaus gibt es noch andere Elemente, mit denen PRINCE2 Scrum ergänzen kann: Wie kommt es von der ersten Produktidee zu einem Projekt mit geklärten Rahmenbedingungen? PRINCE2 hat zwei ausdefinierte Prozesse für die Vor-Projekt- und die Initiierungsphase, bis eine fundierte Umsetzung beginnen kann. Da brauchen wir keine Experimente wie "Sprint Zero, ja oder nein?". Und PRINCE2 hat entwickelte Verfahren für ein systematisches Risikomanagement, was SCRUM ja völlig fehlt. Auch aus dem Qualitätsmanagement von PRINCE2 kann sich ein Scrum-Projekt Elemente "ausleihen".

Ganz einfach ist es trotzdem nicht

PRINCE2 ist keine Wasserfall-Methode, sondern ein Management-Framework für unterschiedliche Lieferansätze und Branchen. Nur deshalb funktioniert eine Integration von SCRUM überhaupt.

Viele zentrale Elemente der Philosophie, Prinzipien oder Grundprinzipien, von SCRUM und PRINCE2 sind identisch oder zumindest ähnlich. Auch auf Detailebene "vertragen" sich die Vorgehensweisen oder können aneinander angepasst werden. Warum könnte eine Produktbeschreibung bei PRINCE2 nicht in Form von User Stories geschrieben werden?

Allerdings sollte man aufpassen, dass man die erwünschte Dynamik eines Scrum-Teams nicht behindert, indem man auf Projektebene zu viele Details entscheidet. Ohne Entscheidungs- und damit Gestaltungsmöglichkeiten wird ein Scrum-Team niemals sein Potential entfalten können. Bei zentralen PRINCE2-Dokumenten, wie dem Business Case oder der Projektproduktbeschreibung, sollten Sie als Projektmanager nicht jedes Detail festzurren.

Bauen Sie ausreichend "Toleranzen" in die Definitionen, um dem Scrum-Team Verantwortung zu lassen. Dafür gibt es erprobte Techniken, wie den Ansatz des "Minimal Viable Product", mit entsprechender Priorisierung (siehe dazu "Schrumpfen Sie Ihr Projekt!").

Das Projektmanagement-System PRINCE2 sollte sich hier anpassen und bewusst Details bloß grob regeln. Denn ohne gesicherte Bedingungen mit Entscheidungsmöglichkeiten für das SCRUM-Team bekommen wir auch keine Dynamik. Und ohne Dynamik ernten wir auch nicht die Früchte der Agilität.