2. Vorgehensmodelle II – Iterativ und agil

Nach diesem Kapitel kannst du:

iterativ-inkrementelles Vorgehen erklären, inkrementell von iterativ unterscheiden und sagen, wann dieses Vorgehen Rückmeldung erzeugt.
die vier Wertepaare des Agilen Manifests erklären und begründen, warum agil weder „keine Dokumentation” noch „kein Plan” heißt.
die Verantwortlichkeiten, Artefakte und Ereignisse von Scrum nennen und das Sprint Review von der Retrospektive unterscheiden.
die Kernmechanik von Kanban (Fluss, WIP-Limit, Durchlaufzeit) erklären und Kanban von Scrum abgrenzen.

Im vorigen Kapitel hast du mit Wasserfall und V-Modell zwei phasenorientierte Modelle kennengelernt, die wie eine am Vorabend festgelegte Route funktionieren: Ob etwas schiefläuft, zeigt sich erst spät. Dieses Kapitel zeigt die Modelle, die wie ein Navi laufend die Position prüfen und neu planen.

Iterativ und inkrementell

Wasserfall und V-Modell erzeugen die erste echte Rückmeldung spät. Die nächste Modellfamilie verlegt sie nach vorne, indem sie in Runden und Stücken arbeitet. In der Analogie ist das der Moment, in dem das Navi übernimmt: Position prüfen, Route anpassen, weiterfahren. Die beiden Begriffe dafür stehen oft nebeneinander und meinen Verschiedenes.

	Inkrementell	Iterativ
Grundidee	in Stücken liefern	in Runden verbessern
Beispiel	zuerst die Anmeldung, dann die Suche, dann der Export	die Suche entsteht grob, wird genauer, dann schneller
Was wächst	der Funktionsumfang	die Qualität des Vorhandenen
Fehlt das andere	frühe Fehlentscheidungen bleiben für immer im Produkt	ständig verbessert, aber nie etwas Fertiges übergeben

Oben inkrementell: In jeder Runde kommt ein fertiges Stück dazu, erst die Anmeldung, dann die Suche, dann der Export. Unten iterativ: Dieselbe Suche wird von Runde zu Runde besser, von grob über genauer bis schnell.

Praktisch werden beide kombiniert: Man liefert Stücke (inkrementell) und überarbeitet Geliefertes anhand von Rückmeldungen (iterativ). Der Gewinn gegenüber dem Wasserfall ist wieder der Zeitpunkt der Erkenntnis: Nach jeder Runde gibt es etwas Lauffähiges, an dem sich Annahmen überprüfen lassen.

Der Prototyp

Ein verwandtes Werkzeug ist der Prototyp: eine bewusst unvollständige Version, die eine einzige Frage beantworten soll. Typische Fragen sind „Lässt sich diese Schnittstelle überhaupt anbinden?” oder „Verstehen die Nutzer:innen diese Bedienung?”.

Wichtig ist die Vereinbarung vorab, ob der Prototyp weggeworfen wird (throwaway prototype) oder die Grundlage des Produkts bildet (evolutionärer Prototyp). Wird das nicht geklärt, landet regelmäßig ein Wegwerf-Prototyp im Produktivbetrieb, samt aller Abkürzungen, die man sich für den schnellen Bau erlaubt hat.

Wo begegnet dir das? Bei jeder App auf deinem Handy, die alle paar Wochen ein Update bekommt: Neue Funktionen kommen Stück für Stück dazu (inkrementell), vorhandene werden nach Rückmeldungen überarbeitet (iterativ). Ein klickbares Figma-Mockup, an dem Nutzer:innen die Bedienung ausprobieren, ist dagegen ein typischer Wegwerf-Prototyp.

Agile Methoden

2001 formulierten siebzehn Softwareentwickler das Agile Manifest als Reaktion auf schwergewichtige, dokumentenlastige Prozesse. Sein Kern sind vier Wertepaare:

Wir schätzen …	… höher als	Konkret heißt das
Individuen und Interaktionen	Prozesse und Werkzeuge	die kurze Rückfrage bei der Kollegin schlägt das Formular, das die Frage in drei Tagen zustellt
Funktionierende Software	umfassende Dokumentation	ein lauffähiger Stand nach zwei Wochen sagt mehr über den Fortschritt als ein 80-seitiges Konzept
Zusammenarbeit mit dem Kunden	Vertragsverhandlung	bei einer Änderung wird gemeinsam die beste Lösung gesucht, statt im Vertrag die Schuldfrage zu klären
Reagieren auf Veränderung	Befolgen eines Plans	widerlegt die Realität eine Annahme, ändert man den Plan - nicht die Realität

