Standmann: Und Sie meinen nun, dass sie auch agil sein müssen. Nur weil das gerade ein Hype ist?
Ich: Nein. Die Vorteile agiler Vorgehensweisen sind ja schon reizvoll. Die will man natürlich auch haben.
Standmann: Also erreichen Sie die versprochenen Vorteile noch nicht so, wie Sie sich das wünschen?
Ich: Viele Dinge laufen bei uns schon gut. Viele Dinge liegen aber auch weit hinter dem, was die agilen Methoden versprechen. Dass wir in besonders hoher Qualität entwickeln würden, kann ich aber leider nicht behaupten.
Standmann: Daran würde sich auch nichts ändern, wenn ich Ihnen "bestätigen" würde, dass Sie bereits agil vorgehen.
Ich: Ja, leider... (Seufz)
Standmann: Es ist tatsächlich unerheblich, ob Sie alle Techniken der agilen Vorgehensweisen einsetzen. Das ist ja alles kein Selbstzweck. Es geht ja letztlich darum, die eigene Softwareentwicklung erfolgreich zu machen und zu verbessern. Das ist ein kontinuierlicher Prozess ohne Ende.
Ich: Dann ergibt es keinen Sinn, davon zu sprechen, dass ein Projekt "agil" ist?
Standmann: Doch, in gewisser Weise schon. Aber es geht nicht darum, ob man alle Techniken von z.B. Scrum einsetzt oder nicht. Es geht darum, ob man die Arbeitsweisen immer weiter verbessert. Und wenn man entsprechende Mechanismen (z.B. Retrospektiven) dauerhaft etabliert, würde ich das Projekt schon agil nennen.
Ich: Während ein Projekt, dass zwar alle Scrum-Techniken einsetzt, diese aber nicht für eine kontinuierliche Verbesserung nutzt, nicht agil zu nennen ist.
Standmann: Genau, Sie bringen es auf den Punkt.
Ich: (Das ist tatsächlich eine neue Perspektive!) Also bedeutet jede Form von kontinuierlichem Verbesserungsprozess Agilität?
Standmann: Das würde ich so nicht behaupten. Es kommt darauf an, in welche Richtung man „verbessert“.
Ich: Wenn man z.B. Angst hat vor Konflikten mit dem Kunden, könnte ein kontinuierlicher Verbesserungsprozess dazu führen, dass man schrittweise immer mehr Vertragsklauseln und Bürokratie "erfindet". Inhaltlich bewegt man sich aber weg von Agilität. Man wird ja immer schwerfälliger. Da fällt mir auf: Ich glaube, genau das haben wir in den letzten Jahren gemacht.
Standmann: Agilität definiert eine Zielrichtung für den kontinuierlichen Verbesserungsprozess, nämlich in Richtung Reaktionsfähigkeit, Transparenz und kürzere Time-to-Market.
Ich: Aber wozu gibt es dann diese ganzen Techniken in Scrum oder eXtreme Programming, wenn es doch nur um den kontinuierlichen Verbesserungsprozess geht? Die meisten Techniken haben mit diesem ja gar nichts zu tun.
Standmann: (Oha. Da muss ich selbst erstmal ein wenig drauf rumdenken.) Äh, ja. Das ist erstmal sehr gut beobachtet. Da muss ich selbst mal überlegen. Also die Techniken sind Best Practices, die sich in vielen Projekten etabliert haben. Wenn man diese Best Practices früh einsetzt, kann man damit schnellere Fortschritte in Richtung Agilität erzielen, als wenn man sie ignoriert und nur in kleinen Schritten verbessert. Und wenn man mit seinem kontinuierlichen Verbesserungsprozess eine bestimmte Verbesserung erzielen will, kann man bei den existierenden Techniken gucken, ob es da schon was gibt. Wenn man also seine Qualität verbessern will, bietet eXtreme Programming testgetriebene Entwicklung sowie Pair Programming und Feature-driven Development bietet Codeinspektionen. Da ist es natürlich viel einfacher, aus bewährten Techniken etwas auszuwählen, als sich selbst etwas auszudenken.
Ich: Klingt einleuchtend.
Standmann: Mir fällt noch etwas ein. Man kann viele der agilen Techniken auch als Feedback-Mechanismus für die Steuerung des kontinuierlichen Verbesserungsprozesses nutzen. Wenn man beispielsweise Probleme hat, seine Iterationsplanung in der vorgesehenen Timebox durchzuführen, ist das ein wichtiger Input für das Nachdenken über die nächste anstehende Verbesserung.
