Hier lernen Sie, wann und wie Sie den hybriden Ansatz am besten nutzen. Ein hybrides Projektmanagement-Beispiel zeigt zudem die Anwendung in der Praxis.

Folgende Kapitel warten auf Sie:

• Hybrides Projektmanagement Definition
• Vorteile hybrides Projektmanagement
• Rollen und Prozesse im klassischen Projektlebenszyklus
• Methoden im agilen Projektmanagement
• Unterschiede zwischen agilen und klassischen Methoden (Tabelle)
• Gemeinsamkeiten zwischen agilen und klassischen Methoden
• Hybride Vorgehensmodelle im Projektmanagement
  • Hybrid: paralleler Einsatz von Methoden
  • Hybrid: vermischter Einsatz von Methoden
• Multiprojektmanagement – agil, klassisch oder hybrid?
• Hybrides Projektmanagement Beispiele
• Tipps zur Einführung von hybridem Projektmanagement (Checkliste)
• Zusammenfassung und Empfehlung

Legen wir los mit einer kurzen Definition von hybridem Projektmanagement.

Hybrides Projektmanagement Definition

„Hybrid“ bedeutet eine Kombination oder Vermischung. Demnach ist hybrides Projektmanagement die Kombination von PM-Methoden. Dabei kommen sowohl die exakten Planungsansätze aus der klassischen PM-Welt als auch die flexiblen Reaktionsmöglichkeiten aus der agilen Welt nach Bedarf zum Einsatz. So lässt sich ggf. der Projektnutzen erhöhen, ein besseres Ergebnis erzielen und mit geringen Kosten schneller das Ziel erreichen.

Seit Jahren spielt Software in immer mehr Hardware-Produkten eine zunehmend wichtige Rolle. Agile Methoden mit ihrem iterativen Vorgehen und der flexiblen Zielgestaltung von Sprint zu Sprint sind auf dem Vormarsch. Und das lässt sich mit den klassischen Methoden verbinden.

Ein solches hybrides Vorgehen, also agile und klassische Vorgehensmodelle im Zusammenspiel, kann z.B. die Integration klassischer Methoden nach PMI mit agilen nach Scrum oder den Einsatz diverser Elemente unterschiedlicher Methoden bedeuten.

Vorteile hybrides Projektmanagement

Durch die Kombination von klassischen und agilen Bestandteilen können Sie die jeweils besten Aspekte aus beiden Welten nutzen. Daraus ergibt sich die Chance für die folgenden Vorteile von hybridem Projektmanagement Sie können ggf.

• den Projektnutzen erhöhen,
• ein besseres Ergebnis erzielen und
• Ihr Projektziel schneller bzw. mit geringen Kosten erreichen.

Hinweis: Die Studie „The Drivers of Agility“ des PMI kommt zu dem Ergebnis, dass Unternehmen mit einer hohen Agilität deutlich mehr Projekte erfolgreich abschließen als andere. Auf die genutzte Projektmanagement-Methode bezogen sind das bei den Unternehmen mit hoher Agilität 68% mit Agile, 71% mit Predictive und 72% mit Hybrid. Bei Unternehmen mit einer niedrigen Agilität sind es nur 41% mit Agile, 45% mit Predictive und 51% mit Hybrid.

Jetzt vergleichen wir zuerst die klassische Vorgehensweise im Projektmanagement mit den agilen Ansätzen.

Rollen und Prozesse im klassischen Projektlebenszyklus

Im klassischen Projektmanagement liefern Ihnen das Konzept und die darauf basierende Spezifikation die Basis für die Umsetzung. Erst am Ende geht es um die Abnahme und die Nutzung des erstellten Gesamtergebnisses. Die beteiligten Rollen sind:

• Projektsponsoren
• ein:e Projektleiter:in
• diverse Teamleiter:innen
• deren Mitarbeitende
• ein Project Management Office (PMO)

Der klassische Prozess im Projektmanagement kann etwa so aussehen:

1. Die Projektsponsoren definieren das Vorhaben und die zu erreichenden Ziele.
2. Im Prozess des Projektportfoliomanagement wird das neue Projekt priorisiert.
3. Die Teamleitenden der Projektbeteiligten müssen zuvor für eine valide Kapazitätsplanung auf Portfolioebene die Voraussetzung schaffen, damit die Ressourcenzuordnung fundiert erfolgen kann. Dabei werden die Teammitglieder für jedes Projekt immer wieder neu zusammengestellt.
4. Die Detailplanung erfolgt in Gantt-Charts und mit Meilensteintrendanalysen.
5. Bei Verschiebungen und inhaltlichen Änderungen steht der geplante Endtermin mit dem vorgegebenen Ziel. Teammitglieder werden ggf. aus anderen Projekten abgezogen.
6. Im regelmäßigen Projektportfoliomeeting wird mittels Projektstatusbericht für ausgewählte Projekte dargestellt, wie weit die bestellten Lieferungen schon fortgeschritten sind.
7. Am Ende steht die Abnahme, in der das gelieferte Ergebnis mit der Beauftragung verglichen wird. Je nach Umstand werden Mängel aufgenommen und entsprechend nachgearbeitet.
8. In der Abschlusssitzung werden die Lessons Learned für kommende Vorhaben dieser Art festgehalten.

Vielleicht fragen Sie sich jetzt, was daran besser gemacht werden könnte? Ziele zu erreichen und geeignete Ressourcen dafür einzuteilen, ist doch erforderlich?

Ja, aber das geht nur, wenn die Ziele so klar sind und auch genauso erreicht werden müssen. Nur dann ist das klassische Vorgehen im Projektmanagement genau richtig.

Lesetipp: Projektmanagement-Methoden im Vergleich – klassisch, agil oder hybrid?

Agile Projektmanagement-Methoden

Agile Methoden hingegen sind dann passend, wenn Sie:

• Ergebnisse liefern müssen, die auf verschiedenen Wegen erreicht werden können,
• im Laufe der Zeit neue Erkenntnisse und Technologien verfügbar werden, die im Sinne einer besseren Lösung auch einfließen sollen, oder
• es gar nicht möglich ist, ein so genaues Bild der geforderten Lieferung vorab zu spezifizieren, weil die Beteiligten dies nicht können.

Vor allem bei der Software-Produktentwicklung ist das Vorgehen heute meist agil. Immer mehr kommt dieser Ansatz aber auch in anderen hochtechnologischen und komplexen Umgebungen zum Einsatz.

Die Rollen im agilen Projektmanagement (wie etwa bei Scrum) sind die folgenden:

• Product Owner: entscheidet alles zum Produkt, priorisiert und pflegt das Backlog und ist permanent erreichbar
• Scrum Master: managt den Prozess, räumt Hindernisse aus dem Weg

Lesetipp: Was ist ein Product Owner und was macht er in agilen Teams?

Wichtigste Merkmale des agilen Projektmanagements sind:

1. 1. Kick-off-Meetings gibt es in agilen Umgebungen nicht mehr zwingend.
   2. Agile Teams sind so weit wie möglich selbstorganisiert oder auch selbstverwaltend.
   3. Die Teams schätzen aus ihrer eigenen Erfahrung heraus Aufwände ab (zu Beginn grob, feiner im Projektverlauf).
   4. Die Fortentwicklung läuft oft parallel zum Einsatz des bisherigen Produkts durch die User.
   5. Das Entwicklungsteam bespricht täglich den Fortschritt im Hinblick auf das Sprint-Ziel.
   6. Regelmäßige Sprint-Planungen, Reviews und Retrospektiven sind Pflicht.
   7. Vorgaben gibt es nur im Product Backlog bzw. Sprint Backlog als Untermenge davon für jeden Sprint. Wenn etwas nicht im Backlog zu finden ist, wird es auch nicht behandelt.
   8. Zur Kommunikation mit den Stakeholdern über die Reviews hinaus gibt es öffentliche Boards mit Backlog und Sprint- oder Produkt-Burndown-Charts. Berichte über Termine, Kosten und Status im klassischen Sinne sind deshalb bestenfalls überflüssig.
   9. Feste Produkt- und Projektteams sowie die feste Taktung vereinfachen die allgemeine Planung und den Mitarbeiterwechsel zwischen Projekten erheblich.

Lesetipp: Agiles Projektmanagement – Grundlagen und Methoden für Einsteiger

Unterschiede zwischen agilen und klassischen Methoden

Die wichtigsten Unterschiede zwischen klassischem und agilem Projektmanagement lassen sich tabellarisch grob zusammenfassen wie folgt:

Gemeinsamkeiten zwischen agilen und klassischen Methoden

Die Gemeinsamkeiten zwischen agilen und klassischen Projektmanagement-Methoden sind folgende:

• Die Arbeit findet in Teams statt.
• Die Vorhaben, die sie umsetzen, sind einzigartig (im Gegensatz zu wiederkehrenden Abläufen, etwa im betrieblichen Tagesgeschäft eines Unternehmens).
• Es gibt Stakeholder mit Anforderungen und Wünschen, die es zu verstehen und erfüllen gilt.
• Vorhandene Ressourcen werden effektiv und effizient eingesetzt, um maximalen Nutzen aus dem Vorhaben zu gewinnen.
• Methodenkenntnis und -vielfalt aus diversen Bereichen können helfen, fallbasierte Lösungen für Probleme zu finden.

Seminartipp: Besuchen Sie unser Seminar Hybrides Projektmanagement und kommen Sie sicher vom klassischen ins teilweise agile Projekt- & Portfoliomanagement.

Hybride Vorgehensmodelle im Projektmanagement

Jetzt kennen Sie die wichtigsten Unterschiede und Gemeinsamkeiten zwischen klassischem um agilem Projektmanagement. Wie können Sie diese unterschiedlichen Welten nun für hybrides Projektmanagement verbinden?

Es gibt mehrere hybride Vorgehensmodelle, die Sie anwenden können.

1. Paralleler Einsatz von klassischen und agilen Methoden

Das hybride Vorgehensmodell des parallelen Einsatzes der Methodenmischung in einzelnen Bereichen des Unternehmens zeichnet sich wie folgt aus:

• Manche Bereiche eines Unternehmens arbeiten immer klassisch (z.B. das Consulting), andere immer agil (z.B. die Softwareentwicklung)
• Einige Projekte laufen klassisch ab, andere agil
• Einzelne Teile eines Projekts werden klassisch durchgeführt, andere Teile agil
• Die Grobplanung in Projekten findet klassisch statt und die Detailplanung dann agil

Unser Tipp: Dass manche Bereiche eines Unternehmens klassisch und andere agil arbeiten, ist eine der häufigsten und reibungslosesten Umsetzungen von hybridem Projektmanagement. Hier haben Sie normalerweise eine hohe Prozessstabilität.

---

2. Vermischter Einsatz von klassischen und agilen Methoden

Die hybriden Vorgehensmodelle des vermischten Einsatzes der Methoden in demselben Projekt können, je nach Schwerpunkt – vorrangig klassisch oder vorrangig agil, wie folgt aussehen:

• Klassische Projekte:
  • Engere Abstimmung mit Nutzer:innen und häufigere, nutzbare Zwischenergebnisse
  • Regelmäßige Stand-up-Meetings zum Fortschritt (muss nicht täglich sein – einmal pro Woche ist schon ein guter Anfang)
  • Planung in Phasen und Meilensteinen übergeordnet zu Sprints
  • Retrospektiven (Lessons Learned) nach jedem Statusbericht-Meeting, nicht erst am Projektende
  • Fixes Team für die gesamte Laufzeit des Projekts
  • Backlog pro Phase als Spezifikation
  • Projektplanung synchron mit Sprint-Längen

• Agile Projekte:
  • Scrum Master sind gleichzeitig auch Projektleitende im klassischeren Sinne
  • Ein Backlog wird für jede Projektphase angelegt, statt als Spezifikation fürs Gesamtprodukt
  • Die Projektplanung wird mit den Sprint-Längen synchronisiert
  • Planen in Phasen und Meilensteinen – den Sprints übergeordnet und ergänzend dazu
  • Es gibt weiterhin Statusberichte und Meilensteintrend-Analysen fürs Management und die übrigen relevanten Stakeholder

(Die beiden letzten Beispiele werden übrigens von vielen Experten der agilen Welt nicht so gerne gesehen, da sie die agilen Grundprinzipien verwässern können.)

Wie könnte das in einzelnen Projekten genauer aussehen? Zum Beispiel könnten in einem hybriden Projekt die folgenden Dokumente und Methoden zum Einsatz kommen:

Die Zutaten für ein “hybrides Rahmenwerk” in einem konkreten Projekt lassen sich z.B. anhand des folgenden Spektrums auswählen:

Mögliche Risiken und Abstriche der Zutaten des „hybriden Rahmenwerks“ sind:

• Arbeitsrhythmen: zu lang: Bezug zur Realität verlieren,
  zu kurz: ins Chaos verfallen
• Arbeitsmanagement-Tool: zu schwergewichtig: schwer zu handhaben,
  zu leicht: unklare Planung
• Langfristige Planung und Terminierung: zu detailliert: schwer zu integrierende Änderung,
  zu wenige Details: unklare Richtung und Ziele
• Schätzung: absolute Einheiten: möglicher negativer psychologischer Effekt,
  relative Größe: Bewusstsein muss vorhanden sein
• Prozessverbesserung: Lessons Learned am Projektende: zu spät für aktuelles Projekt,
  Iterationsretrospektiven: benötigen gute Moderation
• Fortschrittsüberwachung und Statusreporting: Earned Value Management: benötigt verlässliche Daten, Expertise und die richtigen Tools,
  agile Metriken und Visualisierungen: keine integrierte Sicht auf Umfang / Zeitplan / Kosten
• Auftragsvergabe und Beschaffung: Festpreisverträge: Umfangsänderungen erschwert,
  iterative Vertragsmodelle: kann schwer zu verhandeln sein
• Einbindung und Feedback von Stakeholdern: geringe Häufigkeit von Feedback: harte Niederlage gegenüber Stakeholdern,
  hohes Stakeholder-Engagement: schwer zu gewinnen
• Risikomanagement: dedizierte Risikoanalyse: zeitaufwendig, basierend auf Annahmen,
  Risikoentdeckung durch iteratives Arbeiten: große Risiken können zu spät erkannt werden
• Anforderungen: im Vorfeld definiert: kann sich als falsch oder missverstanden erweisen,
  dynamisch entdeckt und just-in-time im Detail verfeinern: erfordert Team- und Stakeholder-Flexibilität
• Kapazitätsplanung: dedizierte Ressourcenplanung: benötigt solide Ressourcenmanagement-Methoden,
  iterationsbasierte Kapazitätsplanung: arbeitet nur mit einem festen Team und kann zu kurzfristig sein, um Kapazitätsprobleme vorherzusehen
• Teamrollen: dedizierte Projektteamrollen: kann zu viel administrativer Aufwand und Kontrolle sein, erfordert klare Verantwortlichkeiten,
  3 agile Kernteamrollen (Kundenvertreter, Entwickler, Coach – Scrum, XP): passt möglicherweise nicht in den organisatorischen Kontext

Methodenkombination und -wechsel im Projekt

Häufiges Wechseln zwischen klassischen und agilen Ansätzen von Projekt zu Projekt kann in wackeliger Prozessstabilität enden. Eine weitere Möglichkeit ist es deshalb, in Projekten nicht zwischen Methoden hin- und herzuwechseln, sondern sie gleich sinnvoll zu kombinieren.

Das kann zum Beispiel so aussehen:

• Konzept, Spezifikation und Umsetzung mit Hardware klassisch
• Softwareentwicklung agil
• Abnahme klassisch

Oder:

• Konzept und Spezifikation agil
• Umsetzung und Abnahme klassisch

Oder:

• Alles bis zur Integration am Schluss klassisch
• Integration agil

 

Unser Tipp: Bei Durchmischung der Methoden innerhalb des gleichen Projekts hat es sich bewährt, unklare Teile des Projekts agil und klarere Teile klassisch zu planen. Bei häufigen Wechseln zwischen klassischen und agilen Ansätzen von Projekt zu Projekt besteht die Gefahr, dass die Prozessstabilität leiden kann.

Klassische Grobplanung und agile Detailplanung im Projekt

Bei hybriden Ansätzen im Projekt hat sich Folgendes bewährt:

• Planen Sie alles auf höherer Ebene grob klassisch als eine Art „Überbau“.
• Fügen Sie dann durch agile Arbeitsweisen iterative Elemente im Nachhinein hinzu.

Auf diese Weise lassen sich etwa Meilensteine und Statusmeetings weiterhin einplanen. Aber die Vorteile agiler Arbeitsweisen kommen dennoch zum Tragen.

Die Meetingfrequenz zu rhythmisieren, minimiert außerdem Reibungen und den allgemeinen Koordinationsaufwand – was am Ende zu mehr Produktivität führt.

Unser Tipp: Trennen Sie die Methoden klar nach Bereichen. Das bringt die höchste Prozesssicherheit. Als erster Schritt ist das meist ein guter Einstieg.

Multiprojektmanagement – agil, klassisch oder hybrid?

In Umgebungen für Multiprojektmanagement sind folgende Übersichten immer erforderlich:

• Status
• Notwendige Entscheidungen
• Liefertermine

Probleme beim Projektstatus müssen schnell und klar sichtbar werden (etwa durch eine rote Ampel).

Hier ist auch ein Unterschied: In typischen (Multi-)Projektlandschaften werden Sie klassische Methoden immer brauchen. Bei laufenden Produktentwicklungen von Version zu Version als „Kleinprojekte“ ist das aber anders. Letztere können Sie generell etwas problemloser agil strukturieren.

Und da es im agilen Umfeld keine Methoden für Multiprojektmanagement gibt, erübrigt sich jede weitere Frage.

Unser Tipp: Im Hybrides Projektmanagement Seminar von TPG bekommen Sie ein Grundgerüst an die Hand, mit dem Sie richtig in ein erfolgreiches hybrides Multi-Projektumfeld starten können. Besonders interessant ist dies für Mitarbeitende in PMOs.

Download (PDF): 8 Tipps für erfolgreiches Programmmanagement

Lesen Sie praktische Tipps, die Ihnen beim Aufbau und der Verbesserung Ihrer Multiprojekt-/Programmmanagement-Umgebung nützlich sein werden.
* Pflichtfeld  |  Datenschutzhinweise

Dieses Formular wird durch Ihre Cookie-Einstellung zu unserer Website blockiert. Bitte klicken Sie hier und wählen Sie mindestens die Marketing-Cookies aus. Dann wird dieses Formular angezeigt. Vielen Dank. ‘.

Unser Tipp: Sind die Anforderungen auf Kundenseite unklar und unsicher formuliert und außerdem der Lösungsansatz im Projekt noch unklar und neu? Dann sind agile Methoden besonders gut für Sie geeignet. Für solche Situationen wurden sie entwickelt.

Hybrides Projektmanagement: Beispiele zur Umsetzung

Folgend geht es um zwei Beispiele im hybriden Projektmanagement.

Beispiel 1: Parallele Consulting- und Produktentwicklungsprojekte

In einem Unternehmen werden Kundenprojekte in Form von Consulting und Produktentwicklung (z.B. Softwareprodukte) parallel durchgeführt. Die Lösung mit hybridem Projektmanagement kann als Beispiel nun so aussehen:

• fremdbestimmte Beratungsprojekte für Kunden werden immer klassisch durchgeführt
• die selbstbestimmte Produktentwicklung läuft agil ab.

Unser Tipp: Beachten Sie bei einem solchen Umfeld aber, dass Kundenwünsche zwischen den Abteilungen abgestimmt werden müssen. Das heißt im Klartext, die Sales-Abteilung muss bei der Release Planung für die Produktentwicklung mitreden dürfen.

Beispiel 2: Softwareentwicklung im Automotive-Bereich mit >100 Teammitgliedern

Ausgangssituation und Problemstellung:

• Über 100 Projektteammitglieder
• Teammitglieder sowie Stakeholder aus verschiedenen europäischen Ländern
• Teammitglieder aus ~5 verschiedenen Unternehmen
• Komplett neues Produkt
• Viele Datenschnittstellen notwendig
• Moderne Architektur-Technologie gefordert
• Zukünftiger Einsatz an vielen Standorten notwendig

Einige Lösungsansätze waren:

• Projektvision: Als Powerpoint-Präsentation, abgelegt in Projektbereich auf Atlassian Confluence
• Teamaufstellung:
  • Teams aufgeteilt in verschiedene Bereiche der zu entwickelnden Anwendung
  • Jedes Team hat einen eigenen PO-Vertreter sowie zusätzlich einen Business Analyst und ca. 8 Developer, zusätzlich UX-Designer und Tester
• Projektrollen:
  • Typische Scrum-Rollen vorhanden
  • Übergeordnete Rollen zur Koordination von Themen wie Security, Architektur, Releaseplanung, agiles Arbeiten, Qualitätssicherung etc.
• Arbeitsrhythmus und Planung:
  • Vorgehen der Teams in Sprints (miteinander synchronisiert), in denen sie aus einem gemeinsamen Product Backlog so unabhängig wie möglich arbeiten und sich bei Abhängigkeiten abstimmen, außerdem zusätzliche Meetings für die übergeordnete Planung
  • Integration der Ergebnisse möglichst früh und regelmäßig
  • Release- und Meilensteinpläne sowie pro Unterauftragnehmer definierte Arbeitspakete und Lastenhefte
