Zurück zur Methodenübersicht

Projektdesign

Projektdesign: Basis

Einleitung Projektdesign

Die Wahl von Ansatz und Vorgehensmodell hat unter Umständen erheblichen Einfluss auf den Projekterfolg.

Deshalb muss sich die Projektleitung auch mit dem Thema “Projektdesign” auseinandersetzen. Es gibt verschiedene grundsätzliche Ansätze, ein Projekt abzuwickeln: Planbasiert, agil oder - mittlerweile in der Praxis dominierend - als Kombination aus beiden Ansätzen, die von vielen Autoren als “hybrid” bezeichnet wird.

Der Projektmanagement-Ansatz beschreibt die grundlegende Orientierung und Philosophie, nach der ein Projekt gesteuert wird. Er beantwortet die Frage: „Wie gehen wir grundsätzlich vor?” Er bewegt sich auf einer abstrakten, strategischen Ebene und umfasst Dimensionen wie: Planungslogik (planbasiert vs. agil vs. hybrid) oder die Ablauflogik: (sequenziell vs. iterativ vs. inkrementell). Der Ansatz gibt die Denkrichtung vor, ohne konkrete Werkzeuge, Rollen oder Prozessschritte zu definieren.

Innerhalb dieser grundlegenden Ansätze gibt es eine Vielzahl von Vorgehensmodellen, unter denen man als Projektleiter die Auswahl hat und die man zudem noch kombinieren kann.

Ein Vorgehensmodell ist eine konkrete, ausgearbeitete Methodik, die einen oder mehrere Ansätze operationalisiert. Es beantwortet die Frage: „Wie setzen wir das genau um?” Es ist gekennzeichnet durch: Detaillierungsgrad (klar definierte Phasen, Prozesse, Rollen, Artefakte und/oder Werkzeuge), Geschlossenheit: (ein eigenständiges, in sich konsistentes Gesamtkonzept), Konkrete Anwendbarkeit: (direkt im Projekt einsetzbar wie z. B. Scrum, Kanban, Wasserfall, V-Modell, SAFe).

Im Kapitel “Projektdesign” werden die grundlegenden Ansätze und Vorgehensmodelle behandelt und gezeigt, wie man planbasierte und agile Ansätze zu einem hybriden Ansatz kombinieren kann.

Mit der Stacey Matrix für eine erste grobe Orientierung bei der Wahl des PM-Ansatzes sorgen

Einfache Projekte: Hier kann das Projekt schnell auf Grundlage von Beobachtungen kategorisiert und entsprechend identifizierter Kategorie bearbeitetet werden.

Komplizierte Projekte lassen sich mit Wissen beantworten. Auf komplizierte („schwierige“) Fragen können wir durch ein Mehr an abrufbarem Wissen reagieren, die Antworten sind meist eindeutig. In Ergänzung zur Beobachtung einfacher Projekte kommt hier eine sorgfältige Analyse dazu, was in den meisten Fällen zu projektspezifischem Tailoring des Projektmanagement-Ansatzes führt.

Anders jedoch bei komplexen Projekten:

  • Jede Teilentscheidung in einem komplexen Projekt hat Konsequenzen, die richtungsweisend wirken und so eine neue Dynamik anstoßen kann. Das heißt kurz gesagt, dass Ursachen und Wirkungen in komplexen Umgebungen erst rückblickend sichtbar werden. Prognosen sind kaum möglich, das Unvorhersehbare wird zum Normalzustand.
  • Oft ist nicht klar, was Ursache und was Wirkung ist.
  • Typisch ist ein hoher Aufwand bei der Feststellung der Ursache-Wirkungsbeziehung, sofern es überhaupt möglich ist. Man spricht oft auch von schwer prognostizierbaren Modellen: Man weiß, dass eine Projektintervention irgendetwas bewirkt. Allerdings passiert das in einer Art Black Box. Was am Ende bei der Blackbox herauskommt, ist nicht oder kaum prognostizierbar. Man kann das Ergebnis also nur sukzessiv beobachten und in der nächsten Iteration „reagieren“.
  • Bei den Elementen und ihren Beziehungen gibt es meist eine hohes Änderungsdynamik
  • Häufig hilft im Umgang mit Komplexität nicht ihre Reduktion, sondern die kollaborative, koordinierte Arbeit in einem multiprofessionellen Team (Nutzung Schwarmintelligenz) und iteratives Arbeiten entlang des Zuwachses an Erkenntnissen, also permanenter Versuch und Irrtum.

Chaotisch: Diese Umgebung ist hochgradig instabil, es liegt ein Notfall vor. Ursache-Wirkungs-Zusammenhänge sind auch nicht im Nachhinein kaum erklärbar. Einzelne Personen müssen mit starkem Mandat ausgestattet werden. Sie „handeln“ bzw. greifen ein, um die Stabilität wieder herzustellen. Es wird nicht experimentiert. Sondern im Anschluss das Ergebnis beobachtet und ggf. reagiert.

Die Stacey Matrix eignet sich nur für eine erste sehr grobe Einordnung, ob man tendenziell eher planbasiert oder eher agil vorgehen möchte. Für eine Entscheidungsfindung, ob ggf. auch eine hybride Variante, also eine Mischung aus einem planbasierten oder agilen Ansatz, in Frage kommt, sollte man sich mit weiteren Kriterien beschäftigen. Aus der Stacey Matrix ergeben sich bereits die folgenden Kriterien: Zielklarheit, Klarheit bei den Lösungsansätzen sowie die sich daraus ergebende Komplexität:

  • Projektart
  • Änderungsdynamik
  • Teamstabilität
  • Grad Virtualität
  • Unternehmenskultur
  • Beteiligung des Auftraggebers
  • Eignung des Teams für agile Werte
  • Projektspezifische Erfolgskriterien und Erfolgsfaktoren
  • Ergebnisse aus Lessons Learned früherer Projektdesigns Diese typischen Kriterien können zum Beispiel in einer Tabelle (siehe Folgekapitel) auf das Projekt angewendet werden - gerne ergänzt um unternehmens- und branchenspezifische individuelle Kriterien.

Komplex ist also nicht einfach „besonders schwierig“. Sondern anders. Deshalb verzerrt der Versuch der Komplexitätsreduktion, um einen leichteren Umgang mit der Situation zu simulieren, die tatsächlich bestehende Realität. Trivialisierung ist nicht der adäquate Weg, um mit komplexen Sachverhalten umzugehen.

Die vorgeschlagenen Strategien für komplexe Welten unterscheiden sich erheblich von chaotischen Umgebungen. In chaotischen Umgebungen wird nicht einfach noch mehr Agilität empfohlen sondern im Gegenteil ein wenig basisdemokratisches Durchregieren, um mit dem Notfall angemessen umzugehen.

Je weiter man in der Stacey-Matrix nach rechts kommt, oben kommt, desto eher antwortet Stacey auf unsere zunehmende VUCA-Welt:

  • Volatibility (Volatilität, Flüchtigkeit, Unbeständigkeit): Änderungen in unserer Umwelt werden immer schneller und extremer, große Schwankungsbreiten.
  • Uncertainty (Unsicherheit: Wir können immer weniger Vorhersagen über zukünftig zu erwartende Ereignisse treffen. Viele Szenarien sind möglich, Effekte des eigenen Handelns sind unklar.
  • Complexity (Komplexität)
  • Ambiguity (Mehrdeutigkeit): Die Faktenlage wird immer mehrdeutiger, es wird immer schwieriger, zutreffende und präzise Beurteilungen zu treffen, Situationen können unterschiedlich bewertet werden, verschiedene Beobachter geben stark divergierende Bewertungen ab.

Mit weiteren Kriterien zusätzliche Erkenntnisse sammeln, z.B. für ein mögliches hybrides Vorgehen

  • Planbasierter Ansatz: Anreicherung mit sinnvollen Methoden aus agilen Ansätzen wie Retros oder Daily Standup-Meetings (Cafeteria Prinzip)
  • Hybrides Vorgehensmodell: Echte Kombination wesentlicher Ansätze für Teilprojekte oder Phasen, z.B. planbasierte Konzeption und agile Umsetzung. In einem Phasenplan sollte mindestens eine Phase agile (mit z.B. Scrum oder Kanban) abgewickelt werden. Hybrides Vorgehen beinhaltet nach einer verbreiteten Definition ein echte Kombination von einem planbasierten und einem agilen Vorgehensmodell.
  • Agiles Vorgehen: Anreicherung mit sinnvollen Methoden aus planbasierten Ansätzen wie Stakeholder- und Risiko-Management. In der Praxis empfiehlt sich die Integration eigener Kriterien und deren Gewichtung (Nutzwertanalyse)

Die Strategien für die jeweilige Gesamteinschätzung stellen nur eine erste Idee dar und sollen bei der groben Orientierung helfen. Auch diese Zuordnung ist nur ein erster Ausgangspunkt für Entwicklung des Projektdesigns für das konkrete Projekt. Wenn man die Schritte bei der Bildung des Projektdesigns aufzählen möchte, könnte sich die folgende Abfolge anbieten. Hinweis: Es gibt zahllose Varianten für die Abfolgen in Praxis und Literatur. Insofern handelt es sich hier nur um ein Beispiel von vielen.

  • Unternehmens- und projektspezifische Kriterien für die Auswahl und Anpassung eines Vorgehensmodells - zum Beispiel erst über Stacey und danach ober eine Tabelle mit verschiedenen Kriterien (siehe oben).
  • Für jede Projektart: Selektion und unternehmensindividuelles Tailoring 2 - 3 passender konkreter Vorgehensmodelle je nach Agilitätsgrad (Wasserfall, V-Modell, Scrum, Kanban…)
  • Für jede Projektart: Vergleich der Vorgehensmodelle für die Beispielprojekte, z.B. auf Basis einer Nutzwertanalyse und Auswahl eines für die jeweilige Projektart passenden erscheinenden Vorgehensmodells
  • Individuelle Anpassung des ausgewählten Vorgehensmodells für ein konkretes Projekt durch Zuordnung der einzelnen Methoden.

Mit planbasierten, hybriden und agilen Vorgehensmodellen beschäftigen, die für das eigene Projekt relevant sein könnten

Definition

Inkrementell: Das System wird schrittweise entwickelt. Nach und nach kommen neue Funktionen hinzu. Iterativ: Es wird wiederholt an Teilen des Systems gearbeitet, um sie zu verbessern – man lernt aus früheren Versionen und optimiert sie. Inkrementell: Das System wird schrittweise entwickelt. Nach und nach kommen neue Funktionen hinzu. Iterativ: Es wird wiederholt an Teilen des Systems gearbeitet, um sie zu verbessern – man lernt aus früheren Versionen und optimiert sie.

Definition

Agiles PM setzt auf Selbstorganisation, dynamische Prozessgestaltung statt präziser Planung, enge Zusammenarbeit (auch mit dem Kunden) und schnell auslieferbare Inkremente.

Definition

Lean Management im Projektkontext bedeutet, Projekte durch Kundenfokus, kontinuierlichen Fluss und konsequente Eliminierung von Verschwendung schlank und wertorientiert zu steuern.

Lean Projektmanagement wird von einigen Autoren zu den agilen PM-Ansätzen gezählt, weil sie sich analog der agilen Werte auf wertschöpfende Arbeiten (Beispiel Struktur User Story in Scrum) konzentrieren und versuchen, eher starre Projektstrukturen zu vermeiden. Konkret wird Lean-Management durch Lean-Prinzipien verkörpert wie “auf Kunden konzentrieren, das Flussprinzip anwenden, das Pull-Prinzip anwenden, Multi-Tasking vermeiden) die letztlich alle das Ziel haben, Verschwendung (unnötige Schnittstellen, Bürokratie, unnötig komplexe Lösungen) zu vermeiden.

