iterativ versus agil

Iterativ ist nicht gleich agil! In vielen Gesprächen, Artikeln und Erfahrungsaustauschen stelle ich immer wieder fest, dass iteratives Vorgehen und agiles Vorgehen gleichgesetzt werden. Dem ist nicht so, zumindest in aller Regel!

Beim Interativen arbeiten nähert man sich in Iterationen dem Gesamtziel, aber sequenziell. Pro Iteration werden geplante Milestones abgearbeitet.

Ein anderes, oft verbreitetes Vorgehen ist der iterative Wasserfall. Oft ist das die erste Ausbaustufe, wenn man vom klassischen Vorgehen auf agiles Vorgehen "umstellt". Das Team abeitet im gewohnten, sequenziellen Modus, aber pro Iteration. Mit diesem Vorgehen erreicht man zwar, dass man pro Iteration funktionstüchtige Artefakte liefern kann, jedoch ist das Ende einer Iteration meist sehr un-planbar und oft geprägt von Refactoring und ordentlich Zeitdruck im Team. Erst beim Test stellt sich heraus, ob alles so funktioniert, wie geplant.

Wahres agiles Arbeiten bedeutet, dass man alle Aufgaben parallel in einer Iteration abarbeitet (siehe c) - Analayse, Design , Programmierung und Testing passiert parallel, quasi Hand in Hand. Es findet stetige Kommunikation zwischen allen Teammitgliedern statt.

Was heisst agiles Vorgehen?

Nach dem agilen Manifest gilt das Prinzip, dass man dem Kunden in regelmässigen Intervallen funktionsfähige, getestet, dokumentierte und brauchbare Artefakte liefert, die einen Mehrwert darstellen.

Wie kommt man von einem klassischen Wasserfall zum agilen Projekt?
Ein Praxisbericht: Schritt 1: man macht den Wasserfall zunächst iterativ.

Bei einem interativen Wasserfall werden pro Iteration Artefakte erarbeitet, die in der kommenden Iteration weiterverarbeitet oder verfeinert werden (Bild oben). Damit bleiben alle Nachteile von phasen- orientiertem Projektvorgehen erhalten: Abkapseln von Anaytikern, Kunden, Testern und Entwicklern sowie Behinderung der direkten Kommunikation aller Beteiligten. (A=Analyse,D=Design,P=Produktion,T=Test)

Da man mit dem iterativen Wasserfall jedoch keine funtionstüchtigen Artefakte mit einem Mehrwert für den Kunden liefert, kommt man zwangsläufig zum Schritt 2: der iterative Mini-Wasserfall (Bild unten).

Um dem agilen Manifest gerecht zu werden und die klassische Vorgehensweise beizubehalten, macht man alle Phasen pro Iteration.
Auch hier gewinnt man nicht viel, denn erfahrungsgemäss ist die Zeit am Ende einer Iteration sehr knapp und Testing fast unmöglich. Dazu kommt, dass die Teammitglieder so noch immer entkoppelt arbeiten und wichtige Kommunikation ausbleibt.

Untersuchen Sie genau Ihre Vorgehensweise. Finden Sie sich teilweise in diesen Aussagen wieder, dann haben Sie kein agiles Vorgehen!