Warum bist du so agil wie meine Oma?

Kürzlich in einer Retrospektive. Das Team sollte Fragen an den vergangenen Sprint formulieren. Diese wurden auf Karten gesammelt und anschließend in der größeren Runde diskutiert, gruppiert und bewertet. Neben Fragen wie “Funktioniert Pair Programming für uns?” oder “Haben die zeitnahen Fachtests dieses Mal besser funktioniert?” ist eine Frage besonders aufgefallen: Ein Entwickler fragte “Wieso bist du so agil wie meine Oma?“.

Neben einigem Gelächter und kurze Diskussionen über noch sehr rüstige ältere Menschen kamen aber vor allem erhebliche Sorgenfalten auf die Gesichter. Das Unternehmen predigte seit Jahren die agile Methodik und nennt dieses als den Hauptantrieb der Entwicklung. Das Kernproblem des Entwicklers lässt sich wie folgt beschreiben: Die Entwicklung arbeitet mit sehr modularen Komponenten, die vorab in technischen Spezifikationen in Word komplett beschrieben werden. Fällt dem Entwickler während der Implementierung auf, dass ein Teil der Komponente A eigentlich besser in Komponente B aufgehoben wäre, dann wäre der Code Change nur weniger Zeilen und inklusive Test-Anpassung in ein paar Minuten gemacht. Die Anpassung der Spezifikationen und das ganze Dateihandling würde jedoch anschließend mehrere Stunden in Anspruch nehmen. Dadurch geht viel Agilität verloren.

Gerne wird dabei darauf verwiesen, dass der Kunde ein Projekt zum Festpreis, mit festem Scope und fester Deadline beauftragt hat und deshalb die agilen Prozesse gar nicht so gut funktionieren. Ich möchte an dieser Stelle weder auf nötige Detailtiefe von Dokumentationen noch auf das Vertragsproblem eingehen. Wichtig ist mir das Verständnis, dass man auch intern agil arbeiten kann, wenn der vertragliche Rahmen es nicht zulässt.

Agilität entsteht nicht durch die Nutzung von Iterationen, Backlogs, Kanban-Boards, User Stories oder ähnlichen Artefakten. Agilität beginnt zunächst und grundlegend in den Köpfen. Umso wichtiger ist es nicht in den alten Trott zu verfallen, Scrum oder ähnliche Frameworks genau nach dem Buch zu modellieren und durch weitere dogmatische Ansätze zu untermauern. Wenn ein Unternehmen auf der einen Seite die agilen Werte anpreist und auf der anderen Seite nur von Standards, 110%-Lösungen, einheitliche Prozesse und “Das liegt seit 2 Jahren brach weil wir noch keine finalen Daten haben” redet, sollten die Alarmglocken läuten. So wichtig Qualität für die Softwareentwicklung ist, so sehr ist Perfektionismus der Feind von Inspect & Adapt.

Die kleinen Schritte führen zum Erfolg. Dies wird leider in der Scrum-Literatur häufig nicht deutlich genug. In meinen Augen macht Kanban das deutlich klarer: Beginne mit dem was du hast und verstelle von dort nach und nach die Schrauben, eine nach der anderen.

Wenn der Perfektions-Anspruch in der Prozess-Gestaltung überwunden wurde ist der Weg frei für agile Methodiken. Und das völlig unabhängig von der Vertragsgestaltung.

Bild: © Ongap | Dreamstime Stock Photos & Stock Free Images

Leave A Reply

Navigate