Vor allem Engpass-Management ist ein wichtiger Bestandteil des Lean Projektmanagements: Die Grundidee ist, das ganze Vorgehen im Projekt an seinen Engpässen zu orientieren, weil dieser den Durchsatz entscheidend bestimmt. Wenn zum Beispiel nur ein Person für das Testen vorgesehen ist und einen Engpass darstellt, nützt es wenig, wenn zum Beispiel die vorgehende Konzeption und die Entwicklung beschleunigt wird: Man muss am Engpass etwas ändern. Insofern ist es bei diesen Vorgehensmodellen von entscheidender Bedeutung, den Engpass des Projekts zu identifizieren und durch geeignete Maßnahmen zu reduzieren oder sogar ganz zu beseitigen:

  • Erhöhung Auslastung Engpass zum Beispiel Entlastung von Aufgaben, die auch andere Nicht-Engpass-Ressourcen durchführen könnten
  • Ausrichtung aller andere Prozesse auf den Engpass, damit der Engpass nicht unnötigerweise auf Zulieferung anderer Mitarbeiter warten muss
  • Erweiterung des Engpasses zum Beispiel durch Qualifizierung von Mitarbeitern, die zusätzlich Engpass-Aufgaben übernehmen können.

Die Begriffe inkrementell und iterativ stammen ursprünglich nicht aus einem bestimmten Methodenumfeld, sondern beschreiben Vorgehensweisen in der Softwareentwicklung. Sie werden allerdings häufig mit agilen Ansätzen assoziiert, obwohl sie theoretisch auch in planbasierten Ansätzen eingesetzt werden können.

  • Aus meiner Sicht hängt die Zuordnung zu agilen oder planbasierten Ansätzen lediglich an der Länge der Zyklen.
  • Oft wird deshalb inkrementelles und iteratives Verfahren eher als Ansatz und weniger als Vorgehensmodell bezeichnet. Ein Vorgehensmodell ist zum Beispiel eher Scrum oder das Spiralmodell, welches mehr oder weniger detailliert mit Templates, Werkzeugen, Rollen und weiteren Aspekten sehr konkret beschrieben wird. Insofern könnte man die obige Tabelle auch anders aufbauen und neben die PM-Ansätze stellen.

Im planbasierten Projektmanagement versucht man in der Terminplan als Erstes beim kritischen Pfad, also dem längsten Weg durch das Projekt, Optimierungen anzubringen (Überlappungen, mehr Ressourcen, effizientere Abwicklung). Beim Optimierungsbeispiel “effizientere Abwicklung” bietet sich an, die Erkenntnisse des Engpassmanagements einfließen zu lassen und den Durchsatz des kritischen Pfads durch entsprechende Maßnahmen zu verbessern. Die Verbesserung des Durchsatzes durch Maßnahmen des Engpass-Managements ist also nichts anderes als die Umsetzung des “Flussprinzips”, dass zu den wichtigen agilen Prinzipien gehört und das - zusammen mit dem Pull-Prinzip - auch ein wesentlicher Bestandteil der Kanban-Methode ist.

Die Critical Chain-Methode konzentriert sich sehr detailliert auf Engpassmanagement. Sie unterstützt insofern Lean Management und kann deshalb auch den agilen Vorgehensmodellen zugeordnet werden. Sie ist schon recht alt und geht auf Goldratt zurück. Diese Methode wird kontrovers diskutiert, weil sie - so die Kritiker - auf eine Reihe von unrealistischen Annahmen beruhen. Entsprechende Pilotprojekte seien nur erfolgreich, weil alle Rahmenbedingungen des Modells durch die Top-Management-Attention künstlich stabil gehalten würden. In den “normalen Projekten” würden dann aber wieder die typischen Selbstoptimierungsverhaltensweisen des “Homo Sapiens” in komplexen Matrixstrukturen durchschlagen. Ich teile viele dieser Kritikpunkte, kann aber trotzdem die Beschäftigung mit der Critical Chain-Methode empfehlen, weil sich - wie ich finde - Rosinenpicking immer rechnet und man sicher die ein oder andere Inspiration zur noch besseren Umsetzung des “normalen” Engpassmanagements findet.

Was vielen Projektleiter zum Beispiel in Anlehnung an die Cricical Chain-Methode übernehmen ist die Platzierung einer Risikoreserve vor neuralgischen Punkten des Projekts, also zum Beispiel vor dem Ende einer Projektphase direkt vor den Abschluss-Meilenstein (siehe auch Kapitel Ablauf- und Terminplanung)

Mit der Wasserfallstruktur das Risiko technischer Restschulden verringern

Jede Phase wird vollständig abgeschlossen, dokumentiert und „abgenommen“, bevor die nächste beginnt. Ein echter Rücksprung würde diese Logik durchbrechen.

Das klassische Wasserfallmodell geht davon aus, dass:

  • Anforderungen zu Beginn vollständig bekannt sind
  • sich während des Projekts nicht wesentlich ändern

Das Wasserfallmodell wird oft als prominentester Vertreter von “klassischem” oder planbasiertem Projektmanagement genannt. Klassisches Projektmanagement setzt auf klar definierte Meilensteine und Projektergebnisse sowie eine intensive Planung und eher auf Auslieferung der Projektergebnisse am Projektende.

Warum sind Phasenrücksprünge im Modell - selbst bei ausbleibendem inhaltlichen Erfolg - eigentlich nicht vorgesehen bzw. versucht man, Rücksprünge unbedingt zu vermeiden?

  • Eine Phase kann trotz ausbleibendem inhaltlichem Erfolg abgenommen werden, weil die Abnahme im Wasserfallmodell meist dokumenten- und formalbasiert erfolgt. Fehler oder Missverständnisse zeigen sich häufig erst in späteren Phasen, sodass eine Phase organisatorisch als erfolgreich gilt, obwohl sie fachlich unvollständig ist.
  • Nach einer offiziellen Abnahme ist ein Rücksprung schwierig, vor allem bei öffentlichen Projekten oder Festpreisprojekten, wo auch einzelne Phasen vertraglich abgeschlossen werden und es politischen Druck gibt.
  • Hohe Kosten bei Rücksprüngen, weil ein Fehler umso teurer wird, je später er entdeckt wird.
  • Ineffizienzen und Qualitätsprobleme der nächsten Phase sollen vermieden werden: Mit der konsequenten Erreichung der Qualitätskriterien des Meilensteins sollen teure Rücksprünge vermieden werden. Man spricht dann auch davon, dass man ohne “technische Restschulden” in die nächste Phase geht. Voraussetzung ist natürlich, dass die Meilensteine mit Kriterien so gut “operationalisiert” werden, dass sie “Prüfcharakter” gewinnen. Wenn man so will, werden die Meilensteine als Zwischenziele genauso SMART beschrieben wie die Projektziele. Abweichend vom Kerngedanken wird in der Praxis manchmal eine Freigabe unter Vorbehalt erteilt mit Erledigungsauflagen innerhalb einer gewissen Frist.

Mit dem V-Modell Testaktivitäten in den Designphasen mitdenken und gestalten und damit für eine hohe Testabdeckung sorgen

Qualitätssicherung erfolgt im Vergleich zum Wasserfallmodell

  • nicht (nur) über Meilensteine sondern klar benannte Verifizierungs- und Validierungsphasen
  • durch hohe Testabdeckung und direktes Mitdenken und Planen spezifischer Tests schon während der jeweiligen Designphase (Jeder Designphase wird spezifische Testphase zugeordnet)