Der meistzitierte und meistüberlesene Satz folgt direkt danach: „Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.” Agil heißt also nicht „keine Dokumentation” und nicht „kein Plan”, sondern eine Gewichtung bei Zielkonflikten.

Die vier Wertepaare als Waage: Links liegen Individuen und Interaktionen, funktionierende Software, Zusammenarbeit mit dem Kunden und Reagieren auf Veränderung und wiegen mehr. Rechts liegen Prozesse und Werkzeuge, umfassende Dokumentation, Vertragsverhandlung und Befolgen eines Plans und bleiben trotzdem auf der Waage.

Hier stößt die Navi-Analogie an ihre Grenze. Das Navi berechnet die Route neu, aber das Ziel bleibt fix. In einem agilen Projekt darf sich auch das Ziel verschieben, wenn sich nach drei Sprints zeigt, dass die Nutzer:innen eigentlich etwas anderes brauchen.

Scrum

Scrum ist das verbreitetste agile Rahmenwerk und bewusst schlank gehalten: drei Verantwortlichkeiten, drei Artefakte, ein fester Zyklus. Der Name stammt aus dem Rugby: Im „Scrum” (Gedränge) treibt das Team den Ball gemeinsam und eng abgestimmt voran. Takeuchi und Nonaka übertrugen dieses Bild 1986 auf Produktentwicklungsteams, die dicht zusammenarbeiten, statt Dokumente wie Staffelstäbe von Phase zu Phase weiterzureichen. Als Rahmenwerk formalisiert haben es später Ken Schwaber und Jeff Sutherland.

Verantwortlichkeiten

Rolle	Aufgabe	Häufiges Missverständnis
Product Owner	verantwortet das Was: Backlog, Priorisierung, fachliche Entscheidungen	ist kein Vorgesetzter des Teams
Entwicklungsteam	verantwortet das Wie: Umsetzung, Schätzung, technische Entscheidungen	schätzt selbst, Schätzungen werden nicht vorgegeben
Scrum Master	verantwortet den Prozess: Hindernisse beseitigen, Regeln schützen	ist kein Projektleiter und kein Protokollführer

Artefakte

Product Backlog: die nach Wert geordnete Liste aller Wünsche an das Produkt. Es lebt und ändert sich ständig, oben steht das Wichtigste.
Sprint Backlog: die Auswahl daraus, die das Team für den laufenden Sprint übernommen hat, samt Plan zur Umsetzung.
Increment: das lauffähige Ergebnis am Sprintende.

Was „fertig” bedeutet, legt das Team vorab gemeinsam in der Definition of Done fest, etwa: getestet, im Code-Review durchgesehen, dokumentiert, auf der Testumgebung lauffähig. Ohne diese gemeinsame Messlatte heißt „fertig” für jede Person etwas anderes. Sprint für Sprint wächst dann ein Berg an Arbeit, die schon als erledigt gemeldet wurde.

Der Zyklus

flowchart LR
  A[Sprint Planning] --> B[Sprint: 1 bis 4 Wochen]
  B --> C[Daily Scrum: taeglich 15 min]
  C --> B
  B --> D[Sprint Review: Ergebnis zeigen]
  D --> E[Retrospektive: Zusammenarbeit verbessern]
  E --> A

Die vier Ereignisse haben jeweils einen eigenen Zweck und ein eigenes Ergebnis. Fällt eines davon weg, fehlt genau diese Wirkung:

Ereignis	Wann	Zweck	Ergebnis
Sprint Planning	zu Sprintbeginn	das Team zieht aus dem Product Backlog, was es im Sprint schafft, und plant die Umsetzung	Sprintziel und Sprint Backlog
Daily Scrum	täglich, 15 Minuten	Selbstabstimmung im Team, Hindernisse früh sichtbar machen	angepasster Plan für den Tag
Sprint Review	am Sprintende	das Increment den Stakeholdern zeigen und Rückmeldung einholen	Rückmeldung, angepasstes Product Backlog
Retrospektive	nach dem Review	die Zusammenarbeit im Team verbessern	ein bis zwei konkrete Verbesserungen für den nächsten Sprint

Review und Retrospektive

Prüfungsrelevant und regelmäßig verwechselt sind die beiden letzten Ereignisse. Weil beide am Sprintende liegen und beide nach „Rückblick” aussehen, verschmelzen sie in der Praxis. Verloren geht dabei immer die Retrospektive, also die einzige Stelle, an der das Vorgehen selbst verbessert wird.

	Sprint Review	Retrospektive
