Auswirkungen und Potenziale agiler Methoden Agilität im Projektportfoliomanagement Autoren: Philip-Jerome Müller, Claus Hüsselmann >> Für eilige Leser Agile Methoden wie Scrum gewinnen zunehmend an Bedeutung. Dabei besteht nicht zuletzt in Unternehmen mit etabliertem Multi-PM Unsicherheit über die Vereinbarkeit mit klassischen Ansätzen auf Steuerungsebene. Beispielsweise gewinnt die unterjährige, rollierende Evaluierung von Faktoren wie der Nutzenentwicklung an Bedeutung, welche erst durch die inkrementelle Entwicklung in agilen Methoden ermöglicht wird. Zudem stellt die Harmonisierung klassischer und agiler Abläufe eines hybriden Portfolios eine zentrale Herausforderung dar. So sollten einerseits Meilensteine zur Abstimmung definiert werden, gleichzeitig dürfen solche starren Vorgaben jedoch nicht die Autonomie agiler Teams einschränken. Ein möglicher Ansatz ist der sogenannte „Agile Release Train“ als Informationsebene zwischen klassischen Wasserfallprojekten und agilen Teams. Nicht zuletzt genießt auch das PMO eine veränderte Rolle im hybriden Projektportfolio. Unternehmen werden auch zukünftig nicht vor einer „Schwarz-weiß“-Entscheidung zwischen klassischen oder agilen Methoden stehen. Vielmehr gewinnen hybride Projektansätze im Zuge von Marktentwicklungen wie der Industrie 4.0 weiter an Bedeutung und klassische Wasserfallmodelle koexistieren zunehmend mit agilem Vorgehen in einer bimodularen Projektlandschaft der Unternehmen. In diesem Zuge wird das Projektportfoliomanagement teilweise in seinen Aufgabenbereichen erweitert, gleichzeitig verlagern sich Kompetenzen. So wird im vorliegenden Artikel der Vorschlag angeboten, einen sogenannten „Agile Release Train“ als zusätzliche Ebene zwischen agilen Teams und dem Management zu schaffen. Der Neuheitsgrad agiler Methoden verlangt zudem ein Schulungs- und Weiterbildungskonzept, welches durch das PMO zur Verfügung gestellt werden sollte. Daneben sehen Unternehmen außerdem eine Coaching-Funktion des PMO unter Integration agiler Rollen in PPM und PMO. Einleitung Getrieben durch die Möglichkeiten der Digitalisierung, durch die massiv kürzer werdenden Entwicklungszyklen im IT-Bereich sowie nicht zuletzt wegen der Wettbewerbstransparenz durch das Internet unterliegen die Unternehmen des produzierenden Gewerbes und des Dienstleistungssektors einem voranschreitenden Preis- und Kostendruck. Dabei verkürzen sich durch den Einzug von Softwareprodukten in sämtlichen Branchen die Produktlebens- und Entwicklungszyklen. Diese Beschleunigung zeigt sich beispielhaft in der Automobilentwicklung. Werden Fahrzeuge klassischerweise im Dreibis Fünfjahreszyklus überarbeitet, gilt ein Infotainment-System nach WISSEN 49 projektManagementaktuell | AUSGABE 2.2017 geringem Wachstumspotenzial der Wunsch nach Produktvariationen, um so ein konstantes Nachfrageniveau zu gewährleisten. Das entstehende Spannungsfeld zwischen geforderter Innovationsrate einerseits und dem Preis- und Kostendruck andererseits wird folglich unmittelbar in Entwicklungsprojekte weitergeleitet, wo der Anspruch an Schnelligkeit, Flexibilität und Innovationsfähigkeit wächst. Gerade diese Attribute stellen jedoch - insbesondere große, traditionelle - Unternehmen vor Herausforderungen, da vielfach hierarchische Strukturen sowie ein ausgeprägtes Konkurrenzdenken von Abteilungen eine anpassungsfähige Organisation behindern. Auf der Suche nach Lösungen, welche diesen Forderungen gerecht werden, bedienen sich Unternehmen zunehmend der Entwicklungsmethoden, die sich in der Vergangenheit bereits im schnelllebigen Start-up-Umfeld sowie in der Softwareentwicklung etabliert haben. Sogenannte „agile Methoden“ werden hier eingesetzt, um eine hohe Innovationsrate bei gleichzeitig hoher Produktqualität zu gewährleisten. Diese setzen - anders als die klassischen, sequenziell ausgerichteten Wasserfallmodelle - auf geplante Rückkopplungen, einen intensiven Austausch sowie die Nähe von Entwicklungsteams und Kunden, um so eine hohe Flexibilität und damit Zielerreichung zu garantieren. Hinsichtlich der Gestaltung und Umsetzung trifft dieser neuartige Ansatz allerdings auf etablierte Projektsichten, was in der Folge besonders bei Multiprojektsituationen zu Konflikten führt. So stehen vor allem Unternehmen mit einem vielfältigen Projektportfolio vor der Aufgabe, klassische und agile Vorgehensmodelle miteinander zu vereinbaren. Dieses erweist sich insbesondere vor dem Hintergrund der angesprochenen Methodeninhomogenität als nicht trivial. Durch den Neuheitsgrad agiler Methoden in vielen fünf Jahren als veraltet. Die entstehende Lücke zwingt Hersteller so zur Angleichung/ Harmonisierung von Entwicklungszeiträumen und -methoden. Daneben steigt in gesättigten Märkten mit PM-aktuell_02-2017_InhaltV4.indd 49 10.04.17 10: 33 projektManagementaktuell | AUSGABE 2.2017 50 WISSEN Kleiner Blick zurück - Ein historischer Exkurs zur Agilität Der Begriff „Agilität“ taucht in der Organisationslehre verstärkt nach 1991 auf, was vor allem auf eine Veröffentlichung des Iacocca Instituts der Lehigh University zurückzuführen ist. Diese beruht auf einer mehrjährigen Studie und ist zentraler Auslöser für die in den Folgejahren aufgekommene Erforschung des Begriffs. Hinter der Breitenwirkung des Lehigh-Reports gerät jedoch häufig die Tatsache in Vergessenheit, dass bereits vor dessen Erscheinen einige Autoren, so z. B. Brown/ Agnew, an der organisationalen Agilität arbeiteten. Brown/ Agnew definieren Agilität als „... the capacity to react quickly to rapidly changing circumstances, requires a focus on clear system output goals and the capability to match human resources to the demands on changing circumstances“ [4]. Hierbei werden bereits wesentliche Charakteristika späterer Definitionen, wie die schnelle Reaktion auf Umweltveränderungen, der Fokus auf klare Ergebnisse, aber auch die große Gewichtung der Ressource Mensch, deutlich. Begriffsdefinitionen nach 1991 sind dagegen äußerst vielfältig, was in der Literatur häufig auf das Fehlen eines einheitlichen Standards zurückgeführt wird. In der Folge entwickelten Autoren verschiedene „Arbeitsdefinitionen“, die auf das betrachtete Anwendungsgebiet angepasst waren. Dabei ist die Tendenz zu erkennen, die Komplexität des Agilitätsbegriffs in eine prägnante Definition zu fassen und dann durch weitere, erläuternde Attribute zu spezifizieren. Bernardes/ Hanna bzw. Gunasekaran/ Yusuf sehen Agilität vor allem als schnelle und flexible Reaktion auf den Wandel und messen zusätzlich der Kunden- und Lieferantenbeziehung eine hohe Bedeutung bei [3, 8]. Seit den späten 1990er-Jahren werden zudem der Wert des Kunden und dessen individuelles Anforderungsprofil hervorgehoben. So sehen Yusuf et al. Agilität als „… a successful exploration of competitive bases (speed, flexibility, innovation proactivity, quality and profitability) through the integration of reconfigurable resources and best practices in a knowledge-rich environment to provide customer-driven products and services in a fast changing market environment“. Sie weichen damit von früheren Definitionen ab, indem Agilität als ein System aus Input, Operationalisierung und Output verstanden wird. Neben Schnelligkeit, Flexibilität, Innovation, Qualität und Profitabilität wird zudem proaktives Handeln thematisiert, während bisherige Definitionen eine Reaktion fokussierten. Weiter unterscheiden sie die Agilitätsgrade „… for the individual (and other resources), enterprise and inter-enterprise“ [21]. Eine aktuelle Definition nach Ganguly et al. reflektiert die Auffassung verschiedener Autoren und fasst den Begriff letztlich als „... an effective integration of response ability and knowledge management in order to rapidly, efficiently and accurately adapt to any unexpected (or unpredictable) change in both proactive and reactive business/ customer needs and opportunities without compromising with the cost or the quality of the product/ process“ zusammen [6]. Hierbei werden neben den nach Yusuf et al. definierten Attributen die Kosten sowie die Produktqualität in den Mittelpunkt gestellt. So dürfe Flexibilität und Schnelligkeit keine Qualitätseinbußen zur Folge haben. Obgleich letztere Definition zunächst allgemein für die Organisationslehre gilt, enthält sie bereits einige Attribute der Projektmanagementauffassung von Agilität. Agilitätsbegriff im Projektmanagement Im heutigen Projektmanagement - vor allem bei Softwareprojekten - spielt der Begriff „Agilität“ eine zunehmend wichtige Rolle, wobei Takeuchi/ Nonaka im Jahr 1986 den Anstoß zur Begriffsetablierung lieferten. Grundlage deren Forschung war der Vergleich innovativer und zu diesem Zeitpunkt wirtschaftlich rentabler Entwicklungsprojekte verschiedener Unternehmen (u. a. Hewlett-Packard). So stellte eine Analyse des Projektmanagements folgende sechs übereinstimmende Charakteristika heraus: • „built-in instability, • self-organizing project teams, • overlapping development phases, • multi-learning, • subtle control and • organizational transfer of learning“. Dabei seien die Eigenschaften für sich jedoch nicht ausschlaggebend, sondern vielmehr die geschickte Kombination führe zu einer hohen Agilität. Die Verwendung solcher vernetzten, selbst organisierten und interdisziplinären Teams bezeichneten die Autoren - analog der Rugby-Formation - als „Scrum“ [19]. Inspiriert von den Ergebnissen dieser Studie, übertrug Sutherland in der Folgezeit der 1990er-Jahre „Scrum“ erstmalig als Methode in die Softwareindustrie, indem er die Projektleiter der Guinness Peat Aviation den Teammitgliedern zuordnete und sie so die Rolle eines Moderators anstelle eines Managers einnehmen mussten. 1995 veröffentlichte Schwaber den ersten Konferenzbeitrag über die Methode: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität“ [17]. Gründe für die Entwicklung dieses neuen Ansatzes in der Softwareentwicklung waren Defizite der damaligen Methoden in Bezug auf dynamische Anforderungen, die resultierenden unplanmäßigen Änderungen sowie der wenig kooperative Ansatz in Projektplanung und -ausführung. So konnte der starre Entwicklungsprozess mit den fünf getrennten Phasen Produktidee, -definition, -entwicklung, -einführung und -elimination nicht auf die schnelllebige Softwareindustrie adaptiert werden. Begründet liegt dieses unter anderem in der klassischen Wahrnehmung des magischen Projektmanagement-Dreiecks, wobei die Einflussgrößen Zeit und Ressourcen als vorrangig variabel, Anforderungen hingegen als fix angesehen werden. Produkte mit kurzen Lebenszyklen - so zum Beispiel Software - erfordern jedoch flexible Anforderungen, um so kurzfristige Markterfordernisse berücksichtigen zu können. Agile Methoden sehen Anforderungen daher grundsätzlich als variabel an. PM-aktuell_02-2017_InhaltV4.indd 50 10.04.17 10: 33 WISSEN 51 projektManagementaktuell | AUSGABE 2.2017 • eine enge und transparente Abstimmung der Projektteilnehmer, zum Beispiel mithilfe einfacher Visualisierungen sowie • die systematische und offene Adressierung von Hindernissen. Bei Methoden wie Scrum findet zudem ein sogenanntes „Timeboxing“ statt, wobei Zeit und Ressourcen des unmittelbar nächsten Ziels als Vorgabe definiert („Boxing“ - verpackt) werden. Die kurzfristige Planung anhand nächster Ziele soll eine hohe Flexibilität gewährleisten. Solche Prinzipien weichen allerdings grundlegend von traditionellen Organisations- und Projektformen ab und stellen diese so infrage. Dieser Konflikt wird nachfolgend näher betrachtet. Gegenüberstellung von klassischen und agilen Vorgehensmodellen Bei vorliegendem Vergleich ist zunächst zu beachten, dass ein solcher durch die Methodenvielfalt nicht detailliert sämtliche Ausprägungen abbilden kann und in der Folge keinen Anspruch auf Vollständigkeit genießt. Die „Schwarz-weiß“- Projektportfoliomanagement (PPM) aufzeigen und zudem potenzielle Integrationsvorschläge anbieten. Charakteristika agilen Vorgehens Obgleich zwischen den heute verbreiteten agilen Methoden Unterschiede bestehen, können grundsätzlich nachfolgend aufgeführte Gemeinsamkeiten herausgestellt werden [11]: • die Entwicklung klarer, jedoch eher skizzenhafter Langfristziele (wie zum Beispiel Visionen), • der Verzicht auf eine langfristige Detailplanung, • jedoch eine detaillierte Kurzfrist-Zielbeschreibung, um unmittelbar Nutzen und Lerneffekte zu ermöglichen, • eine laufende Überprüfung (iterativ) der nächsten Ziele vor dem Hintergrund von Lernkurven und Umfeldveränderungen, • die große Autonomie des Projektteams, • eine hohe Interaktion mit Nutzern und Auftraggebern, Branchen fehlen zudem eine fundierte wissenschaftliche Basis sowie die praktische Erfahrung bei der Eingliederung. So stehen Unternehmen vor der Fragestellung, wie agile Methoden in die Projektportfolio- und Programmlandschaft integriert werden können und welche Auswirkungen dieses mit sich bringt. Steigende Komplexität innerhalb von Projekten (etwa bei der Entwicklung mechatronischer Produkte [5]), verbunden mit der Schnelllebigkeit von Produktvarianten verhindert detaillierte Langfristplanungen und erfordert Flexibilität bei der Definition von Anforderungen, sodass agile Vorgehensmodelle wie Scrum an Bedeutung gewinnen. Trotz bereits veröffentlichter Standards bestehen gerade in etablierten Wasserfallstrukturen Unkenntnis und, daraus resultierend, Hemmnisse, da die Vereinbarung von klassischen und agilen Methoden besonders auf der Multiprojektebene bisher nicht hinreichend erforscht worden ist [9]. So soll der Artikel den „aktuellen Stand sowie Auswirkungen agiler Vorgehensmodelle auf das Motiviert von der Erkenntnis, dass eine traditionell starre Projektplanung die Entwicklung von Produkten mit hochfrequenter Änderungsrate nicht hinreichend abdeckt, wurde 2001 das sogenannte „agile Manifest“ als Rahmen für agile Softwareentwicklungsmethoden mit nachfolgenden Werten definiert: • Individuen und Interaktionen vor Prozessen und Werkzeugen, • eine funktionsfähige Software vor umfassender Dokumentation, • die Kundenzusammenarbeit hat Vorrang vor der Vertragsverhandlung und • die Reaktion auf Planänderungen ist wichtiger als das Befolgen eines Plans [2]. Da inzwischen eine Vielzahl von Entwicklungsprojekten hohen Änderungsraten von Anforderungen unterliegt und Märkte im Allgemeinen höhere Innovationsraten verlangen, bedienen sich auch Unternehmen außerhalb der Softwareindustrie der Methoden des agilen Manifests. Da dieses jedoch auf die Softwareentwicklung ausgerichtet ist, werden häufig modifizierte Modelle oder Kombinationen aus klassischem und agilem Vorgehen genutzt. Steuerung beim „Wasserfall“-Vorgehen Umfang Zeit Kosten planorientiert Steuerung bei agilem Vorgehen Kosten Zeit Umfang mehrwertorientiert fest variabel angelehnt an: Opelt, Gloger, Pfarl, Mittermayer: Der Agile Festpreis Magisches Projektmanagement-Dreieck aus traditioneller und agiler Sicht (vgl. [16]) PM-aktuell_02-2017_InhaltV4.indd 51 10.04.17 10: 33 projektManagementaktuell | AUSGABE 2.2017 52 WISSEN „hybride Ansätze“, bestehend aus klassischen Wasserfallprojekten und agilen Vorgehensmodellen, die durch das PPM geplant und gesteuert werden müssen. Eine zentrale Funktion des PPM ist die Ressourcenallokation auf die Projektlandschaft eines Unternehmens. Klassisch erfolgt dieses häufig auf Basis einer Kombination aus der Bewertung von strategischer Relevanz und den Kosten des Projekts. Zu Beginn wird ein konkretes Projektergebnis definiert und daraus der benötigte Ressourceneinsatz (z. B. Personal-, Finanz- oder Sachmittelbedarf) abgeleitet. Diese Kosten-/ Nutzenrelation wird anschließend bewertet. Agile Methoden hingegen betrachten Anforderungen als variabel, sodass im Umkehrschluss mit vorgegebenen Ressourcen ein variables Projektergebnis verfolgt wird. Durch den „Timeboxing“- Ansatz stellen Ressourcen hierbei eine zu gend als Projektmanagementmethoden im klassischen Sinn anzusehen sind. So sind Projekte zum Beispiel durch die Einmaligkeit ihrer Bedingungen oder die Zeit- und Kostenbeschränkung gekennzeichnet, wobei das agile Vorgehen eine Aufgabe iterativ löst und die Fixierung von Zeit und Kosten voraussetzt. So sieht Komus agile Vorgehensmodelle auf Portfolioebene eher als Programme, Initiativen oder Produkte, die das eigentliche Projektmanagement bei der Produktentwicklung unterstützen [10]. Zudem ist nicht jedes Projekt für Agilität geeignet. Ist im Voraus ein konkretes Ergebnis definierbar, so können komplementäre Teilaufgaben (z. B. das Change-Management oder Personalentwicklung) agil bearbeitet werden. Zusammen mit dem zunehmenden Anteil von Softwareprodukten in einigen Branchen (z. B. das Infotainment im Automobil) entstehen folglich sogenannte Darstellung der in Tabelle 1 gezeigten Gegenüberstellung gängiger Auffassungen klassischer und agiler Vorgehensmodelle soll vielmehr grundlegende charakteristische Unterschiede herausstellen. Auswirkungen agiler Methoden auf das Portfoliomanagement Das PPM bezeichnet die Gesamtheit von Führungsaufgaben, -techniken und -mitteln zur Planung und Steuerung von Projektportfolios. Da solche Portfolios, wie einleitend beschrieben, zunehmend durch agile Methoden erweitert werden, stellt sich die Frage, inwieweit zuvor herausgestellte Unterschiede Einfluss auf das PPM und seine Aufgaben nehmen. Zunächst ist bei der Betrachtung agiler Vorgehensweisen zu beachten, dass diese nicht zwin- „Klassisches“ Vorgehensmodell Agiles Vorgehensmodell Leitungsgefüge tendenziell autoritäre Führung; Entscheidungen: Top-down/ hierarchisch tendenziell kooperative Führung; Entscheidungen: Gegenstromverfahren/ soziokratisch Rolle der Führung Planung, Entscheidung sowie Kontrolle der Projektmeilensteine Mentor und Repräsentant der Stakeholder Steuerung der Projektteams Weisung und Kontrolle durch Entscheidungszentralisation Konsens und Verhandlung durch Entscheidungsdezentralisation Projektteams und Arbeitsteilung Teambildung funktional nach Verrichtungen und Anforderungsprofil; hoher Spezialisierungsgrad Teambildung nach Fähigkeiten und Interessen; interdisziplinäre Zusammenstellung/ Sichtweisen Vorhersagbarkeit der Projektergebnisse durch eine detaillierte Planung und Dokumentation in Lastenheft zu Projektbeginn Iterationen und die Kommunikation mit Stakeholdern können das Projektergebnis laufend verändern. Anforderungsmanagement Projektanforderungen werden zu Beginn definiert und fixiert. Änderungen dieser Anforderungen sind mit hohem Aufwand verbunden und werden daher möglichst vermieden. Grobdefinition von Anforderungen zu Beginn; Änderungen sind während der Realisierung geplant bzw. erwünscht und werden in die jeweils nächste Iteration integriert. Kundeninteraktion geringe Interaktion, meist lediglich zu Beginn und Ende des Projekts Intensiv, häufig zu Beginn jeder Iteration Risikoeinschätzung Risikovermeidung durch eine dezidierte Projektplanung Risiken reduzieren durch iterative Produktanpassungen Räumliche Integration typischerweise keine zentralisierte Projektgruppe Zentralisierung zur Förderung der Gruppendynamik Projektergebnisse vollständige Lieferung des Produktes am Ende des Gesamtprojekts Inkrementelle Lieferung und Bewertung von Teilergebnissen Kriterium Ansatz Tab. 1: Gegenüberstellung klassischer und agiler Vorgehensmodelle anhand ausgewählter Kriterien PM-aktuell_02-2017_InhaltV4.indd 52 10.04.17 10: 33 WISSEN 53 projektManagementaktuell | AUSGABE 2.2017 Das Projektrisiko sollte folglich, wie auch der zuvor beschriebene Nutzen, am Ende eines jeden Inkrements bewertet werden. Hierdurch steigt zwar zusätzlich der Kontrollaufwand, so wird aber zugleich das verbreitete „90-%-Syndrom“ abgeschwächt. Die erhöhte Transparenz über das Projektrisiko kann außerdem einen Projektvergleich ermöglichen. So können renditeschwache Projekte mit einem hohen Risiko, das auch nach Fertigstellung erster Inkremente nicht wesentlich sinkt, frühzeitig beendet werden, was allerdings das Überwinden des „Sunk Cost“-Effekts erfordert. Insgesamt wird durch zuvor herausgestellte Bewertungs- und Kontrollzyklen eine unterjährige Strategie- und Investitionsplanung (bei Scrum werden bewertbare Sprint Tasks in ca. vierwö- Methoden die Möglichkeit, eine höhere Risikotransparenz des Projektportfolios zu erlangen. So kommt es im klassischen Projektmanagement bei der Informationsweitergabe häufig zu einem „Wassermelonen-Effekt“, wobei kritische Statusmeldungen vom Zentrum nach außen von dunkelrot nach hellgrün - ähnlich einer Wassermelone - verändert werden. Häufig motiviert durch eine autoritäre Unternehmenskultur, wird der wahre Projektstatus solange durch das mittlere Management verfälscht bzw. geschönt, bis dieser hellgrün erscheint [10]. Der Effekt wird durch die Entwicklung von funktionsfähigen Teillösungen stark abgeschwächt, da diese am Ende eines Inkrements getestet werden können und hierbei entweder den Vorgaben entsprechen oder nicht. Beginn definierte Größe zur Erfüllung eines noch zu definierenden, sich verändernden Ergebnisses dar. Die klassische Bewertung anhand der Investitionsrechnung (z. B. Kapitalwertrechnung) ist somit wenig sinnhaft, da Ressourcen als fixe Größe vorgegeben sind. Durch das stetige Erzeugen marktfähiger Teillösungen und der daraus resultierenden sichtbaren Nutzenentwicklung muss vielmehr entschieden werden, wie wertvoll bzw. nutzenstiftend die gelieferten Inkremente sind. Die Portfoliobewertung verschiebt sich so von rein „harten“ Faktoren (z. B. Kapitalwert) zu „weichen“ Faktoren wie der Nutzenentwicklung über die Laufzeit. Zudem erfordert sie eine - bislang eher untypische - „unterjährig rollierende“ Prüfung und Bewertung von Inkrementen. Diese bietet dem Management zwar einerseits eine höhere Statustransparenz und schafft so Vertrauen, bindet jedoch gleichzeitig mehr Ressourcen zur Projekt- und Portfoliobewertung. Die angesprochene Fortschrittsbzw. Nutzenbewertung sollte damit am Ende eines jeden Inkrements stattfinden, um so steuernd auf veränderte Bedingungen einwirken zu können. Durch die Vorgabe fixer Ressourcen zu Projektbeginn muss zudem, wie nachfolgend dargestellt, retrograd nach Fertigstellung eines Inkrements überprüft werden, ob der Nutzenzuwachs die angefallenen (zuvor festgelegten) Kosten rechtfertigt [10]. Die inkrementelle Entwicklung kann außerdem zu größeren Bedarfsschwankungen, insbesondere von Personalkapazitäten, führen, da jede Iteration individuellen Anforderungen unterliegt. Das PPM muss somit eine flexible Allokation gewährleisten, jedoch gleichzeitig das individuelle Kosten-/ Nutzenverhältnis abwägen. Eine solche Flexibilität kann allerdings nur durch eine konsequente Agilität des Unternehmens in Gänze geschaffen werden, da andernfalls Konflikte mit der plangetriebenen Sichtweise von Abteilungen - zum Beispiel Ressortegoismus oder Fachbereichsdenken - entstehen. Andererseits kann häufiges Rotieren sowie der Einsatz in multiplen Projekten zu Problemen in der Gruppendynamik oder schlichtweg zur Überforderung der Mitarbeiter führen und eine verursachungsgerechte Ressourcenverrechnung wird erschwert, da Mitarbeiter innerhalb einer Periode in verschiedenen Projekten Kosten induzieren. Neben der Portfoliobewertung und Ressourcenallokation wägt das PPM zudem potenzielle Projektrisiken ab. Ist ein Unternehmen bereit, bestehende Kontrollorgane anzupassen, bieten agile Abb. 1: Vergleich der Nutzenfeststellung und Kostenentstehung klassischer und agiler Methoden (vgl. [10]) Projektnutzen Zeit/ Kostenentstehung Kostenentstehung Nutzenzuwachs agil klassisch Zeitpunkt der Nutzenbewertung Abb. 2: Vergleich der Projektrisikobewertung klassicher und agiler Methoden (vgl. [10]) Projektrisiko Zeit agil klassisch Projektfortschritt Risikominderung Zeitpunkt der Risikobewertung PM-aktuell_02-2017_InhaltV4.indd 53 10.04.17 10: 33 projektManagementaktuell | AUSGABE 2.2017 54 WISSEN tral, da der Train lediglich Entscheidungen auf standardisierte Termine komprimiert [15]. Eine solche Harmonisierung der Release-Zeitpunkte „highly aligned, loosely coupled“ wird auch von Softwareunternehmen wie beispielsweise Netflix berichtet [15]. So bietet Leffingwell im Rahmen des „Scaled Agile Framework“ ein Modell zur Integration von agilen Methoden im gesamten Unternehmen. Das Framework, welches speziell für Softwareunternehmen entwickelt ist, geht zunächst davon aus, dass langfristig jedes Projekt agil durchgeführt wird [13, 14]. Allerdings bietet Leffingwell zusätzlich Ansätze für hybride Strukturen - zum Beispiel für Unternehmen, welche lediglich Teilprojekte zur Softwareentwicklung ausführen (z. B Infotainment im Automobil) - an. Dazu unterscheidet er drei Abhängigkeitsgrade von klassisch und agil durchgeführten Projekten, wobei nachfolgend exemplarisch von einer häufig anzutreffenden mittleren Abhängigkeit der Projekte ausgegangen wird. Wie nachfolgend dargestellt, werden hierbei zu den jeweils produktrelevanten Meilensteinen der klassischen Projektplanung (in einem Programmkontext) Abstimmungstermine initiiert, um die harmonische Integration aus Komponenten klassischer und agiler Vorgehensweise sicherzustellen. Diese Abstimmungstermine finden auf Portfolio-/ Programmebene statt und werden seitens agiler Teams von dem jeweiligen RTE vertreten. Iterationsergebnisse sollten nach Möglichkeit an diese Abstimmungsrunden angeglichen werden. Da großen Projektportfolio ein enormer Bedarf an Kontrollkapazität im PPM. Erfolgt die Entwicklung der Teillösungen zudem in unterschiedlichen Release-Zyklen, so muss praktisch dauernd ein Projekt aus dem Portfolio bewertet werden. Um hier das PPM zu entlasten und gleichzeitig eine übergeordnete Instanz für die jeweiligen agilen Teams eines Unternehmens zur Verfügung zu stellen, bildet Leffingwell innerhalb des von ihm entwickelten „Scaled Agile Framework“ für jedes agile Vorgehen einen sogenannten „Agile Release Train“. Dieser Release Train stellt den Fortschritt des untergeordneten agil ausgeführten Projekts fest und berichtet diesen zu definierten Zeitpunkten an das PPM. So wird die Flexibilität der Teams gewahrt, Teillösungen jederzeit zu veröffentlichen und innerhalb des Release Train vorstellen zu können. Zudem werden überfüllte Release- Termine zur Vorstellung sämtlicher Funktionen an das PPM vermieden. Das macht bspw. bei Softwareprodukten Sinn, da hier unzählige Programmzeilen getestet und abgenommen werden müssen. Ein Abstimmen mit dem übergeordneten PPM erfolgt lediglich zu ausgewählten Terminen (ca. 8-12 Wochen). Hier werden zwar auch Teillösungen besprochen, allerdings in aggregierter Form durch einen sogenannten „Release Train Engineer“ (RTE), welcher die Informationsfunktion ausübt. Der Release Train ist somit nicht als Entscheider, sondern als berichtende Projektinstanz zu verstehen, die entscheidungsrelevante Themen für das PPM filtert und eskaliert. So erfolgen strategische Vorgaben weiterhin zenchigen Zyklen fertiggestellt) notwendig. Die etablierte Planung in Jahresabschnitten muss an agile Vorgehenszyklen, die am Ende eines jeden Inkrements bewertbare Teilergebnisse liefern, angepasst werden. Dieses kann im PPM sowohl die Transparenz wie auch die Bewertungsgenauigkeit erhöhen. Im Gegensatz zu klassischen Wasserfallmodellen wird bei agilen Methoden ein Konzeptplan „rollierend“ nach jedem Sprint konkretisiert bzw. angepasst, um hierdurch der Veränderlichkeit von Anforderungen gerecht zu werden. So rät bspw. Leffingwell zu einer groben Initialplanung „Lightweight, epic-only business cases“, die durch den Erkenntniszugewinn aus Iterationen weiter detailliert wird [13]. Das PPM plant und steuert nicht zuletzt die Harmonisierung der Projektlandschaft und das Angleichen von Portfolio- und Unternehmensstrategie. So herrscht weitgehend Einigkeit darüber, dass vor allem hier große Herausforderungen bei der Implementierung von agilen Vorgehensmodellen entstehen, da die gewünschte Autonomie und Flexibilität von Teams im Widerspruch zu Restriktionen aus Unternehmensstrategie und angrenzenden Projekten steht. Zudem erschwert die iterative Vorgehensweise ohne einheitliche Meilensteine eine projektübergreifend harmonisierte Jahresplanung („Roadmap“). Um sicherzustellen, dass agile Teams autonom entscheiden können, diese Entscheidungen jedoch gleichzeitig mit anderen Projekten und der Unternehmensstrategie harmonieren, ist das einheitliche Verständnis der Teams über die langfristigen Unternehmensziele wichtig, da Verantwortlichkeiten tendenziell in wissensintensive Teams verlagert werden und hierarchische Vorgaben aus übergeordneten Instanzen entfallen. Zudem wird das Erstellen der Roadmap zur Steuerung von Portfolios erschwert. So muss die iterative Entwicklung von Teillösungen in mehrwöchigen Zyklen an standardisierte Projekt- Roadmaps aus Wasserfallmodellen angeglichen werden, gleichzeitig darf den Teams jedoch nicht die Flexibilität entzogen werden, Teilergebnisse jederzeit zu veröffentlichen. Die Einführung des nachfolgend beschriebenen „Agile Release Train“ nach Leffingwell soll dieses Spannungsfeld lösen. Wie bereits angesprochen, ermöglichen agile Modelle durch das iterative Erzeugen von Teillösungen eine Bewertung von Ressourcenverbrauch sowie Projektnutzen und -risiko am Ende eines jeden Inkrements. Sollte dieses zentral vom PPM erfolgen, entsteht bei einem entsprechend Abb. 3: Agile Release Trains zur Vereinheitlichung von Release- und Planungsrunden; vereinfachte Darstelung am Beispiel Scrum PM-aktuell_02-2017_InhaltV4.indd 54 10.04.17 10: 33 WISSEN 55 projektManagementaktuell | AUSGABE 2.2017 wird ein Unterbrechen des Entwicklungsflusses vermieden und Störeinflüsse reduziert. Vähäniitty et al. schlagen vor, strategische „Portfolio Backlogs“ des PPM zur Förderung von Transparenz einzuführen. Diese bilden ähnlich der bei Scrum verwendeten Product Backlogs die Anforderungen sowie eine Prioritätenrangfolge ab, allerdings auf Portfolioebene. Hieraus werden anschließend die Product Backlogs und folgend die Sprint Tasks für Teams abgeleitet. Das Portfolio-Backlog wird zudem zur strategischen Ausrichtung des Release Trains genutzt [20]. Da die verbreitete hierarchische Denkweise infrage gestellt wird, stellt die Unternehmenskultur die größte Herausforderung bei der Etablierung agiler Methoden dar. So ist das PPM folglich nicht nur selbst von Veränderungen betroffen, sondern zudem auf einen Kultur- und Wertewandel des Unternehmens angewiesen. Beispielsweise kann die flexible Ressourcenallokation nur erfolgen, wenn das Unternehmen eine flexible Aufgabengestaltung ermöglicht. Was in kleinen, stark vernetzten Unternehmen keine Umstände bereitet, stellt vor allem große, etablierte Unternehmen vor Herausforderungen im Bereich der sachgerechten Ressourcen-, aber auch Kostenallokation. So müssen Anreize geschaffen werden, um interne „Kompetenzgerangel“ und Ressourcenkonflikte abzuschwächen. Stettina/ Hörz berichten in ihrer Studie zudem von fehlendem Methodenvertrauen der Projektmitarbeiter und -manager, was zu einem Mangel an Hingabe führt [18]. Vertrauen kann durch das Schulen entsprechender Methoden entstehen, was wiederum durch das PMO sicherzustellen ist. Rolle des Projekt-Management- Office (PMO) Dementsprechend wandelt sich neben dem PPM auch das Aufgabengebiet des PMO. Ist dieses in Wasserfallmodellen oft für die Definition und Ausführung eines einheitlichen Projektmanagementstandards verantwortlich, wird die Rolle in agilen Teams z. B. durch den Scrum Master wahrgenommen. Klassischerweise ist das PMO zudem häufig für das Multiprojekt-Reporting zuständig, das bei agilen Methoden durch den zuvor beschriebenen Release Train erfolgen kann. Um folglich Kompetenzkonflikten zu entgehen, sollten Aufgaben neu zugeordnet werden. Leffingwell schlägt hierzu vor, den RTE in das PMO zu integrieren [13]. Hierdurch verbleiben können Teams Teillösungen jederzeit innerhalb des Release Train veröffentlichen. Eine Eskalation auf PPM-Ebene erfolgt somit nur zu den definierten Meilensteinen und gebündelt durch den RTE. Neben diesem „Alignment“ der Projekte genießen auch Pläne und das Reporting einen veränderten Stellenwert. Während der Plan klassischerweise die übergeordnete Leitlinie ist, stellt er im agilen Vorgehen ein Werkzeug zur Zielerreichung dar, das selbst ebenfalls permanenter Veränderung unterliegt. Dieses führt bei der Initialplanung zu Konzeptplänen, die im Laufe der Projekte durch die Anforderungsspezifizierung weiter ausgestaltet werden. Entscheidend für die Bewertung von Plänen agiler Teams ist somit die zuvor erwähnte Projektentwicklung. Auch die Berichterstattung während der Projektlaufzeit wird eher zweckorientiert und prägnant gestaltet, da der Fokus auf dem Wertzuwachs des Produktes und nicht auf der Erstellung einer Dokumentation liegt. Gerade in Softwareprojekten ist es zudem üblich, kommentierte Programmzeilen als Dokumentationsplattform zu nutzen. Das einwandfreie Teilergebnis der Iteration soll für sich sprechen und so Dokumentationsorgane ersetzen. Der abzunehmende Meilenstein des PPM ist folglich nicht, wie bei klassischen Methoden, eine ausgiebige Dokumentation, sondern das marktfähige Teilprodukt. Da der kontinuierliche Iterationsprozess zentral für das agile Vorgehen ist, besitzen Meilensteine zudem eine veränderte Bedeutung. Wird klassischerweise ein Projekt erst fortgeführt, wenn ein Meilenstein erfolgreich abgenommen ist, sollten agile Teams weitere entwickeln, bis das Projekt gestoppt wird. So der RTE jedoch jederzeit über den Fortschritt seines Teams im Bilde ist, können Iterationen auch im Sinne der Autonomie und Flexibilität unabhängig von Abstimmungsterminen dem Team überlassen werden. Entscheidend ist, dass der RTE als Informationsorgan jederzeit den Status kennt und diesen komprimiert weiterleiten kann. Da das iterative Vorgehen in der Regel eine höhere Anpassungsgeschwindigkeit an veränderte Rahmenbedingungen hat als klassische Wasserfallmodelle, werden hier zusätzliche Anpassungszeiträume zur Integration der Teilprodukte eingeplant. Zudem dient eine ausgiebige Test- und Einführungsphase als abschließender Abstimmzeitraum [1, 14]. Hierzu plant Leffingwell zusätzlich eine Zeitspanne zwischen geplanter und tatsächlicher Einführung - ein Ansatz, der aus der Philosophie des Critical Chain Managements bekannt ist [7]. Da die Projektteams der jeweiligen Vorgehensweise auf die Informationsweitergabe angewiesen sind, ist die zielgerichtete Kommunikation von hoher Bedeutung. Diese muss wiederum durch die Portfolioebene bzw. das Projekt-Management-Office (PMO) sichergestellt werden. Zusammenfassend werden in diesem Modell die Parallelprojekte durch vordefinierte Meilensteine koordiniert. Der RTE, der idealerweise zwischen PPM und agilem Team agiert, besitzt das Wissen über den Projektstatus und stimmt das Vorgehen mit der Leitung des klassischen Projekts sowie dem PPM ab. Bei der Anpassung von Teillösungen sollte vor allem die Flexibilität agiler Teams genutzt werden, anstatt Änderungen in Wasserfallprojekten anzustreben. Zur Aufrechterhaltung des agilen Kerngedankens Abb. 4: Synchronisierte Projektsteuerung von korrelierenden klassischen und agilen Vorgehensmodellen; vereinfachte Darstellung am Beispiel Scrum (vgl. [13]) PM-aktuell_02-2017_InhaltV4.indd 55 10.04.17 10: 33 projektManagementaktuell | AUSGABE 2.2017 56 WISSEN gestellt werden sollte. Neben Methoden aus klassischen Projektmanagementstandards (z. B. PM3 oder PMBoK) muss somit das explizit agile Vorgehen etabliert werden. Weiterhin können so Hemmnisse des Managements und der Projektmitglieder abgebaut werden, was derzeit eine große Herausforderung bei der Etablierung agiler Vorgehensmodelle darstellt. Daneben sehen Unternehmen außerdem eine Coaching-Funktion des PMO, wobei die korrekte Ausführung von Methoden sowie die Ressourcenallokation unterstützt werden kann. Wichtig ist insgesamt die Integration agiler Rollen in PPM und PMO, um so Synergien zu nutzen und die Akzeptanz zu fördern. Unternehmen werden auch zukünftig nicht vor einer „Schwarz-weiß“-Entscheidung zwischen klassischen oder agilen Methoden stehen. Vielmehr gewinnen hybride Projektansätze im Zuge von Marktentwicklungen wie der Industrie 4.0 weiter an Bedeutung. Zudem können agile Vorgehensmodelle nicht in jedem Projekt konsequent durchgesetzt werden, da zum Beispiel eine räumliche Entfernung der Projektmitglieder herrscht oder keine täglichen Besprechungen möglich sind. So lohnt es sich, skalierbare Modelle der Softwareentwicklung wie das „Scaled Agile Framework“ nach Leffingwell in Betracht zu ziehen. Zwar unterstellt dieses eine rein agile Portfoliostruktur, jedoch können Erkenntnisse wie zum Beispiel der RTE durchaus in hybride Strukturen überführt werden. Letztendlich wird das Etablieren einer „agilen Betriebskultur“ in hierarchischen Unternehmensformen auch zukünftig die wohl größte Herausforderung darstellen.  Literatur [1] Adzic, G.: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. London 2009 [2] Beck, Kent, et al.: Manifesto for Agile Software Development. http: / / agilemanifesto.org/ iso/ de/ manifesto.html [3] Bernardes, E./ Hanna, M.: A theoretical review of flexibility, agility and responsiveness in the operations management literature. In: International Journal of Operations & Production Management, Ausgabe 01/ 2009, S. 30-53 [4] Brown, J. L./ Agnew, N.: Corporate Agility. In: Business Horizons, Ausgabe 25, 1982, S. 29-33 [5] Feldmüller, D./ Sticherling, N.: Agile Methoden in der Entwicklung mechatronischer Probei Bedarf mit zusätzlichen Ressourcen - zum Beispiel durch Mitarbeiter oder Weiterbildung - ausgestattet werden. Zudem verändert sich die Art der Dokumentation von Projektergebnissen. Waren bislang ausführliche Projekt-Reviews gefordert, fallen diese bei agilen Methoden eher kompakt aus, da ein funktionsfähiges Teilergebnis für sich selbst spricht. Als „Gatekeeper“ kann das PMO außerdem dabei unterstützen, die Arbeitsbelastung durch neue Projekte zu begrenzen. Unter Anwendern agiler Methoden wird teilweise die Notwendigkeit von PMOs infrage gestellt, da Scrum Master bzw. Product Owner einzelne Aufgabenbereiche ersetzen. Vorherige Ausführungen deuten jedoch vielmehr auf eine Erweiterung von Aufgaben hin. Zudem werden agile Rollen, wie der RTE, in das PMO integriert, um so Synergien zwischen klassischem und agilem Vorgehen zu nutzen. Fazit und Ausblick Obwohl das agile Manifest durch das Infragestellen bewährter Methoden zunächst als „Kampfansage“ an klassische Wasserfallmodelle (in der Softwareentwicklung) gedacht war, koexistiert das agile Vorgehen durch die Digitalisierung zunehmend in der Projektlandschaft von Unternehmen. In diesem Zuge wird das PPM teilweise in seinen Aufgabenbereichen erweitert, gleichzeitig verlagern sich Kompetenzen. So wird in vorliegendem Artikel der Vorschlag angeboten, einen sogenannten „Agile Release Train“ als zusätzliche Ebene zwischen agilen Teams und dem Management zu schaffen, wobei der verantwortliche RTE stark mit dem PMO vernetzt ist. Das wahrt einerseits die Flexibilität von agilen Teams, Iterationsergebnisse jederzeit veröffentlichen zu können, andererseits wird das PPM jedoch nicht mit sämtlichen Produktvorstellungen und -bewertungen kapazitiv überlastet. Der RTE, der jeweils für ein agil durchgeführtes Projekt zuständig ist, aggregiert Ergebnisse und Entscheidungen bis zu vordefinierten Terminen und eskaliert diese dann auf PPM-Ebene, wo strategische Entscheidungen verbleiben. Hierdurch wird die für agile Methoden wichtige Flexibilität auf Teamebene beibehalten und zugleich ein standardisiertes Release-Management auf höherer Ebene erreicht „highly aligned, loosely coupled“. Der Neuheitsgrad agiler Methoden verlangt zudem ein Schulungs- und Weiterbildungskonzept, welches durch das PMO zur Verfügung klassische Aufgaben im PMO, das so den Überblick auf die Projektlandschaft wahrt. Da agile Projekte in der Regel eine hohe fachliche und methodische Kompetenz erfordern, kann das PMO von der rein kontrollierenden und unterstützenden Rolle um eine Beraterbzw. Coaching-Funktion erweitert werden. Durch den Neuheitsgrad und die resultierende Unkenntnis von Unternehmen bestehen zusätzlich oftmals Hemmnisse gegenüber agiler Methoden. So sollte das PMO gerade hier einen einheitlichen agilen Standard durch Zertifizierungen und ein Schulungskonzept schaffen. Zwar werden zurzeit bereits international verbreitete Standards wie das PMBoK, die IPMA Competence Baseline oder PRINCE2 geschult, diese gehen jedoch davon aus, dass Anforderungen bereits zu Projektbeginn vereinbart werden können. Diese klassische Sicht muss durch Agilität erweitert werden. Auch Komus zeigt in seiner Studie zu agilen PMOs, dass im Gegensatz zu klassischen Modellen zunehmend Coaching-Funktionen ausgeübt werden [12]. Zwar ist die Studie aufgrund der geringen Stichprobenzahl (n = 32) nicht repräsentativ, da agile PMOs jedoch noch nicht verbreitet sind, zeigt sie erste Tendenzen und Versuchsmodelle von Unternehmen. Die Aufgabe der Methodenführerschaft und des Coachings wird somit eine zentrale Aufgabe zur Etablierung agiler Vorgehensmodelle. Das PMO sorgt für einen einheitlichen, unternehmensweiten Standard und fördert die Methodenakzeptanz. Letztere gewinnt außerdem an Bedeutung, wenn agile Methoden „bottom-up“, aus einzelnen Teams heraus, in Unternehmen etabliert werden und das Management zunächst noch überzeugt werden muss. Daneben sollte das PMO ein standardisiertes Reporting für agile Methoden einrichten, da wie zuvor erwähnt häufig das funktionsfähige Produkt als Dokumentation dient. Zudem verwenden Teams oftmals Whiteboards als transparentes Kommunikationsmedium für den Statusreport und Entscheidungen. Leffingwell schlägt hierzu vor, dass das PMO für ein Reporting aktiv auf die Teams zugeht, um so die Verschiebung der Führungskompetenz zu verdeutlichen [13]. Hierzu ist allerdings der angesprochene Kulturwandel entscheidend, da die Verschiebung von Führungskompetenz zeitgleich einen gefühlten Machtverlust bedeuten kann. Zusammenfassend ermöglicht das Überblicken der Projektlandschaft eine Beraterbzw. Coaching-Funktion. So können Teams gesteuert und PM-aktuell_02-2017_InhaltV4.indd 56 10.04.17 10: 33 WISSEN 57 projektManagementaktuell | AUSGABE 2.2017 umfassen u. a. das Multiprojektmanagement (Ko-Leitung der GPM Fachgruppe) sowie hybride PM-Ansätze. Anschriften der Autoren: THM Technische Hochschule Mittelhessen, Wilhelm-Leuschner- Straße 13, 61169 Friedberg, Tel.: 0 60 31/ 6 04-57 63, E-Mail: Claus.Huesselmann@wi.thm. de bzw. Philip.Mueller@porsche.de [20] Vähäniitty, J., et al.: Towards Agile Product and Portfolio Management. Helsinki 2012 [21] Yusuf, Y.: Agile manufacturing: The drivers, concepts and attributes. In: International Journal of Production Economics, Ausgabe 62, 1-2/ 1999, S. 33-43 Schlagwörter agile Methoden, Projekt-Management-Office, Projektportfoliomanagement, Scrum, Wasserfallmodell Kompetenzelemente der ICB 4.0 1.02 Governance, Strukturen und Prozesse, 2.06 Teamarbeit, 3.02 Anforderungen, Ziele und Nutzen, 3.03 Leistungsumfang und Lieferobjekte, 3.04 Ablauf und Termine, 3.10 Planung und Steuerung Autoren Philip-Jerome Müller, M.Sc. des Wirtschaftsingenieurwesens der Technischen Hochschule Mittelhessen, ist im Bereich Projektplanung und Ressourcenmanagement der Dr. Ing. h.c. F. Porsche AG tätig. Über seine Tätigkeit in der Projektplanung hinaus entwickelt er Softwareanwendungen zur Analyse von Fahrzeugkinematik und -performance im Motorsport. Neben Projekten in Deutschland arbeitete er hierzu auch in Nordamerika, wo er den Einsatz agiler PM-Ansätze kennenlernte. Prof. Dr. rer. oec. Claus Hüsselmann ist Professor für Prozess- und Projektmanagement im Fachbereich Wirtschaftsingenieurwesen der Technischen Hochschule Mittelhessen (THM). Nach dem Studium der Technomathematik wirkte er zunächst als leitender Entwickler in einem SAP-Systemhaus. Bei Scheer verantwortete er anschließend 20 Jahre lang mehrere (Groß-) Projekte, den Project Operations-Bereich für das Consulting-Geschäft sowie als Partner den Beratungsgeschäftsbereich Project Performance Management. 2012-2015 war er als Vorstand der GPM engagiert. Seine Schwerpunkte dukte. In: projektManagement aktuell 2/ 2016, S. 14-22 [6] Ganguly, A., et al.: Evaluating agility in corporate enterprises. In: International Journal of Production Economics, Ausgabe 118, 2/ 2009, S. 410-423 [7] Goldratt, E.: Critical Chain. North River Press, Great Barrington 1997 [8] Gunasekaran, A./ Yusuf, Y.: Agile manufacturing: A taxonomy of strategic and technical imperatives. In: International Journal of Production Research, 40, Juni 2002, S. 1357-1385 [9] Hüsselmann, C./ Seidl, J.: Ausblick - Künftige Herausforderungen. In: Hüsselmann/ Seidl (Hrsg.): Multiprojektmanagement: Herausforderungen und Best Practice. 1. Aufl., Düsseldorf 2015, S. 343-351 [10] Komus, A.: Projektportfoliomanagement mit agilen Methoden - Neue Chancen, neue Herausforderungen. Vortrag auf 9. Jahrestagung IT Projekt Portfolio Management, Berlin 2016 [11] Komus, A.: Scrum & Co.: Sehr erfolgreich - aber selten die reine Lehre. Neuauflage einer Studie zu agilen Methoden. In: projektManagement aktuell 2/ 2014, S. 40-43 [12] Komus, A.: Studie „Agiles PMO“ - Studienbericht für Teilnehmer. Koblenz 2016 [13] Leffingwell, D.: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston 2011 [14] Leffingwell, D.: Technical Strategies for Agile and Waterfall Interoperability at Scale. www.scaledagileframework.com/ technical-stra tegies-for-agile-and-waterfall-interoperabilityat-scale/ [15] Netflix (Hrsg.): Netflix Culture: Freedom & Responsibility. Los Gatos 2009 [16] Opelt, A., et al.: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt- Verträge. 2. Auflage, Hanser 2014 [17] Schwaber, K.: SCRUM Development Process. In: Business Object Design and Implementation. OOPSLA 1995 Workshop Proceedings. 1997, S. 117-134, übersetzt [18] Stettina, C. J./ Hörz, J.: Agile portfolio management: An empirical perspective on the practice in use. In: International Journal of Project Management, 33, 2015, S. 140-152 [19] Takeuchi, H./ Nonaka, I.: The new new product development game - Stop running the relay race and take up rugby. In: Harvard Business Review, Januar-Februar, Boston 1986, S. 137-146 Ressourcenplanung, die funktioniert Projektportfolio-Management Ressourcenplanung Zeit-/ Leistungserfassung Kosten-Controlling Ihre Testinstallation in der Cloud in 1 Stunde für Sie bereit Scheuring AG CH-4313 Möhlin / +41 61 853 01 54 www.scheuring.ch / info@scheuring.ch www.ressolution.ch Anzeige PM-aktuell_02-2017_InhaltV4.indd 57 10.04.17 10: 33