Die Testphasen werden während der Planung der Designphasen gleich mitgedacht. Beispiel Systemdesign: Welche Schnittstellen sind zu testen?

Dieser Aufbau fördert das Qualitätsgedanken und verankert ihn fest im Modell: Alles, was spezifiziert und für was ein Designentwurf erstellt worden ist, muss später im Rahmen der Verifizierung und Validierung überprüft werden.

In Branchen, in denen die Produktsicherheit besonders wichtig ist, wird das V-Modell häufig eingesetzt, weil durch die Verifizierungs- und Validierungsphasen ein vollständiger Nachweis der Anforderungserfüllung erbracht werden kann.

Mit Simultaneous Engineering die sequenzielle Bearbeitung der Wasserfallstruktur für Zeit- und Erkenntnisgewinn aufgeben

Es wird bewusst auf eine sequenzielle Bearbeitung verzichtet. Die Folgephase startet bei ausreichenden Informationen (z.B. Teilergebnisse) mit der Folgephase.

Das Wort “ausreichend” sollte natürlich genau beschrieben werden. Gemeint ist, dass es nach Einschätzung des Projektteams mit einer nur geringen Wahrscheinlichkeit gravierende Änderungen für die Folgephase ergeben. Hier sollte genau überlegt werden, welche Arbeiten schon mit einem geringen Risiko begonnen werden können, dass Änderungen aufgrund neuer Erkenntnisse der Vorphase nötig werden.

Auf der anderen Seite geht es oft auch darum, aufgrund von Erkenntnissen der Folgephase, die zum Beispiel mit dem Bau eines Prototypen beginnt), für Spezifikationsphasen wertvolle Erkenntnisse zu gewinnen.

Vorteile dieses Modells zusammengefasst:

  • Beschleunigung des Projekts
  • Ableitung von Erkenntnisse aus gebauten Prototypen noch für die Spezifikationsphase

⚠️ Es sollte geprüft werden, ob genügend Ressourcen für eine Parallelisierung vorhanden sind. Werden Ressourcen aus der laufenden Phase zum Teil in die Folgephase verlagert, entsteht oft nicht nur kein Zeitgewinn sondern oft im Gegenteil ein Zeitverlust durch ineffizientes Multitasking der betroffenen Ressourcen.

Bei stabilen Grundanforderungen und sinnvollen Teilfunktionen bei wichtigem Time-to-Market mit wiederholenden inkrementellen Vorgehensmodellen auf sukzessive funktionale Erweiterung setzen

Im Gegensatz zum Wasserfallmodell und zum V-Modell sind hier Wiederholungen bis zum Gesamtergebnis ausdrücklich erwünscht. Die Anforderungen werden nur jeweils bis zum nächsten Zwischenergebnis formuliert. Nach Implementierung und Test werden die Erkenntnisse für das nächste Inkrement berücksichtigt.

Man lernt aus  früheren Versionen und optimiert sie. Das frühe Feedback ermöglich eine Art „empirische Produktsteuerung“ durch Rückgriff auf funktionierende Produktversionen. Am Ende jeder Schleife muss etwas Vorzeigbares, Analysierbares stehen.

💡 Wenn zu Beginn des Projekts eine vollständige Anforderungsaufnahme möglich ist, kann die Anforderungsphase bei den späteren Inkrementen weggelassen werden.

Bei hohen Risiken, komplexen Anforderungen und neuen Technologien auf wiederholende Modelle wie das Spiralmodell setzen und mit wiederholten Risikobewertungen und Prototypen den von Anfang an definierten Projektgegenstand verfeinern

Auch hier sind im Gegensatz zum Wasserfallmodell und zum V-Modell Wiederholungen bis zum Gesamtergebnis ausdrücklich erwünscht. Im Gegensatz zum inkrementellen Vorgehen wird der gesamte Projektgegenstand mit jeder Iteration verfeinert und nicht schrittweise von Phase zu Phase mit zusätzlichen Inhalten ergänzt – aber immer innerhalb des anfangs definierten Rahmens. Insofern sind unerwartete Features oder Richtungswechsel im Unterschied zum inkrementellen Vorgehen selten, der gesamte Projektgegenstand steht von Anfang zumindest grob fest.

Eine Besonderheit ist auch der Schritt der Risikoidentifikation und sukzessive Beseitigung durch Prototyping und “iterativer Verfeinerung des Gesamtsystems”. Das Spiralmodell ist risikogetrieben. Mit jedem neuen Prototyp können neue Risiken entstehen (technisch, organisatorisch, wirtschaftlich), deshalb wird die Risikoanalyse wiederholt und angepasst.

Weil das gesamte System als Ganzes schrittweise vom Grob- zum Feinentwurf weiterentwickelt wird, werden Modell wie das Spiralmodell auch als evolutionär bezeichnet. Wie in der Evolution werden sukzessive verfeinerten Lösungen vor allem durch Versuch (Prototyping) und Lernen weiterentwickelt. Das System “evolviert” kontinuierlich, es verändert sich im Zug eines evolutionären Prozesses, es reift also.

Das Modell erinnert wegen der vielen Prototypen stark an Design Thinking.

Typische Einsatzgebiete:

  • Das Modell eignet sich vor allem für Großprojekte (Beispiel Raumfahrt), die aufgrund der hohen Kosten mit hohen Risiken belastet sind und bei denen sich die aufwändige Risikoanalyse und das aufwändige Prototyping lohnen.
  • Forschungs- und Entwicklungsprojekten (Beispiel Medizintechnik): Bei Entwicklung neuer Technologien mit stark experimentellem Charakter.
  • Beispiel Organisationsprojekte: Rollout eines Software-Templates von Region zu Region mit stetig wachsendem Umfang der Features unter Berücksichtigung der Erfahrungen der Region.

Die Stärke dieses Modells ist der strukturierte Umgang mit unscharfen Anforderungen durch bewusst schrittweise Konkretisierung des Projektgegenstands. Seine Schwäche ist ein gewisses Risiko eines Mehraufwands wegen ggf. vieler Änderungen, zu denen das schrittweise Vorgehen einlädt.

Abgrenzung vom inkrementellen Vorgehen:

  • Im Gegensatz dazu entwickelt sich beim inkrementellen Modell nur der Funktionsumfang schrittweise auf Grundlage eines frühzeitig oft feststehenden Grundsystems. Neue Funktionen werden “angebaut” und vorherige Inkremente bleiben weitgehend stabil.
  • Insofern wächst das System bei inkrementellem Vorgehen eher additiv, aber nicht das Gesamtkonzept verändert sich ständig wie bei evolutionären Ansätzen.
  • Der Begriff Evolution wird hier analog der Biologie eher als qualitative Veränderung und weniger für quantitative Erweiterung eingesetzt. Bei Wachstum kommt mehr vom Gleichem hinzu, wobei das Grundkonzept stabil bleibt. Bei der Evolution wird aber das Gesamtsystem inhaltlich und strukturell weiterentwickelt.
  • Natürlich sind das nur ganz grundsätzliche Kategorisierungen, um die Modell und deren Einsatzszenarien besser voneinander unterscheiden zu können. Selbstverständlich lernt man auch bei inkrementellen Modellen dazu und kann dadurch auch das Gesamtsystem verbessern und nicht nur quantitativ ergänzen. Nur, dass das Inkrementelle bei diesen Modellen meist im Vordergrund steht und eben nicht die Verbesserung des Gesamtsystems.

Mit Scrum aufgrund der klaren Strukturen als Einsteiger im agilen PM starten

Scrum ist ein leichtgewichtiges, agiles Rahmenwerk zur inkrementellen und iterativen Entwicklung komplexer Produkte durch ein selbstorganisiertes, interdisziplinäres Team.

Projekte in Scrum werden von selbstorganisierten und interdisziplinären Teams durchgeführt. Diese liefern in festen Zeitabständen (Sprints) ein Produktinkrement. Meist am Sprintende findet eine Bewertung und Abnahme der Userstories bzw. des Inkrements durch die relevanten Stakeholder und den Produkt Owner statt (Review). Es folgen weitere Inkremente, bis das vom Kunden gewünschte Produkt fertig ist.* Eine Abnahme der Userstories kann auch während des Sprints nach Fertigstellung erfolgen.

Nicht abgenommene User Stories werden gestrichen oder wieder in das Product Backlog geschoben. Wenn sich aufgrund einer veränderten Umgebung neue Prioritäten bei den User Stories ergeben haben, werden sie also nicht automatisch im nächsten Sprint beendet. Unter Umständen sogar nie. Durch diesen Ablauf kann man sich bei Scrum ein formales Änderungsmanagement sparen. Es ist sozusagen durch den Ablauf systemimmanent vorhanden.