Blick auf	das Produkt	die Zusammenarbeit
Wer ist dabei	Team und Stakeholder	nur das Scrum-Team
Grundlage	das lauffähige Increment, keine Folien	Erfahrungen aus dem Sprint
Ergebnis	angepasstes Product Backlog	ein bis zwei Maßnahmen mit verantwortlicher Person
Zeitrahmen laut Scrum Guide	höchstens vier Stunden bei einem Monatssprint	höchstens drei Stunden bei einem Monatssprint

Das Sprint Review ist kein Präsentationstermin, sondern ein Arbeitstreffen an der laufenden Software. Die Stakeholder probieren das Increment aus und geben Rückmeldung, der Product Owner passt daraufhin das Product Backlog an. Gezeigt wird ausschließlich, was die Definition of Done erfüllt. Alles andere ist kein Increment, sondern eine Absichtserklärung.

Die Retrospektive schaut darauf, wie gearbeitet wurde: Zusammenarbeit, Werkzeuge, Definition of Done, wiederkehrende Hindernisse. Üblich ist ein einfaches Raster (was lief gut, was lief nicht gut, was ändern wir) oder die Variante Start/Stop/Continue.

Entscheidend ist das Ergebnis: ein bis zwei konkrete Maßnahmen mit verantwortlicher Person, die im nächsten Sprint nachweislich überprüft werden. Eine Retrospektive, die mit „wir sollten besser kommunizieren” endet, war eine Gesprächsrunde. Eine, die mit „ab sofort läuft der Performance-Test in der Definition of Done, Kontrolle beim nächsten Review” endet, war eine Retrospektive.

Wo begegnet dir das? In jedem Team, das eine App mit regelmäßigen Releases entwickelt: Das Review entscheidet, was im nächsten Update kommt. Die Retrospektive entscheidet, warum das letzte Update eine Woche zu spät kam und was sich daran ändert.

Auflösung

(a) ist eine Aussage über das Produkt und wird im Review zu einem Backlog-Eintrag. (b) betrifft die Arbeitsweise und gehört in die Retrospektive, samt der naheliegenden Maßnahme, den Test früher verbindlich zu machen. (c) ist eine Stakeholder-Rückmeldung zum Produkt, also Review.

Kanban

Kanban setzt an einer anderen Stelle an: nicht am Zeittakt, sondern am Fluss der Arbeit. Es gibt keine Sprints und keine vorgeschriebenen Rollen, sondern ein Board mit Spalten. Der Kern sind WIP-Limits (work in progress), also Obergrenzen für die Zahl gleichzeitig bearbeiteter Aufgaben:

Backlog | Analyse (3) | Umsetzung (2) | Review (2) | Fertig

Die Zahl in Klammern ist das Limit der jeweiligen Spalte: In Umsetzung dürfen höchstens zwei Aufgaben gleichzeitig liegen. Ist eine Spalte voll, darf nichts Neues hinein. Wer nichts anfangen darf, hilft dort, wo es klemmt.

Warum weniger gleichzeitig schneller fertig macht

Das wirkt zunächst wie eine Behinderung und ist das Gegenteil. Ein Zahlenbeispiel: Fünf Aufgaben zu je fünf Tagen Arbeit, alle gleichzeitig begonnen, sind frühestens nach 25 Tagen fertig - und zwar alle fünf erst dann. Nacheinander abgearbeitet ist die erste nach 5 Tagen fertig, die zweite nach 10, die letzte weiterhin nach 25.

gantt
  title Fünf Aufgaben zu je fünf Tagen
  dateFormat YYYY-MM-DD
  axisFormat %e
  section Parallel
    Aufgabe 1 :p1, 2026-03-01, 25d
    Aufgabe 2 :p2, 2026-03-01, 25d
    Aufgabe 3 :p3, 2026-03-01, 25d
    Aufgabe 4 :p4, 2026-03-01, 25d
    Aufgabe 5 :p5, 2026-03-01, 25d
  section Nacheinander
    Aufgabe 1 :s1, 2026-03-01, 5d
    Aufgabe 2 :s2, after s1, 5d
    Aufgabe 3 :s3, after s2, 5d
    Aufgabe 4 :s4, after s3, 5d
    Aufgabe 5 :s5, after s4, 5d

Die Achse zählt Arbeitstage. Beide Varianten enden am selben Tag, aber nur bei „Nacheinander” liegen schon nach 5, 10, 15 und 20 Tagen fertige Ergebnisse vor.

