Wer kennt sie nicht, die Diskussionen über Vorgehensmodelle und welche Vorgehensweise „besser“ ist. Die Verfechter der jeweiligen Modelle zeigen oft eine Loyalität zu ihrem favorisierten Modell, die der Diskussion, ob nun Linux oder Windows das bessere Betriebssystem ist, gleich kommt. Welche Stilblüten falsch verstandenes agiles Vorgehen treiben kann, möchte ich an folgenden Beispielen aufzeigen:
Hintergrund: im Rahmen der Kopplung von zwei Systemen wurde im Zielsystem die Visualisierung von Produktinformationen nicht mehr wie gewohnt erreicht.
PO: Wir brauchen dieses Feld, weil es vermutlich das Problem löst, könnte aber sein, dass es auch nichts bringt, aber vorher war dieses Feld noch da und da hat es noch funktioniert!
DEV: Gibt es denn eine Dokumentation oder ein Konzept, was uns nicht nur vermuten lässt, ob das etwas bringt?
PO: Nein, aber das hat schonmal funktioniert und ich vermute, dass es am Fehlen dieser Eigenschaft bei der Datenübertragung liegt. Vorher hat es ja noch funktioniert.
DEV #2: Das Feld wurde noch nie verwendet.
PO: Sehe ich anders!
Lead: Auf Basis von Vermutungen sollten wir keine Entwicklungsaufwände erzeugen - aber wenn ihr meint, setzt das um…
Die gewünschte Änderung wurde vorgenommen - der erhoffte Effekt blieb jedoch aus (siehe dazu: Hoffnung ist keine Strategie). Bis heute weiß ich nicht, auf welche Weise das Problem dann doch noch gelöst wurde. Dokumentiert wurde das sicher auch - irgendwo in den Tickets.
Nicht zuletzt auf Basis dieser Erfahrung führten wir daraufhin einen neuen Standard zur Konzeption von Anforderungen und gleichzeitigen Dokumentation der Lösung ein.
Im Rahmen einer anderen vorzunehmenden Schnittstellenänderung ereignete sich dann folgendes Gespräch:
DEV: um Motivation und Zielsetzung zu verstehen und auch zur Erarbeitung möglicher Lösungsalternativen benötigen wir ein Konzept
PO: wir sind agil, wir schreiben keine Konzepte!
DEV: …
Gefolgt von einer mindestens fünfminütigen, ergebnislosen Diskussion über den Sinn und Unsinn des neuen Konzeptions- und Dokumentationsstandards.
PO: Schreibst Du denn nun das Konzept?
DEV: Nein, das kann ich nicht für Dich übernehmen - aber wir können das gerne gemeinsam machen
PO: Dafür habe ich keine Zeit
DEV: Und wie kommen wir dann weiter?
PO: Gut, dann schreibe ich halt irgendwas und dann kannst Du gucken was Du damit machst…
DEV: Du schreibst das Konzept doch nicht für mich, sondern für uns alle. Du selbst sagtest doch, dass das Projekt in Schieflage ist, eben weil wir uns nie die Zeit für Konzepte genommen haben. Jetzt haben wir sie sogar ganz offiziell.
PO: …
DEV: Lass uns das gerne gemeinsam machen. Wir wollen doch ursächliche Probleme beheben, die wir eben aufgrund der fehlenden Konzepte haben, oder?
PO: Ich muss in den nächsten Termin.
Wie nun mit einer derartigen Blockadehaltung umgehen? Am besten gar nicht - siehe Change-Management: Umgang mit offensivem Widerstand.
Unabhängig von den zuvor genannten Beispielen (das waren Ausnahmefälle und nicht die Regel!) möchte ich an dieser Stelle herausstellen:
Sowohl bei linearen (z. B. Wasserfall) als auch bei iterativen Vorgehensmodellen kommt der typische Management-Cycle zur Anwendung:
Plan - Konzeption
Do - Umsetzung
Check - Soll-Ist-Vergleich und Lessons learned
Act - Anpassung
Der meines Erachtens wesentliche Unterschied zwischen iterativen und linearen Vorgehensmodellen ist lediglich die Dauer eines PDCA-Zyklus. Keine Konzepte und die damit fehlende, aber notwendige Reflexion der Anforderung und möglichen Lösungsoptionen, führt in der Regel zu mindestens dreimal teureren Ergebnissen.
Es gilt: Konzepte sind immer integraler Bestandteil von effizientem und am Ende auch effektivem Vorgehen. Wer sich keine Zeit für Konzepte nimmt, bezahlt das teuer mit Mehraufwänden, Frustration und suboptimalen Ergebnissen. Suboptimale Ergebnisse, weil oft aufgrund des dann irgendwann nicht mehr verschiebbaren Endtermins Funktionalität gestrichen werden soll und erfahrungsgemäß auch immer wird.