Definition of Done (DoD) ist eine vom Scrum Team erstellte Sammlung von Kriterien, die genau festlegen, wann eine Story (nicht Task) als abgeschlossen gilt und wird am besten vor dem nächsten Sprintplanning aktualisiert. Sie stellen grundsätzlich für die Entwicklung der Userstories geltende Qualitäts-/Gütekriterien dar und hängen oft bei physischen Taskboards zur Orientierung am Board. Bei toolbasierten Taskboards wie Jira sind sie ebenfalls leicht zu finden. Die DoD legen fest, wann eine Userstory bzw. die angeforderte Funktionalität „fertig“ (done) ist. Die DoD entspricht damit grundsätzlich den Mess- und Abnahmekriterien im klassischen PM. Zweck:

  • Gemeinsames Qualitätsverständnis im Scrum-Team
  • Vermeidung technischer Schulden, keine Nacharbeiten in nächsten Sprint mitnehmen
  • Vermeidung Perfektionismus bei den Entwicklern. Insofern sind DoD auch als Begrenzung der maximalen Qualität zu verstehen, nicht nur als Mindestanforderung
  • Berücksichtigung bei der möglichen Anzahl für den Sprint gewählten Userstories
  • Verantwortlich: Ganzes Scrum-Team
  • Beispiel:
    • User Story ist von mindestens zwei Entwicklern programmiert
    • Der Quellcode ist für alle Teammitglieder verständlich
    • Die Userstory wurde ins Gesamtsystem integriert
    • Notwendige Dokumentationen wurden ergänzt
    • Alle Akzeptanzkriterien der Story sind erfüllt
    • Die Userstory wurde vom PO abgenommen
    • Die Userstory wurde vom QA-Team abgenommen

⚠️ Der Product Owner ist Teil des Scrum Teams. Es ist üblich, dass die PO-Abnahme Teil der DoD ist. Die Stakeholder sind aber nicht Teil des Scrum-Teams. Ihre formale Abnahme ist nicht zwingend Bestandteil der DoD. Das Feedback der Stakeholder erfolgt im Sprint Review, nicht als formale Done-Bedingung.

Ein Product Backlog ist eine Liste der vom Product-Owner gesammelten Anforderungen in Form von Userstories. Sie wird entsprechend der Wünsche der Stakeholder von ihm priorisiert.

💡 In einer von Jeff Patton entwickelten Methode (User Story Mapping) wird zur besseren Verständlichkeit das klassische Flat-Backlog ersetzt durch ein Big Picture, bei dem die Anforderung in einer Art Landkarte (map) horizontal in der Reihenfolge der Systemverwendung (User Journey) und der entsprechenden Epics dargestellt werden. Die Userstories werden vertikal den Epics zugeordnet. Gleichzeitig werden die Userstories pro Epic in eine Swimelane zugeordnet und erhalten eine Priorisierung wie z.B. MVP oder must have, shoud have, could have (und am Ende won´t have). Diese Struktur des Product Backlogs ist für die meisten wenig erfahrenen Betrachter viel übersichtlicher als eine rein horizontale Auflistung der Userstories, bei der strukturierende Aspekt der Customer Journey fehlt.

Eine Userstory besteht aus der Formel “Rolle, Funktion, Ziel”. Beispiel: “Ich möchte mich als Trainer in einer Datenbank registrieren, um von potenziellen Kunden gefunden zu werden”. Eine Userstory ist die kurze Beschreibung von Anforderungen für agile Projekte in Alltagssprache. Userstories sind erst mal nur Platzhalter für spätere Konversationen während des Sprints zwischen Product Owner und Entwickler. Die Anforderungen im agilen Projektmanagement werden deutlich unschärfer beschrieben als im klassisches Requirements Engineering:

  • Eine USR ist eine User Requirement Specification, die in planbasierten Ansätzen oft auch als als Lastenheft bezeichnet wird.
  • Sie ist ein formelles Dokument, das alle Anforderungen eines Nutzers an ein System oder Produkt detailliert festlegt. 
  • Im Vergleich zu agilen Ansätzen wie Scrum gibt es grundlegende Unterschiede in der Herangehensweise: 
    • Zeitpunkt und Umfang: Die USR wird in der Regel einmalig zu Beginn eines Projekts erstellt. Sie dient als umfassender “Fahrplan” und Vertragswerk, bevor die eigentliche Entwicklung startet. Bei Scrum werden die Anforderungen werden kontinuierlich im Product Backlog verfeinert. Anstatt alles vorab zu planen, wird das Produkt in kurzen, iterativen Zyklen (Sprints) entwickelt. 
    • Form der Anforderungsbeschreibung: Die URS verwendet oft technische und formale Beschreibungen. Sie ist ein offizielles Dokument für regulatorische Compliance (z. B. in der Pharma- oder Automobilindustrie). Scrum nutzt primär User Stories. Diese sind kurz, weniger formal und fokussieren sich auf den Nutzen aus Sicht des Anwenders (“Als Rolle möchte ich Ziel, um Nutzen zu erreichen”). 
    • Flexibilität vs. Stabilität: Die URS ist auf Stabilität ausgelegt. Änderungen nach Projektstart erfordern meist formale Change-Management-Prozesse. Scrum ist auf Anpassungsfähigkeit ausgelegt. Das Team kann nach jedem Sprint auf Feedback reagieren und Prioritäten im Backlog verschieben.

Die Kadenz definiert im agilen Projektmanagement den “Herzschlag der Arbeit”:

  • Sie ist nicht nur die feste Sprintlänge.
  • Sie umfasst auch die regelmäßige Abfolge von festgelegten Events.  Sie legt fest, wie oft Sprints stattfinden, wie lange sie dauern (Timebox, typischerweise 1-4 Wochen) und wann die zugehörigen Events (Planning, Daily, Review, Retrospektive) stattfinden. Die Kadenz stellt sicher, dass Events in einem vorhersehbaren Rhythmus ablaufen. Sie verbindet also die zeitliche Begrenzung (Länge) mit dem inhaltlichen Ablauf (Events). Die Sprintlänge bleibt über die Projektdauer fix - zum Beispiel immer zwei Wochen. Man spicht in diesem Zusammenhang von “Timebox. Timeoboxing ist als eine Voraussetzung für den gewünschten Rhythmus. Idealtypisch wird die Sprintlänge im laufenden Sprint nicht verändert, um Fokus und Stabilität zu gewährleisten. 

Zwecke der Kadenz:

  • Vorhersagbarkeit & Planungssicherheit: Durch den immer gleichen Rhythmus wissen alle Beteiligten (Team & Stakeholder), wann Ergebnisse geliefert werden, was die Planung erleichtert.
  • Fokus & Disziplin: Die feste Timebox zwingt das Team zur Konzentration auf das Sprint-Ziel und verhindert, dass Aufgaben endlos in die Länge gezogen werden.
  • Regelmäßiges Feedback: Durch die festgelegten Events (insb. Sprint Review) erhält das Team in kurzen Abständen Rückmeldung, um den Kurs bei Bedarf anzupassen.
  • Kontinuierliche Verbesserung: Die regelmäßige Retrospektive ermöglicht es dem Team, den eigenen Prozess zu reflektieren und effizienter zu werden. Es findet eine Art Prozessautomatisierung statt, das Team stellt sich immer besser aufeinander ein und steigert die Arbeitsmenge von Story Points (Velocity), die die Entwickler pro Sprint bewältigen können. Auch wenn die Zuwächse von Sprint zu Sprint meist immer geringer ausfallen. Mit Story Points wird die Komplexität von Userstories gemessen.
  • Reduzierung von Komplexität: Ein gleichbleibender Rhythmus nimmt die Notwendigkeit, Termine jedes Mal neu zu verhandeln, und schafft Stabilität, Routine und Vorhersagbarkeit. Zusammenfassend ist die Kadenz ein Mittel, um aus einem “schnellen Arbeiten” einen strukturierten, verlässlichen und anpassungsfähigen Prozess zu machen. 

Retrospektive: Die “Retro” stellt eine Art “Lessons Learned” zur Verbesserung der Teamarbeit (Kommunikation, Konflikte, Abläufe, Werkzeuge…). Es werden klare Verabredungen zum veränderten Verhalten sowie der Abläufe und Werkzeuge für den nächsten Sprint getroffen. Ergebnisse einer Retrospektive in Scrum sein können also zum Beispiel eine optimierte Kommunikation oder der Einsatz besserer Werkzeuge in der Zusammenarbeit sein.

Sprintplanning: Die Planung in agilen Projekten wie Scrum wird nicht zum Projektstart sondern (rollierend) zum Start jedes Sprints vorgenommen. Nach dem Sprint Planning sollen sich Product Owner und Team einig sein, was in dem Sprint erledigt werden soll und was das gemeinsame Sprintziel der ausgewählten Userstories ist.

Damit die Entwickler eine Userstory in den Sprint ziehen, muss sie “ready” für die Entwicklung sein. Kriterien für die Entwicklungsreife werden auch DoR (“Definition of Ready”) genannt. Hilfreich bei deren Definition ist das Investprinzip, das Pendant zur planbasierten SMART-Formel: DoR = Definition of Ready: Erwartungen des Entwicklungsteams an eine Userstory im Product Backlog, damit es für einen Sprint von den Entwicklern ausgewählt werden kann. Dabei ist eine Orientierung am INVEST-Prinzip sinnvoll (Pendant zur SMART-Formel)

  • Independent (für Flexibilität bei der Priorisierung / Verschiebung im Product-Backlog)
  • Negotiable (…während Sprint in Bezug auf den Umfang)
  • Valuable (Mehrwert Kunde steht im Vordergrund, nicht die Technik)
  • Estimable (sonst z.B. Reduktion Größe, Sammlung weiterer Infos, Befragung weiterer Expertinnen und Experten…)
  • Small (z.B. maximal x Storypoints, nicht größer als zum Beispiel 50% eines Sprints). Ein Epic ist eine Userstory, die zu groß für Umsetzung in einem Sprint ist. Die bleibt als Platzhalter im Product-Backlog.
  • Testable: Klare spezifische und wenn möglich quantifizierte Akzeptanzkriterien sind vom Product Owner definiert worden. Beispiel für Akzeptanzkriterien, die sich im Verlauf des Sprints noch verändern können): „Wenn ich mich mit User-ID (meine E-Mail) und Passwort registriert habe, kann ich nach Klick auf eine Bestätigungsmail zu meinem Account anmelden“.

