Projekte sind zeitlich befristet, adressieren besondere, mit Unsicherheiten behaftete Aufgaben und werden von extra zusam-mengestellten Teams als Einzelprojekt oder im Rahmen von Programmen abgewickelt. Etwa seit Mitte der 1990er Jahre finden sys-tematische Untersuchungen über den Erfolg oder Misserfolg von Projekten statt, mit zum Teil erschreckenden Ergebnissen. Da-mals waren nur etwa 20 bis 30 Prozent der untersuchten Projekte uneingeschränkt er-folgreich und bis zu 30 Prozent aller Projek-te mussten ergebnislos abgebrochen werden. In der Folge haben sich die Bemühungen um eine Standardisierung von Methoden für das Projektmanagement verstärkt.

Klassisches ProjektmanagementInternational und auch in der DACH-Re-gion haben sich drei Ansätze für das Pro-jektmanagement durchgesetzt, die jeweils eigene methodische Ansätze und Zertifi-zierungsprogramme für Projektmanager definieren:

n PMBOK (Project Management Body of Knowledge) ist eine Sammlung von Projektmanagement-Techniken des US-amerikanischen Project Management Institute (PMI).

n ICB (IPMA Competence Baseline) ist eine Sammlung von Wissens- und Er-fahrungsbereichen rund um das Pro-jektmanagement, das von der europä-ischen Initiative IPMA (International Project Managers Association) heraus-gegeben wird.

n PRINCE2 (PRojects IN Controlled Environments) wurde als methodischer Ansatz für die Abwicklung von Projek-ten der britischen Regierung entwickelt. Das Verfahren wird heute von Axelos gepflegt, wie z.B. auch das ITIL-Frame-work für IT-Service-Prozesse.

Die genannten Organisationen verfolgen mit ihren Ausbildungs- und Zertifizierungs-programmen auch kommerzielle Interes-sen, weshalb Angaben über den Verbrei-tungsgrad dieser Ansätze mit Vorsicht zu genießen sind. Allerdings scheint ICB vor allem in der DACH-Region eine gewisse Bedeutung zu haben, aber keinesfalls eine dominante Stellung.Ähnlich wie PRINCE2 definieren VModell XT und RUP (Rational Unified Process) methodische Ansätze für die Abwicklung von Projekten speziell in der IT. In allen genannten Ansätzen erfolgen die Steuerung von Projekten und das Berichtswesen von unten nach oben, sind also hierarchisch or-ganisiert (Command and Control).

Agile ArbeitsweisenIn den Untersuchungen zu Projektergebnis-sen wurden diverse Gründe für das Schei-tern von Projekten identifiziert. Bei genaue-rer Betrachtung dieser Risikofaktoren zeigt sich, dass es kaum technische Risikofakto-ren gibt. Allein die Einführung neuer Tech-nologien wird hin und wieder ausgewiesen. Die weitaus meisten Risikofaktoren verwei-sen auf diverse Defizite menschlichen Han-delns in Projekten und deren Umgebung (z.B. Linienmanagement, Stakeholder). Gleichfalls in den 1990er Jahren begann die methodische Entwicklung agiler Ar-beitsweisen, zunächst von der breiten Öf-fentlichkeit weitgehend unbemerkt. Diese neuartigen Arbeitsweisen adressieren ge-nau die Risikofaktoren, die auf Defizite menschlichen Handelns zurückzuführen sind. Seinen bekanntesten Ausdruck findet dies in den vier Werten und zwölf Prinzi-pien des Agilen Manifests von 2001 (vgl. [Bec01]). Die Erstunterzeichner des Mani-fests waren Softwareentwickler, weshalb sich der Begriff „Software“ in diversen Aussagen wiederfindet. Ersetzt man diesen

Begriff etwa durch „Lösungen“, „Services“ oder „Produkte“, lässt sich das Agile Ma-nifest leicht auf andere Einsatzgebiete auch außerhalb der IT ausdehnen. Dass dies ge-schieht, kann man zunehmend beobachten.Inzwischen haben sich diverse agile Ansätze ausgeprägt, deren wichtigste Vertreter ich hier kurz skizzieren möchte:

n Scrum verfolgt das Ziel, eine jeweils ausgewählte Menge an Anforderungen (User-Storys) in kurzen Zeitabschnitten gleicher Länge (Sprints) einsatzfähig zu entwickeln (Potentially Shippable In-crement – PSI). Scrum ist der wohl be-kannteste und am weitesten verbreitete Ansatz für agile Arbeitsweisen in der IT. Er wird vor allem in der Softwareent-wicklung eingesetzt, eignet sich aber auch für die Entwicklung von Produk-ten aller Art.

n Kanban wurde ursprünglich als ein Werkzeug für die kontinuierliche Ver-besserung des Arbeitsflusses (Work-flow) in Produktionssystemen (Toyota Production System – TPS) entwickelt. Es wurde seit Beginn der 1990er Jah-re in der angelsächsischen Ausprägung Lean Production und weiteren mit Lean bezeichneten Verfahren adaptiert und eignet sich z.B. auch für Steue-rungszwecke in Projekten. Für die IT wurde Kanban erst ab etwa 2007 ent-deckt und gewinnt zunehmend an Be-deutung.

n XP (eXtreme Programming) ist eher eine Sammlung geeigneter Praktiken (Good Practices) für die agile Soft-wareentwicklung. Eine bekannte Aus-prägung ist das Pair Programming, also die Entwicklung nach dem Vier-Augen-Prinzip. Auch diese Praxis lässt sich leicht außerhalb der IT anwenden.

n Hybride der genannten Ansätze sind

PRINCE2 goes Agile:Das neue Zertifikat

„PRINCE2 Agile Practitioner“PRINCE2 ist ein Rahmenwerk für das Management von Projekten aller Art. Für die Nutzung agiler Arbeitsweisen

in PRINCE2-Projekten wurde PRINCE2 Agile entwickelt. Es beschreibt ein systematisches Vorgehen für notwendige und hilfreiche Anpassungen des Rahmenwerks an agile Arbeitsweisen. Der Artikel beschreibt dieses

Vorgehen und setzt sich mit dem Nutzen des Konzepts und des zugehörigen Zertifikats auseinander.

PRINCE2 goes Agile: Das neue Zertifikat „PRINCE2 Agile Practitioner“

54

Die Pilotierung war erfolgreich, gleichwohl wurde die Scrum-basierte Zusammenarbeit mit der IT beendet.

PRINCE2 und PRINCE2 AgilePRINCE2 (vgl. [Axe09]) definiert einen Rahmen für das Management von Projek-ten jeder Größe und Komplexität für belie-bige Aufgabenstellungen, indem es die Ma-nagementaspekte eines Projekts sorgfältig von der Arbeitsweise der Spezialisten für die Erstellung der Projektergebnisse trennt. PRINCE2 Agile (vgl. [Axe15]) gibt Anlei-tungen für die Anpassung dieser Manage-mentaspekte, sodass die Spezialisten ihre Produkte mit Hilfe agiler Arbeitsweisen entwickeln können. Dabei steht der engli-sche Begriff Agile für alle Verhaltensweisen, Methoden, Techniken und Rahmenwerke, die mit dem Agilen Manifest von 2001 ver-einbar sind. Das Handbuch hat mit circa 350 Seiten einen ähnlichen Umfang wie das des klassischen PRINCE2. Es kann zum Preis von ca. 145 Euro erworben werden.Der Umfang erklärt sich aus den Unterschie-den von Agile zu klassischen Methoden des Projektmanagements. Die hierarchischen Steuerungsmechanismen (Command and Control) wurden bereits erwähnt. Ferner werden in klassischen Ansätzen Produk-te und Lösungen detailliert vorgegeben, die gewünschten Eigenschaften ex ante zugesagt. Pläne und Meilensteine werden möglichst detailliert ausgearbeitet, weshalb Änderungen der Anforderungen oder die Nutzung definierter Toleranzen eher uner-wünscht sind. Termine und Budgets sind häufig Variablen, die zu Lasten von Auf-traggeber und Kunden angepasst werden (müssen).

Agile basiert auf Kollaboration in Teams, sowohl intern als auch im Außenverhältnis. Produkte und Lösungen werden im Projekt-verlauf entwickelt und ihre Eigenschaften nach Werthaltigkeit priorisiert. Änderun-gen werden begrüßt, weil sie helfen, Pro-dukte und Lösungen an den tatsächlichen oder geänderten Bedarf anzupassen. Die Teams steuern sich und ihre Arbeit selbst. Geplant wird zeitnah nur der unmittelbar bevorstehende Arbeitsabschnitt. Ein Pro-jekt endet, wenn der vorgesehene Termin erreicht ist oder die Werthaltigkeit zusätz-licher Eigenschaften die Kosten der weite-ren Entwicklung nicht mehr rechtfertigen kann.