• Abnahme und Betrieb:
  • Abnahmeprozess für Unterauftragnehmer: Erfolgt über Sprint Reviews
  • Abnahmeprozess mit Endnutzern: User Acceptance Tests dienen als „Gate“ vor betrieblicher Nutzung
  • Teams kümmern sich nach erfolgreicher Abnahme weiter um die Software, aber mit einem etwas anderen Prozess (Arbeit muss in Sprints neben Neuentwicklung ebenfalls untergebracht werden)
• Statusberichterstattung: In Richtung Sponsoren: einmal monatlich Bericht über aktuelle Qualitätsthemen und bekannte Probleme sowie Ursachen, Status-Meetings mit ganzem Team

Tipps zur Einführung von hybridem Projektmanagement (Checkliste)

Die Einführung von hybridem Projektmanagement ist nicht nur ein methodischer Schritt, sondern auch ein kultureller und organisatorischer Veränderungsprozess. Neben der Auswahl geeigneter Tools und Prozesse ist es entscheidend, dass Sie alle Beteiligten durch aktives Change Management mitnehmen. So können Sie Widerstände minimieren, Akzeptanz schaffen und langfristig erfolgreichere Projekte realisieren.

Folgend die praxisorientierte Checkliste für die Einführung von hybridem Projektmanagement:

• Auslöser identifizieren:
  • Management-Entscheidung dokumentieren
  • Gründe für den Hybrid-Ansatz klar kommunizieren (z.B. mehr Flexibilität, höhere Erfolgsquote)
• Situation analysieren:
  • Bestehende Prozesse, Methoden und Tools überprüfen
  • Projektklassifikations-System neu aufsetzen oder anpassen
• Change-Initiierung vorbereiten:
  • Verantwortliches Kernteam benennen
  • Konkreten Umsetzungsplan mit Meilensteinen und Roadmap erstellen
• Umsetzung starten:
  • Geeignete Dokumentationsstandards und Prozessvorlagen bereitstellen
  • Passende Werkzeuge (z.B. Projektportfoliomanagement-Tool) einführen
• Schulungen durchführen & Go-Live begleiten:
  • Teams in Methoden, Tools und neuen Abläufen schulen
  • Erste Projekte unter neuer Arbeitsweise starten und eng begleiten
• Erfolg messen:
  • Prüfen, ob eingeführte Tools wie geplant funktionieren
  • Veränderungen bei Produktivität, Projekttransparenz und Ressourcenplanung messen
• In den Alltag integrieren:
  • Tägliche Arbeitsabläufe kontinuierlich unterstützen und optimieren
  • Regelmäßig nachsteuern, um langfristige Verbesserung sicherzustellen

Wichtig: Die Umstellung auf hybrides Projektmanagement ist kein Selbstläufer. Sie benötigen fortlaufende Betreuung, klare Kommunikation und das aktive Engagement aller Beteiligten, damit Sie damit dauerhaft erfolgreich sein werden.

Zusammenfassung und Empfehlung zu hybridem Projektmanagement

In diesem Artikel haben Sie eine Übersicht aller drei Projektmanagement-Methodenbereiche kennengelernt: klassisch, agil und hybrid. Sie wissen jetzt, wie hybrides Projektmanagement als Mischung von agilen und klassischen Ansätzen in der Praxis aussehen kann.

Sie haben gelernt, dass es von parallelen Einsätzen in verschiedenen Bereichen bis hin zu Mischungen der Ansätze innerhalb desselben Projekts viele Arten für hybrides Projektmanagement gibt. Zwei Beispiele für hybrides Projektmanagement haben Ihnen die praktische Umsetzung verdeutlicht.

Besonders geeignet erscheint uns vor allem die Einführung verschiedener geeigneter Methoden getrennt nach Organisationsbereichen (z.B. fremdbestimmte Kundenprojekte klassisch und selbstbestimmte Entwicklungsprojekte agil). Dabei ist die enge Einbindung aller relevanten Abteilungen (wie z.B. Sales) von Anfang an extrem wichtig.

Versuchen Sie bei der Einführung von Methoden Schritt für Schritt vorzugehen und einen guten Teamrhythmus fürs Projekt zu finden.

Außerdem gilt: Oft verlangen besondere Situationen oder Umgebungen nach speziellen Kombinationen von Methoden. Eine für jedes Projekt individuelle Lösung (wie in den obigen Beispielen) ist immer besser als ein einfach von außen übergestülpter Ansatz.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen zu hybridem Projektmanagement im Multiprojektumfeld stellen? Dann sind Sie genau richtig beim TPG Seminar Hybrides Projektmanagement für PMOs.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

FALSE

---

Über den Autor
Johann Strasser
Nach mehrjähriger Erfahrung als Entwicklungsingenieur im Automotive- und Energiesektor arbeitete Johann Strasser für zehn Jahre als selbständiger Trainer und Berater im Bereich Projektmanagement. In dieser Zeit war er zudem als Projektleiter für Softwareprojekte in der Bauwirtschaft tätig und unterstützte Großbauten im Rahmen von Termin- und Kostenmanagement. Seit 2001 fließt seine Expertise bei TPG in die Produktentwicklung und in die Beratung internationaler Kunden ein. Besonderen Fokus legt er auf die Themen PMO, Projektportfolio, hybrides Projektmanagement und Ressourcenplanung. Sein Wissen gibt er seit vielen Jahren in Form von Vorträgen, Seminaren, Artikeln und Webinaren weiter.
Mehr über Johann Strasser auf Linkedin.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM
Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.
Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag Hybrides Projektmanagement und Vorgehensmodell – Wie Sie agile und klassische Methoden verbinden erschien zuerst auf TPG Projektmanagement Blog für Profis.

In diesem Artikel stellen wir Ihnen die agile PMI-ACP® Zertifizierung vor, den „Agile Certified Practitioner“ des amerikanischen Project Management Instituts (PMI®). Dies ist eine Projektmanagement-Zertifizierung, die mittlerweile sehr an Beliebtheit gewonnen hat. Folgende Kapitel warten auf Sie:

• Für wen eignet sich die PMI-ACP Zertifizierung?
• Wie läuft die PMI-ACP Prüfung ab?
• PMI-ACP Vorbereitung auf die Prüfung
• Kosten der PMI-ACP Zertifizierung
• Unterschiede zu anderen agilen Projektmanagement-Zertifikaten
• PMI-ACP Prüfung: Welche Inhalte Sie kennen sollten
• Zusammenfassung – PMI-ACP Zertifizierung

Legen wir los!

Für wen eignet sich die PMI-ACP Zertifizierung?

Das PMI besteht seit 1969. Seit 1995 gibt es sein Flaggschiff-Zertifikat zum Project Management Professional – PMP® für erfahrene Projektleiter:innen, das weiterhin stark gefragt ist.

Gibt es auch eine „PMP agile“ Zertifizierung?

Nicht direkt, aber fast.

Das PMI hat einige Zertifizierungen für spezielle Bereiche. Hierzu gehört seit 2012 auch das jüngste Zertifikat zum „PMI Agile Certified Practitioner“ (PMI-ACP).

Und dieses boomt:

17.000 Zertifikatsinhaber waren es bereits 2017, also nach fünf Jahren (zum Vergleich: ca. 800.000 PMP-Zertifizierte zum gleichen Zeitpunkt).

Das PMI-ACP Zertifikat möchte all jenen einen möglichen Qualifikationsnachweis bieten, die bereits praktische Erfahrung vorweisen können:

• 8 Monate agile Projektarbeit innerhalb der letzten drei Jahre und
• 12 Monate allgemeine Projekterfahrung innerhalb der letzten fünf Jahre

Letztere entfällt übrigens für PMP-Zertifizierte, was den PMI-ACP zu einer interessanten Zusatzqualifikation für diese Personengruppe macht.

Merke: Das PMI-ACP Zertifikat bietet einen Qualifikationsnachweis für Projektleiter:innen, die bereits agil gearbeitet haben.

Als agile:r Praktiker:in können Sie in der Prüfung nachweisen, dass Sie:

• neben Scrum auch andere Methodenwerke, Ansätze und Ideen sowie deren Stärken und Schwächen und diverse Kombinationsmöglichkeiten kennen,
• mit agilen Prinzipien wie Selbstorganisation und Interdisziplinarität vertraut sind und
• situativ richtig auf beschriebene Problemstellungen reagieren können.

Bei der Prüfungsbewerbung müssen Sie außerdem 21 Kontaktstunden absolviertes Training in agilen Themen angeben. Diese Stunden können Sie erreichen entweder durch

• ein spezielles PMI-ACP-Training zur Prüfungsvorbereitung und / oder
• ein anderes agiles Projektmanagement Seminar

Im häufigsten Fall glaubt Ihnen das PMI Ihre Angaben ohne weitere Überprüfung. Wie bei allen seinen Prüfungen behält es sich allerdings vor, einen gewissen Anteil eingegangener Bewerbungen per Zufallsprinzip einem Audit zu unterziehen. Bei diesem Audit muss der oder die Betroffene die gemachten Angaben schriftlich bestätigen und nachweisen.

Wie läuft die PMI-ACP Prüfung ab?

Ablegen lässt sich der Test bei Prüfungszulassung entweder in einem Computer-Testzentrum des PMI-Partners Pearson Vue oder alternativ auch online – dann aber mit einer Überwachung durch einen so genannten „Proctor“ im Auftrag vom PMI per Webcam und einigen Dingen, die es dabei zu beachten gilt (bitte lesen Sie in jedem Fall das PMI-ACP Handbook genau durch). In beiden Fällen müssen die Prüflinge ihre Termine selbst vereinbaren, sobald sie durch das PMI zum Test zugelassen wurden.

Von diesen Zentren gibt es in Deutschland einige, so dass auch eines in Ihrer Nähe dabei sein sollte. Ansonsten lohnt sich für Bewohner von Grenzregionen eventuell auch ein Blick ins benachbarte Ausland.

In diesen Testzentren dürfen keine persönlichen Gegenstände in die Prüfungsräume mitgenommen werden, auch keine Getränke oder Essen. Lediglich einen Ausweis mit Foto brauchen Sie zum Nachweis, dass Sie tatsächlich der Prüfling selbst sind.

Sie haben die Möglichkeit, alles Persönliche in Schließfächern unterzubringen. Stellen Sie sich darauf ein, dass Sie auf unerlaubte Hilfsmittel durchsucht werden.

Die Prüfung dauert drei Stunden, in denen 120 Multiple-Choice-Fragen beantwortet werden müssen.

Die PMI-ACP Prüfung auf einen Blick

• Wo findet die Prüfung statt: Computer-Testzentrum des PMI-Partners Pearson Vue oder Online Proctored
• Wie melde ich mich an: Nach Zulassung erhalten Sie vom PMI per E-Mail Anweisungen mit Ihrem Berechtigungscode, den Sie benötigen, um Ihren Prüfungstermin in einem Prüfungszentrum oder online zu vereinbaren
• Was brauche ich vor Ort: Ausweis mit Lichtbild
• Was darf vor Ort nicht mit: persönliche Gegenstände, Getränke, Essen (Schließfächer vor Ort)
• Wie lange dauert die Prüfung: drei Stunden (120 Multiple-Choice-Fragen)

 

PMI-ACP Vorbereitung auf die Prüfung

Für die Vorbereitung zur PMI-ACP Prüfung sollten Sie in etwa drei bis vier Wochen einplanen. Zuvor sollten Sie an einem PMI-ACP Training teilnehmen, das als Voraussetzung auch die 21 Kontaktstunden gewährleistet und Ihnen wichtigen Lernstoff und Hinweise für die Prüfung gibt.

So könnte etwa der Ablauf Ihrer Prüfungsvorbereitung aussehen (Empfehlung):

Kosten der PMI-ACP Zertifizierung

In der folgenden Übersicht finden Sie die mit der Prüfung verbundenen Gebühren (Stand 1/2024):

Unterschiede zu anderen agilen Projektmanagement-Zertifikaten

Im Folgenden finden Sie eine kurze Übersicht beliebter agiler Zertifizierungen für den Vergleich.

Scrum Master Zertifikate

Zertifizierungen wie die folgenden drei zum

• „Certified Scrum Master“ der Scrum Alliance
• „Professional Scrum Master I“ der Scrum.org
• „Scrum Master Certified“ der ScrumStudy

richten sich primär an Personen, die das am weitesten verbreitete agile Methodenwerk „Scrum“ in der Rolle des Scrum Master möglichst richtig umsetzen wollen. Richtig heißt hier, entsprechend den Prinzipien aus dem Scrum Guide (Download aller Sprachversionen hier) und vor allem gemäß den Gedanken der beiden Begründer des Frameworks (Ken Schwaber und Jeff Sutherland).

Lesetipp: Projektmanagement-Zertifizierungen und -Gehalt – Vergleich der bekanntesten PM-Zertifikate

Wie unterscheidet sich die PMI-ACP Zertifizierung von Scrum?

Wichtige grundlegende agile Prinzipien wie Selbstorganisation und Interdisziplinarität kleiner, dedizierter Produktteams sind auch in Scrum bereits allgegenwärtig. Die Hintergründe dafür werden aber im Scrum Guide oder in den Prüfungen kaum genauer betrachtet oder situativ hinterfragt.

Projektmanagement-Theorie spielt außerdem in Scrum Prüfungen kaum eine Rolle. Die Inhalte bewegen sich größtenteils auf der Ebene von Produktentwicklungsteams incl. Product Owner und Scrum Master.

In diesen Scrum-Rollen gehen klassische Projektmanagement-Aufgaben zwar teilweise auf, werden jedoch kaum detailliert betrachtet. Zum Teil bleiben sie auch völlig unberührt, und Überlegungen dazu werden anderen überlassen. So hat sich zum Beispiel das PMI die Standardisierung von agilem Projektmanagement auf die Fahne geschrieben.

Dies gilt auch für andere Zertifikate im Scrum-Umfeld, die auf die anderen Rollen oder auf Skalierungsthemen zugeschnitten sind.

Andere agile Zertifikate

Derzeit gibt es auf dem Markt nur wenige Formate, die sich ähnlicher Verbreitung erfreuen wie die oben Genannten. Viele agile Ansätze kommen auch gänzlich ohne Zertifizierungen aus. Sie bestehen beispielsweise mehr aus Empfehlungen für Praktiken und Werte als aus relativ detaillierten Rollen- und Prozessbeschreibungen wie bei Scrum.

Einige Angebote seien an dieser Stelle erwähnt:

• GPM / IPMA Zusatzzertifikat „hybrid +“
• APMG Agile Project Management oder Agile Programme Management (apmg-international.com)
• International Consortium for Agile (icagile.com)

Die GPM bietet z.B. ihr „hybrid+“ als Zusatzqualifikation für Projektleitende an, die das Level-C-Zertifikat besitzen (Zulassungsvoraussetzung). Sie konzentriert sich besonders auf hybride Betrachtungen, also die Kombinationsmöglichkeiten klassischer und agiler Ansätze.

Lesetipp: Agile Projektmanagement-Zertifizierungen im Vergleich – wie sollten Sie vorgehen?

PMI-ACP Prüfung: Welche Inhalte Sie kennen sollten

Die PMI Agile Certified Practitioner Prüfung fragt zunächst wichtige agile Themen in fiktiven situativen Fragestellungen ab. Diese müssen Sie oft aus Sicht einer generell als „agiler Coach“ oder „agiler Praktiker“ bezeichneten Person beantworten.

Neben den bereits genannten Themen Selbstorganisation und Interdisziplinarität sind das zum Beispiel:

• die Umsetzung der Werte aus dem agilen Manifest
• Wertsteigerung für Kunden und Stakeholder
• agile Bedingungen in regulierten Umgebungen, Vertragswesen
• die räumliche Zusammenführung von Teams soweit möglich
• Servant-Leadership und agile Führungsmethoden auf Augenhöhe
• Werkzeuge für effektives Facilitating (Moderieren von Gruppenprozessen)
• Face-to-Face-Kommunikation
• Informationsaustausch auch über Team- und Firmengrenzen hinweg
• Problemlösungsstrategien und Fehleranalyse
• Kontinuierliche Verbesserung und Retrospektiven
• Arbeiten mit „Information Radiators“ und „Low Tech High Touch“-Werkzeugen

Wenn Ihnen der Begriffe „Information Radiators“ bzw. „Low Tech High Touch“ noch unbekannt sind: So werden in der agilen Welt Ansätze genannt, die oft in hochgradig komplexen Technologieumgebungen eingesetzt werden. Sie sorgen für zwischenmenschliche Interaktionen und arbeiten bewusst mit haptischen Werkzeugen, z.B. indem Planungen statt über Software mit Post-Its auf Wänden umgesetzt werden oder Teams bzw. ganze Firmen ihre aktuellen Projektneuigkeiten für alle gut sichtbar ausstellen.

Darüber hinaus testet die Prüfung Ihr Wissen zu Praktiken, Werkzeugen und Ideen aus verschiedensten agilen Methodenwerken. Dazu gehören neben Scrum auch

• der gedankliche „Urvater“ Lean Manufacturing und das daraus entstandene Kanban
• Extreme Programming (XP)
• Dynamic Systems Development Model (DSDM Atern)
• Test-Driven Development etc.

Hinweis: Hier finden Sie einen Überblick agiler Methoden

Abgefragt werden zudem auch Fragen zu Verbindungen verschiedener Methoden sowie generelle Betrachtungen zu hybriden Ansätzen und zum Zuschneiden von Prozessen auf Projektsituationen.

Zu guter Letzt sollten Sie sich als Anwärter:in auf das PMI-ACP Zertifikat auch auskennen mit:

• den Teambildungsprozessen und -theorien
• den Metriken zur Fortschrittsmessung und
• den „Buzzwords“, die im agilen Bereich allgegenwärtig sind.

Hintergrundwissen aus der PMP Vorbereitung und dem „Guide to the Project Management Body of Knowledge“ (PMBOK® Guide) des PMI ist durchaus hilfreich. Das hat zwei Gründe:

1. Die PMI Sicht auf die Welt des Projektmanagements ist damit bereits deutlich vertrauter, was bei der Beantwortung von Prüfungsfragen hilft
2. Einige Werkzeuge und Begriffe finden sich beim PMI-ACP wieder, zum Beispiel
   • IRR / ROI / BCR (Internal Rate of Return, Return on Investment, Benefit/Cost Ratio),
   • das Kano-Modell,
   • das Voice-of-the-Customer-Konzept aus dem Qualitätsmanagement,
   • Risikomanagement-Prozesse
   • oder sogar agiles Earned Value Management etc.

Wichtige Literatur für die PMI-ACP Prüfung

Zunächst sollten Sie sich als Prüfungskandidat:in für eine PMI Prüfung immer das zum Zertifikat gehörige Handbuch und den notwendigen Lehrplan zu den Prüfungsinhalten („Exam Content Outline“) besorgen. Dies können Sie kostenlos herunterladen.

Zusätzlich empfehlenswert: Der PMBOK® Guide in der aktuellen 7. Ausgabe (zumindest grobe Kenntnis empfohlen) als Bundle mit dem „Agile Practice Guide“. Der Download ist für PMI Mitglieder kostenlos.

Diese Kombination kommt nicht von ungefähr: Das PMI hat sich 2017 mit der Agile Alliance zusammengetan und dieses Dokument neu verfasst. Dies geschah, um den übergreifenden und methodenunabhängigen agilen Ideen einen gedanklichen Überbau und eine gewisse Struktur zu geben. Deshalb sollten PMI-ACP Aspirant:innen damit vertraut sein, wenn sie in die Prüfung gehen.

Weitere Literatur hat das PMI online unter den Zertifizierungsinfos zusammengestellt. Gegebenenfalls empfiehlt sich auch ein gutes Vorbereitungsbuch wie „PMI-ACP Exam Prep“ von Mike Griffiths, der als einer der Mitgestalter der Prüfung nah genug an der Quelle ist, um zu wissen, was besonders prüfungsrelevant ist. Das Studium dieses Buchs erspart Ihnen größtenteils, jedes einzelne Buch aus der Referenzliste des PMI erwerben und studieren zu müssen.

Zusammen mit einem guten PMI-ACP Vorbereitungsseminar haben Sie so einige sehr effektive Mittel für eine fundierte Vorbereitung in der Hand.

Sprachlichen Kenntnisse für die PMI-ACP Prüfung

Anders als beim PMP, wo eine deutsche Übersetzungshilfe bei der Bezahlung kostenlos zugebucht werden kann, besteht diese Möglichkeit beim PMI-ACP zumindest derzeit nicht.

Die Prüfung ist ausschließlich auf Englisch.

Ein sicheres Beherrschen englischer Alltags- und Geschäftssprache, agiler Terminologie sowie PMI spezifischer Ausdrücke ist für den Prüfungserfolg absolute Voraussetzung. Ein Vorbereitungsseminar für die PMI-ACP Zertifizierung kann hierbei sehr hilfreich sein. Aber dennoch sollten Sie ein gewisses Maß an Sprachsicherheit mitbringen.

Zusammenfassung – Die PMI-ACP Zertifizierung

Das Zertifikat zum „PMI Agile Certified Practitioner“ (PMI-ACP) ist ein Pluspunkt im Lebenslauf von Projektleiter:innen, die mit agilen Methoden bereits etwas vertraut sind. Dies gilt besonders, wenn Sie dieses Wissen auf ein stabiles theoretisches Fundament stellen wollen.

Diese agile Zertifizierung eignet sich sehr gut als Ergänzung zum „Project Management Professional“ (PMP) oder zu einer Scrum-Zertifizierung. Aber auch für sich alleine hat das Zertifikat schon viel Aussagekraft für Projektprofis im agilen Umfeld.