Daily Scrum: Das Daily ist kein Statusmeeting, sondern dient der Synchronisation und Neuplanung bzw. Plananpassung durch die Entwickler.

💡 Oft werden die einzelnen Entwickler nacheinander aufgerufen, damit sie zu ihren Userstories erzählen können,

Product Owner, Scrum Master und andere Stakeholder können als Gäste unter gewissen Rahmenbedingungen teilnehmen.

💡 Bei Gästen wird das Daily oft zu einer “Berichtsveranstaltung” zweckentfremdet. Deshalb sollte man sich gut überlegen, ob man wirklich Gäste zulassen möchte oder diese in Extra-Meetings über den Fortschritt informieren möchte. Sofern man Gäste zulässt, sollte man zumindest verabreden, dass diese erst im Anschluss an das offizielle Meeting Fragen stellen dürfen.

Rollen in Scrum

  • Entwickler:
    • Setzen die Anforderungen kontinuierlich gemäß der verabredeten DoD um und bauen das nächste Produktinkrement
    • Schätzen die Arbeitsmenge eines Sprints
    • Arbeiten eng mit dem Product Owner zusammen
    • Sind interdisziplinär aufgestellt (T-Shaped Skills) und haben eine Bereitschaft, über den Tellerrand zu schauen. Alle technischen Kompetenzen sollten vertreten sein, um die Entwicklungsarbeit zu vollziehen.
    • Verhandeln mit dem Product Owner den Aufgabenumfang der Inkremente (Sprints)
    • Wirken an Formulierung des Sprintziels mit
    • Präsentieren Ergebnis beim Sprint-Review
    • Organisieren sich selbst. Noch nicht einmal Scrum Master kann Development-Team anweisen, wie das Product Backlog in Inkremente umgesetzt werden soll.
    • Sollte idealerweise 7 +/- 2 Mitglieder umfassen
    • Haben alles, was sie zum Arbeiten brauchen und ist nicht von jemand außerhalb des Teams abhängig. Sie sollten also von der Organisation “empowered” sein.
    • Bilden keine Teilprojektleitungen oder Subteams
    • Sitzen als kompakte Gruppe möglichst in einem Raum
    • Sind möglichst langlebig zusammengestellt, um Kontextwechsel zu minimieren
  • Product Owner:
    • Stellte oft eine Mischung aus verschiedenen Rollen da
      • Sorgt als Anforderungsmanager für aussagekräftige Userstories
      • Ist oft gleichzeitig Projektmanager, Product Manager und Business Analyst
    • Ist verantwortlich (“accountable”) für die Arbeit des Development-Teams und den wirtschaftlichen Erfolg (Wert) des Produkts
    • Verantwortet das Product Backlog und die Priorisierung der Userstories und Epics
    • Nimmt Produktinkremente ab
    • Entscheidungshoheit, ob die Entwicklung weitergeführt oder das Projekt beendet wird
    • Einziger, der einen Sprint abbrechen darf
    • Einzige Person, der Product Backlog managed
    • Produktowner eine Person, kein Committee - repräsentiert aber ggf. ein Committee
    • Fachwissen:
      • Fachwissen zum Einsatzbereich des Produkts
      • Visionär - Erzeugung Gesamtbild
      • Kommunikativ
      • Verhandlungssicher
      • Entscheidungsfähig (mit Mandat)
      • Typ “Steve Jobs„
      • Kann beim Kunden und/oder Dienstleister sitzen
  • Scrum Master
    • Hat eine Management-Aufgabe
    • Überwacht Einhaltung der Scrum-Grundsätze
    • Staffing macht das Development-Team, nicht der Scrum Master
    • Hat idealweise nur ein Team
    • Trainiert auch den PO
    • Servant Leader, sorgt dafür, das “Maschine funktioniert” und hohe Produktivität erreicht
    • Hilft bei Lösung von Problemen, löst sie aber nicht
    • Räumt Hindernisse (“Impediments”) aus dem Weg - Puffer für Development-Team
    • Mediator, Moderator (auf Anforderung), Mentor (sorgt für Realismus)
    • Hat Prozessautorität
    • Muss nicht im selben Raum wie Development-Team sitzen
    • Stellt z.B. fest, dass die Meetings stattfinden (diskutiert aber nicht inhaltlich mit) und Timeboxes eingehalten werden - muss nicht immer dabei sein, Stichproben reichen
    • Hat keine Autorität über das Team, ist also in der Regel kein Projektleiter!
    • Fähigkeiten:
      • Scrum Experte
      • Kennt sich mit Techologien aus
      • Geduldig
      • Teamfähig
      • Hilft Leuten außerhalb des Scrum Teams zu verstehen, welche Interaktionen hilfreich sind für das Scrum Team sind und welche nicht
    • Führt Scrum sukzessive im Unternehmen ein, wobei diese Aufgabe oft auch die eigene Rolle eines Agile Coaches hat.

Viele Puristen raten bei wenig Erfahrung davon ab, Modelle wie Scrum zu stark zu verändern, weil hier immerhin die Erfahrung tausender Projekte eingeflossen ist.

💡 Lieber am Anfang mit geringem Reifegrad mit einfachen Sicherheit gebenden Strukturen wie bei Scrum anfangen und erst dann auf flexibel konfigurierbare Strukturen wie Kanban wechseln, die einen größeren Reifegrad voraussetzen.

Mit Kanban aufgrund der hohen Freiheitsgrade erst mit einer agilen Reife / Erfahrung arbeiten

Kanban (Kan = Signal, ban = Karte): Horizontale japanische Adaption einer Todo-Liste. Ein Kanban-Board visualisiert den Arbeitsfluss und nicht nur den Zustand einer Aufgabe wie ein klassisches Taskboard in Scrum. Durch die Visualisierung aller relevanten Bearbeitungsstationen können Engpässe bei der Bearbeitung einzelner Aufgaben schneller erkannt werden.

Beispiel: In einem Pool werden die anstehenden Projektaufgaben erst mal gesammelt. Die Aufgaben sollten eher klein sein, so dass man zum bei Besprechungen alle zwei Tage einen neuen Bearbeitungsstatus einer Aufgabe hat. Die Projektleitung gibt Aufgaben zur Bearbeitung frei. Die die Aufgaben der Freigabespalte dürfen bearbeitet werden. Bei freier Kapazität werden die Aufgaben vom Bearbeiter in den nächsten Bearbeitungsschritt gezogen.

Fertig: Nur fertige Aufgaben dürfen in die nächste Bearbeitungsspalte nach dem Pullprinzip gezogen werden. Die Auswahl erfolgt nach fachlicher Eignung des Fachspezialisten und nach Priorität. Die Aufgabe landet im nächsten Bearbeitungsschritt in der der “In Arbeit”-Spalte.

Work in Progress Limit (WiP-L):

  • Ziel ist, einen möglichst konstanten Arbeitsfluss sicherzustellen. Neben der Visualisierung der gesamten Abfolge der Bearbeitungsschritte soll der konstante Arbeitsfluss durch Vermeidung von Engpässen in einem Bearbeitungsschritt vermieden werden. Analog einer Autobahn fließt der Verkehr gleichmäßiger bei zum Beispiel einer gleichmäßigen Auslastung von 60%. Alle Autos (Aufgaben) fahren im Schnitt etwas langsamer, dafür gibt es keinen Stau.
  • Ein Engpass entsteht dadurch, dass zu viele Aufgaben aus dem vorangegangenen Arbeitsschritt in die “Engpass-Spalte” gezogen werden, obwohl dort noch viele nicht fertiggestellte Aufgaben liegen. Die vielen nicht fertiggestellten Aufgaben behindern wiederum den nächsten Bearbeitungsschritt, der ja eine fertige Aufgabe zum Start benötigt. Ein klassischer Engpass ist entstanden.
  • Dieser Engpass mit vielen nicht angefangenen und nicht fertiggestellten Aufgaben hat zusätzlich den Nachteil des schädlichen Multitaskings. Man wechselt ständig zwischen vielen Aufgaben hin und her und benötigt jedes Mal geistiges Rüstzeug, um sich wieder neu in eine bestimmte Aufgabe einzuarbeiten.
  • Was kann man tun, wenn man einen solchen Engpass feststellt und eine Bearbeitungsschritt besonders viele angefangene Aufgaben beinhaltet?
    • Sinnvolle Obergrenze an gleichzeitigen Aufgaben definieren. Die folgenden Varianten sind dabei denkbar:
      • Obergrenze gleichzeitiger Aufgaben pro Bearbeitungsschritt
      • Obergrenze gleichzeitiger Aufgaben pro Bearbeiter
      • Oft werden beiden Grenzen gleichzeitig eingesetzt.
    • Zusätzliche Bearbeitungsspalte definieren: Neben dem WiP-L einer Spalte ist es unter Umständen sinnvoll, einfach aus einem Bearbeitungsschritt zwei Bearbeitungsschritte zu machen und dadurch den gleichmäßigen Fluss der Aufgaben durch die Bearbeitungsschritt wieder herzustellen.

Notfallspur: Gute Kanbanboards und entsprechende Tools beinhalten die Möglichkeit, Simelanes (Schwimmbahnen) als weitere Zeilen vorzusehen, in die man Aufgaben schieben und nach selbst definierten Regeln bearbeiten kann. Zum Beispiel könnten Aufgaben in der Notfallspur mit der Regel verknüpft werden, dass alle Arbeiten an anderen Aufgaben solange ruhen, bis die Notfallaufgabe bearbeitet ist. Durch so eine Regel könnte ein größerer Fokus erreicht werden.