PRINCE2 Prinzipien vs. AgilePRINCE2 in der Version 2009 basiert auf sieben Prinzipien, die in allen PRINCE2-Projekten zu beachten sind. In [Axe15] wird gezeigt, dass diese Prinzipien nicht im Widerspruch zu Agile stehen. Vielmehr werden agile Prinzipien im Sinne des Steu-erungsbedarfs zeitlich befristeter Projekte ergänzt. Das Prinzip der fortlaufenden ge-schäftlichen Rechtfertigung ist kompatibel mit Agile, wo Werthaltigkeit möglichst früh und oft geliefert werden soll. Das Lernen aus Erfahrungen wird von Agile in Form von Feedback-Loops, Reviews und Retrospektiven unmittelbar unterstützt. PRINCE2 verlangt definierte Rollen und

Verantwortlichkeiten. Aus agilen Kontex-ten kommen weitere Rollen wie „Scrum Master“ und „Product Owner“ hinzu.PRINCE2 steuert mittels Management-phasen, Agile kennt Timeboxes, Sprints und Releases. Das Steuern nach dem Aus-nahmeprinzip (management by excepti-on) stützt unmittelbar agile Forderungen nach Selbstorganisation und Ermächtigung von Teams. Die Produktorientierung von PRINCE2 findet sich in agilen Kontexten etwa in Form von Priorisierungen und Änderungsbereitschaft wieder. Die Not-wendigkeit zur Anpassung an konkrete Projektumgebungen gilt für PRINCE2 und agile Rahmenwerke wie Scrum oder Kan-ban gleichermaßen. PRINCE2 in der Version 2009 sieht sich also gut vorbereitet für den Einsatz agiler Arbeitsweisen. Es adressiert die drei Ebe-nen:n Projektsteuerungn Projektmanagementn Produktlieferung

Agile adressiert vor allem die Lieferebene. In PRINCE2 Agile werden die Denkansätze von PRINCE2 und Agile miteinander ver-mengt (siehe Abbildung 1).

Agile in PRINCE2-ProjektenUm einen effizienten Einsatz von Agile in PRINCE2-Projekten zu unterstützen,

56

PRINCE2 goes Agile: Das neue Zertifikat „PRINCE2 Agile Practitioner“

Abb. 2: Von PRINCE2 Agile geforder-te Verhaltensweisen (in Anlehnung an [Axe15]).

Abb. 3: Fixierung und Flexibilisierung im PRINCE2-Hexagon (in Anlehnung an [Axe15]).

werden die PRINCE2-Prinzipien von fünf agilen Verhaltensweisen unterstützt (siehe Abbildung 2), die auf allen Ebenen eines Projekts eingefordert und etwa in Form ei-nes Ampelsystems beobachtet werden sol-len. Für den Umgang mit Defiziten bietet [Axe15] eine Reihe von Empfehlungen:

n Transparency: Mit Transparenz ist nicht nur die Sichtbarkeit der aktuellen Situation auf diversen Boards gemeint. Vor allem werden Eigenschaften wie Ehrlichkeit, Vertrauen, Integrität und Respekt, also die Offenheit aller Betei-ligten, gefordert.

n Collaboration: Die Kollaboration nach innen ist gemeinsam mit den Eigen-schaften der Transparenz eine notwen-dige Voraussetzung für die Herausbil-dung motivierter und schlagkräftiger Teams. Im Außenverhältnis wird insbe-sondere ein respektvoller Umgang mit den Kunden gefordert.

n Rich Communication: Für die Kommu-nikation sollen möglichst effiziente Ka-näle genutzt werden. In diesem Sinne sind persönliche Gespräche oder Work-shops ausgedehntem Mail-Verkehr oder gar Spezifikationen vorzuziehen.

n Self Organisation: Planung und Orga-nisation der Arbeit soll jenen überlas-sen werden, die am meisten davon ver-stehen, also den Spezialistenteams auf der Lieferebene.

n Exploration (fail early): Der richtige Weg zur Lösung soll so früh wie mög-lich gefunden und abgesichert werden. Empfohlen werden geeignete Experi-mente und Probearbeiten (Spikes).

