Scrum hat ein enormes Potenzial, das hat die Methode in unzähligen Entwicklungsprojekten – auch außerhalb der IT – bewiesen. Scrum kann die Kräfte von Teams zur Geltung bringen und erzielt damit eine Performance, die man von klassischen Projekten nicht gewohnt ist. Die starke Konzentration auf das Team hat allerdings seine Schattenseiten: Das Verhältnis zur Organisation, repräsentiert durch das "ungeliebte" Management, ist weithin ungeklärt, ja interessiert Scrum eigentlich nicht wirklich. [...]
DRUM PRÜFE, WER SICH EWIG BINDET
Wie bereits gesehen gibt es eine Reihe von Bereichen in denen Prince2 und Scrum von der Ausrichtung her kompatibel sind und auch Bereiche, wo die beiden Vorgehensweisen einander bestens ergänzen. Allerdings ist auch Vorsicht geboten. Die Herangehensweisen stammen ganz offensichtlich aus verschiedenen Kulturen und gerade diese Kulturen sind es, die diese beiden Ansätze jeden für sich erfolgreich machen. Die beiden Vorgehen einfach zusammen zu mischen und gemeinsam anzuwenden wird keineswegs alle Vorteile der beiden Ansätze mit sich bringen – so nach dem Motto: „Ich liebe Senf, ich liebe Schokolade, wie gut muss Senf mit Schokolade sein.“ Hier beispielhaft zwei Themen, bei denen in der Integration großes Fingerspitzengefühl nötig ist:
GOVERNANCE, VORGEGENSWEISEN, MEETINGS
Prince2 sieht eine Governance-Struktur vor, die alle wesentlichen Stakeholder im Projekt prominent in das Geschehen einbindet. So wird grundsätzlich ein Projectboard aufgesetzt, das jedenfalls mit den drei obligatorischen Mitgliedern „Executive“, „Senior User“, „Senior Supplier“ Vertreter für alle wichtigen Stakeholder-Gruppen mitbringt. Sorgfältig ist die Aufgaben- und Gewaltenteilung zwischen dem Projectboard und dem Projectmanager entwickelt, bis hin zu Eskalationsmechanismen für Risken, Problemen und Ausnahmen. Ebenso sind die Rollen, Befugnisse und Grenzen zwischen Projektmanager und Teammanager entwickelt und beschrieben.
Anders ist da die Situation in einem typischen Scrum-Projekt: Die Gewichtung von Prioritätsentscheidungen obliegt hier grundsätzlich und erst einmal allein dem Product-Owner – einer machtvollen Position. Dieser Product-Owner muss es zu Wege bringen, all die gegensätzlichen Interessen von End-Usern, des Managements als Eigentümervertreter sowie der Umsetzer mit ihrem oft hohen inneren Qualitätsanspruch gut auszugleichen.
Alle daraus entstehenden Konflikte soll diese Rolle ausreichend gut bearbeiten, um zu einer Reihung der Umsetzungs-Portionen im Backlog zu gelangen, die sowohl eine vernünftige Reihenfolge im Projekt darstellt, als auch ausreichend Akzeptanz bei den beteiligten Kräften hat, um das Projekt nicht zu gefährden. Allerdings sieht Scrum dafür eine Reihe von Vorgehensweisen vor, die gerade diesem Interessensausgleich dienen. So zieht sich die Einbindung der Kundeseite durch vom Sprint-Planning-Meeting angefangen, über eine mögliche Teilnahme an täglichen Stand-Up-Meetings bis zur Abnahme nach jedem Sprint vor. Scrum verfolgt hier eine Strategie in Richtung intensiver Kommunikation statt vieler Vereinbarungen – siehe auch „Agile Manifesto: Individuals and interactions over processes and tools“.
DON’T KILL THE TEAM!
Prince2 beschäftigt sich mit dem Steuern und dem Management von Projekten – nicht damit, wie die konkrete Arbeit der Entwicklung der Projektprodukte erfolgt. Das ist der Fokus von Scrum. Allerdings tut Scrum dies in einer sehr pointierten Art, die ganz eindeutig Partei ergreift für die Dynamik und Kommunikation im Team und des Teams mit ausgewählten Umwelten. In diese Vorgehensweisen einzugreifen würde bedeuten, den ganzen Witz von Scrum zu nehmen und die Vorteile zu nivellieren.
DER LÖSUNGSANSATZ
Einfach die beiden Methoden zu addieren – also sie mechanistisch aneinander zu stoppeln – führt zwangsläufig zu einer gedoppelten Strategie beim Interessensausgleich zwischen den Stakeholdern. Das wird nicht gut gehen. Entweder verliert Scrum seine Dynamik und die Meetings verkommen zu unkreativen Pflichtterminen, wenn die Umsetzung der Stages strikt nach Prince2 erfolgt. Oder aber die Scrummer behalten die Oberhand und die in Prince2 vorgesehen Rollen und Prozesse verkommen zu potemkinschen Dörfern, deren Erstllung dann nur noch um der Artefakte selbst willen erfolgt, und nicht zur stratgischen Steuerung des Projekterfolgs.
Scrum hat einen so massiven Mangel an Berücksichtigung ausreichender Governance, dass es ohnehin einer Ergänzung bedarf. Auf der anderen Seite bietet Prince2 keinerlei Antworten dafür, wie wir vorgehen können, um effizient und effektiv dem Projektziel entgegen zu gehen. Auch hier gibt es dringenden Ergänzungsbedarf – warum also nicht? Nehmen wir etwas Bekanntes als Gleichnis: das Automobil. Wenn das Scrum-Team der Motor ist, der die ungeahnten Kräfte von Teamarbeit freisetzt, dann ist Prince2 die Kupplung, die dafür sorgt, dass die Kraft auch auf die Räder kommt, das Gesamtsystem weiterbringt und nicht destabilisiert.
Hier ist große Behutsamkeit gefragt, um die nötigen Bedingungen für die produktive Entfesselung der Teamkräfte (Scrum-Kulturen) nicht zu stören, sondern zu sichern. Der Ansatz muss eine klare Grenzziehung sein, welche Regelung in welchen Bereichen gilt: Bis wohin gehen wir „Agile“ („Scrum“) vor und ab wo gelten Prince2-Regeln? Und vor allem braucht es Fingerspitzengefühl beim Projekt-Setup und der initialen Prozesseinführung: Wo verlasse ich mich auf welches Modell – und welche Vorgehensweisen sind absolut inkompatibel, weil sie mir den Nutzen der einen oder anderen Vorgehensweise zunichte machen?
INTEGRATION VON PRODUCT OWNER UND PROJECT MANAGER
Die Rolle des Product Owner in Scrum muss entlastet werden. Zu viele Aufgaben und Konflikte sind in eine Rolle gelegt. Unsere Empfehlung ist, die Rollen von Product-Owner (Scrum) mit der des Project Managers (Prince2) zu verschmelzen. Gegenüber dem Scrum-Team nimmt diese Rolle alle Aufgaben des Product-Owner wahr, gegenüber der Organisation und wichtigen Stakeholdern jedoch nur die Aufgaben eines PM nach Prince2 – denn ein Teil dieser Aufgaben bleibt nach Prince2 ohnehin beim Project Board (Prince2).
Damit entlasten wir die Rolle des Product-Owner erheblich: Seine Handlungsvollmacht und Grenzen erhält er in Abstimmung mit dem Projectboard, das in der Lage ist, wichtige strategische Entscheidungen in der Top Ebene der Organisation herbeizuführen.
DIE ADAPTION DER ERSTEN BEIDEN PROZESSE VON PRINCE2
Die Prozesse und Arbeitsschritte unmittelbar vor Projektstart und in der Startphase eines Projektes entnehmen wir dem Ansatz von Prince2, denn Scrum stellt hier nichts zur Verfügung. Die einzelnen Aktivitäten der beiden Prince2-Phasen „Starting Up a Project“ und „Initiating a Project“ überprüfen wir danach, wie sie die Prozesse und Kommunikationen eines Scrum-Teams unterstützen oder stören:
So wird beispielsweise aus dem „Business Case“ ein „Business Scenario“, das dem PO/PM beschreibt, in welcher Bandbreite er sich gegenüber dem Scrum-Team kommitten darf, bevor er Rücksprache mit dem Projectboard halten muss. Ein anderes Beispiel: Aus der „Project Product Description“ bei Prince2 wird ein „Draft Soryboard“, also ein gemeinsames Zielfoto. Die einzelnen „Product Descriptions“ zu Projektbeginn entfallen ersatzlos.
ZUSAMMENLEGEN VON SPRINTS UND PHASEN
Die Sprints von SCRUM und die Managementphasen von Prince2 können wir zusammenlegen, für die Meetings zu Beginn und Ende eines Sprints kennen wir aus Prince2 den Prozess „Managen des Phasenübergangs“. Um seine Rolle als Project Owner in der Scrum-Welt gut wahrzunehmen hat die Rolle ja seine Handlungsvollmacht als Project Manager in Prince2.
Be the first to comment