Ich bin ja ein großer Freund von agilem und schlankem Vorgehen in der Softwareentwicklung. Aber derzeit scheint mir die Agilität ein bisschen unbescheiden. Sie hebt immer mal wieder ab. So auch in diesem Artikel von Henrik Kniberg (meine Hervorhebung):
Was soll das denn? Vor 2000 wussten Softwareunternehmen nicht, wie man Software ausliefert? Ja, ist das so gewesen?
Und vor 2000 haben Unternehmen keine nützliche, funktionierende Software (“working software”) ausgeliefert, falls sie es denn überhaupt geschafft haben, welche aus der Tür zu bekommen? Ja, ist das so gewesen?
Ich hatte in den 1980ern und 1990ernn schon den Eindruck, mit “working software” zu arbeiten. Und ich habe mit meiner Branchensoftwarefirma 10 Jahre lang selbst “working software” ausgeliefert. Sonst hätten mein Partner und ich uns und unseren Angestellten kein Gehalt zahlen können. (Er liefert übrigens immer noch “working software” aus und lebt davon – obwohl er ganz unagil arbeitet.)
Dass etwas im Argen war mit der Art, wie wir in unserer Branchensoftwarebude Software entwickelt und ausgeliefert haben, ist unbenommen. Und es liegt auch heute noch viel im Argen bei dem, wie Software entwickelt wird. Natürlich bin ich dafür, dass mehr Teams, agil und/oder schlank werden.
Aber wir sollten doch bitteschön nicht verkennen, wie viel geleistet wird ganz ohne Agilität und Schlankheit. Die Softwareentwicklung hat nicht erst mit der Agilität angefangen. Und Agilität ist bei weitem nicht in alle Köpfe, Teams und Unternehmen bisher vorgedrungen. Sind deshalb die, die noch nicht agil oder schlank sind, Hinterwäldler und Dummköpfe? Kriegen die nichts gebacken?
Ein bisschen Bescheidenheit stünde der Agilitätsbewegung gut zu Gesicht, finde ich. Mit solchen Aussagen gewinnt man keine neuen Freunde. Eine abgehobene, arrogante Agilität nützt niemandem.
Und wie kann das Abheben vermieden werden? Ich glaube weiterhin, dass dafür eine glasklare Definition von Agilität nötig ist. Henrik Kniberg bleibt Sie trotz Link auf das agile Manifest schuldig. Und Martin Fowler weiß es nicht besser, sondern erkennt sie einfach, wenn er ihr mal begegnen sollte.
Ob Sie nun meiner persönlichen Definition von Agilität zustimmen oder ihre eigene haben… Wir sollten uns darüber unterhalten, was Agilität im Kern ausmacht. Dass mit ihr “working software” hergestellt werden kann, ist nichts Neues und nichts Besonderes. Ein bisschen mehr Butter bei die Fische darf schon sein.
Was ist also das klar umrissene Nutzenversprechen der Agilität, das sie vom Bisherigen abhebt? Wie kann Agilität einem gestandenen Geschäftsführer, der seit 20 Jahren nützliche und funktionierende Software an den Markt bringt und 20 Leute damit ernährt, in nicht arroganter Weise nahegebracht werden?
Und dann: Mit welchen Merkmalen, Hilfsmitteln, Methoden, Konzepten, Paradigmen versucht Agilität dieses Nutzenversprechen einzulösen? Warum sollen die funktionieren und nicht anderes?
Mein Empfinden ist, dass es bei all der Literatur zu Agilität noch Erklärungsbedarf gibt. Die Marketing-Arbeit der Agilisten ist nicht vorbei. Die Zeit für siegerhafte Arroganz ist noch nicht gekommen. Und sollte am besten auch nie kommen.
PS: Und dass das heutige Problem vor allem sei, das falsche Produkt zu bauen, halte ich auch noch nicht für ausgemacht. Sicherlich ist das ein nicht zu leugnendes Problem – nur hat das nicht speziell mit Softwareentwicklung zu tun. Für viel dringender halte ich das Problem mangelnder Evolvierbarkeit. Die Unwartbarkeit, das Brownfield, die Legacy Code Berge… sie drohen überall. Denn was will man denn machen, wenn man denn nun endlich weiß, welches Produkt man bauen will – und man kriegt es nicht hin? Dann ist das Händeringen umso größer. Deshalb: Ich bin dafür, zuerst die Bedingung für die Möglichkeit des richtigen Produktes anzugehen. Und das ist eine Codebasis, die sich in welche Richtung auch immer geschmeidig anpassen lässt.