Die ersten vier Verhaltensweisen finden sich in ähnlicher Form im Agilen Manifest und in den Prinzipien diverser agiler Ansätze. Bemerkenswert ist die explizite Aufforde-rung zu Experimenten und Probearbeiten. Die Forderung zielt auf die Vermeidung großer Designansätze in frühen Projektpha-sen (Upfront Design). Zudem ist implizit ein Hinweis auf die zumeist ausbaufähige Fehlerkultur einer Entwicklungsorganisa-tion und deren Verhältnis zu Stakeholdern enthalten.

Flexibilisierung im PRINCE2-HexagonPRINCE2 definiert sechs Aspekte, mit de-nen die Performance von Projekten gesteu-ert und gemessen werden können. Neben den klassischen Aspekten „Zeit“, „Kosten“ und „Umfang“ werden „Nutzen“, „Quali-

tät“ und „Risiken“ betrachtet. PRINCE2 Agile verlangt in Übereinstimmung mit agilen Ansätzen die Fixierung von Zeit und Kosten. Für die übrigen Aspekte werden Hinweise für die Nutzung von Toleran-zen im Sinne einer agilen Flexibilisierung gegeben (siehe Abbildung 3). So verlangt PRINCE2 Agile die Definition eines MVP (Minimum Viable Product), das die un-verzichtbaren Eigenschaften des zu ent-wickelnden Produkts beschreibt. Über die im MVP beschriebenen essenziellen Eigen-schaften hinausgehende Anforderungen an Umfang, Nutzen und Qualität sind Gegen-stand möglicher Flexibilisierungen. Leider sind die Beschreibungen zum MVP in [Axe15] recht abstrakt. Hilfreich wäre ein Hinweis auf die Pareto-Regel, nach der nur ca. 80 Prozent der Anforderungen zu Projektstart wirklich essenziell sind. Die übrigen 20 Prozent sind oft den Preis ihrer Entwicklung nicht wert oder binden unan-gemessen die Aufmerksamkeit im Projekt. So hatte sich die Betriebsorganisation eines Versicherungsunternehmens in die Mar-ketingbroschüren diverser Anbieter von Workflow-Managementsystemen verliebt. Sie forderte neben einem Prozessdesign mit tiefen Entscheidungsbäumen (Abbil-dung aller Arbeitsanweisungen) eine ent-sprechende Laufzeitkomponente und eine dem Echtbetrieb möglichst nahekommen-de Simulationskomponente. Dabei wurde übersehen, dass im konkreten Projekt nur ein vergleichsweise einfacher Workflow ab-zubilden war.In einem anderen Fall sollten Vertragsab-schlüsse im Web mit kleinen Bonifikationen gefördert werden. Dabei wurden Betrugs-versuche festgestellt, also Mitnahmen der Boni begleitet von Stornierungen unter

02/2016 57

www.objektspektrum.de

Ausnutzung der Widerspruchsfrist. Das Marketing wollte solche Betrugsfälle unbe-dingt mittels IT-Verfahren verhindern und beschäftigte die Projektgremien wochen-lang mit entsprechenden Anforderungen. Die endlich gestellte Frage nach der Scha-denshöhe wurde mit einem kleinen vierstel-ligen Betrag beantwortet. Das Thema war vom Tisch.Die Fixierung und Flexibilisierung der di-versen Aspekte von PRINCE2 sollen vor allem die Einhaltung von Fristen und Ter-minen unterstützen. Der Schutz essenzieller Qualitätskriterien senkt die Folgekosten des fertigen Produkts über den Lebens-zyklus. Änderungen haben einen positiven Einfluss auf das Projektergebnis und sollen deshalb ganz im agilen Sinne begrüßt wer-den (Embrace Changes). Die Fixierung des Budgets soll unter anderem Versuche ver-hindern, den Projektfortschritt durch den kurzfristigen Ausbau der Kopfzahlen in den Teams zu beschleunigen. Schließlich soll von allen Beteiligten akzeptiert werden, dass es viele Produkteigenschaften gibt, de-ren Mehrwert die Kosten der Fortsetzung eines Projekts nicht zu rechtfertigen vermö-gen.

Anpassungen von PRINCE2 PRINCE2 definiert die folgenden sieben Themen, die in jedem Projekt zu adressie-ren sind:

n Business-Casen Organisationn Qualitätn Plänen Risikenn Änderungenn Fortschritt