Mit der richtigen Vorbereitung und ausreichenden Englischkenntnissen haben Sie gute Chancen, einen agilen Qualifikationsnachweis zu erlangen, der sich branchenübergreifend stetig wachsender Bekanntheit und Beliebtheit erfreut.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig beim TPG PMI-ACP Training zur Prüfungsvorbereitung.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag PMI-ACP Zertifizierung: Was spricht für den PMI Agile Certified Practitioner und wie geht’s? erschien zuerst auf TPG Projektmanagement Blog für Profis.

Wie Ihnen das gelingen kann, lesen Sie in diesem Artikel mit folgenden Kapiteln:

• Wichtigkeit und Zufriedenheit liegen weit auseinander
• Feste Teams als Basis für realistische Planung und hohe Qualität
• Weniger Ressourcenkonflikte durch mehr Ergebnisoffenheit
• Agile Methoden erfordern Optimierung der Organisation
• Beispiel für erfolgreiche agile Ressourcenplanung
• Langfristige Ressourcenplanung / Kapazitätsplanung ist ein Muss
• Agile Ressourcenplanung: Der Takt ist das Wesentliche
• Zusammenfassung

Legen wir los!

Wichtigkeit und Zufriedenheit liegen weit auseinander

Ressourcenplanung hat viele Bereiche und unterscheidet sich je nach Unternehmen. Aber allen Unternehmen gemeinsam ist die hohe Wichtigkeit des Ressourcenthemas.

Denn die Zeiten haben sich geändert: In vielen Unternehmen gibt es nicht genügend Mitarbeitende mit den benötigten Qualifikationen. Deshalb sind zu viele Aufgaben von zu wenigen geeigneten Personen zu erledigen. Egal ob Linientätigkeit oder Projektaufgaben – es gibt immer mehr zu tun als geleistet werden kann.

Und noch etwas: In den meisten Firmen trifft die Wichtigkeit des Ressourcenthemas auf eine hohe Unzufriedenheit mit dem Management von Ressourcenkonflikten.

Dies gilt unserer Wahrnehmung nach für alle Branchen und Größen von Firmen.

Projektmanagement soll hier helfen, etwa durch die detaillierte Planung von Aufgaben. Ziel ist der optimierte Einsatz der Mitarbeitenden, sodass sich gewünschte Ergebnisse rechtzeitig liefern lassen – natürlich unter Einhaltung von Kosten und Qualität.

Ressourcenmanagement ist kein Abfallprodukt des Projektmanagements

Die wenigsten Projekte erfüllen diesen Anspruch allerdings. Das zeigen folgende Beispiele aus dem Projektalltag:

• Termine lassen sich wegen zu geringer Ressourcenausstattung nicht halten.
• Projektbudgets werden mit zu wenig geeigneten Kolleg:innen überzogen, weil die Qualität nicht stimmt.
• Die Koordinationsaufwände zur Lösung von Ressourcenkonflikten sind viel zu hoch und die Ergebnisse oft nur faule Kompromisse.
• Am Ende lassen sich neue Geschäftschancen nicht nutzen und bestehende Kunden sind verärgert.

Dafür gibt es diverse Gründe, wie beispielsweise:

• Auslastungsdiagramme, die einfach nicht stimmen.
• Der Ressourcenpool ist unvollständig gepflegt und ohnehin nicht richtig strukturiert.
• Ressourcenanforderungen aus den Projekten sind nie vollständig und auch nicht gut genug geplant.
• Mitarbeitende haben zu viele Aufgaben gleichzeitig zu erledigen.
• Weder für die Ressourcenanfrage noch für den Konfliktfall gibt es etablierte Abstimmungsprozesse.
• Die Priorisierung von Projekten erfolgt oft gar nicht oder ist nicht allgemein bekannt.
• Teamleiter:innen und Projektleiter:innen haben wegen ungeeigneter Tools auch keine eigenen Planungsstände, auf deren Basis sie die Situationen fundiert diskutieren könnten.

Selbst wenn bei Ihnen das Einzelprojektmanagement sehr gut etabliert ist, hilft das nur bedingt für das Ressourcenmanagement im Multiprojekt-Umfeld.

Gut geplante einzelne Projekte bieten zwar eine sehr gute Basis für die Ressourcenanforderungen. Die valide Zuteilung von Ressourcen erfordert darüber hinaus aber übergeordnete Prozesse und Methoden sowie ein zentrales Tool, basierend auf einer Datenbank.

Vor allem aber brauchen Sie:

• eine geeignete Organisation,
• die Einbindung der Teamleitenden und
• das Setzen von Prioritäten.

Immer-mehr-Fordern funktioniert einfach nicht

Es braucht aber auch etwas Logik und gesunden Menschenverstand: Verantwortliche können von bereits voll ausgelasteten Personen nicht immer mehr verlangen. Es gilt, auch mal was von der Aufgabenliste zu streichen!

Klingt irgendwie logisch. Ist nur nicht leicht zu akzeptieren, wenn Sie den neuen Auftrag, den nächsten Liefertermin oder die Rechnungsstellung am Monatsende vor Augen haben und Zusagen einhalten müssen.

Kommen Sie mit auf eine gedankliche Reise:

Sie sitzen in einem vollen Bus. Dieser hält an einer Haltestelle und weitere Personen möchten zusteigen. Geht das noch? Mal ehrlich: Wenn der Bus voll ist, muss jemand aussteigen, damit jemand anderer einsteigen und gut sitzen kann. Die Erfahrung zeigt, dass auch in den vollen Bus immer noch jemand hineinpasst – stehend, an die Tür gequetscht. Aber wie lange lässt sich das aushalten?

Und hoffentlich hält die Tür wenigstens bis zur nächsten Station. Da müssen Sie ohnehin umsteigen in einen anderen Bus. Sie wissen aber noch gar nicht, wo der genau hält und außerdem kommt er meistens zu spät. Demnächst steigen Sie aber aus der Linie vielleicht ganz aus – soll heißen, Sie verlassen das Unternehmen freiwillig.

Unser Tipp: Bevor Sie Ihr Team mit immer mehr Aufgaben überlasten – priorisieren Sie die Aufgaben und streichen Sie weniger Wichtiges (vorübergehend) von der Liste.

Feste Teams als Basis für realistische Planung und hohe Qualität

Bei Anwendung agiler Methoden müssen Mitarbeitende – um om Bild zu bleiben – nicht ständig mit unterschiedlichen, überfüllten Bussen an fremdbestimmte Orte fahren. Sie steigen gemeinsam in den Bus, der für alle einen Sitzplatz hat. Niemand steigt ein und niemand steigt aus – es ist ein Charterbus nur für ein Projekt oder ein Produkt. Die Reiseleitung ist bekannt und die Zielrichtung auch.

Wie weit sie fahren, wohin genau und auch wie schnell, bestimmt das Team zusammen mit der Reiseleitung entsprechend den Erfahrungen, die sie entlang der Strecke machen.

Und da sind wir nun bei den Randbedingungen, mit denen es umzugehen gilt, wenn Sie mit agiler Ressourcenplanung so schön reisen möchten.

Natürlich ist auch in der agilen Welt nicht der Weg das Ziel. Aber der Weg und das Ziel müssen hier eben nicht von Anfang an ganz feststehen. Was jedoch sehr wohl fixiert wird, ist die Größe des Busses und die Menge an Treibstoff.

Außerdem fährt der Auftraggeber immer mit und wir fragen ihn regelmäßig an Zwischenstopps, wie es ihm gefällt. Und er ist damit einverstanden, dass wir ihn an einen Ort bringen, den auch er vorher vielleicht noch nicht richtig kannte.

Konkret bedeutet diese Vorgehensweise für das Management von Ressourcen: Ein Großteil der Probleme kann gar nicht auftauchen, weil von Anfang an die Weichen korrekt gestellt sind.

Unser Tipp: Setzen Sie auf ein festes Team, also nur eine einmalige Zusammenstellung, statt auf den dauernden Wechsel der Mitarbeitenden zwischen verschiedenen Projekten.

So einfach kann es aber nur sein, wenn Sie folgende Punkte akzeptieren:

Alle sind sich einig, dass in der vorgegebenen Zeit mit dem gesetzten Team das bestmögliche funktionsfähige Ergebnis angestrebt wird. Das muss nicht vorher komplett spezifiziert sein.

• Das Team schätzt die Aufgaben selbst und weiß daher immer am besten, was sich in welcher Zeit erledigt lässt. Das Team wird nicht von außen überfordert.
• Reviews z.B. alle 2 Wochen geben allen Beteiligten Einblicke in die bisherigen Ergebnisse. Das gibt allen die Sicherheit, das Richtige zu tun. Korrekturen können rechtzeitig eingebracht werden.
• Allen ist klar, dass das Endergebnis vielleicht von der ursprünglichen Forderung abweichen kann. Es muss aber einen verwertbaren Nutzen bringen.

Weniger Ressourcenkonflikte durch mehr Ergebnisoffenheit

Mit dem oben beschriebenen Vorgehen sind die Auslastungsdiagramme Ihrer Ressourcen immer richtig und die Kosten vorhersehbar.

Der Endtermin steht fest, nur das Ergebnis zu diesem Zeitpunkt eben nicht. Somit tauschen Sie also Ressourcenkonflikte gegen Ergebnisoffenheit.

Trotzdem ist die Qualität höher, weil bis dahin alle fokussiert an einem Projekt oder Produkt gearbeitet haben.

Und sollte jemand das Team wechseln müssen, dann nicht mitten drin. Dies erfolgt mit dem Sprint oder der Iteration, wie es auch in den anderen Teams gelebt wird. Das macht das Umsteigen in einen anderen Bus viel einfacher.

Vielleicht denken Sie jetzt, dass das ja alles für die Entwicklung von Softwareprodukten recht nett klingt. Aber wenn Sie die Augen nach der gedanklichen Reise aufmachen, sagt Ihre Realität, dass das bei Ihnen nicht funktionieren kann.

Stimmt schon, einen Flughafen können Sie damit nicht bauen. Aber in vielen anderen Bereichen, die nicht reine Softwareentwicklung sind, lässt sich mindestens der Softwareanteil agil erledigen. Und bei all den vielen modernen Digitalisierungsprojekten ist Software allgegenwärtig.

Aber auch jede andere Form von Produktentwicklung können Sie mit einem festen Team und agilen Prinzipien durchführen.

Lesetipp: Ressourcenmanagement einführen – in 6 Schritten schnell und erfolgreich

Agile Ressourcenplanung erfordert Optimierung der Organisation

Bitte beachten Sie: Damit agile Ressourcenplanung und agile Methoden funktionieren, ist eine klare Verfügbarkeit der Personen sowie deren eigene Einschätzung zur Leistbarkeit der geforderten Liefergegenstände Voraussetzung.

Beides sind grundlegende Bedingungen in der agilen Welt, die sich aber auch weitgehend im klassischen Projektmanagement anwenden lassen. Das muss aber nicht nur eine Person aus der Projektleitung, sondern die ganze Organisation drum herum wollen.

Auch hybrides Projektmanagement ist hierfür ein Ansatz. Das heißt, die Produktentwicklung wird agil und die Kundenprojekte werden klassisch umgesetzt. Damit haben Sie vielleicht auch ein Drittel oder die Hälfte Ihres Ressourcenmanagements vereinfacht, wenn Sie die Teams sauber getrennt halten.

Es ist auch denkbar, nur die Spezifikationsphase eines Projektes agil durchzuführen. Nach fünf Sprints wissen alle viel genauer, was sie wollen und was machbar ist.

Das Gleiche gilt für die Integration von klassisch entwickelten Komponenten am Ende eines Projektes. Wenn diese wirklich funktionsfähig geliefert werden muss, können Sie sie für ein halbes Jahr agil aufsetzen.

Beispiel für erfolgreiche agile Ressourcenplanung

Bei TPG The Project Group entwickeln wir Softwareprodukte schon seit fünf Jahren mit agiler Ressourcenplanung und agilen Methoden. Die Kundenprojekte hingegen erledigen wir klassisch in der Matrix. Beides erfolgt intern im gleichen Takt von zwei Wochen.

Ein Wechsel der Teammitglieder zwischen Kundenprojekten und Produktentwicklung findet bei uns schon lange nicht mehr statt.

Wir haben also in der Produktentwicklung keine Schwierigkeiten in der Ressourcenplanung, nur im Finden neuer Kolleg:innen.

Bei TPG kümmern wir uns intensiv darum, dass alle Stakeholder abgeholt, informiert und in die Priorisierung der Features eingebunden sind.

Wir liefern alle zwei Monate Releases unserer Produkte. Bei der Release-Planung macht das Produktmanagement Vorschläge, was im nächsten Release untergebracht werden könnte. Basis sind die vom Developer Team geschätzten Punkte für die Aufwände, die zur verfügbaren Kapazität passen müssen.

Die Kapazität ändert sich aufgrund der festen Teamgröße nur, wenn neue Mitarbeiter eingestellt werden bzw. wenn jemand Urlaub macht oder wegen Krankheit ausfällt.

Teammeetings, Weiterbildung etc. führen wir sichtbar als Aufgaben, sodass vollständige Transparenz gegeben ist. Alle Beteiligten sehen, wie viel Zeit bzw. Punkte in den nächsten beiden Monaten zur Verfügung stehen und wie viel Zeit bzw. Punkte für welches Feature vom Team realistisch geschätzt wurden.

Bei der Festlegung der kommenden Umsetzungen haben Development, Consulting und Sales eigene Stimmen, das Produktmanagement zumindest auf dem Papier ein Einspruchsrecht.

Die Besprechung zur Release-Planung endet, wenn es einen allgemein akzeptierten Beschluss gibt. Dabei können alle mit etwas Kopfrechnen gerne auch mehr fordern, wenn sie dabei auch sagen, worauf sie verzichten können.

Bei uns dauert eine Besprechung zur Release-Planung (alle zwei Monate mit fünf bis zehn Teilnehmer:innen pro Produktgruppe) in der Regel von 14 – 17 Uhr. Aber im Anschluss steht ein Puffer mit open end im Kalender. Der Puffer wurde in all den Jahren aber nur einmal genutzt – witzigerweise bei einer Release-Planung, bei der alle vorher meinten, dass ohnehin alles klar wäre und wir keine Stunde brauchen würden.

Änderungen der Aufgaben während der Entwicklung sind natürlich nur zulässig, wenn eine Katastrophe eintritt.

Unser Tipp: Führen Sie Ihre Release-Planung zum Verständnis für die Prioritäten gemeinsam im Team durch. Ein kleiner unantastbarer Puffer für Unvorhergesehenes hat sich dabei bewährt. Wenn Sie diesen nicht brauchen, kann Ihr Team im letzten Sprint aus der priorisierten Aufgabenliste einfach die nächsten Punkte wählen.

Langfristige Ressourcenplanung / Kapazitätsplanung ist ein Muss

Wie bereits zu Beginn des Artikels gesagt: das Management von Ressourcen hat verschiedene Bereiche.

Den Kern der kurz- und mittelfristigen Ressourcenplanung haben wir mit den Besonderheiten der agilen Gesichtspunkte behandelt.

Die langfristige Hülle bleibt aber für agil, klassisch und hybrid immer gleich. Die Kapazitätsplanung im Projektmanagement entlang der Unternehmensstrategie ist für beide Welten unerlässlich.

Für die Produktentwicklung bedeutet das: Mit jedem neuen Produkt wird ein Team neu zusammengesetzt bzw. aufgelöst, wenn das Produkt nicht weiterentwickelt wird.

Natürlich können Sie auch mehr als ein Produkt in einem Team entwickeln, solange der Product Owner derselbe ist. Schließlich muss jemand die Prioritäten setzen.

Für die langfristige Ressourcenplanung brauchen Sie eine Geschäftsleitung, die eine Strategie vorgibt und ein etabliertes PMO, das das Projektportfolio zur Umsetzung der Strategie steuert.

Dazu gehören die nötigen Mittel wie

• standardisierte Methoden,
• etablierte Prozesse,
• die Betreuung der Projektleiter und Teamleiter mit Ausbildung und Coaching
• und natürlich ein rollenspezifisches Tool mit zentraler Datenbasis.

Agile Ressourcenplanung: Der Takt ist das Wesentliche

Die „taktvolle“ Zusammenarbeit ist unseres Erachtens der wichtigste Punkt, um Ressourcenkonflikte im Projektmanagement zu vermeiden.

• Einerseits betonen wir damit den ordentlichen Umgang miteinander, auch wenn es inhaltlich kritisch wird.
• Und andererseits ist damit der zeitlich synchronisierte Takt von Planung, Abstimmung und Entscheidung über alle Projekte und Ressourcen gemeint.

Zusammenfassung

Hier noch einmal die wesentlichen Punkte zur Vermeidung von Ressourcenkonflikten im Projektmanagement – unabhängig von der Diskussion, ob agile Ressourcenplanung, klassische Vorgehensweise oder beides:

• Ressourcenplanung muss vollständig sein, oder sie ist unbrauchbar. Lieber alle Projekte, grob geschätzt, als nur ein paar Projekte genau.
• Wer mehr Projekte umsetzen will, als ressourcenseitig geht, muss vorab sagen, worauf stattdessen zu verzichten ist. Weniger ist am Ende dann meistens ohnehin mehr.
• Lassen Sie das Team selbst schätzen. Das macht die Planung realistisch.
• Halten Sie die Zusammensetzung der Teams möglichst konstant. Jeder Wechsel ist ein Verlust.
• Planen Sie die Grundlasten sauber ein, sonst gehen Sie immer von falschen Verfügbarkeiten aus. Binden Sie die Teamleitenden dafür gut ein.
• Arbeiten Sie mit einem PMO im gleichen Takt über alle Teams. Dann gibt es weniger Zusammenstöße zwischen agiler Ressourcenplanung und klassischen Projekten.

Das Management von Ressourcen ist je nach Unternehmenskultur eine recht heikle Angelegenheit oder auch nicht. Die Auswahl von Methoden, Prozessen und Tools spielt dabei eine wichtige Rolle.

Zufriedenheit mit diesem Thema können letztlich nur die beteiligten Personen (selbst) herstellen.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig beim TPG Ressourcenplanung Seminar.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über den Autor
Johann Strasser

Nach mehrjähriger Erfahrung als Entwicklungsingenieur im Automotive- und Energiesektor arbeitete Johann Strasser für zehn Jahre als selbständiger Trainer und Berater im Bereich Projektmanagement. In dieser Zeit war er zudem als Projektleiter für Softwareprojekte in der Bauwirtschaft tätig und unterstützte Großbauten im Rahmen von Termin- und Kostenmanagement. Seit 2001 fließt seine Expertise bei TPG in die Produktentwicklung und in die Beratung internationaler Kunden ein. Besonderen Fokus legt er auf die Themen PMO, Projektportfolio, hybrides Projektmanagement und Ressourcenplanung. Sein Wissen gibt er seit vielen Jahren in Form von Vorträgen, Seminaren, Artikeln und Webinaren weiter.
Mehr über Johann Strasser auf Linkedin oder Xing.

Über den Autor
Achim Schmidt-Sibeth

Nach dem Ingenieurstudium in Umwelttechnik sammelte er jahrelang Erfahrung im Projektmanagement bei einem Ingenieurbüro, einem Anlagenhersteller und in einer Multimediaagentur. Seit vielen Jahren ist Achim Schmidt-Sibeth mit seinem Team für Content, Marketing und Kommunikation bei TPG The Project Group verantwortlich.
Mehr über Achim Schmidt-Sibeth auf LinkedIn oder Xing

Der Beitrag Agile Ressourcenplanung – kann eine agile Planung Ressourcenkonflikte in Projekten verringern? erschien zuerst auf TPG Projektmanagement Blog für Profis.

Lesen Sie in diesem Artikel, wie das gelingen kann und erhalten Sie Tipps zur konkreten Umsetzung mit Links zu mehr Informationen. Sie erfahren in drei Teilen:

• Teil 1: Warum braucht es Skalierungs-Rahmenwerke wie SAFe?
• Teil 2: SAFe – Voraussetzungen, Aufbau, erste Schritte
• Teil 3: Unterschied SAFe zu anderen Skalierungs-Rahmenwerken
• Könnte SAFe der richtige Ansatz für Ihr Unternehmen sein?
• Zusammenfassung

Legen wir los mit der Definition von SAFe Scaled Agile Framework.

Definition SAFe Scaled Agile Framework

Die Abkürzung SAFe steht für „Scaled Agile Framework“. Es bietet ein Rahmenwerk für größere Unterfangen oder Unternehmen, die agiles Projektmanagement leben wollen und sich in einer agilen Transformation befinden. SAFe gehört aktuell zu den beliebtesten Skalierungslösungen und eignet sich auch für hybrides Projektmanagement.

Hinter SAFe steht die Organisation Scaled Agile Inc., die auch Zertifizierungen im Zusammenhang mit SAFe anbietet. Gegründet wurde sie von Dean Leffingwell. Er schrieb in seinem Buch „Agile Software Requirements“ bereits 2010, wie man agile Ansätze unternehmensweit skalieren kann.

Teil 1: Warum braucht es Skalierungs-Rahmenwerke wie SAFe?

In den letzten Jahrzehnten ist die Zahl der agil arbeitenden Teams stark angestiegen. Das gilt nicht nur für IT-Abteilungen, die lange eine Art Vorreiterstellung hatten. Jetzt sind auch immer mehr andere Bereiche in Organisationen betroffen.

