Das Grundprinzip jedes Agilen Vorgehens liegt in dem fortgeschrittenen Know-How der Projektbeteiligten. Experten, die sowohl in der Technik firm als auch mit den Organisationsstrukturen vertraut sind, sollen nicht durch starre Regeln in ihrer Effizienz beeinträchtigt werden. Meiner Meinung nach sind daher "Agile Methoden" kein Thema, das man diskutieren sollte: Sie sind in einigen Situationen eine Selbstverständlichkeit. Um agil handeln zu können, muss in "starren" Organisationen begründet werden, dass in der aktuellen Situation agil vorgegangen werden kann. In der letzten Zeit haben verschiedene Evangelisten der Agilen Methoden selbige Salon-fähig gemacht.
Ich habe mittlerweile mehr als eine Agile Organisation kennengelernt, in der Techniker, Projektleiter und Methoden-/Verfahren-Leute gemeinsam über "höhere Ziele" losgelöst von starren Prozessen sprechen können. Sie haben sich von vermeintlich überflüssigen Prozessen befreit und können sich in sogenannten Task-Forces oder Feature-Teams auf höhere Ziele konzentrieren.
Aber was verliert man, wenn man sogar die Hüter der Prozesse bekehrt hat? (Damit meine ich zum Beispiel Mitarbeiter von "Methoden und Verfahren".)
Das Einrichten einer agilen Task Force bzw. eines Feature-Teams ist durch eine Reihe von Annahmen motiviert, unter denen die fachliche Entwicklung möglichst zielorientiert und risikoarm abläuft. Ohne eine vollständige Liste aller Annahmen geben zu können, möchte ich hier doch einige aufführen. Ich glaube allerdings, dass nicht immer alle Annahmen überprüft werden, bevor agile Feature-Teams initiiert werden. Ein iteratives und inkrementelles Vorgehen wird bewusst angestrebt. Die Annahme ist, dass das iterativ-inkrementelle Vorgehen das Risiko minimiert. Das Feature-Team wird durch fachliche und technische Experten gebildet. Dem liegen mehrere Annahmen zugrunde: durch kontinuierliche Validierung der Software durch Fachler wird das gewünschte Ergebnis erreicht. Durch hohe Verfügbarkeit des fachlichen Know Hows wird die Qualität und die Entwicklungsgeschwindigkeit gesteigert. Hier wird häufig die wichtigste Annahme vergessen: der Fachler (oder jemand im Fachteam) hat ein klares Bild von dem gewünschten Ergebnis und kann erkennen, wann die Lösung gegen das gewünschte Ergebnis konvergiert und wann nicht.
Trifft dieser letzte Aspekt nicht zu, kommt es zu Schwierigkeiten. Dann kann sich ein Agiles Vorgehen sehr leicht in eine "Unendliche Geschichte" verwandeln! Das Problem mit so einer "Unendlichen Geschichte" wird erst deutlich, wenn man die Aufgaben und Verantwortung eines Feature-Teams betrachtet.
Experten aus der Anwendungsdomäne spezifizieren die Funktionalität. Techniker analysieren technische Konsequenzen und entwickeln in kurzen Feedback-Schleifen die geforderte Funktionalität. Das Feature-Team trägt gemeinsam die Ergebnisverantwortung. Das Agile Vorgehen fährt in vielen Fällen zum Unterlassen eines in formalen Prozessen sehr bedeutsamen Schrittes: der Abnahme der Zieldefinition.
Hier liegt eine große Gefahr, falls nur eine der grundlegenden Annahmen nicht gilt. Verantwortung kann man nicht teilen!
Wie oft habe ich gehört, dass aufgrund der kurzen Zyklen eine formale Abnahme der Spezifikation nicht nötig sei? Beim Agilen Vorgehen reiche es doch aus, das Ergebnis abzunehmen.
Genau hier liegt allerdings der Haken, sobald es zu Problemen kommt. Wird dann nach der Ursache geforscht, wird in agilen Strukturen dabei gerne vergessen, wie die Verantwortung anfangs definiert wurde: Die Verantwortung trägt das Feature-Team gemeinsam! Jeder versucht sich zu rechtfertigen und zu entlasten. Unglücklicherweise ist der Fertigstellungsgrad immer an der Software messbar. Vielleicht ist sie nicht fertig, obwohl es seit vielen Wochen zu jedem Zeitpunkt eine fachliche Zielvorgabe gibt. Falls sich die Spezifikation leider des Öfteren geändert hat, ist dies nur sehr schwer nachvollziehbar zu erklären. Aufgrund einer fehlenden Abnahme der Spezifikation fehlt die Dokumentation darüber, dass es während der Entwicklung noch kein klares Bild von der gewünschten Funktionalität gegeben hat. (Hier unterstelle ich einfach, dass Änderungen in der Zieldefinition genauso wenig protokolliert werden, wie der Status der Spezifikation.)
Ich ziehe für mich den Schluss, den ich bereits seit langer Zeit in mir herum trage: Agile Prozesse sind für Techniker. In ihrer inhaltlichen Arbeit sollen sie so effektiv wie möglich arbeiten. Allerdings bergen Agile Prozesse für Projektleiter (wie immer man das definiert) eine Gefahr, wenn nicht klar ist, welche Fixpunkte im Projekt wichtig sind und wie Verantwortungen verteilt sind.
Ich plädiere für ein verantwortungsvolles Vorgehen; ausgewogen in seiner Gänze und klar in seiner Ausrichtung.