In der dritten Woche einer sechswöchigen Website-Überarbeitung meldet sich die Rechtsabteilung beim Projektmanager: Eine neue Vorschrift erfordert Änderungen am Prozess der Cookie-Einwilligung. Das Design hat die Wireframes bereits freigegeben, die Entwicklung hat mit der Umsetzung begonnen und das Marketing hat bereits die Ankündigung des Launch-Termins gebucht. Das Team steckt bei einer Entscheidung fest: Sollen wir pausieren und neu planen oder weitermachen und die Änderung später integrieren? Mit jedem Tag, an dem die Entscheidung auf sich warten lässt, häuft sich die Nacharbeit an und das Vertrauen schwindet, da niemand sagen kann, welche Auswirkungen dies auf den neuen Starttermin hat. Dieser Kurs vermittelt Ihnen praktische Vorgehensweisen, um aus einer solchen Sackgasse herauszufinden. Sie lernen, wie kurze Feedbackschleifen funktionieren, wie Sie Backlog und Sprint nutzen, um realistische wöchentliche Zusagen zu treffen, wie Sie Stakeholder durch transparente Artefakte auf dem Laufenden halten und wie Sie mit Änderungen umgehen, ohne dass jede Anfrage zur Krise wird.
Um zu verstehen, was passiert, wenn Feedback zu lange auf sich warten lässt, arbeiten Sie anhand eines einfachen Projektzeitplans durch ein Szenario, in dem sich eine Anforderung mitten im Prozess ändert und vom Team bewältigt werden muss.
Es geht nicht darum, dass Pläne schlecht sind. Das Problem ist: Wenn neue Erkenntnisse erst nach wochenlanger Arbeit gewonnen werden, ist die Aktualisierung des Plans kostspielig.
Ein Plan, der von stabilen Anforderungen ausgeht, gleicht einer einzigen großen Wette. Man definiert alle Anforderungen im Voraus, schätzt den Aufwand für das gesamte Projekt und arbeitet dann auf eine abschließende Übergabe hin. Wenn in der dritten Woche eine rechtliche Anforderung hinzukommt, steht das Team vor zwei schlechten Optionen. Option eins: Die Änderung ignorieren und ein nicht konformes Produkt ausliefern – was betriebliche Risiken und unter Zeitdruck zu erledigende Nacharbeiten nach sich zieht. Option zwei: Die Änderung akzeptieren und frühere Entscheidungen revidieren – was zu Nacharbeit führt, da UI, Tracking, Inhalte und Testskripte für den ursprünglichen Ablauf konzipiert waren. Die Ursache des Scheiterns liegt nicht im Arbeitsaufwand, sondern in der zeitlichen Verzögerung der Erkenntnisgewinnung. Das Projekt gewinnt zwar wichtige neue Erkenntnisse, doch diese kommen zu spät, als dass sie noch kostengünstig in den Plan integriert werden könnten.
Häufiger Fehler Eine Änderung mitten im Projekt als einmalige Ausnahme zu behandeln, führt zu verstecktem Nacharbeitsaufwand und schließlich zu einer späten Terminüberschreitung, die eher wie mangelhafte Umsetzung als wie ein Planungsfehler wirkt.
Agile Methoden begegnen diesem Problem, indem sie den Prozess des Lernens kostengünstiger gestalten. Dies geschieht durch kurze Zyklen: Man plant einen kleinen Teilbereich, setzt ihn um, prüft ihn gemeinsam mit den Stakeholdern und passt das Vorgehen an, bevor man weitere Arbeitsschritte in Angriff nimmt.
Agile Arbeitsweisen sind kein starres Regelwerk. Es handelt sich vielmehr um eine Reihe von Werten, die zu Verhaltensweisen anregen, welche Überraschungen minimieren. Transparenz bedeutet, dass der tatsächliche Status in Artefakten wie Backlog, Sprint-Board und einem überprüfbaren Inkrement sichtbar ist – und nicht nur in aktualisierten Präsentationsfolien. Zusammenarbeit bedeutet, dass Entscheidungsträger und Umsetzungsteam eng und häufig kooperieren, sodass Entscheidungen getroffen werden, solange Änderungen noch kostengünstig umsetzbar sind. Anpassungsfähigkeit bedeutet, dass man mit der Weiterentwicklung von Anforderungen rechnet und einen kontrollierten Prozess für die Neuplanung etabliert, ohne die Verantwortlichkeit zu verlieren.
Bevor Sie diese Werte auf Ihren eigenen Kontext übertragen, überlegen Sie: Welches Verhalten hätte im Fall der rechtlichen Änderung in Woche 3 den größten Teil der Nacharbeit verhindert?
Ein prädiktiver Ansatz – oft als Wasserfallmodell bezeichnet – eignet sich, wenn die Anforderungen stabil sind und die Governance bereits frühzeitig eine festgelegte Basis für den Projektumfang (Scope Baseline) verlangt. Agile Methoden passen, wenn ein hohes Maß an Unsicherheit herrscht, die Release-Häufigkeit wichtig ist und Stakeholder schnelles Feedback geben können. Ein hybrider Ansatz kombiniert beide Methoden, etwa durch feste Meilensteine zur Einhaltung von Vorgaben bei gleichzeitiger agiler Umsetzung innerhalb dieser Meilensteine.
Ein Projektmanager trifft diese Entscheidung auf der Grundlage von Rahmenbedingungen, nicht nach persönlichen Vorlieben. Berücksichtigen Sie dabei die Unsicherheit bei den Anforderungen, die mögliche Release-Frequenz, Compliance-Anforderungen, die Verfügbarkeit von Stakeholdern für Reviews sowie die Stabilität des Teams. Wenn Stakeholder keine wöchentlichen Reviews durchführen können, verkommen agile Zeremonien zu Besprechungen ohne Entscheidungen. Wenn Compliance-Vorgaben detaillierte Vorab-Freigaben erfordern, kann ein rein agiles Vorgehen gegen Governance-Richtlinien verstoßen – es sei denn, man ergänzt es um prädiktive Kontrollmechanismen.
Nutzen Sie die Indikatoren für die Eignung, um eine Entscheidung zu treffen, und achten Sie darauf, welche Rahmenbedingung dabei ausschlaggebend war.