Die Landschaft agiler Ideen wirkt dabei oft wie ein Flickenteppich: So vielseitig wie die verschiedenen Methodenwerke Scrum, Kanban oder Extreme Programming – XP u.a. sind, so unterschiedlich arbeiten auch die Teams bei der Umsetzung.

Die Vielfältigkeit der Vorgehensweisen macht es schwer, sich untereinander und mit Kunden abzustimmen. Außerdem werden häufig auf Teamebene bereits viele Veränderungen umgesetzt und gelebt, aber wenig davon dringt in der Unternehmenshierarchie weiter nach oben.

Zudem geben Leitfäden (z.B. der Scrum Guide) keine Auskunft, wie bei Projekten mit mehr als einem Umsetzungsteam von drei bis neun Leuten vorzugehen ist. Ganz zu schweigen von untereinander abhängigen, parallellaufenden Projekten.

Dies liegt daran, dass der Scrum Guide versucht, Antworten auf eine ganz bestimmte Fragestellung zu geben: Welche Prozesse eignen sich für agile Arbeitsweisen?

Andere Fragen, wie etwa „welche gedanklichen Einstellungen müssen dahinterstehen?“ oder „welche Techniken wenden wir an, um hohe Qualität der Ergebnisse sicherzustellen?“ bleiben weitestgehend unangesprochen.

Skalierungs-Frameworks wie SAFe bieten hier einen Ansatz, methodische Lücken zu schließen: Sie vereinheitlichen die unternehmensweite Einführung agiler Ideen und Methoden auf eine Weise, die ein systematisches Vorgehen erleichtert.

Auch wenn inzwischen die Auswahl der Skalierungs-Ansätze selbst etwas unübersichtlich wird, ist SAFe das derzeit beliebteste und am meisten verbreitete Skalierungs-Rahmenwerk.

Auf einen Blick: Was unterscheidet Scrum von SAFe?

Warum die Umsetzung agiler Methodenwerke oft scheitert

In einzelnen Teams agile Arbeitsweisen einzuführen, das kann bereits ein Umdenken bewirken. So können Sie vor allem auf Einzelteam- bzw. Einzelprojektebene Erfolge erzielen. Und Prozesse, Innovationen oder die Beteiligung von Teams und Stakeholdern lassen sich bereits deutlich beweglicher gestalten – sofern es Ihr Umfeld erlaubt.

Aber: Die große Herausforderung ist, dass Pionierteams intern und bei der Zusammenarbeit mit anderen Firmen schnell auf Hindernisse stoßen.

Diese Hindernisse liegen oft an unterschiedlichen Auffassungen, dem „Mindset“.

Versucht ein neues Scrum Team sich im Projekt an die agilen Prozesse, Rollen und Arbeitsweisen zu halten, gibt es häufig folgende Reibungspunkte:

1. Fehlendes methodische Verständnis: Internen Stakeholdern, Kunden oder Nutzer:innen des entwickelten Produkts ist oft nicht oder nicht ausreichend bewusst, was das Scrum Team tut und warum.
   Beispiel: Ein Kunde soll zu Ende jedes Sprints zum Review-Meeting Feedback zum bis dato entwickelten Produkt abgeben. Er kann dies aber kaum bis gar nicht einrichten. Oder: Ein Scrum-Team braucht eine Person mit speziellen Entwicklungskenntnissen in Vollzeit, um Deadlines einhalten zu können. Diese Person wird aber auch von anderen dringend gebraucht.
2. Ungeeignete Verträge: Kundenaufträge sind nicht auf Bedürfnisse von Scrum Teams zugeschnitten.
   Beispiel: Manche Vertragsmodelle für agile Projekte sehen eine Teilung nicht verbrauchten Rest-Budgets nach Projektbeendigung vor. Dies soll die Kostenrisiken fairer aufteilen und für ein konstruktives Streben nach gemeinsamen Zielen sorgen. Budgetplanungs-Prozesse in vielen großen Unternehmen geben eine solche Freiheit allerdings gar nicht her. Daher sind solche Vertragsklauseln nicht umsetzbar.
3. Ungeeignete Unternehmensorganisation: Viele Firmen sind nach wie vor stark in Silos organisiert.
   Beispiel: Ein Scrum Team möchte möglichst abteilungsübergreifend an einer neuen Lösung arbeiten. Kolleg:innen in diesen Abteilungen sind eine solche Art der Zusammenarbeit aber nicht gewohnt. Und es fehlen auch die räumlichen Möglichkeiten, sich kollaborativ auszutauschen.
4. Klassische strategische Ausrichtung: Firmen, die in Projekten zusammenarbeiten, haben manchmal völlig unterschiedliche Vorstellungen von Agilität und auch verschiedene Reifegrade.
   Beispiel: Ein Dienstleister für Softwareentwicklung hat viel Erfahrung in agilen Methoden und möchte mit dem Kunden für ein neues Projekt zunächst eine Produktvision mithilfe von neuen Methoden wie Lego Workshops entwickeln. Der Kunde reagiert irritiert und ist zögerlich in der Bereitschaft, an einem solchen Workshop überhaupt teilzunehmen. Er zieht es vor, schwer verständliche Use Cases per E-Mail zu schicken.
5. Projekt- statt Produktorientierung: Die Produktorientierung, die agile Teams für ihre Motivation und zielgerichtete Arbeit brauchen, ist vielen Firmen noch völlig fremd.
   Beispiel: Ein Scrum Team plant seine Sprints so, dass jeder im Team die selbst gesetzten Ziele im Sprint kennt. Vorgesetzte des Product Owners haben jedoch andere Vorstellungen davon, woran die Leute im Team genau jetzt arbeiten sollten – Sie „funken“ mit abweichenden Anforderungen dazwischen. Da der Product Owner um seinen Job fürchtet, wenn er sich nicht an die Anweisungen hält, gibt er diese ungefiltert weiter. In der Folge sinkt die Motivation des Teams bezüglich der eigenen Planung von Sprint zu Sprint – da dies sowieso nicht haltbar sein wird.

Diese Liste ließe sich weiter fortsetzen. Die Szenarien aus den Beispielen sind so alle bereits vorgekommen und ereignen sich häufig.

Wie können Skalierungs-Frameworks hier helfen?

Im Prinzip geht es darum, bei allen Beteiligten ein „agiles Bewusstsein“ zu schaffen:

• Führungskräfte eines Unternehmens verschreiben sich bestimmten Werten des agilen Mindsets. Damit können einzelne Teams und am Ende die ganze Organisation erfolgreicher sein.
• ALLE Projektbeteiligten und Stakeholder leben diese Einstellung täglich bei ihrer Arbeit – das gilt auch für Kundenfirmen und Dienstleister.
• Teams innerhalb der Organisation ziehen alle am gleichen Strang, anstatt bei der Zusammenarbeit in Konkurrenz zu treten.
• Bei weltweit verteilten Standorten gibt es eine gemeinsame und durchdachte Strategie.

SAFe bietet viele Ansätze, wie ein wichtiges und großes Vorhaben gelingen kann. Es ist damit aber – wie andere Skalierungs-Frameworks auch – nicht als Blaupause zu verstehen.

Teil 2: SAFe – Voraussetzungen, Aufbau und erste Schritte

Wichtige Voraussetzung für SAFe

SAFe liefert konkrete Vorschläge, wie Sie mit der hohen Komplexität bei Prozessskalierungen umgehen. Dabei ist wichtig zu wissen, dass die Umsetzung Zeit sowie eventuell Schulungen erfordert.

Tipp: Greifen Sie zu Beginn Ihres Weges in die Agilität Ihrer Organisation auf jeden Fall auf Menschen mit Erfahrung und Kenntnissen in Scrum und skalierenden Ansätzen zurück.

Der „State of Agile“-Bericht nennt bei der Einführung von Skalierungs-Frameworks die folgenden fünf Top-Erfolgsfaktoren:

Wie ist SAFe aufgebaut?

SAFe basiert auf neun Prinzipien, angelehnt an Ideen und Prinzipien aus dem Agilen Manifest. Der wesentliche Unterschied zu den klassischen Richtlinien liegt im Aufbau der einzelnen Rollen und Ebenen pro Ausbaustufe (Anforderungen an Projekt- bzw. Teamgröße / Anzahl der Teams).

Die Ausbaustufen von SAFe

Möchten Sie SAFe als Rahmenwerk einführen, sollten Sie sich zunächst zwei Dimensionen bewusst machen:

• Wie stufen wir unsere Vorhaben im Hinblick auf Komplexität und Größe ein? Hier können Sie die untenstehende Tabelle zu Rate ziehen. Das „Essential SAFe Toolkit“ bietet weitere Anhaltspunkte zur Selbsteinordnung. Auch erfahrene SAFe Berater:innen können dabei helfen. Bei Unsicherheit gilt: lieber erst einmal die Umsetzung der Prinzipien in der einfachsten Stufe ausprobieren, bevor ein Ansatz konzernweit ausgefahren wird.
• Welche Ebenen sollen einbezogen werden? Geht es uns mehr um die Einzelteam- und Programmebene? Oder betrachten wir unsere Arbeitsweisen gleich auf Portfolioebene? Oder gar für einen ganzen Großkonzern (Large Solution und bei international agierenden auch Full SAFe)?

SAFe bietet je nachdem, wie Sie diese Frage für Ihre Situation beantworten, verschiedene Ausbaustufen hinsichtlich Projektkomplexität und -größe.

Tipp: Einen guten Überblick erhalten Sie mithilfe der Grafik auf scaledagileframework.com – klicken Sie dort auf die einzelnen Reiter, um das Diagramm für jede der Stufen zu sehen.

Zum besseren Verständnis gehen wir folgend näher auf die Ausbaustufen, einbezogenen Ebenen und Rollen in SAFe ein.

Die SAFe-Stufen im Einzelnen

Die Ebenen im Einzelnen

Je umfangreicher die Skalierung und je komplexer die Anforderungen, desto mehr Ebenen sollten Sie zur Erledigung der Aufgaben pro Stufe einbeziehen:

• Teamebene: SAFe nutzt das normale Scrum Team Setup und wandelt dies ein wenig ab. Pro Team kümmern sich fünf bis neun (statt in Scrum drei bis neun) Developer um die Umsetzung. Sie werden begleitet von einem Product Owner und einem Scrum Master für je circa 1-2 Umsetzungsteams. Außerdem arbeitet der PO dem übergeordneten Produktmanagement auf Programmebene zu. Die Teams arbeiten dabei funktionsübergreifend und weitestgehend selbstorganisiert.
• Programmebene: In SAFe arbeiten bis zu 10 Teams als sogenannte „Agile Release Trains“ für ein Programm zusammen. Produktmanager:innen sammeln und managen die Anforderungen, Product Owner brechen diese auf Teamebene umsetzungsnah herunter. So werden Programm- und Teamebene zusammengebracht. Eine Rolle „Release Train Engineer“ kümmert sich ab Ausbaustufe 2 um Abhängigkeiten und Integrationsaspekte.
• Portfolioebene: Auf dieser Ebene erfolgt die strategische Sicht auf Produktentwicklung, Budgetzuordnung und Abgleich mit Unternehmenszielen.
• Large-Solution-Ebene: Die allergrößten Projekte der Produktentwicklung erhalten mit dieser Ebene einen eigenen „Release Train“ zur Kontrolle des Wertstroms. So will SAFe den Anforderungen besonders großer und komplexer Programme gerechter werden.

Die SAFe-Rollen im Einzelnen

Die Rollen in SAFe sind auf Ebene 1 zunächst die normalen Scrum Teamrollen. Ab Ausbaustufe 2 gibt es zusätzlich folgende Rollen (ähnlich typischen Strukturen in klassischen Unternehmen):

• Ein Product Manager verantwortet das übergeordnete Product Backlog, das dann Program Backlog heißt
• Ein System Architect ist für die Systemgestaltung zuständig
• Ein Release Train Engineer kümmert sich als eine Art teamübergreifender Scrum Master für die Zusammenarbeit und Abhängigkeiten zwischen Teams
• Ein Business Owner behält den Blick auf ROI und Wertmaximierung sowie der Ausbalancierung von Kosten und Nutzen in der Produktentwicklung auf Systemebene; somit entlastet er den Product Manager etwas in dieser Hinsicht
• Natürlich darf auch der Kunde nicht zu kurz kommen – das ist der wichtigste Stakeholder.

Auf den Ebenen 3 und 4 kommen weitere Rollen hinzu, um der steigenden Komplexität gerecht zu werden.

Tipp: Die einzelnen Komponenten von SAFe sollten Sie vor Einführung auf ihre Sinnhaftigkeit in der gegebenen Umgebung prüfen. Genau dies ist die Motivation hinter Rahmenwerken, wie auch Scrum eines ist: einen Rahmen vorzugeben, innerhalb dessen sich Details situationsangepasst gestalten lassen.

Teil 3: Unterschied SAFe zu anderen Skalierungs-Rahmenwerken

Natürlich gibt es neben SAFe eine ganze Reihe Wettbewerber, die jeweils unterschiedliche Schwerpunkte haben. Der folgende Vergleich zeigt die wesentlichen Unterschiede:

Tipp: Die Frameworks in dieser Liste können zur Orientierung und Inspiration dienen; eine Umsetzung sollte aber immer mit Augenmaß dank entsprechender Erfahrung oder Beratung erfolgen. Auch unternehmensweite Ziele sollten Sie zunächst ausarbeiten und kommunizieren, damit sich keiner der Betroffenen überrumpelt fühlt.

Wie eingangs erwähnt nutzen die meisten Unternehmen das SAFe Framework als Inspirationsquelle für mehr Agilität in der Organisation. Warum ist das so?

Die Vorteile von SAFe

SAFe trägt aktiv zu einem agileren Mindset bei. So wichtig eine agile Transformation ist – mit dem Ansatz „Holzhammer-Methode“ wird sie vermutlich scheitern. Dies gilt gerade in großen, gewachsenen Unternehmen, die nicht mit kleineren Start-ups zu vergleichen sind.

Deshalb versuchen sie sich lieber an hybriden Ansätzen, als große Veränderungen zu wagen und dabei an mangelnder Akzeptanz zu scheitern.

So weit, so gut.

Kritikpunkte an SAFe

Befürworter:innen klassischer agiler Methoden sehen SAFe nur als pseudoagiles Rahmenwerk. Zu den häufigen Kritikpunkten zählen:

• SAFe ist nicht agil genug
• Überholte Managementpraktiken bleiben bestehen
• Die Einführung zusätzlicher Ebenen widerspricht dem agilen Prinzip flacherer Hierarchien
• Andere Skalierungsansätze, wie etwa LeSS, sind schlanker gestaltet und näher an agilen Grundprinzipien.

Dennoch: Für viele Unternehmen ist es schwierig, einen Wandel ohne Übergänge zu gestalten. SAFe liefert hier den passenden Zwischenschritt:

• für das hybride Vakuum zwischen traditionellen und komplexen Organisationsstrukturen auf der einen, und
• möglichst agiler Selbstorganisation sowie leichtgewichtigen Prozesse auf der anderen Seite

Tipp: Es gibt kein klar definiertes Einsatzszenario, das für oder gegen eine Einführung von SAFe als agiles Rahmenwerk spricht. Hier wird kontrovers diskutiert. Da SAFe aber sehr detaillierte Vorgaben zur Strategie und Umsetzung liefert, gilt pinzipiell die Empfehlung: Je niedriger der agile Reifegrad der Organisation, desto geeigneter ist SAFe als Veränderungsansatz „Schritt für Schritt“.

Weitere Orientierungshilfe für die Methodenauswahl finden Sie hier: Die bekanntesten Skalierungsansätze im Überblick.

Könnte SAFe der richtige Ansatz für Ihr Unternehmen sein?

Wir empfehlen folgende erste Schritte zur Evaluierung bzw. Einführung nach dem SAFe Rahmenwerk:

• Sammeln Sie Argumente für eine Skalierung (z.B. unsere Projekte sind zu groß für kleine agile Einzelteams und wir wollen eine einheitliche Vorgehensweise)
• Holen Sie die relevanten Stakeholder an Bord, insbesondere auf den wichtigen Entscheidungsebenen
• Prüfen Sie das agile Mindset in der Firma und bei anderen Projektbeteiligten
• Finden Sie interne Experten / Expertinnen und / oder beauftragen Sie externe Berater:innen
• Stimmen Sie das weitere Vorgehen immer mit dem Management ab

Tipp: Ganz wesentliche Faktoren für eine erfolgreiche Einführung eines agilen Umfeldes: Sorgen Sie für die enge Kommunikation intern wie extern (mit Kunden- und Partnerfirmen) und richten Sie ein cleveres Change Management ein.

Zusammenfassung – SAFe Scalable Agile Framework

Sie haben in diesem Artikel gelernt, dass Sie mit dem Skalierungsmodell SAFe mehr Agilität in die Organisation und Prozesse Ihres Unternehmens bringen können.

Sie haben erfahren:

• Warum die Nachfrage nach Skalierungsansätzen wie SAFe so groß ist
• Wie sich SAFe von agilen Methoden unterscheidet
• Welche alternativen Ansätze existieren
• Was Sie beachten sollten, wenn Sie SAFe einführen möchten
• Wie SAFe aufgebaut ist und
• Welche Schritte Sie gehen können, um SAFe in Ihr Unternehmen zu bringen.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifegrad Ihres Projektmanagements!

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag Scaled Agile Framework (SAFe) – Erklärung des Rahmenwerks und wie Sie Ihre Organisation agiler gestalten erschien zuerst auf TPG Projektmanagement Blog für Profis.

In diesem Artikel erhalten Sie vier Tipps, wie Developer Jira und Confluence als Tools für die bessere Begleitung der Prozesse und die Zusammenarbeit im Team nutzen können – und was Sie unbedingt beachten sollten. Dieser Artikel ist Bestandteil unserer Blog-Reihe „Jira für Rollen im Projektmanagement“.

Diese Kapitel warten auf Sie:

• Welche Aufgaben von Developern können Jira und Confluence unterstützen? 
• Tipp 1: Personalisiertes Dashboard
• Tipp 2: Status eines Vorgangs aktualisieren
• Tipp 3: Labels, Versionen, Komponenten und Filter
• Tipp 4: Codes teilen mit dem Code-Block-Makro
• Fazit – Developer Jira und Confluence Tipps

Legen wir los mit einer kurzen Definition. 

Was ist ein Developer laut Scrum?

Als Developer werden in einem Scrum-Team (und auch in diesem Artikel) jene Teammitglieder bezeichnet, die aktiv an der Entwicklung eines Produkts beteiligt sind (aller Art, insbesondere Software), etwa als Entwickler:innen, Tester:innen oder Designer:innen.  

Welche Aufgaben von Developern können Jira und Confluence unterstützen?

Jira ist vor allem für Aufgabenmanagement gedacht. Es bildet die Realitäten verschiedener und insbesondere agil arbeitender Teams durch diverse Projekt- und Boardtypen ab. Somit kann es besonders Developern die Planung und Organisation ihrer Arbeit sowie den Austausch darüber erleichtern.

Durch die einfache Anbindung von Code-Plattformen wie Bitbucket, Github und weiteren Software-Entwicklungstools können die verschiedenen verwendeten Umgebungen integriert und Arbeitsabläufe automatisiert werden. Das kann die Effizienz von Software-Teams drastisch erhöhen.

Die wichtigste Voraussetzung dabei ist allerdings, dass die Teammitglieder eng in die Einrichtung und Abbildung der Prozesse eingebunden sind. Die Prozesse sollten möglichst leichtgewichtig gestaltet werden. Software wie Jira kann dann die Arbeit tatsächlich unterstützen und wird nicht als Belastung gesehen, weil der tägliche Aktualisierungsaufwand gering bleibt.

Damit Ihnen dies besser gelingt, finden Sie folgend einige wichtige Tipps, wie Developer Jira und Confluence in ihrem Umfeld gut zum Einsatz bringen können.

Tipp 1: Personalisiertes Dashboard

Wollen Sie als Teammitglied zu Arbeitsbeginn einen schnellen Überblick erhalten, welche Themen offen und als Nächstes abzuarbeiten sind? Solche Informationen aufzubereiten, ist eine der Stärken von Jira.

Mit eigenen Jira Dashboards können Teammitglieder selbst eine Übersicht zusammenstellen, die die Einführung einer täglichen Routine unterstützen. Die Zusammenstellung der Kästen (“Gadgets”) kann durch jeden Jira User in einem eigenen Dashboard selbst festgelegt werden. 

Auch das Teilen – und damit das Einrichten von Dashboards für ein Team oder auch einen festgelegten Personenkreis – ist in Jira möglich. 

Tipp 2: Status eines Vorgangs aktualisieren

Developer haben mit der Produktentwicklung meist alle Hände voll zu tun. Die Aktualisierung der Planung und des Arbeitsfortschritts sollte daher möglichst intuitiv und schnell geschehen können.

Aus dem Grunde ist es in Jira in den letzten Jahren immer einfacher geworden, solche Updates vorzunehmen: durch intuitivere Benutzerführung und Automatisierung – aber auch dadurch, dass besonders in Jira Cloud oft viele Wege zum Ziel führen.

So lässt sich der Status eines Issues (deutsches Jira: „Vorgang“), also eines Eintrags in einem Projekt, der als Planungsgrundlage für die Arbeit dient, auf mehreren Wegen aktualisieren. Diese geht über:

1. Issue-Schnellansicht
2. Issue-Vollbildansicht
3. einen verlinkten oder einen Parent Issue

Tipp 3: Labels, Versionen, Komponenten und Filter

In Jira dienen Labels, Versionen und Komponenten dazu, Projekte und Issues zu organisieren und zu kategorisieren.  

