Prince2 öffnet die Tür für Scrum

Stellen Sie sich vor, Ihr interner Kunde vertraut Ihnen mehrere Millionen Euro für ein neues IT-System an. Endlich können Sie die in die Jahre gekommene Anwendung ablösen. Aber wie gehen Sie die Herausforderung an? Mit einer konventionellen PM-Methode (Projekt-Management) oder lieber mit einem agilen Vorgehensmodell, beispielsweise Scrum?

Möglicherweise sind Ihre Mitarbeiter und Anwender ja auch so begeistert von Scrum. Die Erfolge kleinerer Pilotprojekte sprechen schließlich für sich. Aber vielleicht stellen Sie als Projekt- oder IT-Verantwortlicher sich dieselben Fragen wie 93 Prozent Ihrer Management-Kollegen:

• Soll ich ein Projekt tatsächlich ohne Projektleiter starten, wie Scrum es eigentlich fordert?

• Wie organisiere ich ein Projekt, das deutlich mehr Personal braucht als die von Scrum empfohlenen sieben plus zwei Teammitglieder?

• Wie kann ich ein Scrum-Projekt lenken? Muss ein Senior Manager jetzt etwa zum "Product Owner" werden und sich ab sofort täglich mit den Projektdetails beschäftigen?

• Bedeutet die Entscheidung für Scrum eine kategorische Entscheidung gegen verteilte Teams, Offshore-Entwicklung und Festpreise?

• Sind klassische Projekt-Management-Ansätze überholt? Und muss sich das Unternehmen deshalb verändern (falls ja, wohingehend?)

Kleines Scrum-Glossar
Was meint eigentlich Scrum, Product Owner oder Backlog? Wir stellen Ihnen die wichtigsten Begriffe und ihre Bedeutung vor.

Scrum
Der Begriff stammt aus dem Rugby und bedeutet wörtliche "Gedränge". In der Softwareentwicklung bezeichnet er ein Vorgehensmodell der agilen Softwareentwicklung, das 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle veröffentlicht wurde.

Das Scrum-Team
Aufgabe des Teams ist es, die Anforderungen der Fachabteilung umzusetzen. Es bietet drei Rollen:

1. Rolle: Product Owner
Er vertritt den Auftraggeber, also die fachliche Seite. Also zeichnet er für die Priorisierung der Anforderungen verantwortlich und letztlich auch für den Nutzen, den das Projekt dem Unternehmen bringt.

2. Rolle: Scrum-Master
Er ist quasi der Herr über die Prozesse. Er sorgt dafür, dass die Scrum-Regeln im Projekt eingehalten werden, er fördert die Transparenz, unterstützt das Team bei der Beseitigung von Hindernissen und sucht ständig nach möglichen Verbesserungen.

3. Rolle: Die Entwicklergruppe
Sie besteht idealerweise aus sieben Entwicklern.

Sprint
Mit diesem Begriff bezeichnet Scrum einen Iterationszyklus, innerhalb dessen ein Scrum-Teams eine Anforderung umsetzt. Ein Sprint dauert mindestens zwei Wochen und maximal einen Monat.

Backlog
So heißt in Scrum die priorisierte Anforderungsliste für das zu entwickelnde Produkt. Sie wird vom Product Owner verantwortet und gepflegt.

Definitionen von fertig
Dabei handelt es sich um die Kriterien, unter den ein Produkt als umgesetzt akzeptiert wird.

Wie Scrum tickt

Um diese Fragen beantworten zu können, ist ein wenig Hintergrundbetrachtung notwendig. In Scrum-Projekten geht es darum, die von der Fachseite gewünschten "Features" zu liefern. Dabei gibt der in das Entwicklerteam eingebettete "Product Owner" in Planungsbesprechungen vor, welche Anforderungen die Gruppe innerhalb eines kurzen, zeitlich exakt begrenzten Projektschritts - des "Sprint" - umsetzen soll. Er tut das auf der Basis eines konkreten Auftrags und eines finanziellen Rahmens.

Aber der Product Owner kann nur das Was bestimmen. Das Team hingegen gibt vor, wie viel davon es in es in einem Sprint zu leisten im Stande ist. Das Wie organisiert die Gruppe also selbst - nach dem berühmten "Toyota-Weg", auch "japanisches Fließband" genannt.

