Agiler Mythos #3: Agil = Schneller

Usain Bolt

http://www.flickr.com/photos/goulao/3842497008/

Viele implizieren mit dem Begriff “Agil” Schnelligkeit. Das ganze wird noch durch den Begriff “Sprint” in Scrum verstärkt, ein aus meiner Sicht unglücklicher Begriff. In Wahrheit bedeutet die Einführung agiler Prozesse erst einmal, dass wir ordentlich auf die Bremse treten. Statt wie irre Code zu schreiben sollte man damit Anfangen das Erstellen von Software als ein Handwerk zu sehen. Die “Software Craftmanship” Bewegung ist eine Ausprägung dieser Idee. Durch die Einführung von testgetriebener Entwicklung, Continuous Integration/Deployment, Pair Programming, Konzentration auf die Erzeugung von “Clean Code” und anderer Techniken wird ein Team von Entwicklern zuerst einmal langsamer. Das ist auch nicht weiter schlimm, den Qualität entsteht nur dort, wo auch sorgfältig gearbeitet wird. Wie Ken Schwaber schon so schön gesagt hat, kann man Qualität nie nachträglich “einbauen”. Agile Teams arbeiten also nicht schneller, sondern langsamer und sorgfältiger. Trotzdem hat man das Gefühl, dass diese Teams schnell sind. Woran liegt das also? Hierfür gibt es 3 Hauptgründe.

1. Weniger Bugs

Dadurch, dass gewissenhafter gearbeitet wird, gibt es auch weniger Fehler in der Software. Das bedeutet, dass die berühmt berüchtigten Bugfixing-Phasen am Ende eines Projektes wegfallen. Das spart natürlich einiges an Zeit und Geld. Gleichzeitig wird durch die hohe Testabdeckung dafür gesorgt, dass bestehende Funktionalität nicht wieder “kaputt” programmiert wird. Wer kennt das nicht, wenn man nach einem halben Jahr die älteren Features ausprobiert und Teile davon nicht mehr funktionieren

2. Einfache Erweiterbarkeit und Wartbarkeit

Der Code in agilen Teams ist besser strukturiert, dadurch ist er auch besser wartbar. Hier hilft natürlich auch die hohe Testabdeckung. Man muss nicht Angst haben, dass man beim Hinzufügen neuer Features etwas kaputt macht oder dass uns bei einem Refactoring alles um die Ohren fliegt. Den so genannten “Big Ball of Mud” hat bestimmt jeder Softwareentwickler schon erlebt. Aus diesen Zeiten kommt auch der Spruch “Never touch a running system”. Ich hatte schon mit Software zu tun, bei der das Ändern der Sortierung von Spalten in einer Tabelle mehrere Tage gedauert hat. Und was passiert dann unweigerlich: Irgendwann schmeiߟt man alles weg und fängt von vorne an, weil das ganze System unwartbar geworden ist. Dieses Szenario können sie sich sparen.

3. Fokussierung auf das Wesentliche

Aus meiner Sicht ist das der Hauptgrund für die gefühlte Geschwindigkeitssteigerung. Anstatt ein Feature nach dem anderen zu entwickeln, macht man sich grundsätzlich Gedanken, welches Ziel man eigentlich erreichen will. Man definiert eine klare Vision oder ein klares Geschäftsziel und leitet alles weitere daraus ab. Man wirft also alles über Board was nicht wirklich gebraucht wird, um das Geschäftziel zu erreichen. Eine Eierlegende Wollmilchsau ist nämlich nie die beste Lösung. Neue Features werden immer genau darauf untersucht, ob sie dabei helfen können dieses Ziel zu erreichen und wenn nicht: weg damit! Gute Tools die einem dabei unterstützen können sind Feature Injection oder Impact Mapping. Ich bin mittlerweile ein großer Fan von Impact Mapping, da es aus meiner Sicht das erste Tool ist, welches das Business Ziel in den Mittelpunkt stellt.

Fazit

Agile Teams sind also nicht unbedingt schneller. Durch das sorgfältigere Arbeiten und dem Fokus auf das Wesentliche ist man aber trotzdem die Firma, die mit Innovationen schneller am Markt ist. Und wenn die agilen Praktiken in Fleisch und Blut übergegangen sind, ist man am Ende vielleicht auch tatsächlich schneller.

P.S.: Wussten Sie, dass sie einen Kindle Fire HD gewinnen können, wenn sie an meinem nächsten Management 3.0 Kurs teilnehmen?

Leave a reply


*