KNOWLEDGE MAKES THE WORLD GO ROUND ®
Agiles Projektmanagement kann mit verschiedenen Vorgehensmodellen durchgeführt werden, u.a. mit Scrum als Framework. Die in dem Scrum Guide vorgeschlagene Vorgehensweise ist für viele Mitarbeiter eine neue Perspektive auf Projektarbeit – auch wenn Scrum schon lange auf dem Markt ist.
Alle Vorgehensmodelle im Projektmanagement haben Vorteile und Nachteile. In einem ersten Beitrag habe ich das beispielsweise schon einmal am Wasserfallmodell dargestellt. Siehe Steckbrief zum Wasserfallmodell: Vorteile und Nachteile.
Wie in der Abbildung zu erkennen ist, hat auch KANBAN Vorteile und Nachteile. Seit Anderson (2010): KANBAN in der IT ist klar, dass KANBAN geeignet ist, wissensbasierte Arbeit zu organisieren.
KANBAN ist weniger präskriptiv (vorschreibend) im Vergleich zum SCRUM Framework, und ist auf der individuellen Ebene, der Teamebene und auf der organisationalen Ebene einsetzbar.
Verwechselt wird KANBAN oft mit allen möglichen Boards, die allerdings keine KANBAN Boards sind, wenn z.B. die Prozessschritte nicht begrenzt sind (WIP: Work in Progress) und die Tickets nicht nach dem Pull-Prinzip abgearbeitet werden.
Es geht in Zukunft immer mehr darum, das geeignete Vorgehensmodell zum Vorhaben (Projekt) auszuwählen. Dieser Trend ist in der Zwischenzeit an dem großen Anteil des Hybriden Projektmanagements – also einer sinnvollen Kombination von mehreren Vorgehensmodellen – abzulesen. Siehe dazu PMI (2024) Global Survey: Hybrides Projektmanagement wird immer wichtiger.
Industriearbeit wurde in der Vergangenheit akribisch (Stichwort: REFA) auf Verschwendungspotenziale untersucht. Ganze Wertstromanalysen wurden beispielsweise betrachtet, um Lean Production oder später Lean Management in der Organisation zu etablieren. Auch das Agile Arbeiten, beispielsweise in Form des Agilen Projektmanagements, hat das Ziel, sich nur auf den Value für den User (Scrum) zu fokussieren. Das Scrum-Framework entstand immerhin aus der Überlegungen, Wissensarbeit besser zu organisieren (Hirotaka Takeuchi und Ikujiro Nonaka).
Es verwundert daher doch etwas, dass aus einer Studie von Asana aus dem Jahr 2023 hervorgeht, dass der Anteil der “Arbeit rund um die Arbeit” bei Wissensarbeit immer noch erheblich ist. In der genannten Studie wurden fast 10.000 Wissensarbeiter befragt.
Dabei wird der Begriff “Arbeit rund um die Arbeit” wie folgt beschrieben: “Tätigkeiten, die der wichtigen Arbeit Zeit entziehen, darunter die Kommunikation über die Arbeit, die Suche nach Informationen, das Wechseln zwischen verschiedenen Apps, die Bewältigung wechselnder Prioritäten und die Statusnachverfolgung von Arbeitsvorgängen” (Asana 2025).
“Laut dem Bericht zur Anatomie der Arbeit von Asana [Anmerkung Robert Freund: aus dem Jahr 2023] werden 60 % der Arbeitszeit einer Person für „Arbeit rund um die Arbeit“ und nicht für Facharbeit aufgewendet” (ebd.).
Bei Studien sollte man immer etwas kritisch sein, denn Asana ist selbst Anbieter einer Work-Management Plattform mit vielen Apps – möglicherweise tragen diese sogar auch zu dem Verschwendungspotenzial bei.
Der von uns entwickelte Blended Learning Lehrgang Projektmanager/in Agil (IHK) wird im Oktober wieder in Düsseldorf angeboten:
Projektmanager/in Agil (IHK) – Blended Learning Lehrgang
Flyer und IHK-Website
27.10.-01.12.2025, IHK Düsseldorf
Ansprechpartnerin: Frau Wanke, Telefon: 0211/17243-35
E-Mail: petra.wanke@duesseldorf.ihk.de
In dem Lehrgang geht es u.a um folgende Themen:
Unternehmen sollten wissen, wie sie die Projekte herausfiltern, die dann sinnvoll mit agilen Methoden durchgeführt werden können.
Es gibt nicht nur Scrum als agiles Rahmenwerk, auch Lean und Kanban gehören zu geeigneten Vorgehensmodellen. Bei Kanban gibt es – im Vergleich zu Scrum – nicht die Trennung der Projektmanager-Rolle in Product Owner und Scrum Master.
Scrum: Hier ist zwischen dem Scrum-Guide und ScrumAnd (z.B. Scrumban) bzw. ScrumBut zu unterscheiden. Nicht alle Unternehmen nutzen Scrum genau nach dem aktuellen Scrum-Guide.
Herauszufinden, was die agilen Anforderungen sind ist nicht Bestandteil des Scrum-Guides. Wir ergänzen diesen Punkt daher mit dem Requirementsboard.
Agile Vertragsgestaltung: Ein wichtiges Element, da die Leistung nicht, wie beim Klassischen(Plangetriebenen) Projektmanagement, genau beschrieben vorliegt (Magisches Dreieck).
Hybrides Projektmanagement: Hier gibt es viele Variationen, was einen Ordnungsrahmen erforderlich macht.
Scaling Agile: Der Scrum-Guide wurde für einzelne Projekte geschrieben, doch wie geht man mit vielen agilen Projekten um? Nexus und LeSS orientieren sich stark am Scrum-Guide. SAFe wiederum hat eine umfangreiche Struktur und nutzt verstärkt Lean und Kanban. Hier schließt sich der Kreis des Gesamtkonzepts.
Ein(e) Projektmanager/in Agil (IHK) ist somit für verschiedene Rollen in Organisationen geeignet.
Wenn es um das Projektcontrolling geht, stellt sich natürlich immer auch die Frage: Von welchem Vorgehensmodell gehen wir aus? Ist es ein eher Plangetriebenes Projektmanagement, so kommen die üblichen Kennzahlen infrage, die beispielsweise aus einer Earned Value Analyse (EVA) entnommen werden können.
Gehen wir von einem Agilen Projektmanagement aus, so wird oft behauptet, dass die klassischen Controlling-Ansätze hier nicht anwendbar sind . Es wird von Objective Key Results (OKR) oder anderen (neuen?) Ansätzen gesprochen. Siehe dazu auch Veränderung des Controllings in einer VUCA-Welt. Das ist alles durchaus einleuchtend, doch gibt es eine Ausnahme.
Gehen wir einmal von der oben angesprochenen Earned Value Analyse aus, so stellt sich die Frage, ob die EVA nicht auch im Agilen Projektmanagement eingesetzt werden kann. Und siehe da: Es gib durchaus Autoren, die diese Frage in ihren Veröffentlichungen bewusst bejahen und auch begründen.
Klein (2021) hat anhand eines Zahlen-Beispiels ausführlich dargestellt, wie die Earned Value Analyse im Scrum Framework genutzt werden kann. Ich gehe hier nicht auf die gesamte Berechnung ein, doch zeigt schon der Ausschnitt in der Abbildung, die Vorgehensweise für die Sprints 1-5.
Wenn es also möglich ist, die Earned Value Analyse (EVA) im Plangetriebenen Projektmanagement und im Agilen Projektmanagement (Scrum Framework) zu nutze, so kann die EVA auch im Hybriden Projektmanagement eine wertvolle Hilfe darstellen.
Die Earned Value Analyse (EVA) stellt sich also als integrierendes Element des Projektcontrollings in verschiedenen Vorgehensmodellen dar.
Künstliche Intelligenz wird unseren individuellen Alltag, Unternehmen/Organisationen und letztendlich die gesamte Gesellschaft in verschiedenen Anwendungsformen immer stärker beeinflussen.
Dabei deutet sich in den Unternehmen/Organisationen eine interessante Entwicklung an.
Organisationen waren in den letzten 100 Jahren der Industrialisierung darauf fokussiert, ihre Prozesse (oftmals Routineprozesse) immer weiter zu optimieren, effektiver und effizienter zu machen. Diese Prozesslandschaften haben dann zu den bekannten Qualitätsmanagement-Systemen oder auch Projektmanagement-Systemen geführt. Gerade im Projektmanagement hat sich diese Vorgehensweise (Vorgehensmodelle) bei Projekten im Entwicklungsbereichen (Innovationen) zu einer Arbeitsform (Vorgehensmodell) entwickelt, die eher produktorientiert ist. Paradebeispiel dafür ist das Scrum-Framework mit den zu erzielenden Increments am Ende des Sprints oder das Minimum Viable Product (MVP), das wir aus dem Lean Start-up-Ansatz kennen.
Dieser Trend wird aktuell durch Künstliche Intelligenz scheinbar wieder umgekehrt. Wie kommt das?
Schauen wir uns einmal an, wie stark Künstliche Intelligenz den gesamten Lebenszyklus der Software-Entwicklung beeinflusst, so können wir erahnen, dass die Zyklen, in denen ein (Software-)Ergebnis (Increment, MVP) produziert werden kann, immer kürzer werden. Möglicherweise so kurz, dass es sich gar nicht mehr lohnt, den gesamten Scrum-Zyklus mit den vorgesehenen Artefakten und Events durchzuführen, und es zu einem kontinuierlichen Fluss an Ergebnissen (Produkten) kommt. In meinem Beitrag Künstliche Intelligenz: Wird Scrum durch den permanenten Fluss an Produkten zu Kanban? hatte ich das schon einmal angedeutet. Es freut mich daher, dass der Gedanke durchaus auch von anderen Autoren vertreten wird:
“Der Fokus essenzieller Design- und Architekturentscheidungen verschiebt sich in der Digitalisierung genau wie einst in der Industrialisierung von der Produktentwicklung hin zur Prozessentwicklung. Hier schließt sich auch der Kreis zu Scrum, denn zwei der wichtigsten Scrum-Pioniere Hirotaka Takeuchiund Ikujiro Nonaka kamen ursprünglich aus industriellen Produktions- und Innovationskontexten, nicht aus der Softwareentwicklung” (Immich, T.(2025): KI-Agenten Teil 2: Von der Produktentwicklung zur Prozessoptimierung, in Heise Online vom 27.05.2025).
Wenn es um Technik geht wird immer wieder die Frage nach der Ethik gestellt, denn Technik kann zum Wohle oder zum Nachteil von (allen) Menschen und der Umwelt genutzt werden. Aktuell geht es dabei beispielsweise um die Ethik bei der Nutzung von Künstlicher Intelligenz. Siehe dazu auch Technikethik (Wikipedia).
In der Softwareentwicklung hat sich der Einsatz von Scrum als Rahmenwerk (Framework) bewährt. In der Abbildung sind die verschiedenen Events, Artefakte und Rollen zu erkennen. Die Autoren Zuber et al. (2024) schlagen nun vor, ethische Überlegungen (ethical deliberations) mit in das Scrum-Framework einzubauen. Diese sind in der Abbildung grün hervorgehoben.
“The core idea is that, before the regular agile cadence begins, in a sprint 0, we first proceed descriptively and align ourselves with societal and organizational value specifications, i.e., we start from a framework defined by society and organization. Second, in the relationship between the product owner and the client, central ethical values are identified within this framework on a project-specific basis, if necessary, and become part of the product backlog. This can be done on the basis of existing codes of conduct or with other tools and methods that are specific to culture and context. We call this the normative horizon that is established during disclosive contemplation. Value-Sensitive Software Design: Ethical Deliberation in Agile. Within each individual sprint, it is a matter of identifying new values and implementing normative demands through suitable technical or organizational mechanisms” (Zuber et al 2024, in Werther et al (eds.) 2024).
Es ist wichtig, dass wir uns mit den ethischen Fragen neuer Technologien wie z.B. der Künstliche Intelligenz auseinandersetzen und es nicht zulassen, dass Tech-Konzerne die Vorteile der neuen Möglichkeiten in Milliarden von Dollar Gewinn ummünzen, und die sozialen Folgen der der neuen KI-Technologien auf die Gesellschaft abwälzen. Hier muss es eine Balance geben, die durch ethische Fragestellungen in den Entwicklungsprozessen von Technologien mit integriert sein sollten – nicht nur im Scrum-Framework.
Wenn es darum geht, Klassische Vorgehensmodelle (Plangetriebene Vorgehensmodelle) und Agile Vorgehensmodelle abzugrenzen, wird oftmals die Stacey-Matrix herangezogen. – obwohl es mit dem Cynefin-Ansatz, dem Vorschlag von Boehm & Turner usw. auch andere Möglichkeiten gibt.
In der Stacey-Matrix werden auf der Y-Achse Anforderungen an das Projekt von “weitreichend klar” bis “geringe Klarheit” positioniert. Hier geht es somit um das WAS. Auf der X-Achse geht es um Technik/Methode, die für das Projekt “im Griff” oder auch “unklar/unsicher” sein können. Hier geht es um das WIE (Siehe Abbildung).
Es ergeben sich daraus drei Bereiche: Simpel, Kompliziert und Komplex. Weiterhin können über die Diagonale die geeigneten Vorgehensmodelle abgeleitet werden. Simpel bedeutet hier, dass die Anforderung als Routinetätigkeit angesehen werden kann. KVP ist die Abkürzung für “Kontinuierlichen Verbesserungsprozess” oder auch Kaizen. Das bedeutet, um die Anforderungen zu erfüllen, muss der Routineprozess verbessert werden. Reicht das nicht mehr aus, so kommen wir in den Bereich des (Klassischen) Projektmanagements, zu dem es Normen und Standards gibt, die sich in vielen Branchen bewährt haben.
Werden die Anforderungen und auch Technik/Methode immer unklarer, kommen wir von dem komplizierten Bereich immer stärker in einen komplexen Bereich, in dem mehr Selbstorganisation gefordert ist, um das Projekt zum Erfolg zu führen. Mit Kanban, Scrum und Design Thinking sind hier nur drei von vielen Vorgehensmodellen genannt, die dem Agilen Projektmanagement zugerechnet werden.
Der Vorteil der Stacey-Matrix liegt darin, dass sie recht einfach umsetzbar ist und somit einen schnellen und guten Einstieg dafür bietet herauszufinden, welches Vorgehensmodell für ein Projekt geeignet erscheint.
Nachteile der Stacey-Matrix sind: (1) Es sind nur zwei Dimensionen zu bewerten – bei einem komplexen Projekt möglicherweise zu wenig, (2) Das Hybride Projektmanagement wird hier nur indirekt thematisiert. Man könnte den Bereich zwischen “Kompliziert” und “Komplex” dafür nehmen, was allerdings recht ungenau wäre.
Zur Verbesserung bietet es sich an ein Analysetool zu verwenden, das mehrere Dimensionen berücksichtigt und auch die Möglichkeit des Hybriden Projektmanagements enthält. Siehe dazu Projektmanagement: Einfaches Tool zur Analyse des angemessenen Vorgehensmodells – Planbasiert, Hybrid, Agil.
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen, Projektmanager/in (IHK) und Projektmanager/in Agil (IHK), die wir an verschiedenen Standorten anbieten. Weitere Informationen zu den Lehrgängen und zu Terminen finden Sie auf unserer Lernplattform.
Der Begriff Komplexität ist im Projektmanagement sehr wichtig. Projektmanagement-Standards wie IPMA, PMI oder auch Prince2 bieten beispielsweise an, die Komplexität eines Projektes, oder vieler Projekte, nach einem definierten Ablauf abzuarbeiten. Auch agile Vorgehensmodelle wie Scrum oder auch Kanban machen hier Vorschläge. Dabei wird Wert darauf gelegt, in kleinen Iterationen vorzugehen.
Im Rahmen der Stacey-Matrix wird weiterhin versucht, anhand der beiden Dimensionen Anforderungen (bekannt – unklar) und Vorgehen (bekannt-unklar) das geeignete Vorgehensmodell zu bestimmen. Im komplexen Bereich wird dann empfohlen, agile Vorgehensmodelle einzusetzen.
Es liegt auf der Hand, dass diese Einschätzung nicht alleine aufgrund zweier Dimensionen gemacht werden sollte, da es eine Vielzahl von Einflussfaktoren auf die Komplexität im Projektmanagement gibt. In der folgenden Tabelle sind einige davon aufgelistet.
| Vielzahl | Vielfalt | Vieldeutigkeit | Veränderlichkeit |
| Größe Volumen Reichweite Häufigkeit Scale Dichte Laufzeit Multikonstella- tionen … | Diversität Heterogenität Interdiszi- plinarität Scope Heterogenity Multiplexität Antagonismen Konflikte Pluralismus Hybride … | Ambiguität Unschärfe Unsicherheit Konfusion Vagheit Intransparenz Spielräume Zweifel Wahlmöglich- keiten Paradoxien Überschnei- dungen … | Dynamik Geschwindigkeit Instabilität Diskontinuitäten Wachstum Überraschungen Volatilität Verbesserung Chaos …. |
In solch komplexen Systemen verändern sich die jeweiligen Parameter permanent, sodass eine eigene Dynamik entsteht. Es ist daher empfehlenswert, die Einschätzung darüber, ob es sich um ein kompliziertes oder komplexes Projekt handelt, mehrmals durchzuführen. Gerade am Anfang eines Projekts liegen noch nicht so viele Informationen über das Projekt vor (Cone of Uncertainty), sodass die erste Einschätzung fehlerbehaftet sein kann.
Grundsätzlich kann man davon ausgehen, dass Selbstorganisation die Antwort auf Komplexität ist. Daraus lässt sich ableiten, dass es nicht alleine erfolgversprechend ist, Standards einzusetzen, sondern dass auf allen Ebenen die Selbstorganisation zu entwickeln. Auf der individuellen Ebene, der Gruppenebene, der organisationalen Ebene und der Netzwerkebene.
Gehen wir nach Erpenbeck/Heyse von Kompetenz als Selbstorganisationsdisposition aus, so bedeutet das, in diesem Sinne Kompetenz auf der individuellen Ebene, der Gruppenebene, der organisationalen Ebene und der Netzwerkebene zu entwickeln (Kompetenzmanagement).
Siehe dazu auch Freund, R. (2011): Das Konzept der Multiplen Kompetenz auf den Analyseebenen Individuum, Gruppe, Organisation und Netzwerk.
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK). Informationen dazu, und zu aktuellen Terminen, finden Sie auf unserer Lernplattform.
Klassische und agile Vorgehensmodelle im Projektmanagement unterscheiden sich bei verschiedenen Kriterien. In der Abbildung ist beispielsweise zu sehen, dass bei agilen Vorgehensmodellen, wie z.B. bei Scrum, der Projektnutzen stufenweise ansteigt. Bei Scrum ist das beispielsweise der Fall, da nach jedem Sprint ein Increment vorgestellt wird, das für den User einen Wert (Value) darstellt. Der nächste Sprint baut darauf auf, usw.
Bei klassischen, eher plangetriebenen Vorgehensmodellen steigt der Nutzen erst relativ spät, und eher “drastisch” an. Das geschieht oft in der Umsetzungsphase (Steuerungsphase). Dabei entstehen hier auch die meisten Kosten.
Siehe dazu auch Projektmanagement: Risikobewertung bei klassischen und agilen Vorgehensmodellen.
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK). Informationen dazu, und zu aktuellen Terminen, finden Sie auf unserer Lernplattform.