46 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 05/ 2021 DOI 10.24053/ PM-2021-0093 Ein Denkanstoß zur kritischen Würdigung der in der Literatur und im öffentlichen Diskurs inflationär verwendeten Begriffe „agiles Projektmanagement“ und „hybrides Projektmanagement“ Es gibt kein „agiles Projektmanagement“ Matthias Eberspächer, Bernd Hahn, René Warweitzky Für eilige Leser | Das sogenannte agile und hybride Projektmanagement wird heiß diskutiert. Aber: was ist das überhaupt? Gibt es einen Konsens darüber, was unter diesen Begriffen zu verstehen ist? In diesem Beitrag vertreten wir die Hypothese, dass die genannten Begriffe prinzipiell nicht genau definierbar sind. Genauer ist es, vom Management agiler (oder hybrider) Projekte zu sprechen. Wir zeigen, zu welchen Fehlentwicklungen eine ungenaue Verwendung der Begriffe in Projekten führen könnte und wie diesen Fehlentwicklungen entgegengewirkt werden kann. Schlagwörter | Agilität, agiles Projektmanagement, Manifest der agilen Softwareentwicklung, Scrum, hybrides Projektmanagement, Projektmanagement, Projektvorgehensmodelle, ICB 4 Seit einigen Jahren werden in der Projektmanagement-Literatur und im öffentlichen Diskurs die Begriffe „agiles Projektmanagement“ bzw. „hybrides Projektmanagement“ immer häufiger verwendet [1]. Dabei entsteht der Eindruck, es handele sich um völlig neue Arten von Projektmanagement, die es bisher nicht gab und die das über Jahrzehnte etablierte Projektmanagement „disruptiv“ obsolet machen und ersetzen. Internet-Suchmaschinen liefern zu den genannten Begriffen-- allein in deutscher Sprache-- über 500.000 Ergebnisseiten. Man sollte also meinen, dass es über die Bedeutung dieser Begriffe ein breites, gemeinsames Verständnis unter ihren Nutzerinnen und Nutzern gibt; und dass diejenigen, die diese Schlagwörter verwenden, eine inhaltlich übereinstimmende Definition der Begriffe geben. Eine Analyse der verfügbaren Literatur und Quellen zeigt aber, dass unter den Autoren sehr unterschiedliche, in der Regel sehr unklare und zum Teil auch widersprüchliche Auslegungen der Begriffe verwendet werden. Agiles Projektmanagement in dieser Zeitschrift Auch die Ausgabe 02 / 2021 von PROJEKTMANAGEMENT AK- TUELL mit dem Titel „Agiles Projektmanagement“ hatte verschiedene Definitionen im Angebot: Die jeweiligen Autoren betonten die Notwendigkeit einer höheren Flexibilität agiler Projekte [2], oder die agilen Werte und Prinzipien [3], eine Kombination aus diesen Konzepten [4] oder verzichteten gänzlich auf eine Definition von „agilem Projektmanagement“ [5]. In anderen Publikationen wird häufig auch der Verzicht auf eine mittelbis langfristige Planung als prägendes Merkmal von agilem Projektmanagement genannt. Woher kommt diese Begriffsunsicherheit? Projektmanagement ist nicht „agil“ In diesem Artikel stellen wir die Hypothese auf, dass es „agiles / hybrides Projektmanagement“ gar nicht gibt, sondern nur ein Projektmanagement im Kontext bestimmter Projektvorgehensmodelle. Zur Begründung unserer Hypothese untersuchen wir zunächst die Begriffe „Projekt“, „Projektmanagement“ und „Agilität“. Die Begriffe „Projekt“ und „Projektmanagement“ Die gängigen Projektmanagement-Standards ICB 4 [6], PMBOK [7] und PRINCE2 [8] basieren alle auf einer konkreten Festlegung, was im Kontext ihres Gültigkeitsbereichs unter den Begriffen „Projekt“ und „Projektmanagement“ zu verstehen ist. Beispielhaft für diese Definitionen zitieren wir die- - quasi amtliche-- DIN-Norm 69 901 [9]: Wissen | Es gibt kein „agiles Projektmanagement“ 47 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 05/ 2021 DOI 10.24053/ PM-2021-0093 Definition Projekt: „Vorhaben, das im Wesentlichen durch die Einmaligkeit aber auch Konstante der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen; -(…)“ Definition Projektmanagement: „Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten.“ Alle Definitionen von „Projekt“ umfassen mindestens die Eigenschaften der Einmaligkeit, der Begrenzung durch Ressourcen und die Befristung des Zeitraums. Alle Definitionen von Projektmanagement beziehen sich auf die Tätigkeiten, die notwendig sind, um Projekte zu organisieren (Aufbau- und Ablauf-Organisation). Keine Definition des Projektbegriffs und auch nicht die Definitionen zum Projektmanagementbegriff, stellen einen inhaltlichen Bezug zum eigentlichen Leistungserstellungsprozess innerhalb eines Projektes her. Ob und nach welchem Vorgehen ich eine Pyramide baue, zum Mond fliege, oder Software entwickele: Projektmanagement bietet lediglich einen organisatorischen Rahmen, in dem ein einmaliger Leistungserstellungsprozess initialisiert, durchgeführt und abgeschlossen wird. Der Begriff „Agilität“ „Es gibt heute unzählige Definitionen des Agilitätsbegriffs“, stellt Steffen Scheurer in seinem Editorial zur Ausgabe 02 / 2021 von PROJEKTMANAGEMENT AKTUELL [10] fest. Ursprung, einziger gemeinsamer Bezugspunkt und damit kleinster gemeinsamer Nenner für all diese „Agilitäts“-Definitionen ist aber immer das sogenannte Agile Manifest. Mangels einer DIN-Norm für „agiles Management“ greifen wir also auf diese Quelle aus dem Jahre 2001 zurück. Abbildung 1 zeigt einen Screenshot des häufig abgekürzt betitelten „Agilen Manifests“ in deutscher Sprache [11]. • Das sogenannte „Agile Manifest“ ist ein „Manifest für Agile Softwareentwicklung “, nicht für das Management von Projekten. • Die „Werte auf der rechten Seite“ sind Werte, die im Projektmanagement einen hohen Stellenwert haben. Diese Werte finden die Unterzeichner des Manifests „wichtig“, sie schätzen aber die „Werte auf der linken Seite“ für die Softwareentwicklung höher ein. • In diesem Manifest für Agile Softwareentwicklung finden sich weder Vorschriften, mit welchen konkreten Maßnahmen diese Wertverschiebungen im Rahmen eines Softwareentwicklungsprozesses noch im Rahmen eines Projektes oder von Projekten innerhalb einer großen Organisation umzusetzen wären. Das Agile Manifest „erschließt bessere Wege, Software zu entwickeln“; es hat nicht zum Ziel, bessere Wege zu erschließen, Projekte durchzuführen. Ein Beispiel für eine Umsetzung der Forderungen des Manifests für Agile Softwareentwicklung ist der Produktentwicklungsprozess des Audio-Streaming-Dienstes Spotify. Das sogenannte Spotify-Modell [12] kombiniert eine Matrix-Aufbauorganisation mit einem auf viele Entwicklerteams skalierten Scrum-Vorgehen. Spotify betreibt damit sehr erfolgreich einen kontinuierlichen, nie endenden Produktentwicklungsprozess. Dieser (Produktentwicklungsprozess) ist kein Projekt im Sinne der obigen Definition. Konsequenterweise fordern agile Vorgehensmodelle auch keine Projektleiterrolle. Denn diese wird nur in Projektvorgehensmodellen benötigt. Gibt es also keine agilen Projekte? Der große Erfolg des Manifests für Agile Softwareentwicklung mit seiner geforderten Verschiebung der vier Werte und al- Abbildung 1: Auszug der Webseite http: / / agilemanifesto.org / iso / de / manifesto.html Wissen | Es gibt kein „agiles Projektmanagement“ 48 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 05/ 2021 DOI 10.24053/ PM-2021-0093 len daraus folgerichtig abgeleiteten Prinzipien und konkreten Handlungsempfehlungen zur Optimierung von Softwareentwicklungsprozessen hat dazu geführt, dass sich auch Projekte mit den agilen Werten, Prinzipien und Konzepten beschäftigt haben. Ziel war es, bewährte Methoden und Praktiken aus der „agilen Welt“ zu analysieren und auf ihre Tauglichkeit für den Einsatz in Projekten zu überprüfen. Heute, 20 Jahre nach dem Manifest für Agile Softwareentwicklung, gibt es sehr viele Projekte, die einen agilen Leistungserstellungsprozess nutzen. Eine Vielzahl dieser Projekte produziert keine Software. Diese Projekte benötigen dann jedoch Projektmanagement, um ihren agilen Leistungserstellungsprozess in ein Projekt zu integrieren. Denn per Definition (s. oben) hat ein Projekt einen Anfang, einmalige Ziele und ein Ende. Per Definition hat die überwiegende Mehrheit der agilen Softwareentwicklungsprozesse das in der Regel nicht. Im Folgenden beziehen wir uns beispielhaft auf das bekannteste und am häufigsten angewandte Framework für agile Softwareentwicklung, den Scrum Guide von Ken Schwaber und Jeff Sutherland [13]. Wir gehen davon aus, dass Sie mit dem 13-seitigen Scrum Guide, seinen drei Rollen, den fünf Ereignissen und den drei Artefakten grundsätzlich vertraut sind. Die angeführten Beispiele gelten im Wesentlichen auch für andere agile Frameworks. Nach dem Scrum Guide gibt es keinen ersten und keinen letzten Sprint und das Product-Backlog muss nicht initial erstellt werden, sondern ist immer da. Das Product-Backlog ist nicht mit einem Pflichtenheft zu verwechseln, denn es ist „(…) eine wachsende, geordnete Liste was benötigt wird, um das Produkt zu verbessern“ [13]. Auch sagt der Scrum Guide nichts darüber, welche Tätigkeiten zum Abschluss des Entwicklungsprozesses notwendig sind, denn er endet nie. Und zu den für ein Projekt so zentralen Aufgabenstellungen wie beispielsweise das Termin- und Kostencontrolling oder das Vertragsmanagement gibt es ebenfalls keine Hilfestellung. Und das, obwohl die Unterzeichner des agilen Manifests auch diese Tätigkeiten „wichtig“ finden. Vorschlag für eine Definition „Agiler Projekte“ Nach unserem Verständnis bildet die folgende Definition für den Begriff „agiles Projekt“ die aktuelle Projektrealität am besten und widerspruchsfreisten ab: „Ein agiles Projekt ist ein Projekt, das mit Methoden des Projektmanagements einen Rahmen vorgibt, in dem ein agiler Leistungserstellungsprozess zur Anwendung kommt.“ Die konkret ausgewählten Methoden und Praktiken aus dem etablierten Kanon des Projektmanagements mögen für agile Projekte andere sein als für nicht agile. Das Projektmanagement selbst ist jedoch nicht anders. Weder kann in einem agilen Projekt auf Projektmanagement noch auf die Rolle des Projektleiters verzichtet werden [3]. Eine Ungenauigkeit in dieser Definition ist die Frage, wie „agil“ der Leistungserstellungsprozess sein muss, damit das Projekt die Definition erfüllt. Reicht die Verwendung eines Kanban-Boards oder die Durchführung eines Daily Scrum? Oder müssen im Falle von Scrum alle drei Rollen, fünf Events gelebt und drei Artefakte vorhanden sein? Aus Sicht der Projektleitung kann die Antwort lauten: Das ist uns egal. Wir machen das, was uns hilft, unsere Projektziele zu erreichen. Wie es heißt und woher es kommt, interessiert uns nicht. Ein reiner Akademikerstreit? Spätestens jetzt stellen Sie sich die Frage: Warum dieses pedantische Herumreiten auf Begriffsdefinitionen? Nachweislich werden zahlreiche agile Projekte auch ohne eine verbindliche Definition und Begriffsabgrenzung erfolgreich durchgeführt. Welchen praktischen Mehrwert bietet diese akademisch anmutende Auseinandersetzung mit diesem Thema? Wir sehen im Wesentlichen drei mögliche, gefährliche Fehlinterpretationen, die falsch verstandene Agilitäts- und Projektmanagement-Begriffe nach sich ziehen und zu Problemen in Projekten führen können. Die Annahme(n), dass • agile Projekte ganz ohne Projektmanagement auskommen können, • alle agilen Konzepte uneingeschränkt in jedem Projektkontext hilfreich sind, • Organisationen sich zunächst „agil transformieren“ müssen, bevor sie agile Konzepte in ihren Projekten einsetzen können. Agile Vorgehensmodelle allein reichen nicht aus Christoph Richter schreibt: „Die Einfachheit von Scrum manifestiert sich z. B. darin, dass der Scrum Guide in der aktuellen Version von November 2020 lediglich 13 Seiten umfasst, während z. B. die Richtlinie zum klassischen Projektmanagementstandard ICB 4- (…) einen Umfang von 216 Seiten hat.“ [14]. Damit wird beim Leser-- wahrscheinlich vom Autor unbeabsichtigt-- der Eindruck erweckt, dass in beiden zitierten Dokumenten die gleichen Inhalte abgedeckt würden und der Scrum Guide in einem agilen Projekt das gesammelte Projektmanagementwissen der ICB 4 ersetzen könnte. Dieser Eindruck kann dazu führen, dass agile Projektteams meinen, sie könnten vollständig auf mittelbis langfristige Planung, Chancen- und Risikomanagement, Termin- und Kostencontrolling, usw. verzichten: Dazu steht nichts im Scrum Guide. Die Rolle des Projektleiters, der diese Tätigkeiten in einem Projekt verantworten würde, gibt es nicht. Andererseits betont auch der Scrum Guide: „Das Scrum-Modell ist absichtlich unvollständig und umfasst nur die Teile, die notwendig sind, um die Scrum-Theorie umzusetzen“ [13]. In der Regel erkennen das auch die Projektteams: Eine firmeninterne Umfrage zum Status Quo Agilität in unseren Projekten aus dem Jahr 2020 [15], lieferte unter anderem die folgenden, für uns überraschenden Ergebnisse: • Der Wert des Einsatzes von Projektmanagementpraktiken wurde in unseren agilen Projekten im Durchschnitt höher bewertet als in den nicht agilen. • Die am höchsten bewertete und am häufigsten genutzte Projektmanagement-Praktik in unseren agilen Projekten ist die Ablauf-, Phasen- und Releaseplanung. • Die große Mehrheit unserer agilen Projekte hat die Rollen Projektleiter oder Projektmanager besetzt. Wissen | Es gibt kein „agiles Projektmanagement“ 49 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 05/ 2021 DOI 10.24053/ PM-2021-0093 Agile Konzepte können Projekten auch schaden Nicht alle agilen Konzepte sind in jedem Projektkontext hilfreich. Ein erfolgreiches Projekt ist „auf Kante genäht“: Es erreicht seine Ziele zur allgemeinen Stakeholder-Zufriedenheit mit dem geringstmöglichen Ressourceneinsatz zum frühestmöglichen Zeitpunkt. Jede geplante und durchgeführte Projektmaßnahme muss darauf geprüft werden, ob sie diese Randbedingungen erfüllt. Nicht alle Verbesserungsmaßnahmen erfüllen dieses Kriterium. Beispielhaft und nicht erschöpfend betrachten wir die Sprint-Retrospektive: Laut Scrum Guide ist das Ziel der Sprint-Retrospektive „Wege zu finden, um die Qualität und die Effektivität zu steigern.“ [13]. Beides ist in Projekten nicht uneingeschränkt sinnvoll. Wenn der Kunde beispielsweise Time-to-Market höher bewertet als die Produktqualität oder die Qualität gegenüber anderen Leistungsanforderungen eine untergeordnete Rolle spielt, ist es auch nicht sinnvoll, die Qualität des Produkts immer weiter zu steigern, wenn die Qualitäts-Anforderungen längst erfüllt sind. Genauso verhält es sich mit der Steigerung der Effektivität. In einem nie endenden Produktentwicklungsprozess ist es in der Regel sinnvoll, jede noch so kleine Steigerung der Effektivität umzusetzen, auch wenn sich die Kosten der Maßnahme erst nach mehreren Sprints amortisieren. In einem Projekt ist es fast ausgeschlossen, dass sich in den letzten Sprints vor Projektende noch Maßnahmen finden, deren Umsetzung sich für das Projekt noch lohnen. Natürlich zwingt niemand ein agiles Projekt dazu, solche nicht sinnvollen Maßnahmen durchzuführen. Um die Sinnhaftigkeit der Durchführung dieser Maßnahmen aber überhaupt bewerten zu können, braucht es Projektmanagement: In den genannten Beispielen sind das nach der ICB 4 u. a. die Kompetenzelemente Qualität (Practice 6), Kosten und Finanzierung (Practice 7) und Chancen und Risiken (Practice 11). Der Scrum Guide hilft bei der wirtschaftlichen Bewertung „absichtlich“ (s. oben) nicht weiter. Ohne agile Transformation keine agilen Projekte? Fast alle großen Organisationen haben es schwer, auf ihre etablierten Berichtssysteme und mehrstufigen Eskalationswege zu verzichten, oder die neuen Scrum-Rollen auszufüllen. Die agilen Rollen, der Verzicht auf die etablierten Projektrollen sowie das als Prämisse vorausgesetzte agile Mindset der Mitarbeitenden stellt viele Organisationen vor große Herausforderungen [18]. Erste Versuche in einzelnen Projekten, ausgewählte agile Konzepte einzusetzen, scheitern häufig am Beharrungsvermögen der Organisation. Die Forderungen des Manifests für Agile Softwareentwicklung kamen 2001 von Entwicklern, nicht von Projektmanagern oder Führungskräften. In der Projektrealität des Jahres 2021 ist es häufig umgekehrt: Die Forderung nach agileren Projekten kommt aus dem Management und wird nicht immer uneingeschränkt von den Mitarbeitenden mitgetragen. In seinem Interview mit Oliver Steeger erläutert Rüdiger Reinhardt, welche Konflikte sich daraus ergeben und wie Führungskräfte damit umgehen können [16]. Beispiel Product Owner Im Scrum Guide ist die Rolle des Product Owners folgendermaßen beschrieben: „[…] Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht.-[…] Der Product Owner verantwortet das effektive Management des Product Backlogs.- […] Der Product Owner bleibt- […] immer rechenschaftspflichtig. Damit der Product Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Der Product Owner ist eine einzelne Person, kein Komitee.-[…]“ [13]. Den meisten Organisationen fehlt es an ausreichend qualifizierten Mitarbeitenden, die in der Lage und willens sind, eine solche Rolle zu übernehmen, ganz abgesehen von den weitgehenden Befugnissen, die in dieser Rolle für die Organisation gebündelt werden. Daneben finden sich auch vertraglich problematische Aspekte, wie die Tatsache, dass viele Kunden ihre Software- Entwicklungs-Projekte als Werkverträge beauftragen und dann natürlich nicht über die Rolle des Product Owners die „rechenschaftspflichtige Verantwortung“ für „den Wert des Produkts“ übernehmen können und wollen. Knittel und Seckinger nennen auch noch mögliche Kollisionen mit Normen als Hindernis [17]. Agile Projekte auch ohne agile Transformation! Natürlich ist es richtig, dass sich die größten Nutzenpotenziale agiler Projekte nur in einer optimal auf diese Projekte abgestimmten Organisation heben lassen können, siehe das Beispiel Spotify. Das können insbesondere große Organisationen nur sehr schwer kurzfristig leisten. Aber sollte man deshalb mehrere Jahre Organisationsentwicklungsprozess abwarten, bevor man einzelne bewährte und hilfreiche agile Konzepte in laufenden Projekten einführen kann? Eine vollständige agile Transformation der Unternehmensorganisation zu fordern, ist nach unserer Erfahrung weder notwendig noch sinnvoll. Unserer Meinung nach entspricht dies auch nicht dem Geist des Manifests für Agile Softwareentwicklung. Und auch der Scrum Guide sagt: „Scrum ist einfach. Versuchen Sie es, wie es ist und stellen Sie fest,-(…) ob es hilft Ziele zu erreichen und Mehrwert zu generieren.“ Fazit Dieser Artikel hat die Frage „Was ist agiles Projektmanagement? “ gestellt und keine wirklich befriedigende Antwort gefunden. Wir sehen unsere Hypothese gestärkt, dass es zwar agile Projekte, aber kein agiles Projektmanagement gibt. Das ist zwar etwas ernüchternd, aber nicht schlimm, denn diese Frage ist ohnehin schlecht gestellt. Viel interessanter ist die gut gestellte Frage: „Was ist im Management agiler Projekte anders als im Management anderer Projekte? “. Dazu haben auch die Artikel dieser Zeitschrift in ihrer Ausgabe zu „Agiles Projektmanagement“ wertvolle Beiträge geliefert. Agilität und Projektmanagement stehen nicht im Widerspruch zueinander, es geht nicht um das eine oder das andere. Im Gegenteil: Sinnvoll eingesetzt, ergänzen sich Agilität und Projektmanagement im Projektkontext. Projektmanagement füllt die beabsichtigten Lücken der Agilität. Wissen | Es gibt kein „agiles Projektmanagement“ 50 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 05/ 2021 DOI 10.24053/ PM-2021-0093 Ausblick Die wissenschaftlich fundierte Untersuchung eines Gegenstandes setzt voraus, dass dieser Gegenstand eindeutig definiert ist, oder diese Definition das Ziel der Untersuchung ist. Sonst besteht die Gefahr, dass sich aus der Unsicherheit ungewollte Spielräume für Fehlannahmen ergeben: ex falso sequitur quodlibet. Ein erster wichtiger Schritt ist der IPMA Reference Guide „ICB 4 in an Agile World“ aus dem Jahre 2018. Das Dokument betont die Wichtigkeit des agilen Mindsets der Projektmitarbeitenden sowie das grundsätzlich andere Führungskonzept in agilen Projekten. Dazu werden die für agile Projekte erfolgskritischen Schlüsselkompetenzen hervorgehoben. Diese Beschränkung wirft aber die Frage auf, ob dann nicht auch Projekte mit einem klassischen Leistungserstellungsprozess agil sein können, wenn das Projektteam das agile Mindset und Führungskonzept anwendet. Darüber hinaus wären weiterführende Untersuchungen hilfreich, die sich aus den besonderen Herausforderungen des Spannungsfelds des agilen Leistungserstellungsprozesses und den Anforderungen des Projektmanagements ergeben, z. B. wie kann ein effektives Kostencontrolling aussehen, wenn das Projekt nur in Storypoints oder T-Shirt-Größen denkt? Welche typischen Chancen und Risiken bieten agile Projekte? Was ist eine sinnvolle Verteilung der Aufgaben, Kompetenzen und Verantwortlichkeiten zwischen Product Owner und Projektleiter? Literatur [1] beispielhaft genannt seien die beiden Ausgaben 2 / 2020 „Agiles und hybrides Projektmanagement“ sowie 2 / 2021 „Agiles Projektmanagement“ von PROJEKTMANAGEMENT AKTUELL [2] Diesterer Georg und Daum, Andreas, „Agilität nimmt weiter Fahrt auf im Projektmanagement“; in: PROJEKTMA- NAGEMENT AKTUELL 2 / 2020 [3] Ochs, Christoph und Spang, Konrad, „Die Projektleiterrolle im agilen Projektmanagement“; a. a. O. [4] Schoper, Yvonne, Gertler Elisa und Fox, Kaily, „Der Einfluss von Kultur und Persönlichkeit auf agile Projektmanagementtechniken“; a. a. O. [5] Meindl, Stefanie, Pfähler, Julia und Bissel Moritz, „Agile Leadership-- Zur agilen Führungskraft geboren“; a. a. O. [6] GPM Deutsche Gesellschaft für Projektmanagement e. V. (Hrsg.): Individual Competence Baseline für Projektmanagement, Version 4.0, deutsche Fassung, Nürnberg (2017) (Onlineausgabe) [7] Project Management Institute (2017), „A guide to the Project Management Body of Knowledge (PMBOK guide)” (6th ed.) [8] AXELOS Ltd. (Hrsg.): „Managing Successful Projects with PRINCE 2” (6th ed.) (2017) [9] Deutsches Institut für Normung e. V. (Hrsg.): DIN-Normenreihe 69 901, (2009) [10] Scheurer, Steffen, „Editorial Agiles Projektmanagement“; in: PROJEKTMANAGEMENT AKTUELL 2 / 2020 [11] http: / / agilemanifesto.org / iso / de / manifesto.html; Stand: August 2021 [12] https: / / www.atlassian.com / agile / agile-at-scale / spotify; Stand: August 2021 [13] Schwaber, Ken und Sutherland, Jeff: https: / / www.scrumguides.org/ ; November 2020 (alle Textstellen sind von den Autoren aus dem Englischen übersetzt) [14] Richter, Christoph, „Was ist dran an der „neuen Sau“ des Projektmanagements? “; in: PROJEKTMANAGEMENT AK- TUELL 2 / 2021 [15] Interne Auswertung einer an die GPM-Studie „Status Quo Agile“ aus dem Jahre 2019 angelehnte firmeninterne Umfrage; Auszugsweise Bereitstellung der Auswertung auf Anfrage [16] Steeger, Oliver, „Vollbremsung aus Angst“, Interview mit Rüdiger Reinhardt; in: PROJEKTMANAGEMENT AKTUELL 2 / 2021 [17] https: / / www.projektmagazin.de / artikel / wer-scrum-einfuehrt-muss-auch-agil-werden_1 093 235; Stand: August 2021 [18] https: / / www.projektmagazin.de / artikel / agil-hybrid-traditionell-pragmatisches-projektmanagement; Stand: August 2021 Eingangsabbildung: © patiwat - stock.adobe.com Matthias Eberspächer Dr. Matthias Eberspächer arbeitet als Qualitäts- und Projektmanager bei msg in München. Sein besonderes Interesse gilt der Optimierung von Projektvorgehensmodellen, dem Aufbau und der Steuerung effizienter Projektteams sowie Methoden zur Erhöhung der Wirksamkeit von Projektmanagementberatung. eMail: mailto: matthias.eberspaecher@msg.group, OR- CID: 0000-0001-7600 - 1921 Bernd Hahn Bernd Hahn ist Leiter des Center of Competence Projektmanagement des Bereichs Public Sector bei msg. Er konzentriert sich insbesondere auf agile und hybride Projekte. Als PRINCE II-, PMI- und IPMA-zertifizierter Projektleiter ist er seit über 10 Jahren im Public Sector tätig. eMail: Bernd.Hahn@msg.group René H. Warweitzky René H. Warweitzky verantwortet innerhalb der msg-Gruppe das Center of Competence Project Management and Agility und arbeitet branchenübergreifend als Projektportfolio- und Projektmanager sowie als Berater. Er bringt die positiven Einflüsse von Agilität z. B. mit Projektmanagementverfahren zusammen, wie etwa beim agilen Festpreis. eMail: rene.warweitzky@msg.group