Abb. 4: Einführung von Agile in PRINCE2 Prozessen (in Anlehnung an [Axe15]).

Dazu kommen sieben Prozesse, mit denen ein Projekt gesteuert wird. Das alles wird von 26 Artefakten gestützt, deren Inhalte im Lauf eines Projekts erstellt und gepflegt werden sollen. PRINCE2 Agile versteht sich nicht als neue Methode des Projektmanagements. Viel-mehr sollen systematische Anleitungen für die Anpassung von PRINCE2 an eine auf Agile basierende Lieferebene gegeben wer-den. Für eine detaillierte Darstellung aller Themen, Prozesse und Artefakte sei auf das umfängliche [Axe15] verwiesen. Allgemein lässt sich festhalten, dass die Nutzung von Agile in der Lieferebene zu einer deutli-chen Rücknahme der formellen Ansprüche an Themen, Prozesse und Artefakte führt (more informal).Für die Ebene der Produktlieferung de-finiert PRINCE2 einen einfachen MP-Prozess (Managing Product delivery), der sich auf die Abstimmung der Pläne und die Überwachung des Arbeitsfortschritts kon-zentriert (siehe Abbildung 4). Die Ausge-staltung der Produktentwicklung überlässt schon PRINCE2 den in den Teams tätigen Spezialisten. Der Einbau agiler Arbeitswei-sen wäre sehr einfach, wenn z.B. Scrum eine Teamleitung kennen würde und die Kollaborationsforderung sich auf interne Teambelange beschränkte. Die Leistung von PRINCE2 Agile besteht darin, die wesentlichen Anpassungsleistungen nicht von Agile zu verlangen, gar unter Aufgabe wichtiger agiler Prinzipien. Vielmehr wer-den Themen, Prozesse und Artefakte von PRINCE2 auf den Umgang mit Agile aus-gerichtet.

PRINCE2 Agile konkret PRINCE2 Agile konzentriert sich auf sol-che Konzepte und Frameworks, die allge-mein einsetzbar sind, also nicht nur in IT-Kontexten. Es werden Konzepte, Methoden und Techniken aus Scrum, Kanban, Lean Startup (vgl. [Wik-b], [Wik-c], [Wik-d]) sowie DSDM (Dynamic Systems Develop-ment Method) und das daraus abgeleitete AgilePM (vgl. [DSDM]) adaptiert – mit einer deutlichen Betonung von Scrum in der Lieferebene. Aus IT-Kontexten werden die Prinzipien von XP (vgl. [Wik-a]) und SAFe V3.0 (Scaled Agile Framework) (vgl. [Sca15]) skizziert. Erwähnt werden ferner DevOps, Crystal und FDD (Feature Driven Development), ASD (Agile Software De-velopment) sowie DAD (Disciplined Agile Development).Von den bekannten Skalierungsansätzen für Scrum wird allein SAFe benannt, nicht

und Projekt herrschende Vertrauen oder die Möglichkeiten für eine direkte Kom-munikation der Beteiligten in jedem Projekt anders einzuschätzen. Die Bewertungen er-folgen aus einer agilen Perspektive. Sie sol-len eine möglichst effektive Anpassung des Projekts an agile Belange ermöglichen. Das Handbuch enthält Hinweise für den Um-gang mit verschiedenen Defiziten.

Für wen ist PRINCE2 Agile?PRINCE2 Agile wendet sich ausdrücklich nicht an reife agile Organisationen. Auch jener Teil der agilen Community, der schon eine Skalierung von Scrum nach dem Mus-ter von SAFe als nicht hinreichend agil oder sogar im Widerspruch zu agilen Arbeits-weisen ablehnt, wird für PRINCE2 Agile nicht erreichbar sein. In erster Linie wurde PRINCE2 Agile für solche Organisationen entwickelt, in denen PRINCE2 bereits heute eingesetzt wird. Auf diesen Benutzerkreis ist auch der of-fenbar nachdrückliche Wunsch für die Entwicklung von PRINCE2 Agile zurück-zuführen. Die Nutzung agiler Arbeitswei-sen in PRINCE2-Projekten wird deutlich erleichtert und sogar gefördert, weil nun auch in klassisch geprägten Organisationen auf Publikation und Ausbildungsangebot einer international anerkannten Organisa-

58

PRINCE2 goes Agile: Das neue Zertifikat „PRINCE2 Agile Practitioner“