Labels können wie Schlagwörter betrachtet werden, mit denen Issues gekennzeichnet und gesucht werden können.  

Unser Tipp: Achtung! Labels können durch alle Nutzenden frei erstellt werden. Um Wildwuchs zu vermeiden, sollten Sie hier verpflichtende Vorgaben für alle Nutzenden definieren.

Versionen ermöglichen es, den Fortschritt von Projekten zu verfolgen und zu planen – durch die Verwaltung geplanter und tatsächlicher Releasedaten.  

Was Jira Releases angeht, haben die Information über sie eher informativen Charakter – außer wenn weitere Developer-Tools angebunden und Automatisierungen eingerichtet werden. Releases / Versionen decken eher die zeitlichen Aspekte der Planung ab. 

Jira Komponenten hingegen ermöglichen es Ihnen, Issues nach Funktionsbereich oder Modul zu gruppieren (etwa für ein zu entwickelndes Produkt).  

Hinweis: Jira Komponenten sind nur in unternehmensverwalteten Softwareprojekten verfügbar.

Diese Gruppierungsmöglichkeiten erleichtern die Zusammenarbeit im Team und machen es Ihnen dadurch einfacher, die Arbeit gemeinsam effektiver zu planen und zu verfolgen. 

Auch dienen sie als Basis für Suchfilter, die sich auf Ihre Arbeit zuschneiden lassen. Labels, Versionen und Komponenten sind filterbar. Die Filtersuche können Sie speichern sowie auf Dashboards abbilden. 

Tipp 4: Codes teilen mit dem Code-Block-Makro 

Ein weiteres interessantes Feature für Developer betrifft Confluence und dient dem Teilen von Code oder Script-Elementen: Mit dem „Code Block Makro“ können Sie die Sprache ihres Codes wählen und dann von der Funktion „Syntax Highlighting“ profitieren.  

Wie Sie den Code Block Schritt für Schritt hinzufügen: 

1. Wählen Sie das „+“ Symbol von der Symbolleiste und dann „Andere Makros“
2. Wählen Sie „Code Block“ in der „Formatting“-Kategorie
3. Wählen Sie die Sprache ihres Codes
4. Wählen Sie „Hinzufügen“
5. Tippen oder fügen Sie Ihren Code im Makro-Platzhalter ein 

Das Code Makro unterstützt viele Sprachen wie z.B. JS, C++, Java. 

Fazit: Developer Jira und Confluence Tipps

Jira lässt sich für die Zwecke von Scrum-Teams sinnvoll nutzen. Die Voraussetzung dafür ist, dass Developer das Tool nach gemeinsamen Standards und effizient einsetzen. Persönliche Dashboards, regelmäßige Aktualisierungen der Issues, richtige Labels, Komponenten und Filter helfen dabei.

Gegebenenfalls kann Sie dabei auch die Nutzung von Makros in Confluence unterstützen. Mit den oben dargestellten Tipps können Sie Ihre Arbeit als Teammitglied einfacher durchführen und auf Dauer erfolgreichere Ergebnisse erreichen. 

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel zu Jira und Confluence ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO
• Teil 2: Jira für Scrum Master
• Teil 3: Jira für Product Owner
• Teil 4: Jira für Developer (dieser Artikel)
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag 4 Developer Jira und Confluence Tipps, durch die Sie in der Scrum-Umgebung leichter arbeiten erschien zuerst auf TPG Projektmanagement Blog für Profis.

Lernen Sie, wie Sie diese Tools für eine bessere Begleitung Ihrer Prozesse sowie für die Team-Fortschrittsmessung nutzen können. Dieser Artikel ist Bestandteil unserer Blog-Reihe „Jira für Rollen im Projektmanagement“.

Diese Kapitel warten auf Sie:

• Welche Aufgaben eines Scrum Masters können Jira und Confluence unterstützen?
• Tipp 1: Quickfilter für das Sprintboard einsetzen
• Tipp 2: Retrospektive mit Sprint-Report verknüpfen
• Tipp 3: Retrospektiven-Vorlage in Confluence und weitere Templates
• Fazit – Jira lässt sich für Scrum Team Zwecke sinnvoll einsetzen

Legen wir los mit zwei kurzen Definitionen.

Was ist Jira?

Atlassian Jira ist ein webbasiertes Tool für Aufgabenmanagement, Projektmanagement und Fehlerverwaltung. Es kommt hauptsächlich bei Teams in der Produkt- und Softwareentwicklung zum Einsatz. Teams, die im agilen Projektmanagement arbeiten, werden mittels verschiedener Projekt- und Boardtypen (z.B. Kanban, Scrum, Projektmanagement u.v.m.) unterstützt.

Was ist Confluence?

Atlassian Confluence ist eine webbasierte Wiki-Software, die die interne Zusammenarbeit in Projektteams und im Unternehmen unterstützt. Das Tool lässt sich hervorragend mit Jira integrieren und bietet in dieser Kombination beste Voraussetzungen für agil arbeitende Teams.

Welche Aufgaben eines Scrum Masters können Jira und Confluence unterstützen?

Jira ist vor allem für Aufgabenmanagement gedacht und bildet dabei die Realitäten verschiedener Teams durch diverse Projekt- und Boardtypen gut ab.

Für Scrum Teams gibt es in Jira unter den Softwareprojekten den Vorlagentyp „Scrum“.

Diesen Vorlagentyp zeichnet gegenüber beispielsweise Kanban Projekten aus, dass er eine Sprint-Funktionalität hat. Dies bedeutet, dass ein Sprintboard für Planung und Durchführung von Arbeit in getakteten Iterationen zur Verfügung steht.

In Scrum Teams kümmern sich Scrum Master insbesondere darum, die Prozesse und die Zusammenarbeit des Teams bestmöglich zu unterstützen. Sie helfen der Organisation dabei, Scrum besser zu verstehen und anzuwenden.

Als Scrum Master können Sie die Arbeit Ihres Scrum Teams mit den speziellen Funktionalitäten von Scrum Projekten in Jira und Confluence gut begleiten. Drei aus unserer Sicht sehr wichtige Tipps lesen Sie im folgenden Text.

Fangen wir mit dem Sprintboard an.

Tipp 1: Quickfilter für das Sprintboard einsetzen

Quickfilter befinden sich direkt über dem Board. Mit ihnen lassen sich die Issues filtern, die in Form von Karten auf dem Board angezeigt werden. Wenn beispielsweise ein Quickfilter für eine bestimmte zugewiesene Person (Assignee) aktiviert ist, sind auf dem Board nur diejenigen Issues zu sehen, welche gerade dieser Person zugewiesen sind.

Dies lässt sich gut als Moderationshilfe einsetzen: Gerade bei neuen Scrum Teams ist es häufig noch ein Scrum Master, der zumindest unterstützend durch das Daily Scrum Event führt. Das Daily Scrum dient als tägliche Zusammenkunft zur Überprüfung des Fortschritts im Hinblick auf das Sprintziel.

Wenn das Team das Daily so gestaltet, dass jedes Teammitglied den anderen zu seinen aktuellen Themen etwas erzählt (etwa zu Arbeitsfortschritt, Hindernissen, Erfolgen), können Sie als Scrum Master auf einem geteilten Bildschirm deren aktuelle Themen schnell für alle transparent machen. Nutzen Sie dazu die jeweilige Aktivierung des Quickfilters für die betreffende Person.

Unser Tipp: Springen Sie bei Ihren Daily Scrum Events auf diese Weise einmal reihum durch die Mitglieder Ihres Teams – und durch das Board mithilfe der Quickfilter, wie oben beschrieben.

Quickfilter für Assignees gibt es in Jira oft schon voreingestellt. Darüber hinaus können Sie auch für viele andere Faktoren selbst weitere Filter einrichten – Board-Konfigurationsrechte vorausgesetzt.

Quickfilter für Jira Boards basieren auf der so genannten „Jira Query Language“. Alles, was sich in Jira filtern lässt, können Sie auch als Boardfilter einsetzen, wie zum Beispiel verschiedene Prioritätsstufen.

Auf diese Weise können Sie als Scrum Master sicherstellen, dass in den Team-Meetings und Scrum Events die Themen auf dem Board angezeigt werden, auf die sich das Team gerade konzentrieren möchte.

Tipp 2: Retrospektive mit Sprint Report verknüpfen

Zu Ihrem Aufgabenfeld als Scrum Master kann auch gehören, möglichst produktive Retrospektiven zu gestalten. Zum Beispiel, indem Sie diese selbst moderieren. Oder indem Sie den anderen Scrum Teammitgliedern zeigen, wie sie selbst Retrospektiven abhalten können, die zu sinnvollen und nachhaltigen Verbesserungen von Prozess und Teamarbeit führen.

Die Arbeit von Scrum Teams wird in Jira durch Scrum-projektspezifische Auswertungen in Form von Reports unterstützt. Für Retrospektiven am Ende eines Sprints kann Ihnen der Sprint Report in Jira helfen, die Effektivität der erledigten Arbeit besser zu verstehen.

Wenn aktive Sprints in Jira beendet werden, zeigt die Software automatisch einen Sprint Report an:

Tipp 3: Retrospektiven-Vorlage in Confluence und weitere Templates

Damit Teams ihre Retrospektiven moderativ begleiten und ihre Erkenntnisse notieren können, gibt es einige verschiedene Vorlagen in Confluence. Wenn Sie eine neue Seite in Confluence mit der entsprechenden Vorlage anlegen möchten, können Sie beim Beenden eines Sprints dem Link aus Schritt 3 im vorherigen Tipp folgen – oder einfach in Confluence auf Vorlagen (engl. Templates) klicken.

In einigen Confluence Versionen gelangen Sie zu den Vorlagen über den Erstellen-Button (engl. Create). Wählen Sie hier die Vorlagen mit dem Namen „Retrospective“.

Neben Metadaten wie Seitentitel, Datum und Teilnehmende der Retrospektive können Sie bei der Bearbeitung von Retrospektiven-Seiten in Confluence auf Basis dieser Vorlage eingeben, was die Teilnehmerinnen und Teilnehmer im nun gerade zu Ende gehenden Sprint beobachtet haben und welche Verbesserungsvorschläge sie für den nächsten Sprint hätten.

Außerdem lassen sich Action Items zur konkreten Umsetzung dieser Verbesserungen festhalten und zuweisen. Diese werden dann allerdings in Confluence und nicht in Jira getrackt.

Alternativ können Sie auch Backlog-Einträge in Jira für die Umsetzung erstellen.

Eine weitere Retrospektivenvorlage, die Confluence bietet, ist die „4Ls“-Retrospektive: Sie unterscheidet sich von der vorherigen Vorlage vor allem durch das eingesetzte Diskussionsformat. Statt „Start Doing“, „Stop Doing“ und „Keep Doing“ gibt es hier vier Kategorien:

1. „Loved“ (dt. „geliebt“): Was fanden die Teammitglieder in diesem Sprint am allerbesten?
2. „Longed For“ (dt. „danach gesehnt“): Was hätten sie sich zudem gewünscht?
3. „Loathed“ (dt. „verachtet“): Was fanden sie ganz furchtbar?
4. „Learned“ (dt. „gelernt“): Was haben sie in diesem Sprint dazugelernt?

Außerdem können sie gemeinsam Meilensteine festhalten, deren Erreichung sie besonders wichtig finden, und die 4 Ls nach diesen gruppieren.

Fazit – Jira lässt sich für Scrum Team Zwecke sinnvoll einsetzen

Jira und Confluence lassen sich für die Zwecke eines Scrum Teams dann wirklich sinnvoll einsetzen, wenn Sie als Scrum Master wissen, was Ihnen diese Tools bieten.

In den oben vorgestellten drei Tipps haben Sie erfahren, wie Sie Ihr Scrum Team effektiver begleiten mit den richtigen Filtern im Sprint-Board Ihres Teams, Sprint Reports für eine gemeinsame Analyse des Sprintverlaufs und Retrospektiven-Vorlagen in Confluence zum Moderieren und Festhalten Ihrer Diskussionen und beschlossenen Verbesserungen.

Damit können Sie auf Dauer nachhaltigere positive Veränderungen in Ihrem agilen Projektumfeld bewirken.

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel mit Scrum Master Jira / Confluence Tipps ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO
• Teil 2: Jira für Scrum Master (dieser Artikel)
• Teil 3: Jira für Product Owner
• Teil 4: Jira für Developer
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag 3 Scrum Master Jira / Confluence Tipps, durch die Sie leichter mit den Tools arbeiten erschien zuerst auf TPG Projektmanagement Blog für Profis.

• Aufgaben eines Product Owners
• Tipp 1: Stories schreiben, die nicht bleiben
• Tipp 2: Akzeptanzkriterien für gute Stories
• Tipp 3: Wenn es mal zu viel wird: Stories aufteilen
• Fazit – der Einsatz von Jira als Product Owner ist leicht, aber…

Doch bevor wir mit den Aufgaben und Tipps für den Product Owner starten ist es sinnvoll, einen Überblick über die verschiedenen Atlassian Tools zu haben. Klären wir also zunächst, worum es sich bei Jira und Confluence handelt.

Was ist Jira?

Atlassian Jira ist ein webbasiertes Tool für Aufgabenmanagement, Projektmanagement und Fehlerverwaltung. Es kommt hauptsächlich bei Teams in der Produkt- und Softwareentwicklung zum Einsatz. Agil arbeitende Teams werden mittels verschiedener Projekt- und Boardtypen unterstützt, z.B. Kanban, Scrum, Projektmanagement.

Was ist Confluence?

Atlassian Confluence ist eine webbasierte Wiki-Software, die die interne Zusammenarbeit in Projektteams und im Unternehmen unterstützt. Das Tool integriert sich gut mit Jira, daher bietet diese Kombination beste Voraussetzungen für agil arbeitende Teams.

Warum spezielle Jira Tipps für Product Owner?

Die Rolle des Product Owner wird mittlerweile in vielen Projekten eingesetzt – auch bei denen, die nicht auf dem Framework Scrum basieren, sondern lediglich Elemente daraus bedienen. Der Aufgabenbereich des Product Owner ist folglich von Unternehmen zu Unternehmen unterschiedlich, da Scrum nicht als einheitliche Grundlage verwendet wird.

Jira wiederum ist eine Aufgabenmanagement-Software, die weltweit bei über 14.000 Kunden von Atlassian im Einsatz ist. Sie hat demnach eine sehr hohe Verbreitung und wird sowohl in klassisch geprägten Konstellationen als auch in modernen Projektmanagement-Organisationen verwendet.

Als Product Owner kommen Sie heute kaum noch um den Einsatz digitaler Tools herum. Da Jira aktuell der Weltmarktführer für Aufgabenmanagement ist, konzentrieren wir uns in diesem Artikel auf die Tipps im Umgang mit Jira.

Aufgaben eines Product Owner

Wie bereits erwähnt, ist es von Organisation zu Organisation unterschiedlich, welche Aufgaben ein Product Owner übernimmt. Folgende Aufgaben fallen jedoch häufig in den Verantwortungsbereich der Rolle:

• Anforderungen aufnehmen und abstimmen
• Repräsentation von Stakeholdern im Team
• Kommunikation nach innen und außen
• Produkt- oder Projekt-Marketing
• Definition der Roadmap
• Beschreibung, WAS umgesetzt werden soll
• Priorisierung und Budgetierung
• Fokus auf der Produktentwicklung und Integration in die Unternehmensstrategie

Die meisten dieser Punkte können mithilfe von Jira umgesetzt werden. Der Schwerpunkt von Jira liegt dabei auf der Formulierung der Anforderungen und der Erstellung der Roadmap.

Schauen Sie sich nun die Liste noch einmal genau an. Fällt Ihnen etwas auf?

Bei den Anforderungen an den Product Owner liegen kaum Unterschiede zur Rolle der Projektleitung vor. Der Fokus liegt hier allerdings mehr auf dem Projekt und dessen erfolgreicher Umsetzung. Anders beim Product Owner: Der Fokus liegt hier darauf, dass das Produkt langfristig erfolgreich ist und dass es zur Gesamtstrategie des Unternehmens passt.

3 Tipps für Product Owner

Anforderungen aufnehmen, das WAS beschreiben, priorisieren und eine Roadmap erstellen. Das sind alles Aufgaben, die Sie als Product Owner in Jira abbilden können. Aber auch wenn Sie es nicht selbst machen, sondern die Aufgabe an das Team delegiert haben, werden Ihnen die nachfolgenden Tipps sicher weiterhelfen.

Tipp 1: Stories schreiben, die nicht bleiben

Stories schreiben in Jira ist sehr einfach. Doch gute Stories zu schreiben, die vom Team verstanden werden und das beinhalten, was die Stakeholder wollen, ist die Herausforderung.

Warum also Stories schreiben, die nicht bleiben?

Eine Story dient nur einem Zweck: der Umsetzung einer Anforderung oder eines Wunsches. Sie ist nicht für die Dokumentation ausgelegt, gleichwohl wird sie in manchen Unternehmen auch zur Dokumentation des Umgesetzten eingesetzt.

Was sind Anforderungen?

Anforderungen sind funktionale und nicht-funktionale Spezifikationen, Wünsche und Ideen. Meistens sind Anforderungen zunächst unklar und entwickeln sich mit der Zeit. Wenn sie spezifisch genug sind, können sie als Story in Jira erfasst werden.

Wo werden Anforderungen ansonsten beschrieben?

Stories können grundsätzlich immer verwendet werden.

Es kann sich aber auch anbieten, Anforderungen zunächst in Confluence zu beschreiben und mit den Stakeholdern abzustimmen. Aus einer Anforderung werden dann eine bis mehrere Stories erstellt. Dafür bietet sich Jira als Tool an. Sie sollten jedoch darauf achten, dass Sie die Stories in Jira mit den Anforderungen in Confluence verlinken.

Was ist der Vorteil des Einsatzes von Confluence?

Wenn Sie die Anforderungen in Confluence beschreiben, haben Sie dort auch die geeignete Stelle zur Dokumentation gefunden. Confluence kann besser zur strukturierten Ablage von Informationen verwendet werden.

Jira ist kurzlebig. Sobald eine Story abgeschlossen ist, verschwindet sie aus dem sichtbaren Bereich und muss gesucht werden, um wieder sichtbar zu werden.

Wie kann das noch strukturiert werden?

Jira arbeitet standardmäßig mit sogenannten Epics. Ein Epic ist eine große Story. Diese wird in Jira als ein Strukturelement dargestellt. Unter einem Epic können dabei mehrere Stories untergebracht werden. Die Struktur der Anforderungen kann wie im folgenden Beispiel aussehen:

Die Struktur gestaltet sich in der Regel so:

1. Aus einer Anforderung in Confluence können eine bis mehrere Epics erstellt werden.
2. Unter einem Epic kann es Story, Bug und Task geben.
3. Stories und Tasks können dabei wiederum in Sub-Tasks unterteilt werden.

Wofür werden Stories verwendet?

Stories werden für die Beschreibung von Kundennutzen verwendet. In den letzten Jahren hat sich dafür ein Template zur Beschreibung von User Stories etabliert:

Als [Nutzer] möchte ich [Funktion], um [Mehrwert].

Ein Beispiel: Als Autor des Blogbeitrags möchte ich das Schreiben von Stories vermitteln, um Product Owner in ihrer täglichen Arbeit zu unterstützen.

Wie werden Stories in Jira dargestellt?

Drei Felder sind in Jira Pflichtfelder: Projekt, Vorgangstyp und Beschreibung.

Das oben genannte Template wird in der Beschreibung eingetragen. Für unser Beispiel bedeutet das:

Nur der einleitende Text wird allerdings nicht ausreichen, um die Story umzusetzen. Im Fall des Blog-Beitrags werden noch benötigt:

• Keywords des Beitrags
• Länge des Beitrags
• Beitragsbilder
• Welche Tipps behandelt werden sollen

Sie müssen als Product Owner also noch weitere Informationen liefern, um die Story zu beschreiben. Dazu können Sie einfach weitere Informationen in der Beschreibung ergänzen oder auch als Anhang hinzufügen.

Eine Möglichkeit, um weitere Informationen zu erfassen, ist in Form der Akzeptanzkriterien.

Tipp 2: Akzeptanzkriterien für gute Stories

Das zuvor beschriebene Beispiel wurde um die Akzeptanzkriterien ergänzt:

In dem Beispiel wurden zur Story drei Akzeptanzkriterien in der Beschreibung aufgenommen:

• Stories schreiben, Akzeptanzkriterien und Stories aufteilen wurden beschrieben
• Beitragslänge von ca. 1.500 Zeichen
• Absätze gehen nicht über 3 bis 4 Sätze hinaus

Alternativ zum Erfassen in der Beschreibung kann auch ein To-Do-Plugin verwendet werden. In diesem Fall werden die Akzeptanzkriterien dann als einzelne Einträge dargestellt, die Sie auch abhaken können.

Tipp: Ein geeignetes Plugin zur Erfassung der Akzeptanzkriterien in Jira ist z.B. Acceptance Criteria for Jira von HeroCoders.

Für den Start mit der Arbeit mit Jira Akzeptanzkriterien ist das Beschreibungsfeld allerdings ausreichend.

Tipp 3: Wenn es mal zu viel wird: Stories aufteilen

Auch wenn Sie die zuvor beschriebene Hierarchie verwenden, werden einige Stories zu groß sein. Aber was genau bedeutet zu groß?

Ist eine Story zu groß, dann kann sie nicht in einem angemessenen Zeitrahmen umgesetzt werden und auch die Schätzung des Aufwands oder Komplexität ist schwierig bis gar nicht machbar.