Der Gesamtaufwand ist identisch, der Auftraggeber bekommt aber vier Ergebnisse deutlich früher. Genau diese Zeitspanne von angefangen bis fertig ist die Durchlaufzeit (lead time), die Kanban kurz halten will. Jede zusätzliche parallele Aufgabe verlängert sie für alle anderen mit.

Ein Durchgang am Board

Wie sich das im Betrieb auswirkt, zeigt ein Durchgang am Board eines kleinen Wartungsteams:

Backlog	Analyse (3)	Umsetzung (2)	Review (2)	Fertig
Rechnungsexport	Suche langsam	Login-Fehler	Passwort-Reset	Mailvorlagen
Mailversand		CSV-Import	Sortierung	Druckansicht

Umsetzung und Review sind beide voll. Jetzt wird der Login-Fehler fertig und bleibt trotzdem liegen, weil in Review schon zwei Aufgaben warten. Damit ist auch Umsetzung weiter blockiert, und die frei gewordene Entwicklerin darf sich nichts Neues aus dem Backlog holen. Genau an dieser Stelle entscheidet sich, ob das Board etwas bewirkt:

Ohne WIP-Limit zieht sie einfach den Mailversand nach. Das Board hat dann drei angefangene Aufgaben in der Umsetzung, der Stau vor dem Review bleibt unangetastet, und die Durchlaufzeit steigt für alle Aufgaben - auch für die beiden, die nur noch reviewt werden müssten.
Mit WIP-Limit bleibt ihr nur eine sinnvolle Tätigkeit: eines der wartenden Reviews zu übernehmen. Damit wird Review frei, der Login-Fehler rückt nach, Umsetzung wird frei. Erst jetzt darf der Mailversand aus dem Backlog nachgezogen werden.

Der Engpass war in beiden Fällen dasselbe Review. Das Limit hat ihn nicht beseitigt, sondern sichtbar und unumgehbar gemacht. Steht die Review-Spalte über Wochen regelmäßig voll, ist das keine Meinung mehr, sondern eine Messung. Die naheliegende Konsequenz: Reviews auf mehr Personen verteilen oder die Limits anpassen.

Scrum und Kanban im Vergleich

	Scrum	Kanban
Rhythmus	feste Sprints	kontinuierlicher Fluss
Rollen	drei definierte	keine vorgeschrieben
Planung	pro Sprint	fortlaufend
Kernmechanik	Zeitbox und Commitment	WIP-Limit und Durchlaufzeit
Passt gut bei	planbarer Produktentwicklung	Support, Wartung, wechselnden Prioritäten

Wo begegnet dir das? Bei einem IT-Support, etwa dem der Schule: Störungsmeldungen kommen unvorhersehbar herein und lassen sich nicht zwei Wochen im Voraus in einen Sprint planen. Ein Board mit Spalten wie Neu, In Arbeit, Wartet auf Rückmeldung und Erledigt passt hier besser als ein Sprintrhythmus.

Zusatzmaterialien

Agiles Manifest - der vollständige Originaltext mit den zwölf dahinterliegenden Prinzipien; kurz genug, um ihn ganz zu lesen, statt ihn nur zitiert zu kennen.
Scrum Guide - die verbindliche Originalquelle zu Scrum; hilft, wenn im Projekt jemand behauptet, „in Scrum macht man das so”.
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business - zeigt Kanban jenseits der hier gezeigten Grundidee, inklusive Messgrößen für den Fluss.

Zum Anhören

Diesen Text kannst du dir kostenlos mit der Vorlesefunktion deines Browsers oder Betriebssystems vorlesen lassen, z. B. in Microsoft Edge über „Laut vorlesen”.

Lernergebnisse: Was du nach diesem Kapitel können solltest

Erklären: iterativ-inkrementelles Vorgehen erklären, inkrementell von iterativ unterscheiden und sagen, wann dieses Vorgehen Rückmeldung erzeugt.
Erklären: die vier Wertepaare des Agilen Manifests erklären und begründen, warum agil weder „keine Dokumentation” noch „kein Plan” heißt.
Nennen: die Verantwortlichkeiten, Artefakte und Ereignisse von Scrum nennen und das Sprint Review von der Retrospektive unterscheiden.
Erklären: die Kernmechanik von Kanban (Fluss, WIP-Limit, Durchlaufzeit) erklären und Kanban von Scrum abgrenzen.

Passende Übungen

Dieses Kapitel hat keine eigene Übung. Die passende Übung folgt in Kapitel 03:

Aufgabe 01 - Modell-Matrix

In den 70 Praxisminuten setzt du die Vergleichsmatrix aus Aufgabe 01 mit den Modellen aus diesem Kapitel fort: iterativ-inkrementell, Scrum und Kanban.

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules