Noch ein wichtiger Punkt, der unbedingt angemerkt werden muss: Alles, was ich hier schreibe, ist meine persönliche Meinung und spiegelt auch nur diese wider. Diskussionen sind herzlich willkommen! Falls sich der eine oder andere Kollege angesprochen fühlt, natürlich ist alles frei erfunden und Ähnlichkeiten sind rein zufällig... :-)

Agilität versus fachlicher Mehrwert?

Wir arbeiteten mit einem Kunden seit Monaten an einem größeren Code-Clinic-Projekt, in dem wir während des Betriebs nach und nach fachliche Teile der Anwendung refactored und mit einer neuen technischen Servicearchitektur versahen. Von Beginn an wurde der Aufwand im technischen Stack so klein wie möglich und so groß wie nötig gehalten. Es war einfach noch viel zu wenig Erfahrung aus dem bereits acht Jahre laufenden Projekt vorhanden, um wirklich bewusst eine sinnvolle Architekturentscheidung zu treffen. Wir wollten erst einmal viel mehr fachliches Wissen aufbauen, die versteckten Features finden, und waren uns auch der Gefahr dabei sehr bewusst. Dokumentation war der Code, die fachliche Logik steckte in Stored-Procedures und falsch verwendeten Triggern (manche dieser Trigger manipulierten fünf bis sechs Datenbanktabellen). Der Sponsor des Kunden war von der Idee, agil vorzugehen, von Beginn an begeistert und trug diese voll mit.

Neun Monate später war es dann soweit. Wir begannen mit dem weiteren Refactoring unseres neuen Stacks, da die Wissenslücken einigermaßen gefüllt waren und sich der Nebel des weiteren Vorgehens lichtete. Aus einer Webanwendung auf Basis von Wicket und Spring (-Remoting, -Integration usw.) entwickelten wir eine komplette serviceorientierte Architektur, in der die eigentliche Middleware in einer Serviceanwendung steckte, die Wicket-Anteile in reine Webanwendungen ausgelagert wurden, die kleine fachliche Einheiten bildeten (warum dies so entschieden wurde, ist ein anderes Thema und kann jederzeit separat mit mir diskutiert werden).

Das Refactoring dauerte alles in allem ca. 60 Stunden, inklusive weiterer Tests (Akzeptanz, Integration, Regression). Als der Product Owner dies absegnen sollte, bekam er Bedenken, dass der Sponsor dies nicht akzeptieren würde, da wir ja auf einer „niegelnagelneuen“ Anwendung arbeiten würden. Er könne dem Sponsor durch die 60 Stunden Mehraufwand keinen fachlichen Mehrwert liefern. Vergessen wurde bei dieser Aussage wohl das Modell, in dem entwickelt wurde, das eben agil war. Aufwände sollten somit erst dann entstehen können, wenn es nötig wurde.

Meine Meinung zu diesem Dilemma

Normalerweise stehe ich hier ganz klar auf der Seite des Product Owners und vertrete den dogmatischen Ansatz des agilen Modells, dass jede Story für den Sponsor wirklich einen fachlichen Nutzen, einen Mehrwert haben sollte. Allerdings sollte man in Projekten, die zur Anwendungszeit weiterentwickelt werden, in der Lage sein, hier Kompromisse einzugehen. Es macht nur bedingt Sinn zu versuchen, jederzeit einen fachlichen Mehrwert zu erzeugen, wenn dadurch kritische Produktionsbedingungen entstehen. In unserem Fall hätte das Team nun begonnen, immer bestimmte Teile des Refactorings während der User Stories mit zu implementieren.

Dies halte ich für kritisch, da Umbauten in diesen Größenordnungen die volle Aufmerksamkeit des Teams benötigen. Auf der anderen Seite steht natürlich die Aussage, dass der Sponsor ja hier auch einen Businessvalue bekommt: Dieser kommt indirekt durch die Hintertür, da seine Anwendung auf dem Laufenden bleibt, sein Entwicklungsteam motiviert bleibt und es leichter hat, Erweiterungen zu entwickeln.

Wie ist ein Team in der Lage, dies zu kommunizieren, ohne dass es dabei nach einem Schutzschild für die eigene Inkompetenz in Sachen Planung ausschaut?

Man sollte jederzeit die totale Transparenz über die Dogmen des agilen Modells stellen und das große Refactoring vorab genau skizzieren, um dem Sponsor dabei zu helfen, den Mehrwert anerkennen zu können. Es gibt eine Menge Möglichkeiten, dies mit recht wenig Zeitaufwand zu schaffen. Umgekehrt jedoch wird der Sponsor wenig davon haben, wenn sein Team Zeit aufwenden muss, um die fachlichen Values eines Refactorings herauszuarbeiten, da es meist einfach nur wenige gibt:

• schnellere Implementierungen mit saubereren fachlichen Grenzen
• Motivation des Teams
• Wissensaustausch innerhalb des Teams durch die Planung und Restrukturierung des Codes
• schnelleres Ausrollen besser gekapselter fachlicher Erweiterungen und Änderungen

Derzeit kann man die Diskussionen, die sachlich mit dem Thema Agilität in der IT umgehen, eher an einer Hand abzählen, wogegen jedoch die Powerpoint-Präsentationen, bei denen Agilität alle Probleme der IT-Welt auf einmal löst, unzählbar werden. Agilität hilft nur dann wirklich weiter, wenn innerhalb des Teams – angefangen beim Sponsor bis zum DevOp - jeder das gleiche darunter versteht. Aus meiner Erfahrung heraus ist dies leider nicht sehr oft der Fall. Man muss innerhalb des kompletten Teams, vom Sponsor bis zur Teamassistenz, immer und immer wieder dafür werben, dieses Vorgehen konsequent einzusetzen. Dann erfährt auch JEDER im Team die Vorteile, nicht nur die arbeitende oder nur die organisierende und bezahlende Seite.

Ich würde mich sehr über eine anregende Diskussion freuen und verspreche, wie schon im vorigen Artikel, auch dieses Mal sehr zeitnah zu reagieren und mich intensiv in die Diskussion einzuklinken, denn das ist ja schließlich auch ein Ziel dieser Kolumne !

Leute, in einem niegelnagelneuen Projekt kann ich meinem Chef kein Refactoring verkaufen!