Das Ergebnis eines Sprints ist eine funktionierende Software. Die kann, muss aber noch nicht dem Endergebnis entsprechen. Im etablierten Projekt-Management nach Prince2 heißt das erwartete Ergebnis "Produkt". Auch Scrum kennt den Produktbegriff. Ein Produkt muss hier den ausgewählten Anforderungen aus den "Selected Backlogs" entsprechen. Aus Teamsicht sind die Kundenerwartungen in den Artekfakten "Definitionen von fertig" beziehungsweise "Akzeptanzkriterien" enthalten. In Prince2 entspricht das den "Qualitätskriterien."

Ein Produkt erfordert, dass bestimmte Aufgaben erledigt sein müssen (gemäß dem "Sprint Backlog"). Zudem muss der finanzielle und zeitliche Rahmen, innerhalb dessen die Aufgaben zu erfüllen sind, eingehalten werden.

Backlog, Backlog-Einträge und geeignete Filter, wie sie in Scrum genutzt werden, genügen durchaus den Prince2-Ansprüchen. Entgegen seinem Ruf muss Prince2 nicht dokumentenlastig sein. Hinsichtlich des Auftrags ist die etablierte Vorgehensweise allerdings etwas präziser: Neben Kosten- und Zeitrahmen werden auch eingrenzende Informationen für Qualität, Umfang, Risiko und Nutzen erwartet.

Fünf Gründe für den agilen Ansatz
Neue Methoden der Softwareentwicklung begeistern die Mitarbeiter und die Kunden. Da stellt sich die Frage, woher es kommt, dass "Agilität" derartig beliebt ist? Alexander Ockl nennt Fünf Gründe:

Weniger Prozess - dafür mehr Mensch
Offenbar haben wir gelegentlich das Prozessrad zu weit gedreht. Mit Know-how in den Prozessen wollten wir gute Software wie am Fließband im "billigen Ausland" herstellen lassen. Probleme lassen sich mit noch ausgefeilteren Prozessen und Rollen beseitigen, so dachten wir. Aber inzwischen wissen wir, dass wir am so genannten Fließband meist individuell arbeiten. Und talentierte Mitarbeiter haben auch im Ausland inzwischen ihren Preis.

Persönliche Motivation statt Existenzangst
In der agilen Welt zählt der Mensch wieder etwas. Statt verteilt zu sitzen, schauen sich agile Teams wieder in die Augen. Effektive, direkte Kommunikation ersetzt endlose, anonyme Telefonkonferenzen und überlaufende E-Mail-Postkörbe. Größerer Gestaltungsspielraum und überschaubare Rollen geben Mitarbeitern das Gefühl, endlich wieder etwas bewegen zu können. Das setzt Kräfte frei. Und motiviert, anstatt zu frustrieren.

Entfaltete Stärken statt Fesseln
Endlich wieder kreativ sein und nicht starre Prozesse befolgen müssen! Kein Wunder also, dass gerade Entwickler und Analysten diesen Ansatz lieben. Im agilen Umfeld sind sich alle bewusst, wie wichtig ein gut zusammengestelltes Team ist. Das übersehen wir in der "alten IT-Welt" häufig - zwischen den vielen Prozessdetails und virtuellen Teams. Unsere Kunden freuen sich auch, denn schließlich steht wieder die Lösung ihrer Probleme im Vordergrund.

Gemeinsam entwickelte Arbeitsweise
Neue Prozesse bedeuten in unserem herkömmlichen Alltag häufig neue Rollen. So entstehen Teamveränderungen und Umstrukturierungen. Die vorgegebene Arbeitsweise passt aber vielfach nicht zum Team. Agile Methoden wie Scrum zeigen, dass es auch anders geht. Den "Toyota-Weg" als Vorbild, organisieren sich schlanke Teams innerhalb eines groben Rahmens am besten selbst.Es lohnt es sich, ein funktionierendes Team - wie im Fußball - nicht zu stark zu verändern. Gemeinsam entwickelt, richtet sich die Arbeitsweise nach den Möglichkeiten der Mitarbeiter.

