Entwicklungsteams müssen Prinzipien und Praktiken bewusst einsetzen, um qualitativ hochwertige Softwaresysteme zu erstellen.
Interne Code-Qualität eines Softwaresystems hat eine enorme Auswirkung auf den wirtschaftlichen Erfolg eines IT-Unternehmens. Der Grad der Wartbarkeit und Erweiterbarkeit eines Systems hat eine direkte Auswirkung auf allen Feedback-, Kommunikations- und Handlungsebenen einer Organisation. Schlechte Code-Qualität bedeutet eine lange Time-to-Market, sie verursacht schlechte Kundenzufriedenheit, Geldverschwendung und große Frustration in den Teams und in der ganzen Organisation.
Die interne Codequalität fällt nicht vom Himmel. Darum beschäftigen sich viele Softwareentwickler und Tester mit den Themen wie Clean Code und Extreme-Programming-Techniken.
Aber Moment Mal! Waren solche Probleme nicht die Probleme von Wasserfall, also aus der Vergangenheit? Ist nicht mit SCRUM alles stets anders, besser und problemlos? Sollte agile Prozesse es nicht ermöglichen, vor allem erfolgreiche Produkte in einer dynamischen und komplexen Welt bauen zu können, die sich zu schnell verändert?
Agile Prozessmodelle wie SCRUM und Kanban können erst durch geeignete Entwicklungsmethoden, die die Qualität eines Produktes gewährleisten, zu effizienten Entwicklungsmodellen werden. Natürlich haben beide einen Beeinfluss aufeinander. Teams brauchen einen Rahmen, indem sie sich schlank bewegen und das Richtige richtig tun können. Aber immerhin, nicht wie der Prozess drum herum aussieht und beschrieben wird ist für den Erfolg entscheidend, sondern wie das Produkt im und vom Team hergestellt wird.
Daher finde ich es sehr wichtig, ein geeignetes Umfeld zu haben, damit Clean Code und XP Techniken effizient eingesetzt werden können. Das ist aber leider nicht immer der Fall und viele Entwickler leiden unter Pseudo-Agilität, in der das Experimentieren und die schnelle Feedback-Zyklen nicht möglich sind. Dazu kommt, dass alte zentralisierte Command-and-Control-Systeme nur einen anderen Namen bekommen haben. Diese heißen nicht mehr Manager sondern Master.
Auch mit SCRUM brauchen Entwickler, die zu wenig Einfluss und zu wenig Kontext haben, viel zu lange. Dabei entwickeln sie Produkte – auch noch mit schlechter Codequalität - die die Kunden eigentlich gar nicht haben wollen. Das hat unzufriedene Kunden, unmotivierte Entwickler und frustrierte Manager -pardon - Scrum Master zur Folge.
Das ist höchstwahrscheinlich eine „Dirty Agile“ Welt, in der die agilen Werte und Prinzipien nicht gelebt werden. Das wahre Potenzial von Clean Code kann in einem agilen Umfeld leichter ausgeschöpft werden. Meiner Sicht nach, braucht Clean Code ein wahres, authentisch agiles Umfeld. Aber was genau bedeutet agile Softwareentwicklung? Und wie ist es ursprünglich entstanden und evolviert?
In diesem Vortrag werden Antworten auf Fragen gegeben, die aus meiner Sicht im Zusammenhang mit agilen Werten, Prinzipien und Clean Code entstanden sind. Darüber hinaus werden ein paar Beispiele aus der Praxis präsentiert, um zu zeigen, wann agile „dirty“ sein kann.

Ich habe den Vortrag auf folgende Events gehalten:
https://www.dev-days-online.de/session/clean-code-dirty-agile/
https://www.ittage.informatik-aktuell.de/programm/2020/clean-code-dirty-agile.html
https://basta.net/agile-devops/clean-code-dirty-agile/