On hold: Beliebt ist auch die “On hold Spur”, in der Aufgaben stehen, bei denen man noch externen Input von zum Beispiel einem Fachbereich benötigt.

Das Kanban-Prinzip “Richtlinien explizit machen” wird gelebt, in dem projektindividuelle Regeln - wie oben anhand der Notfallspur beispielhaft erläutert - direkt am Board angebracht werden, zum Beispiel als “Policy-Feld”. Das geht bei einem physischen Kanbanboard natürlich einfacher als bei einem digitalen Kanbanboard. In digitalen Kanban-Boards gehören sie prominent ins Board-Layout und nicht in eine versteckte Dokumentation.

Tipps zur Einführung von Kanban:

  • Mit dem anfangen, was man hat (also möglichst einfach starten)
  • Keine Vorgabe durch die Projektleitung sondern gemeinsame Prozessdefinition im Team
  • Auch der Projektleiter sollte seine Karten aufhängen
  • Regeln des jeweiligen Kanban-Boards explizit machen und System permanent optimieren

⚠️ Überspitzt formuliert, ist Kanban keine Methode zur agilen Produktentwicklung sondern eher eine agile evolutionäre Changemanagement-Methode auf Prozessebene. Das bedeutet, dass der bestehende Prozess in kleinen Schritten (evolutionär) verbessert wird. Indem viele kleine Änderungen durchgeführt werden (anstatt einer großen), wird das Risiko für jede einzelne Maßnahme reduziert.

Kanban kann man sich wie eine Bergwanderung vorstellen, bei der man mit einer guten Landkarte ausgestattet ist und ein konstantes Marschtempo vorlegt. Bei Hindernissen ist eine Routenänderung möglich, ohne das Ziel aus den Augen zu verlieren.

Im Gegensatz dazu gleicht Scrum eher dem Marsch durch einen Dschungel: Man weiß auf dem Weg oft nicht genau, wo man ist. Die Marschrichtung geht zu einem markanten Geländepunkte (Sprintziel). Dort folgt die Neuorientierung für die nächste Etappe.

Kanban ist kein “echte” agile Methode sondern ein Vorgehensmodell für evolutionäres Management von Veränderungsprozessen (Changemanagement). Das bedeutet, dass der bestehende Prozess in kleinen Schritten (evolutionär) verbessert wird. Indem viele kleine Änderungen durchgeführt werden (anstatt einer großen), wird das Risiko für jede einzelne Maßnahme reduziert. Darüber hinaus führt der eher sanfte Stil von Kanban in der Regel zu weniger Widerständen bei den Beteiligten.

💡 Wer Kanban einführen möchte, wird sich unter Umständen mit kritischen Stimmen auseinandersetzen müssen. Man kann aber immer argumentieren, dass es eine Grundlegel von Kanban ist, erst mal den Status Quo als Prozess aufzunehmen. Die einzige “Änderung”, wenn man sie überhaupt als solche bezeichnen möchte, ist lediglich die Visualisierung der aktuellen Prozesse nach einem bestimmten Verfahren.

Die Kerneigenschaften von Kanban sind recht breit formuliert und geben keine Auskunft darüber, wo im Unternehmenskontext sich Kanban einbettet. Trotzdem unterliegt Kanban häufig dem Irrtum, dass es ein agiler Ansatz zur Team-Optimierung sei. Kanban kann durchaus auf Team-Ebene eingesetzt werden, es hat jedoch stets die gesamte Wertschöpfungskette im Blick.

Kanban ist im Vergleich zu Scrum eine weniger invasives Modell, das den Fokus vor allem darauf legt, den bestehenden Workflow zu verstehen und dann zu optimieren. Als evolutionäre Herangehensweise werden nicht erst einmal alle Prozesse über den Haufen geworfen und durch neue Rituale und Rollen zu ersetzt: Stattdessen erfolgt eine schrittweise Verbesserung vorhandener Prozesse. Das kann aber auch eine Gefahr sein: Wegen der hohen Freiheitsgrade wechseln viele ehemalige Scrum-Anhänger zu Kanban, weil sie aus irgendwelchen Gründen nicht funktioniert. Wenn man genauer hinsieht, liegt es selten daran, dass die vielen Meetings, Rollen und sonstigen Modellbestandteile zu aufwändig sind. Sondern fast immer liegt es daran, dass die Unternehmenskultur und die diese Kultur prägenden Manager bestimmte Modellbestandteile ignorieren, die aber entscheidend für das Funktionieren des Modells sind. Typische Beispiel: Mitten im Sprint werden autoritär neue Userstories “reingedrückt” und dafür andere rausgenommen. Oder im Sinne des “Time to Market” werden die Bedenken der Entwickler ignoriert, das Gesamtsystem mit technischen Userstories zu stabilisieren. Stattdessen sollen kurzfristig nur Userstories mit einem Business Nutzen gemacht werden. Die typische Struktur einer Userstory enthält ja den Nutzen und einer der Mehrwerte von Scrum im Vergleich zu planbasierten Ansätzen. Diese Formel kann aber bei großem Druck vom Business zu schlechten Gesamtsystemen führen, in dem notwendige Architekturmaßnahmen auf immer spätere Sprints geschoben werden.

⚠️ Solche grundsätzlichen kulturellen Phänomene wird man nicht los, nur weil man von Scrum zu Kanban wechselt. Diese Probleme werden auch bei Kanban weiter ihre Wirkung entfalten.

Bei hybrider Einschätzung mit Checkliste zuerst die verbreitetste Variante (agiles Vorgehen eingebettet in planbasiertem Framework) checken

Erläuterung der einzelnen Phasen

  • Initialisierung und Auftragsklärung Motivation, Hintergründe, betroffene Org-einheiten, Festlegung Kernteam
  • Kritische Bestandsaufnahme und Standortbestimmung vollständiges Bild aktuelle Projektmanagement-Verfahren, auch mit Reifegradmodellen, Ableitung Qualifizierungsmaßnahmen
  • Externe Orientierung und Qualifizierung unabdingbar, dass sich Kernteam mit State of the art des PM beschäftigt, Befassung mit Erfahrung anderer branchennaher Unternehmen
  • Sollkonzeption, Maßnahmen und Zielbestimmung in Abstimmung auf die spezifischen Belange der Organisation, initiale Befüllung des Product Backlogs:
    • Eine Überforderung kann nur mit möglichst exakter Standortbestimmung vermieden werden.
    • Empfehlung für die Reihenfolge im Product Backlog:
      • Die Erfahrung zeigt, dass erst neue Methoden, dann neue Prozesse und schließlich neue Projektorganisationen mit neuen Handlungskompetenzen eingeführt werden sollten
      • Meine Empfehlung ist außerdem, zunächst mit Einzelprojektmanagement anzufangen und nicht gleichzeitig die komplexen und oft politischen Portfoliomanagementprozesse einzuführen. Gegen sehr grobe Portfolio-Prozesse wie z.B. welches Gremium genehmigt wann Projektanträge ist natürlich nichts zu sagen. Aber darüber hinausgehende Detaillierungen im Portfoliomanagement erhöhen aus meiner Sicht deutlich die inhaltliche Komplexität, die aufgrund des hohen Politikfaktors dieses Themas noch weiter gesteigert wird. Deshalb würde ich immer die “Einführung von Portfoliomanagement” als eigenes Changeprojekt definieren - auf Basis des erfolgreich eingeführten Einzelprojektmanagements.
  • Schrittweise Entwicklung und Implementierung inklusive Pilotanwendungen,  Projektmarketing und Kurzschulungen. Beispiel für das Vorgehen:
    • Im ersten Sprint werden die drei top priorisierten Themen („Userstories“), z.B. Zielhierarchie, Risikomanagement und Stakeholdermanagement aus dem Product Backlog in das Sprint Backlog gezogen.
    • Dann werden sie methodisch entwickelt.
    • Danach oder parallel zur Entwicklung werden sie in 1-3 Pilotprojekten ausprobiert.
    • Am Monatsende erfolgt der Review und die Abnahme der Userstories.
    • Das im Intranet begehbare PM-Handbuch wird aktualisiert - verbunden mit kurzen Schulungsvideos und ggf. einer Aufforderung zur Nutzung durch das Top-Management.
  • Evaluation Anwendbarkeit und Nutzen Einbau der Feedbacks aus Pilot- und Breitenanwendung
  • Kontinuierliche Verbesserung (KVP)

