Ein paar Meetings in den Kalender gesetzt, Post-Its gekauft und ein paar zusätzliche Rollen verteilt, fertig ist der neue agile Entwicklungsprozess. Dann mal schnell lossprinten, damit die Spezifikation bald fertig wird und das Projekt komplett durchgeschätzt werden kann. Der Projektleiter macht eh schon Druck.
Ganz so anders als vorher fühlt sich das allerdings gar nicht an… Schade eigentlich, im Training schien das alles noch so einfach. Jetzt in der Praxis scheint jeder im Team eine andere Vorstellung davon zu haben, wie das alles genau geht und die Post-Its wollen auch nicht kleben bleiben. Willkommen im Alltag und an dem Punkt, an dem klar wird, dass der agile Neustart vielleicht doch nicht ganz so einfach wird.
Das Thema
Die agilen Techniken sind an der Oberfläche bestechend einfach und pragmatisch. Die anstehende Arbeit in Backlogeinträge zerlegen, schrittweise abarbeiten und zwischendurch immer mal schauen, wo man steht und gemeinsam ein wenig planen. Allerdings, so richtig wirkungsvoll wird das Ganze erst, wenn man mit dem Verständnis für die dahinterliegende Strategie dafür sorgt, dass die einzelnen Techniken auch richtig ineinandergreifen.
In einer Situation, die jeder kennt, steckt die zentrale Erkenntnis hinter dem Konzept agiler Softwareentwicklung: „Das hättet Ihr doch erkennen müssen!“. Denn im nachhinein sind die Dinge immer ganz klar, nur unterwegs haben wir sie nicht erkannt. Softwareentwicklung bleibt neben solidem Handwerk immer auch ein komplexes Unterfangen. Das heißt, selbst das erfahrenste Team erlebt regelmäßig Überraschungen dieser Art und muss mit ihnen umgehen. Aber ein agiles Team hat dafür eine Strategie parat.
Die Strategie
Das Ziel einer agilen Realisierungsstrategie ist, sich möglichst systematisch und frühzeitig überraschen zu lassen. Praktisch bedeutet das:
Nur im Ganzen sieht man die Fehler im Kleinen
Erst bei der Integration des Systems in ein lauffähiges Ganzes erkennt man Probleme und zwar technische genauso wie fachliche. Wer darauf achtet, dass Produktbacklogeinträge tatsächlich fachliche (Teil-)Abläufe beschreiben, ist daher klar im Vorteil und in der Lage, im Review zu lernen, was schwieriger/anders/besser funktioniert als erwartet.
Wir glauben viel, wir wissen wenig
„Das müsste so funktionieren…“ ist eine Aussage, die wir auch alle kennen. Dabei gibt es drei Möglichkeiten, wie es tatsächlich ist:
- Es funktioniert genau so
- Es funktioniert ganz anders
- Es funktioniert ungefähr so, aber nicht genau so
Ich würde behaupten, in den meisten Fällen tritt die Variante 3 ein. Statt also viel darüber zu reden und zu analysieren, wie es funktionieren sollte/könnte, ist es oft eine gute Idee, Dinge einfach auszuprobieren. Praktisch bedeutet das auch, dass es häufig mehr Sinn macht, weniger Aufwand in eine Spezifikation oder ein Design vorab zu investieren, aber dafür systematischer das Erprobte zu dokumentieren und innerhalb des Projekts zu kommunizieren. Damit dabei die Codequalität nicht leidet, braucht es eine darauf ausgerichtete Definition of Done sowie die Bereitschaft, Themen, die im Review erkannt werden, auch tatsächlich unmittelbar zurück ins Backlog fließen zu lassen.
Kleine Schritte machen
Wer bei kleinen Schritten mal daneben tritt, fällt nicht gleich hin. Mitten im Sprung sieht es da schlechter aus. Lösungsdesign nicht so gelungen? Das lässt sich jetzt schnell noch wieder gerade ziehen. Die Zeit reicht nicht mehr aus? Das, was wir jetzt haben, ist gerade genug, dass es ein paar Wochen in Produktion übersteht. Anforderungen sinnvoll in kleine Schritte fürs Backlog zu zerlegen, ist eine Herausforderung, sorgt aber gleichzeitig dafür, dass Anforderungen früher getestet und Probleme erkannt werden können.
Fazit
Agile Softwareentwicklung braucht immer auch ein Verständnis fürs Ganze. Damit man die agilen Techniken tatsächlich gewinnbringend einsetzt, sollte man sich immer wieder fragen: Was will ich eigentlich erreichen und habe ich das bei dem, was ich tue, noch im Auge? Denn mit Post-Its alleine werden keine agilen Teams gemacht, die Strategie macht den Unterschied.