aber z.B. LeSS (Large Scaled Scrum) (vgl. [LeSS]). Nexus von scrum.org (vgl. [Scr15]) wurde zeitgleich mit PRINCE2 Agile erst im Juni 2015 veröffentlicht, konnte also schon deshalb nicht berücksichtigt werden. Eine Technik wie das „Release Planning“ aus SAFe wird nicht erwähnt, seine Anwen-dung ist aber auch nicht ausgeschlossen. Obgleich agile Skalierungen in Ansätzen erkennbar sind, setzt PRINCE2 Agile doch vor allem auf die in größeren Projekten be-währten Mittel von PRINCE2.

Das AgilometerIn [Axe15] wird eine Reihe von Konzepten, Techniken und Frameworks beschrieben, die anderen Kontexten entnommen oder entlehnt wurden und auch außerhalb von PRINCE2-Projekten genutzt werden kön-nen. Ein Beispiel ist das Agilometer, das aus einem Fragenkatalog von DSDM ab-geleitet und für den Bedarf agiler Projekte zugeschnitten wurde (siehe Abbildung 5). Anhand von Schiebereglern (Suitability Sli-ders) sollen Projekt und Projektumgebung regelmäßig auf ihre Reife für die verschie-denen agilen Kriterien überprüft werden. Das Agilometer ist ein Werkzeug für das Projektmanagement. Es liefert Hinweise für die Einschätzung einer konkreten Projektsi-tuation. So sind etwa das zwischen Kunde

Abb. 5: Das Agilometer von PRINCE2 Agile (in Anlehnung an [Axe15]).

tion zurückgegriffen werden kann. Für die primäre Zielgruppe ist PRINCE2 Agile so-mit ein begrüßenswerter Ansatz.PRINCE2 und das für agile Arbeitsweisen angepasste PRINCE2 Agile sind produkt-neutral. Für die Arbeit der Spezialisten in der Lieferebene sollen bewusst keine Vorga-ben gemacht werden. Bei projektgetriebener Entwicklung von Software muss daher auf verfügbare Konzepte, Methoden und Tech-niken zurückgegriffen werden. PRINCE2 Agile erleichtert die Nutzung von Ansätzen wie Scrum, XP und anderen, einschließlich der jeweils angebotenen Techniken (Good Practices). Diese Techniken wurden speziell für die Softwareentwicklung bereitgestellt und genügen vielen Aufgabenstellungen. Die Frage ist also, ob PRINCE2 Agile auch eine ernsthafte Option für die Entwicklung von Software sein kann.Softwareentwicklung im Großen benötigt Rahmenwerke, die z.B. eine Skalierung von Scrum ermöglichen. So können LeSS und SAFe erfolgreiche Implementierungen vor-weisen. Das erst im Juni 2015 veröffentlichte Nexus benötigt noch etwas Zeit, wird aber auch seine Erfolge haben. Es deutet sich an, dass auf absehbare Zeit kein Skalierungsan-satz den Markt dominieren wird. Vielmehr ist zu erwarten, dass diese und andere agile Ansätze ihren Nutzerkreis finden und weiter ausgebaut werden. Für Organisationen, de-ren Geschäftsziel die Entwicklung von Soft-wareprodukten ist, sind sie einem PRINCE2 Agile wohl vorzuziehen.Es bleibt eine Vielzahl von Organisationen, für die Software nicht ihr Kernprodukt ist. Auch haben größere Softwarevorhaben Ausprägungen, die von agilen Ansätzen (noch) nicht ausreichend adressiert werden. Zu nennen sind beispielsweise die Einfüh-rung von Softwareprodukten mit mehr oder weniger großem Anpassungs-, Migra-tions-, Schulungs- und Rollout-Bedarf und ferner Technologiewechsel mit grundsätzli-chen Fragen an Architektur und Entwick-lungsumgebung, Entwicklungen in Kom-bination mit maschinennaher Embedded Software im Sinne von Industrie 4.0 oder IoT (Internet of Things). Dazu kommen standortübergreifende Vorhaben und sol-che, in denen agile und nicht-agile Orga-nisationen zusammenarbeiten müssen. Bei entsprechend anspruchsvollen Projekten oder Programmen lässt sich die Nutzung klassischer Ansätze des Projektmanage-ments mit geeigneten Anpassungen wie in PRINCE2 Agile durchaus begründen.PRINCE2 Agile wurde im Juni 2015 ver-öffentlicht. Es hat damit einen Verzug

