TOP 3 Agile Worst Practices – Teil 3: Den Release hinauszögern

NR. 3: NICHT RELEASEN

Man kann doch nicht nach drei Monaten bereits einen Release des MVPs durchführen. Die Funktionalität reicht doch vorne und hinten nicht. Der User wird enttäuscht sein. Enttäuscht wovon? Von der Funktionalität, die es noch nicht gibt? Die Features, von denen ein Anwender noch nicht mal weiß, dass sie einen Mehrwert für ihn haben? Ich will hier aber nicht auf die Vorteile eines MVPs eingehen. Sondern auf die Folgen aufmerksam machen, die auftreten, wenn man nicht LIVE geht:

• Die Stabilität der Umgebung sinkt.
  Wenn wir wissen, dass ein Release erst in Jahren(!) erfolgt: Warum sollte man sich dann JETZT damit beschäftigen, dass die Infrastruktur läuft? Warum sollte man die Performance der Anwendung berücksichtigen? Wir haben doch keine Zeit und müssen Features entwickeln …
  
• Kaputte Software wird toleriert.
  “Das funktioniert noch nicht und wird mit User Story XY fertiggestellt. Klick da bitte nicht drauf, sonst stürzt die Anwendung ab!” Autsch. Wenn ihr sowas hört: RED FLAG. Eine User Story ist dann fertig, wenn ein Mehrwert für den Anwender geliefert wurde. Außerdem sollte ein „releasefähiges Inkrement” entstehen. Wenn man aber nicht released, fällt der letzte Teil oft hinten runter. Dadurch baut man immer wieder Software, welche in sich nicht abgeschlossen ist. Hierbei ist es wichtig, unfertig – wann ist eine Software jemals fertig? 😉 – nicht mit kaputt zu verwechseln. Es ist natürlich in Ordnung, wenn ein Anwender noch nicht die Information bekommt, die er braucht. Aber es ist nicht in Ordnung, dass ein Anwender ein Feature nicht verwenden darf, weil sonst die Anwendung abstürzt.
• Anwender-Feedback fehlt.
  Agilität lebt von Feedback. Sie ist das Grundgerüst, um das sich alles dreht. Inspect & Adapt. Oder auch, wie ein agiler Kollege zu sagen pflegte: Hypothese erstellen → Ausprobieren → Messen → Anpassen (Neue Hypothese aufstellen). Wenn diese Schleife fehlt, entwickelt man “blind”. Ja, es gibt natürlich noch das Backlog. Und meistens auch einen PO bzw. eine Person aus dem Fachbereich, welche “schon weiß, was der Anwender braucht”. Leider ist es ein Trugschluss, davon auszugehen, dass dadurch die Features umgesetzt werden, die wirklich genutzt werden. Das KANO Modell beschreibt dieses Thema sehr gut. Der meiner Meinung nach wichtigste Aspekt dabei ist, dass es schwierig ist, alle Basic Features direkt zu erkennen. Oft erkennt erst ein Anwender bei Abstinenz dieser, dass “etwas Wichtiges fehlt”. So schließt sich der Kreis, warum man unbedingt den Release durchführen muss, damit man dieses wertvolle Feedback bekommen kann.