Checkliste zur Prüfung, ob eine Phase agile abgewickelt werden kann Bei der Prüfung, ob es eine Phase im Phasenplan gibt, die sich agil gestalten lässt, geht man aus meiner Sicht am besten alle Phasen nacheinander durch und setzt sich mit den folgenden Fragestellungen auseinander. Der Einfachheit halber unterstelle ich hier eine Abwicklung mit der verbreitetsten agilen Methode Scrum. Wenn die meisten der folgenden planbasierten Checklistenpunkte als gegeben abgehakt werden, sollte man sich als Projektleiter gut überlegen, diese Phase trotzdem agil zu gestalten:

  • Die Qualität des Phasenabschluss-Meilensteins kann mit klaren (ggf. quantifizierten) Kriterien beschrieben werden.
  • Eine klar definierte Qualität am Ende einer Phase ist wichtig, um ohne technische Restschulden in die nächste Phase zu gehen und/oder, weil sich zu einem bestimmten Zeitpunkt andere Projektpartner auf die definierte Qualität einstellen müssen (z.B. auf das Vorliegen einer klar beschriebenen Schnittstelle)
  • Die einzelnen Arbeitspakete einer Phase bauen (wahrscheinlich) aufeinander auf und müssen in einer klar definierten Sequenz bearbeitet werden. Man kann also einen klaren kritischen Pfad definieren. Darüber hinaus ist die Einhaltung des Meilensteintermins wichtig.
  • Die Arbeiten müssen überwiegend von Spezialisten mit klar zu planender und zu verabredender zeitlicher Verfügbarkeit durchgeführt werden. Eine flexible gegenseitige Vertretung während der Phasenabwicklung ist kaum möglich.
  • Eine tägliche Neuplanung von Tagesaufgaben sowie flexible Übernahme verschiedenster Fachthemen durch verschiedene Teammitglieder erscheint nicht sinnvoll oder möglich.
  • Ein wöchentliches oder zweiwöchentliches Berichtswesen auf Arbeitspaketebene im Teamjourfix erscheint praktikabler als die in agilen Strukturen oft individuell gehaltenen Besprechungen zwischen einzelnen Teammitgliedern und der Projektleitung. An dieser Stelle sicherheitshalber die Begründung, warum ich beim Berichtswesen nicht das Daily erwähne: Idealtypisch dient das Daily bei Scrum nicht einer Statusbesprechung sondern der Vernetzung der Teammitglieder, dem Diskutieren über Probleme sowie der kleinteiligen Neuplanung der Arbeiten.

Ohne agiles Mindset der agilen Teams und der betroffenen Führungskräfte gleichen agile Vorgehensmodelle schnell einer substanzlosen Theater-Inszenierung

Das “Mindset” und die “Governance” sind das Fundament bei agilen Vorgehensmodellen. Hypothese einiger Experten: Es ist einfacher, mit einem agilen Mindset ein klassisches und damit auch hybrides Projekt zu managen, als mit einem klassischen Mindset ein hybrides oder agiles Projekt.

Für den Begriff “Mindset” gibt es die unterschiedlichsten Übersetzungen. Beispiel:

Mindset bedeutet ein Mischung aus Denkweise, Haltung und Herangehensweise. Werte und Prinzipien können insofern zum Sammelbegriff “Mindset” dazugezählt werden.

Diese Mischung ist zum Teil erlernt, basiert aber auch auf Persönlichkeitsmerkmalen. Zum Mindset gehören auch Annahmen: Positive Annahmen können uns in bestimmten Bereichen ermutigen und bestärken. Negative Annahmen können dazu führen, dass wir uns einige Dinge nicht zutrauen, sie deshalb vermeiden und damit auch nicht lernen können. 

Mit Governance sind Strukturen, Systeme und Prozessen einer Organisation gemeint, welche dem Projektleiter als Vorgaben Orientierung geben oder ihn in seiner Arbeit - hier Projektarbeit - unterstützen.

Governance kann sich beim Thema Projektmanagement zum Beispiel in einem Projektmanagement-Handbuch und einem Projektmanagementoffice manifestieren. Wenn es für bestimmte Projektarten und Rahmenbedingungen nicht offiziell erlaubt oder sogar gewünscht ist, mit agilen oder hybriden Vorgehensmodellen zu arbeiten, bedarf es schon eines gewissen Muts, solche Modelle trotzdem anzuwenden.

⚠️ Das Vorgehensmodell ist für Agilität nicht entscheidend, sondern Mindset und Governance

Werte sind dynamische, sich verändernde Vorstellungen davon, was richtig und erstrebenswert ist. Firmenwerte sind also moralisch positiv bewertete Überzeugungen und Verhaltensweisen, die von den Mitgliedern der Organisation geteilt werden.

Prinzipien sind nicht verhandelbare Grundsätze für die Zusammenarbeit in Organisationen, etwas immer gleich zu machen. Prinzip: „Das macht man immer so – ohne Ausnahme“. Regeln, an die wir uns immer halten wollen.

Werte sind sowas wie der Pfirsichkern und Prinzipien das Fruchtfleisch, damit einem die Werte schmecken. Werte können verändert werden und von Organisation geprägt werden. In Firmen ist es wichtig, aus den verschiedenen individuellen Werten eine gemeinsame Basis zu schaffen, sie in gemeinsamen und akzeptierten Prinzipien (“agile Verfassung”) sichtbar zu machen. Ein solcher Wert- und Kulturwandel ist komplex und nicht einfach. In diesem Zusammenhang sollte man aber auch bedenken, dass die konsequente Anwendung agiler Frameworks nicht nur Werte voraussetzt, sondern durchaus auch umgekehrt die Bildung agiler Werte bewirken kann. Das ist aber aus meiner Sicht nur ein Zusatzfaktor und “cultural design” in Richtung agiler Werte nicht ersetzen.

Bei agilen Werten muss man unterscheiden:

  • Die agilen Werte aus dem Scrum Guide von Sutherland und Schwaber sind Fokus, Offenheit, Mut, Respekt und Commitment. Auf die Bedeutung der einzelnen Werte wird im “Hintergrund-Teil” näher eingegangen.
  • Die agilen Werte aus dem agilen Manifest, bei dem Softwareentwickler 2001 zusammenkamen, um eine gemeinsame Antwort auf - aus ihrer Sicht - starre, schwerfällige Entwicklungsprozesse zu formulieren und eine flexiblere, menschenzentrierter Arbeitsweise zu schaffen:
    • Individuen und Interaktionen über Prozesse und Werkzeuge: Das Team kommuniziert regelmäßig und arbeitet eng zusammen, anstatt sich auf starre Prozesse und Tools zu verlassen.
    • Funktionierende Software über umfassende Dokumentation: Das Ziel ist es, funktionsfähige Software schnell bereitzustellen, statt sich auf umfangreiche Dokumentation zu konzentrieren.
    • Zusammenarbeit mit dem Kunden über Vertragsverhandlungen: Der Kunde wird kontinuierlich in den Prozess eingebunden, sodass Änderungen und Feedback schnell umgesetzt werden können.
    • Reagieren auf Veränderung über das Befolgen eines Plans: Agilität bedeutet, flexibel auf Änderungen zu reagieren und den Plan je nach Bedarf anzupassen.

⚠️ Die Autoren des Manifestes meinten nicht, dass die Werte auf der rechten Seite hinter “über” ignoriert werden dürfen, sie sind für das agile Arbeiten nur weniger wichtig als die Werte auf der linken Seite.

Das agile Manifest unterscheidet auch 12 Prinzipien für eine flexible, kundenorientierte und iterative Arbeitsweise, auf die im Hintergrundteil weiter unten näher eingegangen wird.

Beispiel aus der obigen Darstellung: Es braucht Mut und Offenheit, sich täglich in einem Daily (Methode) an Taskboard (Werkzueug) zu stellen, um von Problemen zu berichten, die man gerade mit seiner aktuellen Aufgabe (Task) hat. Einfacher und gesichtswahrender und ist es meist in planbasierten Ansätzen, als Arbeitspaketverantwortlicher alle zwei Wochen ohne Taskboard im Teamjourfix über sein Arbeitspaket zu „philosophieren“. Meist können die anderen wegen der strikten Arbeitstrennung nicht genau beurteilen, ob es irgendwo hakt und ob der Kollege mit einem Tipp vielleicht effizienter arbeiten könnte. Die Transparenz ist geringer und das Reden über die Arbeit erfordert meist deutlich weniger Mut.

Die Werte von SCRUM sind universell einsetzbar und fördern eine gesunde, produktive und kollaborative Arbeitskultur – ganz gleich, ob es um Marketingkampagnen, Eventorganisation, Produktentwicklung oder Change-Prozesse geht.

Commitment kann auch mit “Selbstverpflichtung zur Erreichung anspruchsvoller Ziele” übersetzt werden: Menschen übernehmen bewusst Verantwortung für ihre Aufgaben. Teams arbeiten zielgerichteter, wenn sie sich gemeinsam zu einem Ziel bekennen – z. B. bei der Organisation einer Messe oder der Entwicklung einer neuen Dienstleistung. Umsetzung in Scrum zum Beispiel:

  • Ambitionslos gezogene Userstories im Sprintplanning und fehlendes Einbringen von Verbesserungsvorschlägen sind Indizien für fehlendes Commitment.
  • Stabile 100%-Zuordnung der Ressourcen zu Scrum Teams verhindert eine Zerfaserung der Projektloyalität, wie es in einer Matrix deutlich schneller passieren kann.

⚠️ Viele Führungskräfte machen mit Bereitschaft zur Selbstorganisation und Verantwortungsübernahme und der sogenannten “New Work” ernüchternde Erfahrungen.

Fokus bedeutet “Konzentration auf das Wesentliche”: In Projekten gibt es oft viele parallele Themen. Der Wert Fokus hilft, Prioritäten zu setzen und nicht in Aktionismus zu verfallen. Gerade bei cross-funktionalen Teams (z. B. Marketing, Vertrieb und Produktion) sorgt der Fokus dafür, dass alle am gleichen Ziel arbeiten. Umsetzung in Scrum zum Beispiel:

  • Priorisierung im Product Product und Sprint Backlog
  • Limitierung Sprints auf erreichbares Inkrement
  • Enge Zusammenarbeit im Sprint
  • Bereitstellung eines Projektraums
  • Vereinbarung Spielregeln der Zusammenarbeit, z.B. wann Unterbrechungen erlaubt sind

