Zwei Teams, ein Projekt, eine Deadline. Das eine arbeitet seit acht Monaten an einem Lastenheft, das inzwischen 94 Seiten hat. Das andere hat nach drei Wochen eine erste Version ausgeliefert, die der Kunde immerhin schon benutzen kann. Beide nennen ihr Vorgehen agiles Projektmanagement. Nur bei einem stimmt es.
Ich habe in den letzten Jahren mehrfach auf beiden Seiten gestanden: als Teil eines klassisch geführten Teams, das plötzlich Sprints machte, weil es alle machten. Und als Berater in einem Haus, wo agile Methoden tatsächlich funktionierten. Der Unterschied lag nie an Scrum. Er lag daran, ob jemand bereit war, Macht abzugeben.
Dieser Artikel ist keine Methodenübersicht mit schönen Worten. Er ist das, was ich Leuten erzähle, die mich fragen: „Wir wollen auch agil werden – wie fangen wir an?"
Wichtige Erkenntnisse
- Agiles Projektmanagement heißt vor allem: Entscheidungen nach hinten verlegen, nicht Pläne abschaffen.
- Der häufigste Fehler ist nicht die falsche Methode, sondern agiles Vokabular in unveränderten Machtstrukturen.
- Scrum passt für Produktentwicklung mit unklaren Anforderungen. Für Festpreis-Bauprojekte ist es die falsche Wahl.
- Ohne drei konkrete Kennzahlen ist „agil" nicht überprüfbar – und damit auch nicht steuerbar.
- Eine Weiterbildung bringt selten etwas, wenn nicht gleichzeitig jemand die Rolle des Product Owners ausfüllt.
Agiles Projektmanagement einfach erklärt: was sich wirklich ändert
Der Kern ist ein einziger Satz: Man tut nicht so, als wüsste man am Anfang, was am Ende gebraucht wird. Statt diese Unsicherheit in einem monatelangen Planungsprozess zu verstecken, baut man sie ins Vorgehen ein. Kurze Zyklen, sichtbare Ergebnisse, echte Rückmeldung.
Klingt banal. Ist es aber nicht, denn es verschiebt, wer wann entscheiden darf.
Der Unterschied liegt nicht im Rhythmus, sondern im Recht zu ändern
Ein Team, das alle zwei Wochen ein Meeting „Sprint Review" nennt, ist nicht agil. Agil wird es in dem Moment, in dem der Auftraggeber nach dieser Review sagen darf: „Punkt drei hat sich erledigt, Punkt fünf ist dringender" – und das tatsächlich Auswirkungen hat.
Ich habe einmal erlebt, wie ein Bereichsleiter genau das nicht zuließ. Die Reviews fanden statt, es wurde fleißig präsentiert, und danach ging das Team zurück zum ursprünglichen Plan. Nach fünf Monaten war das Projekt genauso im Verzug wie vorher. Nur mit doppelt so vielen Meetings. Das ist der teuerste Fehler, den ich in diesem Feld kenne.
Was die Methode nicht ist
Agil ist kein Freifahrtschein gegen Dokumentation. Kein Verzicht auf Architektur. Kein Grund, keine Zusagen mehr zu machen. Wenn Ihnen jemand erzählt, im agilen Arbeiten brauche man keine Absprachen, hat er die Sache gründlich missverstanden – oder er will Ihnen etwas verkaufen.
Agiles Projektmanagement-Methoden: welche passt zu was
Die ehrliche Antwort: Für die meisten Teams ist die Wahl zwischen Scrum und Kanban die einzige, die wirklich zählt. Der Rest ist Zierleiste. Wer mit SAFe anfängt, ohne dass Scrum im Haus funktioniert, baut ein zweites Stockwerk auf ein Fundament, das noch nicht gegossen ist.
Scrum, Kanban, Wasserfall im Vergleich
| Ansatz | Wann sinnvoll | Woran es scheitert |
|---|---|---|
| Scrum | Produktentwicklung, Anforderungen ändern sich realistisch alle paar Wochen | Product Owner ohne Entscheidungsbefugnis; Team ohne eigene Verantwortung |
| Kanban | Dauerbetrieb mit schwankendem Eingang (Support, Betrieb, Content) | Wird als „einfach ohne Sprints" missverstanden, WIP-Limits ignoriert |
| Klassisch / Wasserfall | Bau, behördliche Vergabe, klar abgrenzbare Lieferung mit Festpreis | Wird auf Projekte angewandt, deren Anforderungen sich laufend ändern |
| Hybrid | Vertraglich klassisch, intern iterativ – sehr häufig in regulierten Branchen | Die Phasen werden nur umbenannt, das Steuerungsmodell bleibt starr |
Was das Manifest tatsächlich sagt
Die vier Werte des agilen Manifests sind über zwanzig Jahre alt und immer noch die beste Prüfliste, die ich kenne. Kurz zusammengefasst: Menschen und Interaktion vor Prozessen und Werkzeugen. Funktionierende Software vor umfassender Dokumentation. Zusammenarbeit mit dem Kunden vor Vertragsverhandlung. Reagieren auf Veränderung vor Verfolgen eines Plans.
Auffällig ist das Wort, das die Leute immer überlesen: „vor". Es steht dort keine Abschaffung. Es steht eine Gewichtung. Wer „vor" als „statt" liest, baut keine Agilität, sondern ein Chaos mit Zeremonien.
Agiles Projektmanagement vs. klassisches Projektmanagement
Die Debatte wird meistens falsch geführt: als Glaubensfrage. Dabei ist es eine Frage der Form des Risikos. Ein klassischer Phasenplan ist dann die richtige Wahl, wenn ein Fehler in der Konzeptionsphase später nicht mehr korrigierbar ist. Ein Fundament, das steht, lässt sich nicht mehr verschieben.
Agil ist dann richtig, wenn frühe Rückmeldung den Plan ohnehin verändern würde. Und jetzt kommt der Punkt, über den ich mich mit Kollegen regelmäßig streite: Agil ist nicht besser. Agil ist bei falschen Rahmenbedingungen nur teurer. In einem Festpreisvertrag mit starrem Leistungskatalog einzuführen, dass Umfang verhandelbar ist, ist keine Agilität, sondern ein Rechtsstreit mit Ansage.
Festpreis und Agilität – geht das zusammen?
Ja, aber nicht so, wie es meistens versucht wird. Was funktioniert: Festpreis auf einen Zeitrahmen oder ein Budget, nicht auf einen Leistungskatalog. Man verkauft dem Kunden die ersten drei Monate mit einem festen Team und einer festen Rechnung – und lässt den Leistungsumfang in diesen drei Monaten schieben. Der Kunde behält die Kostenkontrolle, das Team behält die Freiheit, nachzusteuern.
Was nicht funktioniert: ein Dokument unterschreiben, in dem 140 Anforderungen stehen, und dann im Sprint merken, dass Nummer 12 niemand braucht. Ich habe genau das einmal begleitet. Wir haben acht Wochen gebraucht, um den Vertrag nachzuverhandeln. Acht Wochen, in denen das Team wartend dastand.
Agiles Projektmanagement: ein Beispiel aus der Praxis
Ein mittelständischer Softwareanbieter, 40 Mitarbeitende, ein Kundenprojekt mit unklarer Zielgruppe. Zwei Teams, unterschiedliche Herangehensweisen, gleiche Deadline.
Was das erste Team gemacht hat
Erst Monate konzipiert, dann gebaut, dann ausgeliefert. Das ist kein schlechter Weg – nur der falsche für dieses Projekt. Bei der Abnahme kam heraus, dass die Hauptnutzergruppe eine Funktion gar nicht in der Tiefe brauchte, dafür eine Schnittstelle, die niemand spezifiziert hatte. Nacharbeit: zwei Monate.
Was das zweite Team gemacht hat
Sechs Wochen eine schmale Version gebaut, ausgeliefert, echte Nutzer zugesehen. Von den vier geplanten Funktionen flogen zwei raus und eine kam neu hinzu – nach Rückmeldung aus dem Feld, nicht aus einem Workshop. Das Ergebnis war nach demselben Zeitraum funktional schmaler, aber tatsächlich im Einsatz.
Was dabei unterging, und das gehört zur Ehrlichkeit dazu: Die Dokumentation war zum Auslieferungszeitpunkt löchrig. Zwei neue Entwickler brauchten deutlich länger, um einzusteigen, als im klassischen Team. Agil löst nicht alle Probleme. Es tauscht sie nur gegen andere.
Weiterbildung: was tatsächlich etwas bringt
Zertifikate sind billig zu haben und sagen über Kompetenz erstaunlich wenig. Ich habe Bewerbungen auf dem Tisch gehabt, in denen drei Zertifikate standen und die Person im Gespräch nicht erklären konnte, was ein Sprint-Backlog von einem Produkt-Backlog unterscheidet. Umgekehrt kenne ich einen sehr guten Scrum Master ohne jedes Zertifikat.
Woran Sie einen brauchbaren Lehrgang erkennen, sind drei Dinge: Er arbeitet an einem echten Fall, nicht an einem Spielzeugbeispiel. Die Teilnehmenden kommen aus unterschiedlichen Rollen, nicht nur aus dem Projektmanagement. Und es gibt jemanden, der hinterher die Product-Owner-Rolle im Haus tatsächlich ausfüllt – sonst verpufft das Gelernte innerhalb von Wochen.
Die IHK bietet in vielen Regionen Zertifikatslehrgänge zum agilen Projektmanagement an, häufig als kompakte Blöcke über mehrere Wochen. Sinnvoll als Einstieg, wenn Sie ein Team führen, das gerade erst anfängt. Weniger sinnvoll als Karrieresprung – dafür zählt am Ende, ob in Ihrem Verantwortungsbereich etwas ausgeliefert wird.
Wo agiles Arbeiten regelmäßig scheitert
Drei Muster sehe ich immer wieder. Das erste: Der Product Owner ist ein Bauchladen. Er sammelt Wünsche von allen Seiten und sagt zu jedem „kommt aufs Backlog", statt auszuwählen. Ergebnis ist ein Backlog mit 300 Einträgen und ein Team, das nie das Wichtigste zuerst baut.
Das zweite: Das Team hat keine Befugnis, sondern nur Verantwortung. Man macht es „selbstorganisiert" und gibt ihm gleichzeitig vor, welche Werkzeuge, welche Architektur und welche Reihenfolge gilt. Das ist keine Selbstorganisation, das ist Alibi.
Und das dritte Muster, das mir am häufigsten begegnet: Man misst agiles Arbeiten an denselben Kennzahlen wie vorher. Velocity, Story Points, Auslastung pro Person. Letzteres ist besonders grotesk, weil Auslastung genau das Gegenteil von dem ist, was ein Team befähigt, auf Veränderung zu reagieren. Wer zu 100 Prozent verplant ist, kann nicht reagieren.
Stattdessen lohnt es sich, drei andere Dinge zu beobachten: Wie oft liefert das Team etwas Auslieferbares? Wie lange dauert es von der Idee bis zur ersten echten Rückmeldung? Und wie häufig ändert sich der Plan tatsächlich, nachdem er aufgestellt wurde? Letzteres klingt nach Planlosigkeit. Es ist das Gegenteil: Wenn sich nie etwas ändert, hört niemand zu.
Der Teil, den niemand hören will
Agiles Projektmanagement ist ein Werkzeug, das die Machtverhältnisse im Projekt verschiebt: vom Plan zum Team, vom Auftraggeber zur Rückmeldung, von der Prognose zur Beobachtung. Genau deshalb funktioniert es dort, wo jemand bereit ist, einen Teil seiner Kontrolle abzugeben – und genau deshalb bleibt es dort Fassade, wo diese Bereitschaft fehlt.
Meine unbequeme Meinung nach etlichen Projekten: Bevor Sie eine Methode einführen, prüfen Sie eine einzige Frage. Darf das Team in drei Monaten etwas anderes bauen als heute geplant, ohne dass jemand eskaliert? Wenn ja, reden wir weiter. Wenn nein, brauchen Sie kein Scrum – Sie brauchen ein Gespräch mit dem, der das entscheidet.
Und wenn Sie sich beim Lesen dabei erwischt haben, heimlich zu antworten „eigentlich nein" – dann ist das kein Grund zur Sorge. Es ist der Anfang. Die zweite Frage wäre: Wer genau müsste diese Entscheidung treffen, und wann setzen Sie sich mit dieser Person zusammen?
