You name it – we have it: Antipatterns im Management „agiler“ Projekte

Die meisten Softwareentwickler, Architekten, Projektmanager und auch Kunden erfahren das immer wieder und teils frustrierend in ihrem Arbeitsalltag. Daher ist sinnvoll, sich ab und zu einmal gängige Muster für das anzuschauen, was üblicherweise in Softwareprojekten schief geht, damit man es früh erkennt, verbalisieren und dann auch vermeiden kann.

Dieser Artikel zeigt Ihnen ein paar „Oldies but Goodies“ aus der Welt der Antipatterns mit Schwerpunkt auf agile Projekte, deren Kenntnis nützlich ist, und gibt Ihnen Hinweise, wo Sie mehr finden. Wenn man seine Probleme verbalisieren kann und eine Sprache dafür hat, kann man sie leichter angehen und lösen. Dieser Artikel ruft ein paar Vokabeln aus der Sprache von Projekten in Schwierigkeiten ins Bewusstsein und zeigt Ihnen, wo Sie bei Bedarf mehr finden.

Der Artikel zeigt Ihnen, wo Sie nachsehen können und wo Sie Checklisten für typische Probleme in agilen Projekten finden, wenn Sie in Ihrem Projekt das Gefühl haben, dass „irgendetwas nicht stimmt“. Sie können dann typische Antipatterns in Ihren agilen Projekten leichter identifizieren und dazu beitragen, wirksame Gegenmaßnahmen zu ergreifen.

Agil heißt noch nicht problembefreit

Im Jahr 1994 erschien der erste Chaos Report der Standish Group. Management Stakeholder wurden damals mit dem Befund „geschockt“, dass nur etwa 16 Prozent aller IT-Projekte erfolgreich waren. Damals hatte man es vor allem mit Wasserfallprojekten zu tun. Bis heute hat die Standish Group ca. 40.000 Projekt untersucht, kategorisiert und auf ihre Erfolge hin eingeordnet.

Dabei hat sich sehr wohl gezeigt, dass die Erfolgswahrscheinlichkeit von agilen Projekten, die ab den späten 1990er-Jahren populär wurden, etwa um den Faktor 2 höher ist als Wasserfallprojekte mit ähnlichen Größenparametern. Es finden sich aber sowohl in Wasserfallprojekten als auch in agilen Projekten typische Muster dafür, was oft nicht gut läuft. Agil allein ist auch sicher nicht der alleinige Treiber von Projekterfolg, wie Abbildung 1 eindrucksvoll illustriert.

Abb. 1: Erfolgswahrscheinlichkeiten von Projekten – Auswertung von Chaos-Reports der Standish Group 1996 – 2022. Quelle: Blog von Michael Küsters [1]

Michael Küsters, der Autor von Abbildung 1, schreibt dazu in seinem Blog [1]:

Restating the obvious: there were many factors at play, each of them certainly significant to boost success rates from about 15% in 1994 to the 30% we see today. But there's no one single factor that could be isolated to say, "This factor brought us to 30%, and if we just do more of that, it'll bring us to 50% or higher!" If anything, the data shows that no single factor has been identified that has the potential to boost success rates any further than what we already had in the early days of the Agile Manifesto [K. Beck et al.].

"Agile" most certainly hasn't proven to be the Silver Bullet that will singlehandedly fix the industry

Übersetzung: Das Offensichtliche neu formuliert: Es waren viele Faktoren im Spiel, die alle sicherlich bedeutsam waren, um die Erfolgsquoten für Projekte von etwa 15 % im Jahr 1994 auf die 30 % zu steigern, die wir heute sehen. Aber es gibt keinen einzelnen Faktor, der isoliert werden könnte, um die Aussage zu erlauben: „Dieser Faktor hat uns auf 30 % Erfolgsquote gebracht, und wenn wir einfach mehr davon machen, wird er uns auf 50 % oder höher bringen!“ Wenn überhaupt, zeigen die Daten, dass kein einzelner Faktor identifiziert werden konnte, der das Potenzial hat, die Erfolgsquoten weiter zu steigern als das, was wir bereits in den Anfangstagen des Agilen Manifests gesehen haben. „Agil“ hat sich ganz sicher nicht als die Wunderwaffe erwiesen, die im Alleingang die Branche reparieren wird.