Wenn Sie als Product Owner nach dem Scrum Framework arbeiten, ist Ihr Maßstab ein Sprint. Eine Story sollte so beschrieben werden, dass sie im Rahmen eines Sprints umsetzbar ist.

Lesetipp: Scaled Agile Framework (SAFe) – wie Sie Ihre Organisation agiler gestalten

Arbeiten Sie ohne Sprints, dann können Sie mit dem Team zusammen herausarbeiten, wie umfangreich eine Story maximal sein sollte. Meistens einigen sich Teams darauf, dass Stories innerhalb von 2 Wochen abgearbeitet werden sollten.

Wie teile ich eine Story in Jira auf?

Um eine Story in Jira aufzuteilen, können Sie die Split-Funktion verwenden. Klicken Sie dazu im Backlog mit der rechten Maustaste auf Ihre Story und dann im sich öffnenden Kontextmenü auf Split issue.

Daraufhin öffnet sich dieses Dialogfenster:

Für unsere Beispiel-Story wollen wir hier das Korrekturlesen und auch die Veröffentlichung in separaten Stories behandeln. Zu den beiden Stories gehören noch weitere Aufgaben. Zum Beispiel gehört bei der Veröffentlichung auch dazu, dass Links auf dem Blogbeitrag hinzugefügt werden und der Beitrag in die Seitenstruktur aufgenommen wird.

Für unsere ursprüngliche Story – das Erstellen des Beitrags – ist das nicht mehr relevant. Wir können das Erstellen des Beitrags als fertig betrachten, auch wenn der Blogbeitrag noch nicht veröffentlicht worden ist.

So lässt sich eine Story in sinnvolle Zwischenschritte unterteilen.

Wie kann die Story sinnvoll aufgeteilt werden?

In dem vorherigen Beispiel wurde die Aufteilung aus logischer Sicht vorgenommen. Wir haben drei Stories, die sich am Prozess der Veröffentlichung orientieren:

• Schreiben des Beitrags
• Korrekturlesen
• Veröffentlichung

Aber auch das Schreiben des Beitrags hätte bereits in mehrere Stories unterteilt werden können. Zum Beispiel in:

• Schreiben der Einleitung
• Schreiben von Tipp 1
• Schreiben von Tipp 2
• Schreiben von Tipp 3
• Integration von Bildern
• Erstellen des Fazits

Hier wäre die Unterteilung in die einzelnen Arbeitsschritte erfolgt. Das kann zum Beispiel dann erfolgen, wenn unterschiedliche Teams an einer Story arbeiten. Oder wenn ein Teil für einen Sprint geplant wird und der Rest erst später. So könnte der Beitrag über mehrere Sprints hinweg entstehen und die Stories könnten einzeln abgeschlossen werden.

Die Story könnte auch funktional aufgeteilt werden, z.B.:

• Schreiben eines Beitrags mit Tipps für Product Owner
• Recherche nach geeigneten Bildern

In diesem Fall wird die Story aufgeteilt in das eigentliche Schreiben und die Bilder-Recherche. Übertragen auf ein Software-Projekt heißt das:

• Implementierung der Backend-Funktionalität
• Bereitstellung eines Frontends zur Bedienung des Backends

Wie Sie sehen, gibt es viele Wege und Möglichkeiten, eine Story sinnvoll aufzuteilen. Besprechen Sie mit Ihrem Team, was am besten funktioniert und am hilfreichsten für Sie ist.

Wie stellen Sie Abhängigkeiten dar?

Wenn Sie eine Story aufgeteilt haben, ist dies sowohl in der ursprünglichen Story, als auch in den neuen Stories ersichtlich:

Über die Board-Konfiguration können Sie sich Abhängigkeiten auch im Backlog (oder auch auf dem Board) in Textform anzeigen lassen. Gehen Sie dazu in die Konfiguration (Board Settings) oben rechts:

Gehen Sie dann auf Card layout (1) und fügen Sie anschließend “Linked issues” bei der Backlog-Ansicht (2) hinzu. Vergessen Sie bitte nicht, auch auf “Add” (3) zu klicken.

Wenn Sie nun in das Backlog zurückgehen, werden die Abhängigkeiten unterhalb der Zusammenfassung mit ausgegeben.

So sehen Sie die Abhängigkeiten von Stories in Textform untereinander.

Fazit – der Einsatz von Jira als Product Owner ist einfach, aber…

Mit den zuvor genannten Tipps lässt sich Jira als Product Owner einfach anwenden. Stories lassen sich schnell und strukturiert erstellen. Im Zusammenspiel mit Confluence können Sie Anforderung transparent und nachhaltig erfassen.

Durch Beschreiben der Jira Akzeptanzkriterien ist ganz klar, was eine Story beinhalten muss. Und arbeiten mehrere Leute an einer Story oder wird die Story schlichtweg zu groß, lässt sie sich sehr einfach auf mehrere Stories aufteilen.

Doch wie bei so vielem: Der Teufel steckt im Detail.

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel zu Jira und Confluence ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO
• Teil 2: Jira für Scrum Master
• Teil 3: Jira für Product Owner (dieser Artikel)
• Teil 4: Jira für Developer
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Der Beitrag 3 Product Owner Jira / Confluence Tipps, durch die Sie leichter mit den Tools arbeiten erschien zuerst auf TPG Projektmanagement Blog für Profis.

• Definition Agiles Projektmanagement
• Vorteile von agilem Projektmanagement
• Woher kommt agiles Projektmanagement?
• Das Agile Manifest von 2001
• Die 12 Agilen Prinzipien zusammengefasst
• Agiles vs klassisches Projektmanagement – wichtigste Unterschiede
• Welche agile Methoden gibt es?
• Wann agiles Projektmanagement – für welche Projekte?
• Zusammenfassung – Agiles Projektmanagement Grundlagen

Legen wir los mit der Definition von „agil“ und „Agiles Projektmanagement“.

Das Adjektiv „agil“ meint, dass Management und Steuerung von Projekten und Prozessen sehr dynamisch und flexibel erfolgen. Damit lassen sich etwa Änderungsanträge schnell umsetzen.

Definition Agiles Projektmanagement

Agiles Projektmanagement folgt einem iterativen Ansatz, bei dem in kurzen Abständen (Teil)-Ergebnisse geliefert werden und schnelles Feedback von Stakeholdern eingeholt wird. Im Gegensatz zum traditionellen Projektmanagement wird die Einhaltung von Terminen und Kosten oder die Erfüllung eines spezifizierten Leistungsumfangs weniger oder nicht berücksichtigt. Stattdessen steht das zu liefernde Werk und dessen Akzeptanz durch die Endanwender:innen im Fokus.

Die Vorteile von agilem Projektmanagement

Agiles Projektmanagement bietet viele Vorteile für Unternehmen, die sich in einem dynamischen und komplexen Umfeld bewegen. Einige sind etwa:

• Hohe Anpassungsfähigkeit: Agiles Projektmanagement hat den Vorteil, schnell auf geänderte Anforderungen, Kundenwünsche oder Marktsituationen reagieren zu können. Durch kurze Iterationen und regelmäßiges Feedback kann das Projektteam flexibel auf Veränderungen eingehen und das bestmögliche Ergebnis erzielen.
• Hohe Kundenzufriedenheit: Die Kunden werden beim agilen Vorgehen aktiv in den Entwicklungsprozess eingebunden. Sie können ihre Erwartungen und Bedürfnisse jederzeit äußern und erhalten laufend (Teil-)Ergebnisse, die sie bewerten und abnehmen können. So entsteht ein Produkt, das genau auf den jeweiligen Kundenwunsch zugeschnitten ist.
• Hohe Qualität: Agiles Projektmanagement legt großen Wert auf die Qualität des Produkts oder der Dienstleistung. Durch automatisierte Tests, ständige Optimierung und kontinuierliche Verbesserung wird sichergestellt, dass das Produkt fehlerfrei, funktional und benutzerfreundlich ist.
• Hohe Kreativität: Die Kreativität und Innovation des Projektteams wird durch agiles Projektmanagement gefördert. Durch offene Kommunikation, flache Hierarchie und hohe Eigenverantwortung können die Teammitglieder ihre Ideen einbringen und umsetzen. Das führt zu neuen Lösungen und Wettbewerbsvorteilen.

Doch zunächst die Antwort auf die Frage: Wie und warum sind agile Methoden eigentlich entstanden?

Woher kommt agiles Projektmanagement?

Grundsätzlich gehen viele agile Ideen zurück auf die Philosophie des Lean Manufacturing, auch bekannt als Toyota Production System.  Dabei hat man in Japan bereits kurz nach dem 2. Weltkrieg verstanden, dass es auf zwei Dinge in der Produktion ankommen sollte:

• Den menschlichen Faktor – wenn ein Problem auftrat, sollten Menschen in die automatisierten Prozesse eingreifen können, anstatt tatenlos zuzusehen, wie fehlerhafte Ergebnisse gefertigt werden.
• Schlanke Prozesse – Ergebnisse sollten „just in Time“ erzeugt werden. Das bedeutet, dass jeder Prozess nur das hervorbringt, was der nächste Prozess braucht. Und das zur richtigen Zeit und in der richtigen Menge.

Diese Ideen wurden mit der Zeit auch in anderen Ländern bekannter. Sie waren schließlich auch eine wichtige Inspiration für 17 Männer, die in den 1990er-Jahren neue Management-Ansätze für die Softwareindustrie entwickelten – zuerst unabhängig voneinander.

Lesetipp: Agile Projektmanagement-Zertifizierungen im Vergleich – wie sollten Sie vorgehen?

Das Agile Manifest von 2001

2001 kamen diese Softwareexperten schließlich in einem Skiresort in Utah zusammen, um die Ideen festzuhalten, auf die sie sich alle als gemeinsame Grundlage einigen konnten. Sie unterschrieben das Agile Manifest, in dem einige Werte (linke Seite) definiert sind, die wichtiger sein sollten als andere (rechte Seite):

• Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
• Funktionierende Software ist wichtiger als ausführliche Dokumentation
• Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen
• Reaktion auf Veränderungen ist wichtiger als die Befolgung eines Plans

Ganz wichtig ist der Zusatz:

„Während die Dinge auf der rechten Seite durchaus einen Wert haben, schätzen wir die Dinge auf der linken Seite als wertvoller ein“.

Das wird oft übersehen.

Es ging den Autoren des agilen Manifests nicht darum, Prozesse, Dokumentation, Verträge und Pläne für überflüssig zu erklären. Vielmehr wollten sie, dass diese Dinge, so notwendig sie sein mögen, an die richtige Stelle rücken: An die hinter den Menschen, die im Projekt arbeiten und die Ergebnisse nutzen, und hinter die Ergebnisse der Arbeit.

Die 12 Agilen Prinzipien zusammengefasst

Da das agile Manifest eher kurz und knackig formuliert wurde, gibt es zum besseren Verständnis der Absichten dahinter noch 12 ergänzende Prinzipien. Diese finden Sie folgend zusammengefasst:

Qualität und Wert für den Kunden

Wert für den Kunden zu erzeugen, ist die höchste Maxime. Dies kam für die Autoren des agilen Manifests nicht von ungefähr: Die Standish-Group hatte 1996 in einer Studie festgestellt (Seite 15), dass 45 % aller Softwarefunktionen nicht verwendet wurden, 19 % selten.

Es ist zu hoffen, dass sich dieses Missverhältnis mittlerweile verbessert hat. Allerdings kennt wahrscheinlich jeder von uns Beispiele für teure und aufwändige Softwarefunktionen, die wir niemals nutzen. Deshalb helfen agile Projektmanagement-Methoden bei der Klärung der Frage, was der Kunde wirklich braucht und will.

Eins bedeutet Agilität nicht: Schnelle Ergebnisse um jeden Preis. Qualität und Wert für den Kunden stehen im Mittelpunkt und dürfen keinen zeitlichen oder monetären Zielen geopfert werden.

Mit Veränderungen umgehen und kontinuierlich besser werden

Agile Methoden bieten durch iterative und inkrementelle Vorgehensweisen Möglichkeiten, schnell auf Änderungen reagieren zu können.

Wer häufig in möglichst kurzen Entwicklungs- und Lieferzyklen (Iterationen) liefert, hat zwei Vorteile:

• Quick Wins: Frühe nutzbare Ergebnisse generieren bereits Einkommen
• Frühes Feedback: Die regelmäßige Präsentation und Übergabe von Ergebnissen ermöglicht, nah am Kunden zu sein und auf Wünsche und Anregungen besser eingehen zu können.

Wie kurz die Iterationen sein sollen, sieht jede agile Methode etwas anders vor. Es hängt auch von einigen projektspezifischen Faktoren ab wie Marktsituation und -fenster, Personalverfügbarkeit, vertragliche Vorgaben, Deadlines und vielen mehr.

Nicht nur das Ergebnis der Arbeit, sondern auch die Teamdynamik und die Prozesse selbst werden häufiger Prüfung unterzogen: In regelmäßigen Retrospektiven erörtern und diskutieren die Teammitglieder Probleme und finden Lösungen und Verbesserungsvorschläge.

Menschen im Mittelpunkt

• In agilem Projektmanagement geht es vor allem um Menschen und ihre Interaktionen (erster Wert des Manifests). Ohne enge Zusammenarbeit zwischen Projektteam und Stakeholdern keine brauchbaren Ergebnisse.
• Das “agile Mindset” beinhaltet den festen Glauben an das Gute im Menschen. Ein motiviertes Team, zum Beispiel dank einer guten Vision, mit der sich alle identifizieren können, hat bessere Chancen auf vorzeigbare Projektergebnisse, auf die alle stolz sein können. Interessant ist hier auch die genaue Formulierung: Der motivierte Mensch steht im Mittelpunkt des Projekts.
• Wenn wir gerade über Menschen sprechen, sollten wir nicht vergessen, dass Teammitglieder eine motivierende Umgebung, Unterstützung und Vertrauen brauchen. Wer all dies nicht bereitstellen will oder kann, braucht sich an agilen Methoden kaum zu versuchen.
• Agile Methoden sind für komplexe Umgebungen mit unsicheren Anforderungen gemacht. Es scheint fast so, als soll dazu ein Ausgleich gefunden werden, um in all der Hochtechnologie, die von agilen Teams entwickelt wird, den Menschen nicht aus dem Blick zu verlieren. Ein Credo aller agilen Methoden ist deshalb die Bevorzugung von direkter Kommunikation, Angesicht zu Angesicht – nicht etwa per E-Mail, die normalerweise sehr zeitverzögert ist und oft in einer Flut an Information untergeht. Das kommt Verschwendung gleich, die wir ja vermeiden wollen.

Funktionierende Software als wichtigste Basis für Fortschrittsmessung

Vorgesetzte oder Kundenkontakte fragen oft nach ausführlichen Berichten zum Projektfortschritt. Diese zu erstellen, kostet Sie oft mehr Zeit, als Sie möchten? Sie haben das Gefühl, Ihre berichteten Zahlen sind zum Versandzeitpunkt bereits nicht mehr aktuell? Mit diesem Problem sind Sie nicht alleine. Mit Sicherheit findet in diesem Bereich einiges an Verschwendung von Zeit und Ressourcen statt.

In agilen Methoden gibt es nach wie vor Fortschrittsmessungen und KPIs, allerdings verschlankter gegenüber klassischen Methoden. Und prinzipiell zeigen aktuelle Arbeitsergebnisse am besten, wo ein Team steht.

Nachhaltigkeit und Einfachheit

Nachhaltigkeit ist in Zeiten knapper Ressourcen oberstes Prinzip. Also: Nicht mit schwer aufrechtzuerhaltenden Billigprodukten Mittel und Zeit verschwenden.

Zu Nachhaltigkeit gehört es auch, keine Menschen auszubeuten. Die Vermeidung von dauerhaft vorkommenden Überstunden im Team gehört dazu.

KISS – “Keep it simple, stupid!” ist ein bekanntes Motto. Wer allerdings versucht, wirklich immer nur das gerade Notwendige zu tun und eigentlich überflüssige Prozesse abzubauen, weiß, dass das sehr herausfordernd sein kann.

Das zehnte Prinzip sagt: „Einfachheit – die Kunst, die Menge nicht erledigter Arbeit zu maximieren –  ist essentiell“. Damit ist nicht etwa gemeint, sich auf die faule Haut zu legen – sondern eigentlich überflüssige Tätigkeiten zu identifizieren und zu streichen. Damit am Ende der Aufwand in die Arbeit gesteckt wird, die sich tatsächlich lohnt.

Selbstorganisation und Moderation

Informationen über hierarchische Strukturen hinweg und Befehlsketten machen Agilität fast unmöglich. Selbstorganisierte Teams sind notwendig: Sie haben ein hohes Maß an Demokratie und Konsensfindungsprozessen.

Das erfordert eine gewisse Teamreife und kann auch mal müßig werden. Sie sind dabei aber nicht alleine. Agile Coaches oder bei Scrum auch Scrum Master helfen, unterstützen und beraten. Wenn es einmal nicht mehr weitergeht, hauen sie im Notfall auch mit der Faust auf den Tisch und treffen Entscheidungen.

All diese Werte und Prinzipien waren von Programmierern vorrangig für die IT-Branche gedacht. Aber natürlich sind sie auch für Projekte außerhalb von Softwarethemen wichtig. Und sie können dort genauso angewendet werden.

Agiles vs klassisches Projektmanagement – wichtigste Unterschiede

Die Unterschiede zwischen agilem und klassischem Projektmanagement lassen sich grob zusammenfassen wie folgt:

Steht beim klassischen Projektmanagement das Ziel fest und Termine wie Kosten sind veränderbar, so ist es im agilen Ansatz anders: Termine und Kosten werden soweit möglich fixiert und das Ergebnis ist am Ende ggf. völlig anders, als zu Projektbeginn avisiert – aber es schafft den geforderten Kundennutzen!

Lesetipp: Projektmanagement-Methoden Vergleich: Agil, klassisch oder hybrid?

Welche agilen Methoden gibt es?

Einige der Unterzeichner des agilen Manifests haben eigene Methoden und Frameworks entwickelt. Jede davon mit eigenen Lösungsvorschlägen, wie die Ideen aus dem Manifest konkret angewendet werden können. Einige lassen sich auch gut miteinander kombinieren.

Das bekannteste und meistbenutzte Framework ist Scrum.

Einige Organisationen bieten dazu auch Scrum Zertifizierungen an, etwa zum:

• Professional Scrum Master der Scrum.org – 80 Multiple-Choice-Fragen in einer Stunde, nicht ganz einfach zu knacken und deshalb anerkannt
• Certified Scrum Master der Scrum Alliance – eine der ersten und ältesten Zertifikate im Scrum-Bereich

Einige weitere agile Projektmanagement-Ansätze unter vielen sind:

Extreme Programming (XP) – vor allem basierend auf Werten und Prinzipien für Entwicklungsteams und ihre Kunden. Einige XP-Prinzipien sind weltweit anerkannt und werden häufig eingesetzt, wie etwa Pair Programming oder Continuous Integration.

Kanban – ein Werkzeug zur Aufgabenplanung, das aus Lean Manufacturing entstanden ist („Kanban“ ist japanisch für „Schautafel“). Selbst, wenn dieser Begriff unbekannt ist, kennt fast jeder Tabellen mit Aufgaben in Spalten namens „To Do“, „In Progress“ und „Done“. Das Team schiebt die Aufgaben selbst zwischen den Spalten hin- und her. Software wie Trello bildet das recht simpel ab.

Ein wichtiges Prinzip im Kanban ist die Begrenzung von gerade stattfindender Arbeit (Work in Progress oder kurz WIP Limit): Da Teams, die versuchen, immer mehr zu erledigen, paradoxerweise immer langsamer Ergebnisse liefern, darf nie mehr als eine bestimmte Anzahl Aufgaben gleichzeitig in Arbeit sein.

• Test-Driven Development (TDD) – ein Ansatz der Softwareentwicklung, bei dem zuerst Test Cases geschrieben werden, „gegen“ die dann Code geschrieben wird. Zunächst schlagen deshalb alle Test Cases erst einmal fehl. Steht der Code, wird er gemäß den Test Cases getestet und dann für gut befunden, wenn dieser Test erfolgreich war. So soll vermieden werden, dass Dinge entwickelt werden, die überhaupt nicht angefordert sind.
• The Spotify Model – Die Firma Spotify hat ihren eigenen Weg zur agilen Organisation gefunden und diesen als Video auf Vimeo mit der Welt geteilt. In der Folge übernehmen nun viele Firmen diese Ansätze. Ein bisschen stellt sich dabei die Frage, wie erfolgversprechend es sein kann, auf andere Unternehmen zugeschnittene Lösungen für sich selbst zu kopieren.

Besonders geeignet, miteinander kombiniert zu werden, sind etwa:

• Scrum und XP, da Scrum das Prozess-Rahmenwerk liefert und XP Handlungsempfehlungen
• Scrum und Kanban (zu dieser Kombination bietet Scrum.org sogar eine eigene Zertifizierung)
• Zu einem gewissen Grad auch klassische und agile Methoden

Eine Zertifizierung, die deutlich mehr als nur Scrum abdeckt, sondern alle agile Methoden und die ihnen gemeinsamen Ideen dahinter unter einem Hut vereint, ist der Agile Certified Practitioner  des Project Management Institute (PMI®).

Die Vielfalt der Ansätze führt uns als Nächstes zur Frage: Welche Projekte und Umgebungen sind überhaupt für agile Methoden geeignet? Gibt es Faktoren, die eher dagegen sprechen?