Respekt bedeutet “Wertschätzung der Vielfalt”: Unterschiedliche Perspektiven und Fachbereiche treffen oft aufeinander. Respekt sorgt dafür, dass Zusammenarbeit gelingt, auch wenn Menschen anders denken oder arbeiten. Gerade in interdisziplinären Projekten ist das Gold wert. Umsetzung in Scrum zum Beispiel:

  • Respekt gegenüber anderen ist Basis für Offenheit (ernsthafte Beschäftigung mit Vorschlag)
  • Andererseits: Die automatische Interpretation von Vorschlägen anderer als Respektlosigkeit und persönlicher Angriff blockiert sachliche Abwägung
  • Sinkende gesellschaftliche Streitkultur und Toleranz stellen für diesen Wert schwierige Rahmenbedingungen dar.

Offenheit meint den ehrlichen Umgang mit Fortschritt und Problemen: In agilen Projekten entstehen häufig neue Anforderungen oder unerwartete Hindernisse. Offenheit schafft die Grundlage, schnell zu reagieren. Beispiel: In einer agilen Produktentwicklung (z. B. Möbelstück oder Schulungskonzept) bringt Offenheit neue Ideen schneller in den Prozess. Offenheit fühlt sich umgangssprachlich ähnlich an wie “Respekt”. Es gibt aber einen entscheidenden Unterschied: Geäußerte Ideen werden nicht nur gewürdigt (Respekt) sondern wirklich ernsthaft in Betracht gezogen und nicht direkt blockiert. In Scrum bedeutet Offenheit zum Beispiel:

  • Ehrlichkeit beim Review (was wurde erreicht, was nicht)
  • Unrealistische Sprintumfänge werden angesprochen (Pull-Prinzip stützt das)
  • Ehrlichkeit über Probleme in Retro und Daily (Struktur zwingt zur Offenheit)
  • Sichtbarkeit Taskboard

Mut meint, Veränderungen anzusprechen und Neues ausprobieren: In jedem agilen Projekt (egal ob IT oder nicht) müssen Menschen Entscheidungen treffen, Dinge hinterfragen, Fehler zugeben oder neue Wege einschlagen. Mut schafft Raum für Innovation, Experimente und konstruktives Scheitern. Gerade VUCA-Zeiten erfordern eher Mut als Zaghaftigkeit. Umsetzung in Scrum zum Beispiel:

  • Im Sprint bedeutet Mut zum Beispiel, auf ein zu “Warmes Anziehen” im Sprintplanning zu verzichten.
  • Umgekehrt erfordert aber i.d.R. Mut, einem hierarchisch höhergestellten Product-Owner (was nicht selten der Fall ist) bei unrealistischen Sprintzielen zu widersprechen.

Die 12 Prinzipien des agilen Manifestes lauten wie folgt:

  • Kundenzufriedenheit durch kontinuierliche Lieferungen:
    • Eine frühe und regelmäßige Auslieferung nutzbarer Ergebnisse liefert dem Kunden schnell einen sichtbaren Mehrwert und sorgt deshalb zur Zufriedenheit wegen der schnell möglichen Nutzung von Projektergebnissen.
    • Ebenso trägt beim Kunden zur Zufriedenheit bei, kontinuierliches Feedback bei vielen Teillieferungen geben zu können anstatt nur am Ende bei einer großen Lieferung. So können Fehlentwicklungen eher vermieden werden, was die Kundenzufriedenheit ebenfalls steigert.
    • Bei Zwischenmeilensteinen wird oft der Fokus auf reine Planerfüllung und weniger auf Kundenzufriedenheit gelegt. Durch die kontinuierlichen Lieferungen wird also die Kundenzufriedenheit zum zentralen Erfolgsmaßstab
  • Fortlaufende Lieferung von (Teil-) Ergebnissen:
    • Die frühe und kontinuierliche Lösung oder Teillösung an den Nutzer nach jedem Zyklus sollen frühe Rückmeldungen durch die tatsächliche Nutzung ermöglichen.
    • Die neuen Erkenntnisse werden kontinuierlich aufgegriffen. Zudem wird die Kundenzufriedenheit durch die intensive und regelmäßige Einbeziehung (bei unterstellter Bereitschaft dazu) sowie eine frühe und kontinuierliche Versorgung mit neuen Funktionalitäten erhöht.
    • In planbasierten Ansätzen erhält der Kunde seine Lieferobjekte oft erst am Ende.
  • Begrüße Änderungen:
    • Änderungen werden selbst spät in der Entwicklung begrüßt, weil im Vordergrund die Stärkung der Wettbewerbsfähigkeit des Kunden und nicht der Aufwand im Projektmanagement steht.
    • In planbasierten Ansätzen werden Änderungen meist eher als Störfaktor bewertet, weil der Änderungsprozess aufwändig ist und Pläne geändert werden müssen.
  • Crossfunktionale Zusammenarbeit:
    • Interdisziplinäre Teams vereinen alle benötigten Kompetenzen, um Ergebnisse eigenständig und ohne externe Abhängigkeiten liefern zu können.
    • Statt Silodenken sollen durch crossfunktionale Zusammenarbeit Abstimmungen beschleunigt und Reibungsverluste reduziert werden.
    • Gemeinsame Verantwortung für das Ergebnis gehört beim crossfunktionalen Arbeiten dazu, sodass nicht einzelne Silos, sondern das Team als Ganzes für den Erfolg einsteht.
  • Arbeite vertrauensvoll mit motivierten Teams:
    • Fachexperten sollen während des Projekts in stabilen Teams täglich nur in einem Projekt zusammenarbeiten, während in planbasierten Ansätzen die Teams oft während der Projektzeit neu zusammengestellt werden und oft in mehreren Projekten (Matrix) arbeiten.
    • Dadurch kann die Motivation und das gegenseitige Vertrauen sinken, was oft ein zusätzlich demotivierendes Mikromanagement zu Folge hat. In agilen Teams wird eher auf ein motivierendes Umfeld gesetzt und darauf vertraut, dass das Team die Aufgaben erledigt.
  • Persönliche Kommunikation hat Vorrang: Sie ist die effizienteste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, weil sie Rückfragen bei Unklarheiten zulässt im Gegensatz zu der oft asynchronen Kommunikation in planbasierten Ansätzen.
  • Abgeschlossene Ergebnisse als Fortschrittsmaß: In agilen Ansätzen wie Scrum sind Inkremente am Ende eines Sprints in der Regel ein effizienteres inhaltliches Fortschrittsmaß als bei planbasierten Ansätzen, die oft auf inhaltliche Fortschrittskontrolle verzichten und sich oft nur auf die Kontrolle Kosten und Zeit konzentrieren (was in vielen agilen Ansätzen wegen dem stabilen Team und dem Timeboxingprinzip oft eine untergeordnete Rolle spielt).
  • Nachhaltige (Arbeits-) Geschwindigkeit:
    • Auftraggebern, Entwickler und User sollen langfristig das gleichmäßige Tempo halten, was in planbasierten Ansätzen oft schwieriger ist:
    • Die häufige Kombination aus großer Verantwortung und wenig Befugnissen der Projektleitung in Verbindung mit oft Top-Down vorgegebenen unrealistischen Zielen (im Gegensatz z.B. zur Festlegung der Userstory-Zahl durch die Entwickler bei Scrum) führt oft zu Projektverzug und Eskalationen, die oft zu weiteren Verzögerungen und nicht zum gewünschten gleichmäßigen Fortschritt führen.
    • Nach vielen Untersuchungen ist die Zufriedenheit in (gut gelebten) agilen Strukturen auch deshalb größer, weil es weniger kurzfristige Belastungsspitzen durch Top-Management-Druck gibt.
  • Strebe Vereinfachung und Reduzierung an:
    • Fokus auf das Wesentliche, indem nur Arbeit umgesetzt wird, die echten Mehrwert für den Kunden schafft.
    • Vermeidung unnötiger Komplexität, etwa durch schlanke Lösungen, reduzierte Bürokratie und klare Prioritäten.
    • Bewusste Minimierung nicht benötigter Arbeit, um Ressourcen zu schonen und Durchlaufzeiten zu verkürzen.
  • Streben nach (technischer) Exzellenz:
    • Die Kunst besteht darin, im Gegensatz zu dem (gerade in Deutschland) verbreiteten Perfektionismus auf Goldstandards zu verzichten und sich die Essenz aus Kundensicht zu konzentrieren.
    • Das Streben nach Reduzierung wird auch durch agile Ansätze wie Minimal Viable Product oder Design Thinking (frühe und viele Test schon mit einfachen Prototypen) gefördert.
    • Die Komplexität soll in planbasierten Ansätzen eher durch Pläne und nicht durch iteratives und inkrementelles Vorgehen beherrscht werden, was durch  spätere Änderungen zu Qualitätseinbußen führen kann.
    • Die technische Excellenz kann durch einen zu großen Kundenfokus erfahrungsgemäß aber auch beeinträchtigt werden, wenn notwendige Architektur-Userstories zugunsten wertschöpfender Userstories auf spätere Zeiten verschoben werden und dadurch ggf. Stückwerk entsteht.
  • Das Team arbeitet selbstorganisiert: Durch Selbstorganisation entstehen oft bessere Architekturen und Entwürfe als durch kreativitätshemmende hierarchische Strukturen mit Fehlervermeidungskulturen, wie sie planbasierten Ansätzen noch weit verbreitet sind.
  • Reflektion und Adaptation: Die Reflexions- und Adaptionshäufigkeit ist oft deutlich größer als in planbasierten Strukturen, zumal sie in Ansätzen wie Scrum (Retrospektiven) für jeden Sprint vorgesehen sind, während sie in planbasierten Vorgehensmodellen oft erst während der Abschlussphase auftauchen.