Steuerbare Kraft: Die Integration von Prince2 und Scrum

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. [...]

In der Praxis müssen die daraus resultierenden Spannungen dann einzelne Personen aushalten – selten der Scrum Master, viel häufiger trifft es den bedauernswerten Product Owner. Alles Ungeregelte wird in seine Rolle gelegt und damit zu seiner Aufgabe. Wie gehen Organisationen, die mit Scrum arbeiten wollen, mit diesen Spannungen um? Beispiele aus der realen Praxis zeigen, dass diese Organisationen häufig parallel zum Scrum-Team eine klassische Projektstruktur mit einem Projektmanager und den üblichen Planungen und Reportings aufbauen. So entstehen aufwändige Parallelstrukturen und die tägliche Frage, wer den Schwarzen Peter gerade hat.

Da muss es doch bessere Lösungen geben – in letzter Zeit ist die Kombination von Prince2 und Scrum zum Thema geworden. Das ist lohnend, denn die beiden Methoden, sowohl Prince2 als auch Scrum, haben ihre Stärken. Diese liegen in ganz unterschiedlichen Sphären und fokussieren mit Absicht auf unterschiedliche Aspekte. Prince2 gibt sich ganz der Governance, dem Zusammenspiel der Managementebenen von Projekten, hin – Scrum hingegen hat mit seinem Ansatz vor allem Augen für die Entfesselung der Potenziale von eingeschworenen Teams.

Warum also sollten wir die beiden zusammenbringen? Deshalb, weil sie sich theoretisch in ihren Blickwinkeln ergänzen würden? Ziehen sich Unterschiede so sehr an, dass sich die Reibung lohnt? Wie immer liegt das Verzücken im Detail.

GEMEINSAMKEITEN ALS BASIS
Eine sorgfältig überlegte Kombination von Prince2 und Scrum kann die Probleme des täglichen Projektalltags lösen, ohne überflüssige Parallelstrukturen aufzubauen. Das ist – bei allen Unterschieden – deshalb möglich, weil die beiden Ansätze einige prinzipielle Gemeinsamkeiten aufweisen, die sie grundsätzlich in ihrer Philosophie kompatibel machen.

PRODUCT RULES!
Beiden Ansätzen ist gemein, dass sie in hohem Ausmaß produktorientiert sind. Ein Projekt beginnt in beiden Fällen damit, das Produkt zu verstehen und die Erwartungen an das Produkt zu fassen. Nicht im Traum würde Prince2 oder Scrum einfallen, mit einem Aktivitätsplan oder einer Work-Breakdown-Structure zu beginnen, das kommt bei Prince2 viel später, bei Scrum in der klassischen Form gar nicht.

REALISE BENEFITS!
Nicht das Abarbeiten von Tasks und Deliverables ist der Zweck eines Projektes. Prince2 beschäftigt sich von der ersten Idee weg mit dem Nutzen, den das Projekt für verschiedene Stakeholder stiftet und bezieht auch die Zeit nach Projektende in die Planung mit ein. Scrum geht noch einen Schritt weiter und verlangt, dass in jedem einzelnen Sprint konkreter Nutzen realisiert wird und an den Kunden übergeben werden kann. Wenn die beiden auch im Detail unterschiedlich damit umgehen, bei keinen anderen Ansätzen steht der Kundennutzen so sehr im Zentrum der Methodik.

CHANGE INSIDE!
Kennen Sie den: „Planung ersetzt den Zufall durch den Irrtum“? Keine der beiden Methoden geht davon aus, dass eine Planung zu Projektbeginn für das ganze Projekt valide bleibt. Prince2 plant zwar zu Beginn. Aber erst in den einzelnen Management Stages, in die sich ein Projekt gliedert, erfolgt die Detailarbeit und Anpassung. Und Scrum kennt die Sprints, zu deren Beginn die konkrete Arbeit im Team eingeschätzt und verteilt wird. Und am Ende erfolgt die Auswertung, erst dann geht es zum nächsten Sprint.


Mehr Artikel

News

Große Sprachmodelle und Data Security: Sicherheitsfragen rund um LLMs

Bei der Entwicklung von Strategien zur Verbesserung der Datensicherheit in KI-Workloads ist es entscheidend, die Perspektive zu ändern und KI als eine Person zu betrachten, die anfällig für Social-Engineering-Angriffe ist. Diese Analogie kann Unternehmen helfen, die Schwachstellen und Bedrohungen, denen KI-Systeme ausgesetzt sind, besser zu verstehen und robustere Sicherheitsmaßnahmen zu entwickeln. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*