Der Scrum Guide 2020

Zum 25. Geburtstag von Scrum, dem 18. November 2020, hat der Scrum Guide 2017 sein letztes Update bekommen. Im neuen Scrum Guide wird Scrum als Rahmenwerk beschrieben, das dabei hilft, durch adaptive Lösungen für komplexe Probleme Wert zu generieren. Dabei wurden aus der alten Version teilweise Passagen gekürzt oder sogar gestrichen.

Insgesamt beschreibt der Scrum Guide 2020 jetzt weniger, wie die Elemente von Scrum umgesetzt werden sollen. Das erleichtert das inhaltliche Verständnis beim Lesen.

Weitere Änderungen des Scrum Guides 2020 sind außerdem:

• Rollen: Statt „Development Team“ ist jetzt die Rede von „Developers“
• Es gibt drei Zielsetzungsebenen, denen das Team sich verschreiben soll: Das Product Goal für das Produkt, das Sprint Goal für den Sprint und die Definition of Done für das Inkrement
• Der Scrum Master ist nun offiziell verantwortlich für die Effektivität des Scrum Teams
• Statt „selbstorganisiert“ ist das Scrum-Team nun „self-managing“

Hier finden Sie den Scrum Guide 2020 zum Download.

---

Wann agiles Projektmanagement – für welche Projekte?

Agiles Projektmanagement wurde für hochkomplexe Umgebungen wie in der Softwarebranche entwickelt. Dennoch erfreuen sie sich auch in anderen Bereichen steigender Beliebtheit.

Wann also passt agiles Projektmanagement? Agile Methoden passen für alle Projekte oder Projektumgebungen mit einem hohen Maß an Unsicherheit bei z.B.

• Anforderungen
• verwendeten Technologien
• Risiken
• Umgebungskomplexität

Und wenn das Ziel zu Beginn noch nicht klar definiert ist und häufige Änderungen zu erwarten sind, dann passen agile Methoden ebenfalls.

Zusammengefasst: Agile Methoden werden besonders in Projekten eingesetzt, die zu Anfang sehr unklare Anforderungen haben. Oft sind häufige Änderungen abzusehen. Meist gibt es sogar nicht mehr als nur eine Vision. Diese soll dann auf innovative Weise vom Team umgesetzt werden.

Knapp ein Drittel aller Projektmanagerinnen und Projektmanager leitet nach eigenen Angaben Projekte, bei denen die Identifizierung der Anforderungen Teil des Projekts ist – Tendenz steigend.

Für solche Situationen bieten agile Methoden Wege, mit denen Sie besser durch unsichere Gewässer navigieren. Vorteile ergeben sich unter anderem durch:

• Kurze Planungshorizonte, nur grobe langfristige Planung
• Kurze und häufige Iterationen als Liefer- und Feedbackzyklen mit inkrementeller Ergebniserzeugung
• Klare Taktung und Rhythmisierung der Arbeit durch die Iterationen
• Enge Einbindung der Stakeholder von Anfang an
• Selbstorganisierte Teams, Unterstützungsprozesse und Motivatoren
• Räumliche Zusammenführung von Teams und Fokussierung auf Ergebnisse
• Klar kommunizierte Visionen für das Produkt bzw. das Ergebnis
• Vermeidung von Verschwendung von Zeit und Ressourcen oder zu viel Verwaltungsaufwand
• Führungsstile mit positiver Grundhaltung sowie flache Hierarchien

Es stellt sich die Frage: Gibt es auch Projekte und Branchen, für die agiles Projektmanagement nicht so geeignet ist?

Hier ist vielleicht der Ansatz des Hybriden Projektmanagements der richtige. Lesen Sie dazu den folgenden Artikel.

Lesetipp: Hybrides Projektmanagement und Vorgehensmodell – Wie Sie agile und klassische Methoden verbinden

Zusammenfassung – Agiles Projektmanagement Grundlagen

In diesem Artikel haben Sie erfahren, was agiles Projektmanagement ausmacht und was seine Vorteile gegenüber der klassischen Herangehensweise sind. Sie haben die wichtigsten Werte und Prinzipien des Agilen Manifests kennengelernt und mehr über einige agilen Methoden erfahren. Außerdem kennen Sie jetzt die wichtigsten agilen Projektmanagement-Zertifizierungen. Und Sie wissen, für welche Projekte agile Methoden besonders geeignet sind.

Grundsätzlich gilt zum Schluss: Agilität und die Haltung dahinter können Sie nicht erzwingen. Sie sind am wirkungsvollsten, wenn die Vorzüge bei der Projektabwicklung im Team freiwillig zum Vorschein treten dürfen.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig beim TPG Scrum Grundlagen Seminar.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

FALSE

---

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag Agiles Projektmanagement Grundlagen – Definition, Vorteile und Methoden für Einsteiger erschien zuerst auf TPG Projektmanagement Blog für Profis.

Die Projektarbeit benötigt künftig einen klareren Fokus auf den Geschäftswert, mehr Innovationskraft und Kreativität sowie auch kürzere aber solide Planungshorizonte. Dass Unternehmen diesen Wechsel vollziehen, zeigt sich unter anderem am Entstehen neuer agiler Berufsbilder. Und hier spielen agile Projektmanagement Zertifikate eine Rolle.

Lesen Sie in diesem Beitrag:

• Neue Berufsbilder durch agiles Projektmanagement
• Warum sind Scrum-Zertifizierungen sinnvoll?
• Weitere Ansätze und Zertifikate für agiles Projektmanagement
• Übersicht wichtiger agiler Projektmanagement Zertifikate
  • PMI Agile Certified Practitioner (PMI-ACP)
  • Certified Scrum Master (CSM)
  • Professional Scrum Master I (PSM I)
  • Certified Scrum Practitioner (CSP)
  • Scaled Agile Framework (SAFe)
• Welche agile Zertifizierung ist die Richtige für Sie?
• Zusammenfassung: Agile PM-Zertifizierungen

Legen wir los!

Neue Berufsbilder durch agiles Projektmanagement

Wussten Sie, dass sich ‚Scrum Master‘ und auch ‚Product Owner‘ immer mehr zur eigenständigen Berufsbezeichnung mausern?

Vom Namen einer Rolle im Scrum-Team kommend, werden diese Begriffe immer häufiger in Stellenanzeigen explizit ausgeschrieben. Und Firmen nehmen diese Bezeichnungen in die Karrierepfade für die Mitarbeitenden auf.

Wie in jedem Bereich zählt hier die Erfahrung der Kandidatinnen und Kandidaten. Sie darf auf keinen Fall unterschätzt werden. Scrum Master brauchen in ihrer hochgradig vermittelnden und unterstützenden Rolle neben genug Berufserfahrung zudem:

• gute Menschenkenntnis
• Feingefühl
• Moderationsfähigkeit
• Konfliktlösungskompetenz

Warum sind Scrum-Zertifizierungen sinnvoll?

Rund um Scrum gibt es viele Missverständnisse. Die erfolgreiche Einführung der Methoden hängt auch stark vom Wissensschatz der Beteiligten ab.

Daher können Grundlagen für agile Projektmanagement Zertifizierungen wie etwa der „Professional Scrum Master I“ von Scrum.org oder der „Certified Scrum Master“ von der Scrum Alliance sehr hilfreich sein.

Diese beiden Zertifizierungen sind für Einsteiger:innen in die agilen Methoden gedacht.

Zunächst signalisieren Sie als zertifizierte Person, dass Sie die Grundprinzipien des Scrum Framework verstanden und dies in einer Prüfung unter Beweis gestellt haben.

Außerdem zeigen Sie durch eine der oben genannten Zertifizierungen die Bereitschaft:

• in einer solchen Rolle andere zu führen und unterstützen,
• der Organisation bei der Umsetzung von Scrum zu helfen und
• selbst mehr Erfahrung mit Scrum sammeln zu wollen.

Der letzte Punkt ist besonders wichtig, wenn Sie selbst noch am Beginn einer Scrum-Karriere stehen.

Durch agile Zertifizierungen signalisieren Sie als angehender oder bereits aktiver Scrum Master, dass Sie die relevanten Inhalte des Scrum Guides und weitere Literatur gelernt und dieses Wissen in einer Prüfungssituation unter Beweis gestellt haben.

Weitere Ansätze und Zertifikate für agiles Projektmanagement

Ein hervorragender Scrum Master verengt den Blick nicht auf Scrum allein. Es gibt eine Vielzahl agiler Methoden und Ansätze. Sie können miteinander kombiniert werden und haben viele Aspekte gemeinsam. Beispielsweise basieren viele Methoden auf:

• ein vertrauendes und offenes Menschenbild oder
• einer iterativ-inkrementelle Arbeitsweise.

Außerdem gibt es Umfeld-Themen in Organisationen, denen agile Methoden oft weniger Beachtung schenken. Hier sind beispielsweise zu nennen:

• Portfoliomanagement
• Ressourcenmanagement
• Projektauswahlmethoden
• Organisationsstrukturierung
• etc.

All dies führt nun von der Produktentwicklung auf Einzelteamebene, für die Scrum primär entwickelt wurde, zurück zu Projektmanagement-Themen. Dies erfordert einen ganzheitlichen und eher übergeordneten Blick auf die Themen.

Hier kommt der PMI-ACP® („Project Management Institute Agile Certified Practitioner“) ins Spiel.

PMI Agile Certified Practitioner (PMI-ACP)

Das PMI-ACP-Zertifikat ist für Personen gedacht, die bereits (agile) Projekterfahrung vorweisen können. Es hat den Anspruch, die Ideen aller agilen Methoden zu sammeln und standardisiert zusammenzufassen.

Dies ist ein Ziel, mit dem es das Project Management Institute (PMI)® durchaus ernst meint: So wurde sein Standardleitfaden für die Projektmanagementbranche, der „Guide to the Project Management Body of Knowledge“ (PMBOK® Guide) in seiner 6. Ausgabe im September 2017 als Bundle zusammen mit dem Agile Practice Guide herausgebracht. Mittlerweile gibt es den PMBOK® Guide in der 7. Ausgabe – der Agile Practice Guide aber ist immer noch aktuell.

Download (PDF): Hybrid – Wie Sie agile und klassische PM-Methoden verbinden

Laden Sie sich dieses PDF mit vielen praktischen Tipps zum Um- und Einsetzen von hybridem Projektmanagement jetzt kostenlos herunter.
* Pflichtfeld  |  Datenschutzhinweise

Dieses Formular wird durch Ihre Cookie-Einstellung zu unserer Website blockiert. Bitte klicken Sie hier und wählen Sie mindestens die Marketing-Cookies aus. Dann wird dieses Formular angezeigt. Vielen Dank.

Agile Practice Guide

Der Agile Practice Guide enthält, neben Betrachtungen zu einzelnen agilen Methoden, auch  Leitfäden und Hilfestellungen für situative Methodenauswahl sowie Brückenschläge zu klassischen Projektmanagement-Methoden.

Diese werden immer noch sehr dringend benötigt an all den Punkten, an denen agile Ansätze bei der Problemlösung nicht ausreichend dienen können.

Die Inhalte des Agile Practice Guide sind aus einer Zusammenarbeit des PMI mit der Agile Alliance (ein Zusammenschluss vieler Förderer der agilen Ideen und nicht zu verwechseln mit der Scrum Alliance) entstanden.

Dies signalisiert eine solide Expertenbasis für den neuen Agile Practice Guide.

Seit Ende März 2018 ist dieser Guide auch die offizielle Prüfungsreferenz für den PMI-ACP – aber nur als eine von vielen relevanten Quellen aus dem Katalog agiler Literatur.

Die Popularität des Agile Certified Practitioner Zertifikats steigt in letzter Zeit stark an. Folglich ist der Bedarf an qualitativ hochwertigem Material zur Prüfungsvorbereitung vorhanden.

Immerhin hilft der Agile Practice Guide Prüfungskandidaten aber dabei, die Perspektive des PMI auf agiles Projektmanagement besser einordnen zu können sowie die vorgestellten Methoden in der Praxis anzuwenden.

Kombination von PMI-ACP mit der PMP-Zertifizierung

Der PMI-ACP eignet sich übrigens sehr gut als Kombi-Zertifikat zum klassischen PMP® (Project Management Professional) des PMI.

Für eine Kombination spricht auch, dass die Prüfungsvoraussetzungen für Personen mit PMP® Zertifikat leichter zu erfüllen sind. Wenn Sie also PMP sind, dann müssen Sie keine zusätzliche Projekterfahrung nachweisen. In Bezug auf agile Projekterfahrung und Training gilt dies allerdings nicht. Nachweise dazu werden nach wie vor von allen Kandidat:innen verlangt.

So erhält die PMP-Prüfung seit Anfang 2021 zusätzlich Fragen zu drei Projektmanagement-Ansätzen:

• Prädiktiv
• Adaptiv / agil
• Hybrid

Damit müssen auch PMP-Prüflinge einige agile Ideen und Methoden kennen, z.B. Backlog-Pflege, Schätzmethoden oder Retrospektiven.

Download (PDF): PM-Methoden – agil, klassisch oder hybrid? (ein Vergleich)

In diesem herunterladbaren Artikel zum PM-Methoden Vergleich (agil, klassisch und hybrid) erfahren Sie die Unterschiede und erhalten mehr Klarheit im Umgang mit der Wahl der richtigen Methode.
* Pflichtfeld  |  Datenschutzhinweise

Dieses Formular wird durch Ihre Cookie-Einstellung zu unserer Website blockiert. Bitte klicken Sie hier und wählen Sie mindestens die Marketing-Cookies aus. Dann wird dieses Formular angezeigt. Vielen Dank.

Übersicht wichtiger agiler Projektmanagement Zertifikate

Im Folgenden finden Sie die in diesem Artikel erwähnten agilen Zertifikate noch einmal gegenübergestellt. Zusätzlich werden die Zertifizierungen Certified Scrum Practitioner (CSP) für Fortgeschrittene und Scaled Agile Framework (SAFe) für die Skalierung agiler Methoden aufgegriffen.

PMI Agile Certified Practitioner (PMI-ACP)
Aussteller des Zertifikats: Project Management Institute

Voraussetzungen

– 2000 Stunden Projekterfahrung (entfällt für PMP Zertifikatsträger)
– 1500 Stunden Erfahrung in agilen Umgebungen
– 21 Stunden Training in agilen Methoden (z.B. durch das PMI-ACP Seminar bei TPG)

Art der Prüfung

Vor Ort im Test-Center; 120 Multiple-Choice-Fragen mit vier Antwortoptionen und je einer richtigen Antwort, zu beantworten in 3 Stunden

Auch möglich: Online Proctored Exam (Online-Prüfung mit per Webcam zugeschaltetem Prüfungsverantwortlichen)

Passing Score (Anteil benötigter richtiger Antworten)

Geheim (geschätzt auf ca. 70 %)

Kosten für Prüfung

$ 435 (PMI® Mitglieder, etwas höher für Nichtmitglieder)

Gültigkeit

3-Jahres-Zyklus (30 Professional Development Units – PDUs müssen in diesem Zeitraum in agilen Arbeitsumgebungen und / oder Aktivitäten erarbeitet sein.)

Zweck

Standardisierung möglichst vieler agiler Methoden

Zielgruppe

Personen, die ihre Erfahrung mit agilen Methoden und ihr Verständnis davon verbessern und unter Beweis stellen möchten

Certified Scrum Master (CSM)
Aussteller des Zertifikats: Scrum Alliance

Voraussetzungen

Absolvierung eines 2-tägigen Seminars durch einen speziell autorisierten Trainer, nicht länger zurückliegend als 90 Tage vor der Prüfung

Art der Prüfung

Online; 35 Multiple-Choice-Fragen, zu beantworten in 1 Stunde

Passing Score (Anteil benötigter richtiger Antworten)

68,6%

Kosten für Prüfung

Prüfung nur erhältlich nach Seminarbuchung und in Seminarkosten enthalten

Gültigkeit

2-Jahres-Zyklus (Rezertifizierung danach online für 100 $)

Zweck

Klarstellung und Förderung von Scrum

Zielgruppe

Personen, die einen ersten Schritt hin zur Beherrschung von Scrum machen möchten

Professional Scrum Master I (PSM I)
Aussteller des Zertifikats: Scrum.org

Voraussetzungen

Keine formalen (tiefes Verständnis des Scrum Guides zum Bestehen notwendig; Probeprüfung „Scrum Open” gibt es auf scrum.org)

Art der Prüfung

Online; 80 Multiple-Choice-Fragen mit unterschiedlich vielen Antwortoptionen und einer oder mehreren richtigen Antworten, zu beantworten in 1 Stunde.
Tipp: Bei TPG erhalten Sie ein Scrum-Seminar mit anschließender Prüfungsmöglichkeit. Nach nur 3 Tagen können Sie damit Ihr PSM I Zertifikat zielsicher und schnell in Händen halten.

Passing Score (Anteil benötigter richtiger Antworten)

85%

Kosten für Prüfung

150 $

Gültigkeit

Unbegrenzt

Zweck

Klarstellung und Förderung von Scrum

Zielgruppe

Personen, die einen ersten Schritt hin zur Beherrschung von Scrum machen möchten

Certified Scrum Practitioner (CSP)
Aussteller des Zertifikats: Scrum Alliance

Voraussetzungen

Zertifikat als A-CSM, min. 2 Jahre Erfahrung in der Rolle des Scrum Masters innerhalb der letzten 5 Jahre.
Abschluss der am Ende des Kurses verteilten Hausaufgaben innerhalb von 12 Monaten.

Eine Teilnahme am Kurs ist auch ohne diese Voraussetzungen möglich. Allerdings wird dann kein Zertifikat erworben.

Art der Prüfung

–

Passing Score (Anteil benötigter richtiger Antworten)

–

Kosten für Prüfung

$ 250

Gültigkeit

Dauerhaft

Zweck

Ausbau der agilen Produktmanagement-Expertise

Zielgruppe

Die CSP-SM-Zertifizierung eignet sich für Scrum Master, wohingegen sich die CSP-PO-Zertifizierung für Product Owner eignet.

Scaled Agile Framework (SAFe)
Aussteller des Zertifikats: Scaled Agile, Inc.

Voraussetzungen

5+ Jahre in Software-Entwicklung, Testen, Geschäftsanalyse, Produkt- oder Projektmanagement & Erfahrung in Scrum

Kurs zur Abdeckung der SAFe-Inhalte durch Ausbildungsanbieter

Art der Prüfung

Multiple-Choice, 45 Fragen in 90 Minuten, online möglich.

Passing Score (Anteil benötigter richtiger Antworten)

76%, 34 Fragen

Kosten für Prüfung

$ 435

Gültigkeit

1 Jahr, nach Ablauf der Gültigkeit kann die Zertifizierung für $ 100 ohne erneute Prüfung verlängert werden.

Zweck

Agile Skalierung / Scrum Methoden

Zielgruppe

Führungskräfte, Scrum Master, Product Owner, Anforderungs-, Release- und Testmanager, Coaches, Projektleiter, die mehrere Teams erfolgreich agil organisieren wollen.

Welche agile PM-Zertifizierung ist die richtige für Sie?

Nun haben Sie die wichtigsten agilen Zertifizierungen kennengelernt. Doch woher wissen Sie, welche für Sie die richtige ist?

Zunächst empfehlen wir es als sinnvoll, bei den Grundlagen von Scrum zu beginnen. So schaffen Sie eine gute Basis für die Mehrzahl der oben genannten Zertifizierungen.

Anschließend haben Sie die Möglichkeit, Ihr Wissen wie in folgender Grafik gezeigt weiter auszubauen:

Zusammenfassung: Agile PM-Zertifizierungen

In diesem Artikel haben Sie erfahren, was agile Methoden allgemein sind und wo ihre Anwendung vorteilhaft sein kann. Weiterhin wurde ein besonderer Fokus auf Scrum gelegt.

Sie haben folgende agile Zertifizierungen kennengelernt:

• PMI Agile Certified Practitioner (PMI-ACP)
• Certified Scrum Master (CSM)
• Professional Scrum Master I (PSM I)
• Certified Scrum Practitioner (CSP)
• Scaled Agile Framework (SAFe)

Damit können Sie nun besser einschätzen, welcher Weg für Sie persönlich oder für Ihre Mitarbeitenden am sinnvollsten ist.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei den folgenden TPG Seminaren Scrum Seminar bzw. PMI-ACP Seminar.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

FALSE

---

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag Agile Projektmanagement-Zertifizierungen im Vergleich – wie sollten Sie vorgehen? erschien zuerst auf TPG Projektmanagement Blog für Profis.

In diesem Artikel lernen Sie alles über diese wichtige Rolle. Diese Kapitel warten auf Sie:

• Product Owner Definition
• Gibt es Product Owner nur in Scrum-Teams?
• Product Owner Aufgaben
• Verantwortung der Product Owner Rolle
• Qualifikation: Was muss ein Product Owner können?
• Was ist „Product Backlog-Management“?
• Metriken zur Messung von Produktnutzen
• Herausforderungen für Product Owner
• Zusammenfassung

Los geht’s.

Product Owner Definition

Der Scrum Guide definiert: Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht. Wie dies geschieht, kann je nach Organisation, Scrum-Team und Einzelpersonen stark variieren.

Gibt es Product Owner nur in Scrum-Teams?

Die Rolle des Product Owner kommt ursprünglich aus Scrum. Aber viele agile Entwicklungsteams  haben jemanden, der die damit verbundenen Aufgaben wahrnimmt – auch wenn sie nicht nach Scrum arbeiten.