Eine nachvollziehbare Teamleistung
Schreit unser Umfeld nach Agilität, so sollten wir nicht dagegen reden, sondern genau hinschauen. Agilität und gute Prozesse wollen das Gleiche. Müssen wir dennoch verteilt arbeiten, so sollten wir unbedingt auf die menschliche Komponente achten. Frei nach Felix Magath bei der Vorstellung des Spielers Raul sollte es "unsere Verpflichtung sein", die Mitarbeiter "so in Szene zu setzen", dass Sie "ihre Fähigkeiten voll ausspielen können". Andernfalls schließt auch Raul keine Tore, sondern wird zu einem mittelmäßigen und schließlich frustrierten Mitspieler.

Sieben Grundprinzipien von Prince2

Um es gleich vorwegzunehmen: "Prinzipiell" passen Prince2 und Scrum gut zueinander. "Prince" bedeutet ausgeschrieben "Projects in Controlled Environments". Die Projekte sollen sieben Grundprinzipien gehorchen.

1. Die Vorhaben werden in Phasen unterteilt und analog dazu gelenkt (Management by Stages).

2. Sie sind fortlaufend wirtschaftlich (nach ihrem Nutzen) zu begründen - mindestens am Ende jeder Etappe.

3. Es gibt klar geregelte Rollen und Verantwortlichkeiten.

4. Die Planung ist ergebnisorientiert (zum Beispiel auf die fertige Software ausgerichtet).

5. Das Vorgehen unterliegt der kontinuierlichen Verbesserung (Motto: aus Erfahrung lernen).

6. Für die Steuerung gibt es einen klaren Handlungsrahmen nach dem Ausnahmeprinzip (Management by Exception), so dass nur bei Überschreitung der messbaren Toleranzen eingegriffen werden muss.

7. Prince2 sollte nach klaren Vorgaben an die Bedürfnisse des Projektes angepasst werden.

Auch hinsichtlich dieser Grundprinzipien widersprechen sich die beiden Ansätze nicht. Im Gegenteil: Wenn die Anforderungen - treu nach Scrum - während eines Sprints "eingefroren" werden, also keine Änderungen mehr zugelassen sind, kommt das auch dem Projekt-Management nach Prince2 entgegen. Bleibt das Scrum-Team in dieser Zeit innerhalb des Handlungsrahmens, so muss überhaupt nicht steuernd eingegriffen werden.

Scrum macht weiter, wo Prince2 aufhört

Die Prince2-Phasen sind in der Praxis typischerweise länger und umfangreicher als ein Sprint. So entspricht ein Sprint, der über zwei bis vier Wochen laufen soll, von der Größe her eher einem Prince2-Arbeitspaket. Das ist insofern entscheidend, als es die Übergabepunkte zwischen der Steuerungsebene und der Lieferebene betrifft.

Prince2 geht es hauptsächlich darum, dem Verantwortlichen für das Arbeitspaket - entweder dem Projekt-Manager oder optional dem Team-Manager - einen klaren Auftrag mit einem definiertem Handlungsspielraum zu geben. Das könnte auch der Rahmen sein, in dem der Product Owner dem Scrum-Team Vorgaben für einen Sprint macht. Folglich ist es möglich, dass das Prince2-Projekt ab einem bestimmten Punkt mit Scrum weiterarbeitet. Dazu sind zwei Varianten denkbar.

Variante 1: Der Product Owner ist der Prince2-Projekt-Manager

In einem weniger komplexen Projekt bietet es sich an, den Product Owner zum Prince2-Projekt-Manager zu machen. Er ist dann für das Ergebnis verantwortlich. Dabei darf er das Team nach eigenem Ermessen führen beziehungsweise organisieren. Insofern kann er durchaus zulassen, dass sich das Team nach Scrum selbst organisiert - jedenfalls, solange es innerhalb der Toleranzen seines Auftrags agiert.

Auf diese Weise bekommt das Projekt das Beste aus beiden Welten. Es hat einen Projekt-Manager, der während des Projekts das Tagesgeschäft im Auftrag des Lenkungsausschusses steuert. Sollte sich abzeichnen, dass - insbesondere zwischen den Sprints beziehungsweise Arbeitspaketen - der Handlungsspielraum (hinsichtlich Kosten, Nutzen, Qualität, Risiken etc.) überschritten wird, muss der Projekt-Manager die "Lenker" um eine Entscheidung bitten. Schließlich kann es durchaus sein, das sich die Fortsetzung des Projekts nicht lohnt.

