agile review Leseprobe Erfolgreich agil! (2021/S) - Page 9

die rache von xp
Die Entwicklung erreicht nahezu einen Stillstand . Der vernachlässigte Onkel der agilen Bewegung sitzt in der Ecke , schaut zu und genießt seine späte Rache .
Kärtchenschieben
Nachdem XP Ende der neunziger Jahre die Grundlagen für agile Software-Entwicklung gelegt hatte , traten viele andere agile Methoden auf das Spielfeld . Heute wird die Szene von Scrum und Team-Kanban dominiert . Zwei Methoden , die ausschließlich auf den Prozess fokussieren . „ Wenn deine Software Mist ist , bringen dir Haftnotizen an der Wand auch nichts .“ sagt Hendrik Kniberg [ Kniberg2019 ] und hier rächt sich , wenn wir Handwerk jahrelang vernachlässigt haben .
Gewinne privatisieren – Verluste sozialisieren
Managerin Doris rühmt sich , entscheidend dazu beigetragen zu haben , dass das verlangte Feature implementiert wurde . Der Product Owner des Teams muss umgekehrt dafür gerade stehen , dass sein Team im Gegenzug nicht alle geplanten Features geschafft hat . Aber weil durch Doris Aktivität der Handlungsdruck abgebaut wurde , kümmert sich niemand darum , das organisatorische Problem zu lösen , wegen derer der Product Owner die Priorität des Sonder-Features nicht erkannte . Entweder fehlt ihm Wissen oder es war nur aus Partikular-Interessen wichtig ( dann war es aber schädlich , das Feature vorzuziehen ). Die Entwickler : innen und das ganze Team müssen damit leben , dass ihr System nun technische Schulden enthält . Dadurch werden sie zukünftig entweder langsamer oder sie müssen das Aufräumen explizit einplanen . Die Erfahrung zeigt , dass sie die leichte Verlangsamung in Kauf nehmen werden und versuchen , wieder die gleiche Anzahl an Storys umzusetzen . Wir blicken auf ein System , in dem die Konsequenzen des Handelns einer Einzelperson ( hier Doris ) von anderen ( die Organisation ) getragen werden . Der Erfolg ist einer Person zuzuschreiben , die Zinsen zahlen Team und Product Owner .
Insolvenz und Inflation
Nach ca . 18 bis 24 Monaten zeigen sich die Symptome . Entweder das Team erreicht ein Plateau und kommt nur noch langsam vorwärts oder es beginnt die Diskussion , ob eine Neuimplementierung notwendig wäre . Letzteres ist wegen der großen Investition in die Bestandssoftware aber wirtschaftlich schwer argumentierbar . Der Product Owner erklärt seine Insolvenz , weil er sich nicht mehr als Herr über das Produkt sieht . Das Backlog wird zunehmen nach „ was ist machbar “ und weniger nach Geschäftswert priorisiert . Es gibt viele Sachzwänge und dadurch treffen de facto Andere Entscheidungen . Die Programmier : innen rufen eine Inflation aus . Sie können nicht mehr die für das Unternehmen wertvollsten Features , sondern nur noch die machbaren Features bauen . Weil sie neue Funktionen immer schwerer in das System integriert bekommen , werden diese immer teurer . Änderungen an der Architektur können nur mit großem Aufwand vorgenommen werden , weil viele kleine Aufräumarbeiten versäumt worden sind und sich nun aufsummiert haben . Die Tester : innen erklären ihre Insolvenz , weil immer geringere Anteile des Systems automatisch getestet sind und damit in bestimmten Bereichen händische Tests notwendig werden , die in der zur Verfügung stehenden Zeit nicht zu leisten sind . In dieser Situation ist guter Rat teuer .
agile rewiew Leseprobe Sonderausgabe 2021 9