Auch wenn die Erfolgswahrscheinlichkeit agiler Projekte heute mit rund 30 Prozent höher ist als die von Wasserfallprojekten in den späten 1990er-Jahren, gibt es noch sehr viel Luft nach oben, was Projekterfolg anlangt. Interessant an Abbildung 1 ist vor allem die Schwankung der Erfolgsquote und die Tatsache, dass es keinen stabilen Trend nach oben gibt. Es muss also viele Einflussfaktoren geben. Wenn man darüber sprechen möchte, was Projekte erfolgreich macht oder eben auch nicht, stößt man auf den schon älteren Begriff von Antipatterns [2].

Antipatterns und warum sie nützlich sind

Patterns sind unter anderem deshalb nützlich, weil sie eine gemeinsame Sprache schaffen für Dinge, die jeder Softwareschaffende kennt. Es begann unter anderem mit dem Buch „Design Patterns“ von Erich Gamma et al. Aber die sogenannte Pattern Community beruft sich vor allem auf die Werke von Christopher Alexander, der schon in den 1970er-Jahren Patterns im Bereich von Bauarchitektur beschrieben hatte („A Pattern Language: Towns, Buildings, Construction" im Jahr 1977).

Daraus resultierte die Idee, nicht nur Dingen einen Namen zu gebe, die positiv sind und gut laufen, sondern auch solchen Phänomenen einen Namen zuzuweisen, bei denen man sehr oft bemerken konnte, dass sie weniger gut laufen. Es entstand die Idee von Antipatterns, siehe das Buch von William Brown, Hays McCormick und Scott Thomas [2], die in der Pattern Community heftig diskutiert wurden, weil sie eben nicht zunächst „das Gute und Schöne thematisierten“, sondern ein Vokabular für Dinge schufen, die eher negativ laufen und daher „refactored“ werden müssen. In dem Buch gibt es, wie auch bei positiven Patterns, eine Pattern-Form, das sich vor allem auch damit beschäftigt, was man tun kann, um das negative Phänomen zu beseitigen.

Nicht alle diese Muster haben sich als Begriffe durchgesetzt. Hier seien ein paar genannt und Sie können den Test machen, ob Ihnen diese Dinge als Antipatterns geläufig sind: The Standards, Micro Management, Corporate Craziness, The Brawl, Size isn’t Everything, Chaos, Process Disintegration, Batteries not Included, Distributed Disaster, Gilding the Lily (aka Gold Plating), Killer Demo, One-Shot Deal.

Das Buch enthält mehr. Aber man sieht schon, nicht alle diese Antipatterns sind einem sofort präsent, wenn man diese Liste liest. Eher wenige, einmal abgesehen von Micro Management oder „Goldenen Türgriffen“ (Gold Plating). Das Konzept an sich ist gut – für ein Vokabular zum Thema notleidende Projekte, speziell im agilen Umfeld soll Ihnen dieser Artikel noch ein paar nützliche Ideen geben. Sie mögen sich jetzt fragen, was wir hier mit 20 Jahre alten Quellen zeigen wollen. Das Thema ist ein Dauerbrenner und wird durchaus weiter beachtet, wie aktuelle Beiträge von Ben Linders [3], [4] zeigen.

Death March – die Mutter der Projekt-Management-Antipatterns

Beginnen wir mit einem recht fundamentalen Antipattern im Projektmanagement, das die Mutter vieler Folgeprobleme in agilen und anderen Projekten ist: Death-March-Projekte sind ein fundamentales Antipattern im Projektmanagement, das auch im agilen Kontext weiterhin relevant bleibt. Der Begriff geht auf Edward Yourdon zurück [5], der ihn aus dem Film „Die Brücke am Kwai“ bezog, in dem englische Kriegsgefangene der Japaner unter unmenschlichen Bedingungen eine Eisenbahnlinie bauen mussten.

Ein Death-March-Projekt ist dadurch gekennzeichnet, dass es in mindestens einem Punkt um mindestens einen Faktor 2 oder größer von der Norm abweicht. Also zum Beispiel doppelt so schnell sein sollte wie normal; halbe Ressourcen wie normal; Vielfaches einer normalen Projektgröße oder auch komplett neue Technologien. Viele Death-March-Projekte erfüllen mehr als ein solches Kriterium.

Entwickler sollten den Begriff aus mehreren Gründen kennen. Wenn solche Projekte schlecht laufen, kann es sein, dass das Management die Mitarbeiter beschuldigt – obwohl eigentlich klar ist, dass sie nicht einfach faul sind, sondern es eben mit einem Death March zu tun haben. Eine häufige Folge ist Burn-out – den man passabel vermeiden kann, wenn man weiß, in welchem Umfeld man sich bewegt.

In diesem Kontext sind auch Subtypen von solchen Projekten noch interessant. Yourdon verwendet hier eine bei Beratern gerne verwendete 4-Quadranten-Matrix (siehe Abb. 2) und benutzt Happiness (also positive Gefühle der Mitarbeiter im Projekt) und Erfolgschancen als Kriterien. Die Bezeichnungen sind eigentlich selbsterklärend und nicht wenige von uns waren sicher schon mal in einem „Ugly Project“ oder haben sich gefreut, eine Mission Impossible doch bewältigt zu haben.

Abb. 2: Vier Typen von Death-March-Projekten nach Yourdon [5]

Man kann dann mit seinem Management auch darüber sprechen, was man hier gemeinsam vor sich hat, und die Konsequenzen ziehen, wenn das Management sich taub stellt. Allein schon die Einschätzung als Death March ist eine wichtige Information für Projektmanager und betroffene Mitarbeiter. Und sowohl Projektmanager als auch Mitarbeiter können auf dieses Wissen reagieren.

Auch in der Ära agiler Methoden, die laut Standish Group immerhin eine 3- bis 4-mal höhere Erfolgswahrscheinlichkeit bieten als ein Death March mit Wasserfall, bleiben Death-March-Projekte ein relevantes Problem. Daher ist es auch im agilen Umfeld immer noch wichtig, genau dieses Muster erkennen zu können.

Häufige Antipatterns in „agil“ genannten Projekten

Man wird bestimmt um die 100 Antipatterns im Kontext agiler Projekte finden können. Allein der LinkedIn-Artikel von Norul Ameen A [6] enthält 83 Thumbnails, die man als Checkliste einsetzen kann. Die folgende kleine Auswahl von zehn Thumbnails gängiger Antipatterns soll Ihnen noch ein paar Vokabeln für Dinge an die Hand geben, die Sie vielleicht auch schon einmal in agilen Projekten gesehen haben, und Ihnen die Idee vermitteln. Diese und andere Antipatterns haben oft negative Auswirkungen auf den Projekterfolg, wenn man sie nicht angeht.

Tabelle 1 zeigt, dass viele der im Folgenden genannten Antipatterns aus dem agilen Kontext auch in jeder anderen Art von Projekten auftreten können. Doch hier eine Auswahl häufig vorkommender agiler Antipatterns in der Form von Thumbnails.

Waterfall in Disguise

Agile Prozesse werden formal eingeführt, aber in der Praxis wird ein Wasserfallansatz verfolgt. Teams planen große Releases weit im Voraus, ohne iterative Feedbackschleifen, was die Flexibilität einschränkt. Anforderungen werden in langen Dokumenten festgelegt, und Änderungen sind schwer umzusetzen. Dies führt zu verzögerten Lieferungen und Frustration im Team. Agilität bleibt ein Schlagwort ohne tatsächliche Umsetzung.

Cargo Cult Agilität

Teams kopieren agile Praktiken wie Daily Standups oder Sprints, ohne deren Sinn zu verstehen. Rituale werden mechanisch durchgeführt, ohne dass sie Mehrwert liefern. Beispielsweise werden Standups zu langen Statusmeetings, anstatt Probleme zu lösen. Dies führt zu ineffizienten Prozessen und fehlendem Teamengagement. Die wahre agile Kultur bleibt aus.

Big Design Upfront (BDUF)

Trotz agiler Methodik wird viel Zeit in eine detaillierte Planung und Architektur investiert, bevor der Entwicklungsprozess beginnt. Dies widerspricht dem iterativen Ansatz und verzögert die erste Auslieferung. Änderungen im Verlauf des Projekts werden schwierig, da die Architektur unflexibel ist. Teams verlieren die Möglichkeit, frühzeitig Feedback zu erhalten. Es entsteht ein Konflikt zwischen Planungssicherheit und Agilität.

Feature Factory

Teams konzentrieren sich darauf, möglichst viele Features schnell auszuliefern, ohne den Nutzen für den Kunden zu validieren. Die Qualität und Wartbarkeit des Codes leiden darunter. Es fehlt an Priorisierung basierend auf Kundenwert, und technische Schulden häufen sich an. Dies führt zu einem Produkt, das zwar viele Funktionen hat, aber schwer wartbar ist. Langfristig steigen die Wartungskosten erheblich.

Hero Culture

Einzelne Teammitglieder werden als „Helden“ gefeiert, die in letzter Minute Probleme lösen oder Überstunden machen, um Deadlines einzuhalten. Dies fördert keine nachhaltige Teamarbeit und führt zu Burn-out. Wissen bleibt bei wenigen konzentriert, was die Zusammenarbeit erschwert. Langfristig leiden die Teamdynamik und die Projektstabilität. Eine Kultur der Zusammenarbeit wird untergraben.

Overloaded Sprints

Teams nehmen in jedem Sprint zu viele Aufgaben an, um Deadlines zu erfüllen. Dies führt zu Überlastung, schlechter Qualität und unvollständigen Arbeiten. Die ständige Eile verhindert Reflexion und Lernen. Technische Schulden wachsen, und die Teamdynamik leidet unter Stress. Nachhaltige Entwicklung wird unmöglich.

Proxy Product Owner

Der wirkliche Product Owner ist nicht direkt involviert. Der Proxy dafür im Projekt hat keine Entscheidungsbefugnis, sondern fungiert als Stellvertreter für Stakeholder. Dies führt zu verzögerten Entscheidungen und unklaren Prioritäten. Das Team arbeitet an Features, die nicht den tatsächlichen Kundenbedürfnissen entsprechen. Missverständnisse und Nacharbeiten häufen sich. Der agile Wert der Kundenorientierung wird untergraben.

Siloed Teams

In großen Projekten arbeiten Teams in isolierten Silos, ohne ausreichende Kommunikation oder Abstimmung. Abhängigkeiten zwischen Teams werden nicht koordiniert, was zu Verzögerungen führt. Jeder Teil des Systems wird unabhängig optimiert, was die Gesamtarchitektur schwächt. Die Integration am Projektende wird chaotisch. Ein gemeinsames Ziel fehlt.

Neglecting Technical Debt

Teams priorisieren neue Features über die Behebung technischer Schulden, um schneller Ergebnisse zu liefern. Dies führt zu instabilem Code, häufigen Fehlern und steigenden Wartungskosten. Die Entwicklungsgeschwindigkeit nimmt langfristig ab, da Probleme sich häufen. Frustration im Team wächst, da einfache Änderungen kompliziert werden. Nachhaltigkeit wird geopfert.

Viele dieser Antipatterns lassen sich vermeiden, wenn man einen guten erfahrenen Agilisten im Team oder Projekt hat. Leider wird der oft wegrationalisiert und dann hat man das Antipattern ScrumBut vor sich.

ScrumBut

Teams behaupten, Scrum zu nutzen, passen aber zentrale Praktiken an oder lassen sie weg („Wir machen Scrum, aber ...“ – Scrum .. but). Beispielsweise werden Retrospektiven ausgelassen oder Sprints nicht konsequent geplant. Dies führt zu unklaren Prozessen und mangelnder Transparenz. Die Vorteile von Agilität (oder Scrum), wie kontinuierliche Verbesserung, gehen verloren. Das Projekt stagniert in einer halb-agilen Grauzone. Eine Ausprägung davon ist, dass der Scrum Master oder agile Coach eingespart wird. Das Antipattern wird dann auch als „Scrum Master Cut“ bezeichnet.

Beischreibung von Antipatterns

Die zehn Beispiele oben sind natürlich nur sogenannten Thumbnails der eigentlichen Patterns. Oft reichen solche Thumbnails aber aus, um das Problem für jeden wiedererkennbar zu beschreiben, um ihm einen Namen zu geben und um dann in der Folge darüber sprechen zu können, ob man im Projekt betroffen ist.

Eine Form, die einer Beschreibung in der Literatur näher käme, zeigt Kasten 1. Und daran sieht man auch, dass es den Umfang eines solchen Artikels sprengen würde, würde man hier auch nur die obigen zehn Antipatterns komplett ausformulieren. In [2] nimmt ein einziges Antipattern mit Kontext, Varianten und Ansätzen für Verbesserungen oft zehn oder mehr Buchseiten ein.

Name: Scrum Master Cut
Ein einprägsamer Name, der das Problem beschreibt: Der Scrum Master wird aus Kostengründen entfernt oder durch eine billigere, unqualifizierte Alternative ersetzt, was den agilen Prozess schwächt.

Beschreibung (Problem)

Ein Unternehmen oder Projektteam, oft unter finanziellen Zwängen, betrachtet den Scrum Master als entbehrliche Kostenstelle und rationalisiert die Rolle weg oder überträgt deren Aufgaben an unqualifizierte Teammitglieder (z. B. Entwickler oder Projektmanager). Dies führt zu einem Mangel an Facilitation, Coaching und Konfliktlösung, wodurch agile Prinzipien wie Selbstorganisation und kontinuierliche Verbesserung verloren gehen. Der Prozess wird ineffizient, und das Team fällt in alte, nicht-agile Verhaltensmuster zurück. Zum Beispiel könnte in einer Festpreissituation der Auftragnehmer den Scrum Master entfernt haben, um Kosten zu sparen, was eine Projektbudgetkrise mittelfristig eher verschärft. Das Antipattern widerspricht dem agilen Wert, Menschen und Interaktionen über Prozesse und Tools zu stellen.

Kontext

• Tritt häufig in Festpreisprojekten mit Budgetdruck auf, bei denen der Auftragnehmer am finanziellen Limit ist.
• Häufig in Organisationen, die Agilität als Kostenfaktor statt als Investition sehen.
• Oft in „agilen“ Projekten, die nur oberflächlich agil sind (z. B. Ihr Projekt, das „agil“ genannt wird, aber Wasserfallelemente zeigt).
• Besonders relevant, wenn das Management die Rolle des Scrum Masters nicht versteht oder unterschätzt.

Symptome und Konsequenzen

• Symptome: Fehlende Moderation bei Sprint-Planungen oder Retrospektiven, ungelöste Teamkonflikte, Rückfall in Wasserfallpraktiken, unklare Rollen.
• Konsequenzen: Sinkende Teamproduktivität, mangelnde Selbstorganisation, erhöhte technische Schulden durch fehlende Prozesskontrolle, Demotivation des Teams, verschärfte Projektkrisen (z. B. Bugwelle, verspätete Dokumentation).
• In vielen Projektsituationen kann dies zu mangelnder Koordination zwischen Kunde (Fachbereichsprozesse) und Auftragnehmer führen, da kein Scrum Master die Zusammenarbeit fördert.

Ursachen

• Finanzielle Zwänge: Der Auftragnehmer spart an „nicht-produktiven“ Rollen, um das Budget zu strecken.
• Missverständnis der Rolle: Das Management sieht den Scrum Master als reinen Meeting-Moderator statt als Coach und Change Agent.
• Kostendruck in Festpreisprojekten: Der Fokus liegt auf sichtbaren Ergebnissen (z. B. Code, Features), nicht auf Prozessverbesserung.
• Mangelnde agile Reife: Die Organisation versteht nicht, wie ein Scrum Master den Projekterfolg steigert.
• Angstkultur: Der Auftragnehmer vermeidet Investitionen, die das Top-Management hinterfragen könnte.

Ansätze für Verbesserungen

• Wiederherstellung der Rolle: Einen erfahrenen Scrum Master einstellen oder einen internen Mitarbeiter schulen, um die Rolle professionell auszufüllen.
• Bildung des Managements: Dem Management die Bedeutung des Scrum Masters erklären, z. B. durch Beispiele für Prozessverbesserungen oder Konfliktlösungen.
• Kosteneffiziente Alternativen: Einen Teilzeit-Scrum Master oder einen externen Coach für kritische Phasen engagieren, statt die Rolle komplett zu streichen.
• Team-Empowerment: Dem Team beibringen, einige Scrum-Master-Aufgaben (z. B. Moderation) selbst zu übernehmen, während ein externer Coach die Strategie unterstützt.
• Transparenz: Die Auswirkungen der Entfernung (z. B. Verzögerungen, Konflikte) messen und dem Management vorlegen, um Investitionen zu rechtfertigen.

Beispiel

In einem Festpreisprojekt könnte der Auftragnehmer den Scrum Master entfernt haben, um Kosten zu sparen, da die Rolle als „überflüssig“ galt. Ohne Scrum Master fehlt die Moderation bei Sprint-Planungen, was zu überladenen Sprints und technischen Schulden führt. Retrospektiven werden ausgelassen, sodass Probleme wie verspätete Dokumentation oder mangelnde Kundenbindung nicht angesprochen werden. Das Team fällt in einen Wasserfallmodus zurück, was den Overrun, der aus Kostengründen zum Abbau des Scrum Masters führte, verschärft. Ein Scrum Master hätte durch klare Priorisierung und Kommunikation die Krise abmildern können.

Verwandte Antipatterns

• ScrumBut: „Wir machen Scrum, aber ohne diverse Praktiken (Retros, Planning), weil die zu teuer sind.“
• Cargo Cult Agilität: Rituale wie Standups werden beibehalten, aber ohne Führung durch einen Scrum Master wirkungslos.
• Missing Facilitation: Allgemeiner Mangel an Moderation und Coaching in agilen Prozessen.
• Teamüberlastung: Ohne Scrum Master werden Teams mit Prozessaufgaben überfordert, wie in „Death March“ beschrieben.

Kasten 1: Antipattern: Scrum Master Cut

Wenn man die Probleme erkannt hat, wie beseitigt man sie dann?

Bleibt als Frage noch: Wenn man ein Problem zum Beispiel mithilfe von Antipatterns erkannt und benannt hat, wie löst man es dann. Es ist schon viel gewonnen, wenn man das Problem benennen und damit im Team einfacher diskutieren kann. Die Ansätze für Verbessrungen sind oft trivial, aber doch oft aufgrund von Rahmenbedingungen sehr schwer umsetzbar. Im Beispiel des Scrum Master Cut aus Kasten 1 ist die einfachste Lösung, wieder einen Scrum Master einzustellen. Doch wie soll das gehen, wenn kein Geld da ist.

Es ist bei sehr vielen „Good Practices“ leider immer wieder ähnlich: Man erkennt ein Antipattern, wie zum Beispiel „Feature Factory“, also dass zu viele Features geliefert werden, die nicht nach Kundenwert optimiert werden. Die Grundreaktion ist immer dieselbe: „Ja dann gehen wir es halt an!“ Die Gegenreaktion ist auch oft dieselbe: „Wir müssen fertig werden“ oder „Wir müssen einen Vertrag erfüllen“.

Die alte Parabel, dass man seine Axt nicht schärfen kann, weil man zu beschäftigt ist, Bäume umzuhacken, begegnet einem immer wieder im Projektgeschäft. Die Wege, um die Menschen zu überzeugen, die für noch schnelleres Hacken mit einer stumpfen Axt plädieren, sind vielfältig. In gut geschriebenen Antipatterns kann man oft Ansätze finden.

Immerhin kann man mithilfe von Antipatterns mindestens in die Diskussion mit den Management-Instanzen einsteigen, die über Budgets entscheiden, und falls man ignoriert wird (was nicht so selten vorkommen wird), sind die Risiken, Problemursachen und Verantwortung dokumentiert und man kann Trost aus der Tatsache ziehen, dass andere Menschen dieselben Probleme hatten und diese sogar so häufig vorkommen, dass sie einen Namen als Antipattern bekommen habe.

Ausblick: Es gibt viel mehr ...

Der Artikel hat Ihnen das Konzept von Antipatterns als Vokabular für Projektprobleme in Erinnerung gebracht und Ihnen weiter einige verbreitete Muster ins Gedächtnis gerufen. Oder er hat Ihnen Begriffe für Dinge gegeben, die Sie zwar immer wieder in Ihren Projekten sehen, aber vielleicht nicht verbalisieren und damit auch schwerer eskalieren können.

Womit wir beim Thema Eskalation angelangt wären. Brennen Sie sich nicht aus, sondern zögern Sie nicht, das, was Sie sehen, klar zu verbalisieren und klar zu eskalieren. Bleiben Sie dabei natürlich konstruktiv.

Auch wenn eine Eskalation keinen Erfolg hat, kann sehr hilfreich sein, zum Beispiel in einem schwierigen Projekt zu wissen, was man da eigentlich an Herausforderungen vor sich hat und warum. Man reduziert so das Risiko, auszubrennen. Ich war selbst in mehr als einem Death March. In meinem ersten Death March war das Buch von Ed Yourdon meine Nachlektüre unter dem Kopfkissen, wenn ich viel zu spät aus dem Projekt nach Hause gekommen bin. Ich konnte nicht alles abgestellt bekommen – aber immerhin konnte ich es immer wieder eindrücklich verbalisieren und kommunizieren.

Politik ist Wiederholung.

Literaturangaben

[1] M. Küsters, Is “Agile” just smoke and mirrors, BLOG entry, 26.1.2023, siehe: https://failfastmoveon.blogspot.com/2023/01/is-agile-just-smoke-and-mirrors.html

[2] W. J. Brown, H. W. McCormick, S. W. Thomas, AntiPatterns in Project Management, Wiley, 2000

[3] B. Linders, D. Johnston, Agile Anti-Patterns, A Systems Thinking Approach, infoQ. 14.6.2019, siehe: https://www.infoq.com/articles/agile-anti-patterns-systems-thinking/

[4] B. Linders, Organisational-Level Agile Anti-Patterns – Why They Exist and What to Do about Them, infoQ, 19.11.2020, siehe: https://www.infoq.com/news/2020/11/organisation-agile-anti-pattern/

[5] E. Yourdon, Death March, 2nd Edition, Pearson, 2003

[6] Norul Ameen A, List and Gist of Antipatterns for Agile; LinkedIn, 25.3.2023, siehe: https://www.linkedin.com/pulse/list-gist-antipatterns-agile-noorul-ameen-a/