Als Projekt-Manager und Arbeitspaket-Verantwortlicher ist der Product Owner Bindeglied zwischen dem Senior Management und der agilen Detail- oder Lieferebene. Der Prince2-Rahmen sorgt dafür, dass es auf der Teamebene nicht zu viele Überraschungen gibt, weil das Projekt zielgerecht gelenkt wird.

Sowohl Arbeitspakete als auch das Tagesgeschäft werden vom Product Owner fachlich geführt. In den Arbeitspaketen geht es um die technische Umsetzung der fachlichen Anforderungen. So steht der Nutzen des Fachbereichs immer im Vordergrund des Projekts.

Die täglichen Scrum-Meetings machen viele E-Mails und weitere Besprechungen auf der Arbeitspaket-Ebene überflüssig. Die Kommunikation bleibt allerdings nur effektiv, so lange das Team klein ist. Außerhalb der Arbeitspakete kommt deshalb wieder Prince2 ins Spiel. Das sorgt für eine effektive Kommunikation und Zusammenarbeit zwischen

• Lenkungsebene (Lenkungsausschuss) beziehungsweise darüber liegender Programm- oder Unternehmensebene;

• Steuerungsebene (Projekt-Management in unterschiedlichen Phasen) und

• Lieferebene (Arbeitspakete, Sprints).

Hier findet der Austausch nicht ständig, sondern nur im Ausnahmefall und zielgerichtet nach Rollen statt. So leidet das Projektumfeld nicht unter einer Kultur à la: "Jeder muss mit jedem über alle Details sprechen". Falls zwischen den Arbeitspaketen viele Abhängigkeiten bestehen, kann der Lenkungsausschuss nach Prince2 Entscheidungen auch an einen Änderungsausschuss delegieren.

Spielregeln für das Projekt-Team
Diese Spielregeln sorgen für eine offene Kommunikation und bieten auch im Konfliktfall eine Orientierung.

Projektauftrag klar definieren
Der Projektauftrag ist das A und O der Projektdurchführung. Er bildet die Grundlage für die Abnahme der Projektergebnisse und damit den Projekterfolg!

Projekt in steuerbare Arbeitspakete schneiden
In jeder Phase des Projekts den Überblick bewahren.

Betroffene zu Beteiligten machen
Ein offenes Ohr für die Projektbeteiligten erhöht die Akzeptanz der zukünftigen Nutzer.

Projekt(kern)team klein halten
Auch bei der Durchführung eines Projektes gilt: Zu viele Köche verderben den Brei.

Umgang mit Change Requests definieren
Hinterfragen Sie Änderungswünsche während der Projektdurchführung kritisch und prüfen Sie sie auf ihre Sinnhaftigkeit.

Abnahme-Prozess formalisieren
Keine Kritik ohne Verbesserungsvorschlag: Ein Feedback-Formular mit Pflichtfeld "Verbesserungsvorschlag" sorgt für Konstruktivität im Feedback-Prozess.

Projektmanagement leben
Kommunikation, Kommunikation und nochmal Kommunikation!

Management of Change: „Hypercare“ einplanen
Ein speziell hierfür ernannter Ansprechpartner hilft über Probleme und Sorgen in den ersten Tagen nach der Systemeinführung hinweg.

Übergabe in den Betrieb sicherstellen
Eine geregelte Übergabe ermöglicht den reibungslosen Betrieb des IT-Systems.

Lessons Learned
Die Erfahrungen sollten am Ende eines Projekts zusammengetragen werden, um für die nächsten Projekte zu lernen.

Variante 2: Der Product Owner ist der Prince2-Team-Manager

In größeren Projekten müssen möglicherweise sehr viele Arbeitspakete simultan erledigt werden. Beispielsweise könnte es sein, dass mehrere Systeme gleichzeitig anzupassen sind. Zudem könnte es sinnvoll sein, mehrere "Feature-Teams" parallel Vorgaben für den nächsten Sprint beziehungsweise das nächste Arbeitspaket erarbeiten zu lassen.