von vier Jahren im Vergleich zu dem auf PMBOK referenzierenden PMI-ACP (vgl. [PMI15]). Für einen Vergleich dieser beiden Ansätze fehlt in diesem Artikel der Raum. Zu beachten ist aber, dass PMBOK eher eine Sammlung von Techniken des Projekt-managements ist, während PRINCE2 den Anspruch eines methodischen Ansatzes für die Abwicklung von Projekten erhebt.

Noch ein Zertifikat?Für PRINCE2 Agile kann das Zertifikat ei-nes „PRINCE2 Agile Practitioner“ erwor-ben werden. Voraussetzung ist das gültige Zertifikat eines PRINCE2 Practitioner. Die Ausbildung wird als dreitägiges Seminar angeboten (Handbuch inklusive). Die Prü-fung erfolgt am Nachmittag des dritten Ta-ges, dauert zweieinhalb Stunden und um-fasst 50 Multiple-Choice-Tests in deutscher Sprache. Obwohl nicht Voraussetzung, sollten Teilnehmer fundierte Kenntnisse aus mindestens einem agilen Ansatz mitbrin-gen. Die Prüfung ist durchaus anspruchs-voll und stellt auch gestandene PRINCE2-Trainer vor eine Herausforderung. Das Seminar ist ein interessantes Weiterbil-dungsangebot. Ob das Zertifikat im Markt erfolgreich sein wird, bleibt abzuwarten. Eine deutsche Übersetzung des Handbuchs war zunächst nicht geplant. Deren Bereit-stellung wird ein Indikator für den Erfolg von PRINCE2 Agile in der DACH-Region sein. Die Diskussionen zwischen Vertretern klas-sischer und agiler Ansätze sowie zwischen

02/2016 59

www.objektspektrum.de

Literatur & Links[Axe09] Axelos, Erfolgreiche Projekte managen mit PRINCE2, Handbuch, 2009

[Axe15] Axelos, PRINCE2 Agile, Handbook, 2015

[Bec01] K. Beck et al., Manifest für Agile Softwareentwicklung, 2001, siehe:

http://agilemanifesto.org/iso/de/

[DSDM] DSDM Consortium, siehe: http://www.dsdm.org/

[LeSS] The LeSS Company, siehe: http://less.works/

[PMI15] Project Management Institute (PMI), PMI Agile Certified Practitioner (PMI-ACP)

Handbook, 2015, siehe: https://www.pmi.org/~/media/PDF/Certifications/handbooks/

agile-certified-practitioner-handbook-acp.ashx

[Sca15] Scaled Agile Inc., Scaled Agile Framework, 2015, siehe:

http://scaledagileframework.com/

[Scr15] Scrum.org, Nexus Framework, 2015, siehe:

https://www.scrum.org/Resources/The-Nexus-Guide

[Wik-a] Wikipedia, Extreme Programming, siehe:

https://de.wikipedia.org/wiki/Extreme_Programming

[Wik-b] Wikipedia, Kanban, siehe: https://de.wikipedia.org/wiki/Kanban

[Wik-c] Wikipedia, Scrum, https://de.wikipedia.org/wiki/Scrum

[Wik-d] Wikipedia, Lean Startup, siehe:

https://de.wikipedia.org/wiki/Startup-Unternehmen#Lean_Startup

|| Klaus Fricke (klaus.fricke@kegon.de) ist Managementberater bei der KEGON AG und hat langjährige Erfahrung als Projektmana-ger. 2015 war er Teilnehmer eines der ersten deutschsprachigen Seminare für PRINCE2 Agile. In dem Artikel schildert er seine Eindrücke dieses neuen Angebots von Axelos.

Der Autor

Vertretern verschiedener agiler Ansätze ha-ben mitunter ideologische Züge. Dabei darf nicht übersehen werden, dass abseits aller Argumente auch die ökonomischen Interes-sen von Zertifikatsanbietern und -inhabern eine Rolle spielen. Deshalb ist bis auf weite-res nicht zu erwarten, dass einzelne Skalie-rungsansätze aufgegeben oder mit anderen verschmolzen werden. Eine Entscheidung für oder gegen einen bestimmten Ansatz kann nur im Einzelfall für ein bestimmtes Projekt in einer bestimmten Organisation und mit Blick auf die dortigen Rahmenbe-dingungen getroffen werden. ||