In Extreme Programming, einem anderen agilen Ansatz neben Scrum, gibt es beispielsweise die Rolle eines „On-Site Customers“ oder eines „Customer Proxy“ – also jemandem, der gegenüber den Developern die Kundensicht vertritt und dabei aber selbst Teil des Produktentwicklungsteams ist.

Die Notwendigkeit dafür leuchtet schnell ein: Die meisten agilen Teams befassen sich mit innovativen Lösungen. Dabei sind sie oft von der Entwicklung, Weiterentwicklung und Aufrechterhaltung, bis hin zur Ablösung, komplett für „ihr“ Produkt verantwortlich. Sie brauchen also eine Person, die sich darum kümmert, dass diese Arbeit von Anfang an in die richtige Richtung geht. Das kann der Product Owner sein.

Product Owner Aufgaben

Die Rolle des Product Owner soll sicherstellen, dass das Produkt:

• den Markt bedient und Lösungen für vorhandene oder gar neu geweckte Nachfrage bietet
• dem Wettbewerb wenigstens standhält, oder besser: ihm voraus ist
• die Stakeholder und vor allem die Endkunden möglichst glücklich macht – aber natürlich nur gegen vertretbaren Aufwand und Kosteninvestitionen sowie ohne, dass die Wunschliste der Anforderungen ins Unendliche wächst
• Lösungen bietet, die wirklich sinnvoll und nützlich für die Kolleg:innen sind gegen einen vertretbaren Aufwand (gilt für interne Produktentwicklungen, etwa für andere Abteilungen in der eigenen Organisation)
• möglichst bald gewissen Zielvorstellungen entspricht, die mit Stakeholdern abgestimmt und dem Entwicklungsteam bekannt sind, bestenfalls eines, womit sich alle identifizieren können
• in einem bestimmten Zeitrahmen möglichst weit fortgeschritten in der Entwicklung ist, eventuell in Form von abgestimmten, schrittweisen Zwischenergebnissen
• Quick-Wins erzeugen kann, damit notwendige Liquidität für die Weiterentwicklung herrscht
• eigenen und äußeren Qualitätserwartungen entspricht
  

Um dieser sicherzustellen, sind wichtige Aufgaben des Product Owner im Detail:

1) Ziele und Vision entwickeln

• Ziele setzen und verfolgen: Product Owner müssen die größeren Ziele setzen und langfristig im Blick behalten. Die Developer hingegen kümmern sich um die iterative Umsetzung auf technischer Ebene.
• Produktvision entwickeln: Sie sollten eine Produktvision als langfristigen Nordstern mit Stakeholdern entwickeln und mit dem Team besprechen. (Ein Beispiel: „Die App „BestDoc“ ist eine Plattform zur Arztsuche, -bewertung und Terminbuchung am Smartphone – für Personen, die auf der Suche nach den besten Ärzten in der Region sind.“ Es kann aber auch ein Slogan sein oder etwas besonders Mitreißendes / Motivierendes.)

2) Stakeholder früh und häufig einbinden

• Ein Product Owner ist „Stakeholder-Versteher“, mit dem Ziel, ihre Interessen zu wahren, aber auch aktiv damit umzugehen und gegenüber dem Team gegebenenfalls zu filtern.

3) Übergeordnete Planung vornehmen

• Iterationen vorausplanen: Auf zeitnaher Ebene immer bereits die nächsten 1-3 Iterationen inhaltlich vorbereiten und mit einer groben Vorstellung für deren Zielsetzungen ans Team herantreten.
• Release-Pakete planen: Übergeordnete Zielsetzung und die richtige Planung; zum Beispiel, welche Funktionen wann live gehen sollen.

4) Erfolg und Nutzen messen

• Metriken festlegen, mit denen sich der tatsächliche Nutzen und die Werterzeugung im Produkt auch reaktiv messen lässt.

5) Product Backlog erstellen und pflegen

• Die Übersicht stetig selbst pflegen bzw. verfeinern oder dafür sorgen, dass es im Sinne des Product Owner von anderen erstellt wird.

6) Sprint-Reviews vorbereiten

• Welche Key-Stakeholder werden eingeladen und was sollen sie zu sehen bekommen? Welches Feedback wird von ihnen benötigt? Wer im Team kann welche Funktionen zeigen?

7) An Retrospektiven aktiv teilnehmen

• Wo stehen wir als Team und mit unseren Werkzeugen und Prozessen, wo können wir uns verbessern? An team-internen Aktivitäten zur kontinuierlichen Verbesserung arbeitet der Product Owner genauo mit wie die anderen Teammitglieder.

Verantwortung der Product Owner Rolle

Damit sorgt die Product Owner Rolle im umgekehrten, ergebnisoffenen Dreieck der agilen Welt die Hauptverantwortung für die Ausbalancierung und Priorisierung der Aspekte Inhalt, Kosten und Zeit.

Zusammen mit dem Team der Umsetzer ist ein Product Owner außerdem für die Einhaltung von Anforderungen an die Qualität zuständig. Einige Dreiecksmodelle nennen diese gerne als zusätzlich zu beachtende Dimension.

Insofern lässt sich tatsächlich sagen: Die Product Owner Rolle umfasst viel davon, was klassische Projektleitung beinhaltet.

Allerdings sind Projektmanager:innen auch für die Entwicklung des Projektteams, die Aufgabenverteilung an Projektmitarbeitende und deren Überwachung verantwortlich. Sie können zudem bereits in der Projektinitiierung, wie etwa während der Projektauswahl oder Machbarkeitsprüfungen, in Erscheinung treten.

Dies ist bei der Product Owner Rolle meist anders:

Lösungsorientierte Produkt-Perspektive

Agile Product Owner kümmern sich um eine lösungsorientierte Produkt-Perspektive entlang des gesamten Lebenszyklus ihres Produkts. Sie denken an ihr Produkt und dessen Anwender:innen, inklusive betrieblicher Abläufe nach der Erstentwicklung. Dabei lösen sie sich von der reinen Projektdenke.

Initialer Backlog

Eine frühe Aufgabe des Product Owner ist typischerweise das Erstellen eines initialen Backlogs (der Liste aller Anforderungen ans Produkt) zusammen mit den Stakeholdern – und eventuell dem Entwicklerteam oder Vertretern daraus.

Umsetzung des Produkts im Detail

Das Unterfangen wurde bereits z.B. durch das Produktmanagement entschieden, das im agilen Kontext meist eine übergeordnete Portfolioperspektive hat. Der Product Owner widmet sich hingegen der Umsetzung eines Produkts im Detail.

Unterstützung durch agile Coaches

Teamentwicklung, Konflikte, Prozessgestaltung und Regeln für die Zusammenarbeit sind Sache agiler Coaches (in Scrum: Scrum Master). Sie helfen außerdem Product Ownern bei ihren Aufgaben, so dass diese bei Bedarf immer Unterstützung haben.

Abstimmung mit dem Entwicklerteam

Die Aufgabenverteilung macht das selbstorganisierte Entwicklerteam unter sich aus. Auch übernimmt es dabei die Qualitätsverantwortung in den Iterationen weitgehend selbst. Das Team muss sich aber häufig mit dem Product Owner abstimmen, damit es hierbei nicht von Zielen, Anforderungen und Marktrealitäten abschweift.

Gemeinsame Verantwortung mit dem Entwicklerteam

Statt Berichtswesen zeigen die Developer anhand von regelmäßigen Demonstrationen ihrer Arbeitsergebnisse (z.B. neuen Funktionen im Produkt), wo sie stehen. Beim Product Review für die Stakeholder, am Ende der Iteration, tun Product Owner und Development dies nochmals gemeinsam für alle Personen außerhalb des agilen Produktteams. Gemeinsam übernehmen sie die Verantwortung für die eigenen Resultate.

Die wichtigste Verantwortung für die Product Owner Rolle ist es, verschiedene Faktoren gegeneinander abzuwägen und auszubalancieren:

• Kosten, Profitabilität und Rentabilität der Produktentwicklung gegen Kundenzufriedenheit und Marktfähigkeit
• Die oftmals nicht enden wollenden Wünsche und Anforderungen der Stakeholder gegen die Kapazität und Fähigkeiten des Entwicklerteams
• Produktivität des Teams (Output) gegen Ergebnisqualität und Nutzen (Outcome)
• Proaktive Maßnahmen (Risikoerforschung, Entwicklung neuer Funktionen, Integration) gegen reaktive (Tests, Fehlerbehebung, Qualitätssteuerung, Wartung)

Idealerweise können Product Owner in ihrer Rolle diese oftmals konträren Aspekte gut ausbalancieren. Das ist jedoch keine einfache Aufgabe. Um sie gut wahrzunehmen, sollten Personen in dieser Rolle Kenntnisse und Fähigkeiten erlangen und einsetzen, die auch für Projektmanager und Projektmanagerinnen wichtig sind.

Qualifikation: Was muss ein Product Owner können?

Folgende Qualifikation, Kenntnisse und Fähigkeiten sollte ein Product Owner für seine Aufgaben haben:

• Rentabilitätsberechnungen
• Das Sicherstellen von Nutzen durch die entwickelte Lösung („Benefit Engineering“)
• Methoden der Risikoanalyse
• Anforderungsanalyse und Priorisierungstechniken in Bezug auf das Management des Product Backlog
• Stakeholderanalyse und gutes Gespür im Umgang mit diesen Personen
• Sicheres Auftreten und Verhandlungsgeschick
• Innovationsbewusstsein
• Menschenkenntnis, auch im Umgang mit dem Entwicklerteam

Product Owner müssen also mehr können, als der Scrum Guide zu ihrer Rolle angibt.

---

Was ist „Product Backlog-Management“?

Hierzu finden sich einige Aussagen im Scrum Guide. Dieser sagt Folgendes:

„Das Product Backlog-Management umfasst:

• Die Product Backlog-Einträge klar zu formulieren
• Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionen optimal erreicht werden können
• Den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt
• Sicherzustellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum-Team als nächstes arbeiten wird
• Sicherzustellen, dass das Entwicklungsteam die Product Backlog-Einträge im erforderlichen Maße versteht.“

Natürlich reicht auch diese Liste im Scrum Guide allein für die Praxis nicht aus. Dazu ist sie auch keineswegs gedacht. Ein guter Product Owner ist jemand, der es schafft, Requirements Engineering im agilen Kontext zu betreiben.

Zur Verfeinerung des Product Backlogs gehören:

Entscheidungen zu Backlog-Inhalten

Was soll im Backlog stehen und was nicht? „Nein“ sagen zu können gegenüber Stakeholdern zu Anfragen, die zum gegenwärtigen Zeitpunkt unpassend oder unrealistisch sind. Ein Unternehmen muss Entscheidungen des Product Owner respektieren, auch wenn es manchmal schwerfällt. Dazu gehört zudem: Neue Einträge hinzufügen, sobald es nötig ist und überflüssig gewordene streichen.

Entscheidungen zur Art der Einträge

Funktionsbeschreibungen, Spezifikationen, Bugfixes, nichtfunktionale Anforderungen etwa an Sicherheit, Skalierbarkeit, Wartbarkeit? Oder die ergebnisorientierte Lösungsbeschreibung aus Kundensicht (User Stories) in einem kurzen Satz? Sinnvoll ist die Mischung, da keiner dieser Eintragstypen alle Anforderungen an ein Produkt voll erfüllt.

Entscheidungen über Anforderungen und Zeitpunkt

Welche Anforderungen sind für welche Iteration und für welches Release vorgesehen? Konkret ist dies die Sache des gesamten Teams in der Iterationsplanung. Auch die meisten Stakeholder wollen hier gerne mitreden. Eine User Story Map kann hilfreich sein.

Aufwandsschätzungen

Das Einholen von groben, relativen Aufwandsschätzungen mit Story Points oder ähnlichem durch das Team. Denn auf Product Backlog-Ebene sind Anforderungen vor allem aus Anwendersicht formuliert. Das Herunterbrechen in Aufgaben erfolgt erst in der Iterationsplanung. Die Aufgaben kommen dann ins Iterations-Backlog.

Entscheidungen über die Priorität der Einträge

Im Normalfall ist dies einfach eine lineare Liste im Product Backlog. Das heißt, die Priorität ergibt sich etwa aus der Reihenfolge: Dinge, die weit oben stehen, sind früher umzusetzen als Einträge weiter unten.

Unser Tipp: Formulieren und schätzen Sie nur die obersten Einträge im Backlog besonders gut. Nach unten hin ist dies weniger wichtig, denn diese Einträge könnten sich noch ändern oder ganz herausfallen.

Dieses Vorgehen nach dem „Just-in-Time“-Prinzip hilft Ihnen, Verschwendung durch Aufwand für nicht zeitnah anstehende Anforderungen zu vermeiden. Es folgt den DEEP-Kriterien. Auf diese Weise stellen Sie sicher, dass Ihr Arbeiten mit Product Backlogs agilen Denkweisen folgt und nicht etwa eine Wasserfallplanung mit neuem Namen ist.

Unser Tipp: Wenn Ihnen eine flache, lineare Backlog-Priorisierung nicht ausreicht, können Sie sich mit User Story Mapping als erweiterte Technik zum mehrdimensionalen Backlog-Management auseinandersetzen.

Metriken zur Messung von Produktnutzen

Was sind Metriken zum Messen von Produktnutzen? Diese Frage ist in dieser oder ähnlicher Form beliebt in Product Owner-Zertifizierungsprüfungen wie etwa der Scrum.org. Sie ist zunächst schwer verständlich: Wie messen wir als Team den Wert unseres Produkts? Rein anhand unserer Produktivität sicherlich nicht – diese kann hoch sein, aber wenn die Ergebnisse in die falsche Richtung gehen, bringt uns das kaum etwas.

Tatsächlich gibt das „Evidence-based Management“ einige Metriken vor, die noch teilweise unbekannt sind. Für Product Owner können sie jedoch sehr hilfreich sein.

Das Evidence-based Management kennt vier Hauptkategorien, in die einzelne Metriken fallen:

• Current Value: Er misst, wie das Produkt am Markt angenommen und genutzt wird. Aber es beachtet auch, wie gut die Stimmung im Team derer ist, die es entwickeln. Wie zufrieden sind mögliche Investoren?
  Beispielmetriken: Die in diese Kategorie fallen, sind etwa: Kundenzufriedenheitsindizes (bspw. aus Umfragen und Produktfeedback generiert), Messungen der Nutzung einzelner Funktionen im Vergleich zur Kundenzufriedenheit mit diesen.
• Time-to-Market: Er misst, wie lange es dauert vom Zeitpunkt, wenn eine neue Anforderung zum ersten Mal formuliert wird, bis der Urheber die Lösung in der Hand hält. Wie schnell lernen wir aus neuen Informationen und verwerten sie?
  Beispielmetriken: Release-Häufigkeit, Integrationshäufigkeit, Durchlaufzeit von Backlog-Einträgen, Vorlaufzeit.
• Ability to Innovate: Dies ermittelt, wie innovativ die Lösungsfindung ist. Wie neuartig sind die Funktionen und das Produkt generell? Diese Frage sollte auch bei der Weiterentwicklung an gewachsenen Systemen in Großkonzernen gestellt werden.
  Beispielmetriken: Nutzung einzelner Funktionen im Vergleich zu anderen, Aufwand oder Kosten für Neuentwicklung (in Prozent) gegenüber reaktiven Tätigkeiten wie Wartung, Messung der Zeit, die das Team tatsächlich am Produkt beschäftigt ist (im Vergleich zu anderen Aufgaben).

• Unrealized Value: Hier geht es darum, welches Potenzial momentan noch nicht ausgeschöpft ist. Wie sinnvoll wäre es, sich damit einmal näher zu beschäftigen?
  Beispielmetriken: Marktanteil, Erwartungen der Anwender im Vergleich zu dem, was sie bekommen.

Unser Tipp: Richtig wirkungsvoll sind solche Metriken, wenn Sie diese über längere Zeit hinweg erfassen. Dann können Sie Entwicklungen und Trends recht gut erkennen.

Lesetipp: 3 Jira Tipps für Product Owner, die Sie kennen sollten

Herausforderungen für Product Owner

Bislang haben Sie die Rolle des Product Owner und einige wichtige Werkzeuge und Aufgaben im Detail kennengelernt. Jetzt erfahren Sie, welchen Herausforderungen Product Owner in ihrem Alltag häufig begegnen.

Umfragen durch agile Coaches unter Product Ownern und Developern haben ergeben, dass das vor allem die folgenden Herausforderungen sind:

Zeitmangel des Product Owner

Mögliche Probleme: Die Rolle darf nicht in Vollzeit ausgefüllt werden, sondern muss noch neben Linienarbeiten stattfinden. Es sind zu viele Produkte und Teams gleichzeitig zu betreuen. Die Balance zwischen Zeit für Stakeholder und für die Teams ist schwer.
Mögliche Lösung: Ursachenanalyse: Was ist wirklich der Grund für die Zeitprobleme? Was lässt sich ändern? Gibt es Zeitmanagement-Methoden, die helfen könnten? Vielleicht hilft eine Repriorisierung von Projekten und Anforderungen?

Mangelndes Wissen über Aufgaben

Mögliche Probleme: Der Product Owner weiß zu wenig über die eigene Rolle und agile Entwicklung. Die Rolle wird oft einfach vergeben ohne weitere Erklärung oder Training.
Mögliche Lösung: Weiterbildung, Literatur wie etwa das sehr zu empfehlende Buch „Der professionelle Product Owner“ von Don McGreal und Ralph Jocham.

Mangelndes Wissen zu Tools

Mögliche Probleme: Der Product Owner kennt nötige / wichtige Dokumente und Metriken für seine Arbeit nicht.
Mögliche Lösung: Auseinandersetzung mit Tools zur Erstellung von Produktvisionen, Impact-, Story- und Roadmaps, Release-Planungsstrategien, Evidence-based Management, Stakeholderanalyse-Werkzeugen.

Mangelnde Entscheidungsgewalt

Mögliche Probleme: Der Product Owner ist nicht autorisiert zu entscheiden. Eskalationspfade sind zu kompliziert und langwierig.
Mögliche Lösung: Eskalation und Diskussion solcher Probleme auf Metaebene mit dem Management

Probleme mit Stakeholdern

Mögliche Probleme: Mangelnde Beteiligung und Interesse durch die Stakeholder, Konflikte unter Stakeholdern bzgl. Festsetzung von Prioritäten, zu viele Stakeholder.
Mögliche Lösung: Stakeholderanalyse, Moderationstechniken erlernen und anwenden, Anforderungsanalyse zusammen mit Stakeholdern, etwa m. H. eines Product Vision Canvas, Einbinden agiler Coaches.

Probleme in der Aufbauorganisation

Mögliche Probleme: Hohe Organisationskomplexität und Silo-Symptome
Mögliche Lösung: Verkürzen der Feedback-Loops mithilfe agiler Coaches

Hohe Projektkomplexität

Mögliche Probleme: Projekte mit vielen verschiedenen Firmen als Beteiligte. Der Product Owner und die Developer gehören unterschiedlichen Firmen an.
Mögliche Lösung: Dies muss nicht automatisch ein Problem sein, es ist aber ein Thema, mit dem bewusst umgegangen werden sollte: Vertragsgestaltung und Teamvereinbarungen helfen.

Hochregulierte Umgebungen

Mögliche Probleme: Das Umfeld / die Branche erschwert leichtgewichtige Arbeitsweisen durch Prozessüberbau.
Mögliche Lösung: Situative Intelligenz und Konzentration auf eine gute Fehlerkultur und möglichst schnelles Lernen angesichts der äußeren Umstände.

Product Owner können und müssen all diese Probleme nicht allein lösen. Hier sind oft das Management und die Beteiligung aller Betroffenen sowie zusätzlich gutes Coaching gefragt.

Unser Tipp: Wenn in Ihrem Unternehmen einige der oben beschriebenen Probleme auftreten, lohnt es sich sicherlich, diese möglichst frühzeitig an die zuständige Stelle zu adressieren.

Zusammenfassung: Product Owner

In diesem Artikel haben Sie unter anderem erfahren, welche Aufgaben und Verantwortungen ein Product Owner hat, welche Herausforderungen von ihm zu meistern sind, welche Metriken zur Messung von Produktnutzen es gibt und welche Inhalte das Product Backlog-Management umfasst.

Zusammenfassend lässt sich sagen: Gute Product Owner können ganz wesentlich zum Erfolg eines Unternehmens am Markt beitragen. Sie sind somit in einer sehr spannenden und einflussreichen Position voller Möglichkeiten. Aber die Rolle muss sich gegebenenfalls auch mit schwierigen Herausforderungen auseinandersetzen.

Daher sollten Sie, wenn Sie sich in der Rolle des Product Owner befinden oder diese anstreben, auf permanente Fortbildung einstellen: methodisch, toolseitig und besonders auch im zwischenmenschlichen Umgang.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!

Ist Ihre Neugier geweckt? Dann probieren sie agile Methoden mit Ihren Team und in Ihrem Projekt aus! Und wenn Sie Ihr Wissen ausbauen wollen, dann ziehen Sie doch eine Weiterbildung in Betracht – etwa zum Professional Scrum Master (PSM I) oder zum PMI Agile Certified Practitioner (via PMI-ACP Training bei TPG).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

FALSE

---

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag Product Owner – Definition, Aufgaben, Verantwortung und Herausforderungen in agilen Teams erschien zuerst auf TPG Projektmanagement Blog für Profis.