Das dürfte einen Product Owner als Projekt-Manager nach Prince2 in vielen Fällen überfordern. Wenn dem so ist, sollte er lieber als Team-Manager fungieren. Er zeichnet dann besser "nur noch" für die Ergebnisse der Arbeitspakete (Sprints) verantwortlich und erhält die Vorgaben von einem dedizierten Projekt-Manager. Da diese Vorgaben mit dem Auftraggeber und Benutzervertreter im Projekt abgestimmt werden, bewegt sich der Handlungsspielraum des Team-Managers auf jeden Fall im Sinne des Kunden und der Anwender. Er agiert praktisch als ein fachlicher Projekt-Manager.

Auf diese Art und Weise lassen sich auch mehrere Scrum-Produkte gleichzeitig steuern - selbstverständlich mit mehreren Product Owners. Bestehen viele Abhängigkeiten zwischen den Arbeitsergebnissen, müssen möglicherweise auch die Backlogs, sprich: Anforderungen, aneinander gekoppelt werden.

Die Bedeutung des Scrum-Master

Prince2 mit Scrum zu koppeln erfordert von allen Beteiligten starke Rollendisziplin. Der Vorteil für das Projekt wird nur evident, wenn das Vorhaben ausschließlich innerhalb der Arbeitspakete nach Scrum agiert. Das bedeutet eine Änderung für alle Beteiligten, sofern sie an das klassische Projekt-Management nach Prince2 gewöhnt sind.

Insofern sollte der "Scrum-Master", der innerhalb eines Scrum-Teams für die Prozesse verantwortlich ist, auch in Sachen Prince2 beschlagen sein. Sonst ist er nicht in der Lage, die beiden Welten zu trennen. Wenn ein Prince2-Projekt-Manager seine Rolle als Scrum-Master nicht versteht beziehungsweise die beiden Funktionen nicht zu trennen versteht, wird er möglicherweise versuchen, die Arbeit innerhalb des Teams zu lenken, anstatt sie zu coachen. Das führt schnell zu Konflikten. Zudem ist er bei den vielen Details - je nach Projektgröße - wohl schnell überfordert. Und damit würde er seiner wichtigen, weil erfolgsentscheidenden Rolle als Scrum-Master nicht gerecht.

Eine gute Idee ist es daher, den Scrum-Master in die übergeordnete Sicherung des Prince2-Projekts einzubinden. Die Projektsicherung agiert auf allen Ebenen, ist unabhängig vom Projekt-Manager und dafür verantwortlich, dass die definierten Standards beachtet werden.

Fazit: Wie Prince2 und Scrum sich ergänzen

Alles in allem schafft Prince2 einen Rahmen, den Unternehmen für den Einsatz agiler Methoden wie Scrum benötigen. Die Lenkungsebene kann die Verantwortung an den Prince2-Projektleiter und den Product Owner delegieren. Sie muss sich also nur im Ausnahmefall mit Details beschäftigen.

Das Team wiederum bekommt die Möglichkeit, sich nach Scrum selbst zu organisieren. So profitiert das Projekt von der nicht zu unterschätzenden "agilen" Begeisterung und der effektiven Zusammenarbeit - ohne dass dabei auf die straffe und zielgerichtete Führung nach Prince2 verzichtet werden muss.

Wo ist aber nun die Schnittstelle zwischen beiden Methoden anzulegen? Entscheidend ist dabei der Blickwinkel. Sehen Sie einen oder mehrere Scrum-Sprints als ein Prince2-Arbeitspaket? Auf jeden Fall hört Prince2 genau da auf, wo Scrum beginnt.

Mit Prince2 kann ein Unternehmen auf die "klassische" Art agil werden, also ohne allzu große Änderungen vornehmen zu müssen. In der Kombination mit Scrum verliert Prince2 dann für die meisten Kollegen auch sein Image als Bürokratiemonster, das es übrigens spätestens seit der letzten Anpassung des Standards im Jahr 2009 sowieso nicht mehr ist.

In jedem Fall haben Sie mit einer solchen Kombination eine bessere Chance, die organisatorischen Vorbehalte gegenüber agilen Methoden aufzulösen. Insofern kann Prince2 sogar so die Tür zum flächendeckenden Einsatz von Scrum in den Unternehmen öffnen. (Computerwoche)

Autor Alexander Ockl ist zertifizierter Projekt-Manager und Buchautor.