„Wir können nicht agil arbeiten, wir machen nur Wartung!“ – Kommt Ihnen diese Aussage bekannt vor?
Finden Sie heraus, wie Sie mit den dahinterstehenden Annahmen aufräumen können und wie Sie mit einer agilen Arbeitsweise in der Wartung Ihre Geschäftsziele leichter erreichen.
Mythos 1: die ideale User Story
Das Team sagt: „Wir können nicht mit User Stories arbeiten, weil wir Issues zur Bearbeitung bekommen und kaum Features entwickeln.“
Egal, ob Sie in Ihrem Team von Issues, Fehlermeldung oder Bugs reden: Dieses Argument ist auf eine Idealvorstellung einer User Story zurückzuführen, die in den Schulungen vermittelt wird. Tatsächlich ist es auch bei laufender Software sinnvoll, Anforderungen nach den INVEST Kriterien zu formulieren, um sicherzustellen, dass sie effizient und effektiv umgesetzt werden können.
Was sind die Besonderheiten der INVEST Kriterien in der Softwarewartung?
- Independent: Die meisten Issues zu laufender Software sind unabhängig, da sie sich auf einen einzelnen Aspekt beziehen, der nicht oder nicht mehr wunschgemäß funktioniert. Wenn der Issue komplexer ist, spricht alles dafür, ihn in unabhängige Backlog Items aufzuteilen, damit die Umsetzung planbar wird.
- Negotiable: Das Ergebnis einer User Story muss verhandelbar sein. Auch für Issues in laufender Software gibt es meistens mehr als eine mögliche Lösung. Auch in der Softwarewartung ist es sinnvoll, über die Lösung zu verhandeln, die die Anforderungen zu den geringstmöglichen Kosten erfüllt.
- Valuable: Eine User Story muss einen klar herausgearbeiteten Business Value haben. In der Wartung spielt es sogar eine noch größere Rolle, dass der Wert der Lösungen klar ist. Denn die Bereitschaft zu investieren, sinkt mit zunehmender Lebensdauer der Anwendung. Der Wert ist die Voraussetzung für eine Priorisierung, bei der jeweils der Issue umgesetzt wird, der aktuell den höchsten Business Value bringt.
- Estimable: User Stories müssen schätzbar sein, damit das Umsetzungsteam sich zu einem Umsetzungsplan verpflichten kann. Es spielt dabei keine Rolle, ob es sich um eine Neuentwicklung oder eine Änderung einer Software handelt.
- Small: User Stories müssen klein genug sein, dass sie innerhalb des Planungszeitraums, zum Beispiel eines Sprints, einen Business Value liefern. Die Diskussion darüber wird im Team hauptsächlich geführt, damit die Erwartungen auf den Tisch kommen. Dies gilt für Neuentwicklungen und Weiterentwicklungen, sowie Fehlerbehebungen gleichermaßen.
- Testable: Um nachweisen zu können, dass der vereinbarte Business Value geliefert wurde, muss jedes Backlog Item testbar sein. In der Wartung ist der Nachweis der Funktionsfähigkeit, abhängig vom Release-Zyklus, oft noch wichtiger als im Verlauf der Neuentwicklung.
Fazit: Es ist nicht unbedingt notwendig, dass jede Anforderung sich in eine idealtypische Story verpacken lässt. Die Orientierung an den INVEST Kriterien ist auch bei Altanwendungen sinnvoll und möglich.
Mythos 2: Scope Management ist unnötig
Der Produktmanager sagt: „Wir brauchen kein Backlog, wir machen ohnehin nur mehr Dinge, die wir unbedingt machen müssen.“
Diese Meinung drückt die Erwartung aus, dass die Benutzer nur absolut notwendige Arbeiten in Auftrag geben, da die Anwendung ihr Einsatzende fast erreicht hat. Diese Anwendungen wurden meistens nach dem Wasserfall-Modell entwickelt, das heißt alle Funktionalitäten wurden vorab spezifiziert und – häufig Jahre später – umgesetzt ohne noch einmal nach dem Nutzen zu fragen. Im Wasserfall-Modell geht man davon aus, dass alles umgesetzt werden muss, was spezifiziert wurde.
Gerade bei Altanwendungen am Ende ihres Lebenszyklus hilft ein agiles Vorgehen, weil es die Optimierung des Business Value in den Mittelpunkt stellt. Durch eindeutige Priorisierung und Umsetzung mit dem Business Value im Fokus kann die Entwicklung jederzeit beendet werden, sobald der zusätzliche Nutzen geringer ist als die zusätzlichen Kosten. Die Praxis zeigt, dass Benutzer und Umsetzer am besten gemeinsam über die optimale Nutzung des bereitgestellten Budgets entscheiden können.
Fazit: Aktives Scope Management ist die Voraussetzung dafür, dass nicht nur das Budget im Rahmen bleibt, sondern auch das Ergebnis optimiert wird. Das gilt in der Wartung genauso wie bei der Neuentwicklung.
Mythos 3: Störungen haben Vorrang
Das Team sagt: „Wir können nicht mit der Bearbeitung dringender Fehlermeldungen warten, bis der Sprint vorbei ist. Wir müssen uns sofort darum kümmern.“
Dieser Mythos ist auf die herrschende Meinung zurückzuführen, dass nur eine sofortige Reaktion auf alle Inputs von Kunden oder Benutzerinnen als kundenfreundlich gilt. Nach dem Push-Prinzip werden alle Anforderungen, die vom Kunden dokumentiert wurden, sofort in Bearbeitung genommen. Viele werden aber lange nicht fertig, zum Beispiel weil es offene Fragen gibt oder weil das bemängelte Verhalten auf dem Testsystem nicht reproduzierbar ist. Die Konsequenz ist häufig, dass sich eine lange Liste von Issues „in Bearbeitung“ befindet.
Die Wahrheit ist: Die meisten Issues sind gar nicht so dringend. Eine bewusste Priorisierung hilft dabei, die richtigen Anforderungen umzusetzen und so den Business Value zu optimieren. Das agile Team bearbeitet immer nur so viele Issues, wie tatsächlich umgesetzt werden können. Es stellt diese fertig, bevor es neue aus dem Backlog annimmt.
Fazit: Wer nach dem Pull-Prinzip vorgeht, statt nach dem Push-Prinzip, arbeitet effizienter, erledigt mehr und wird mit den wirklich wichtigen Aufgaben verlässlich fertig. Dies gilt auch in der Wartung.
Mythos 4: das Highlander Syndrom
Die Entwickler sagen: „Wir sind kein Team. Jeder von uns hat sein Spezialgebiet.“
In der Vergangenheit waren Produktentwicklungsteams häufig eher eine Gruppe von Spezialisten als ein Team. Die zugrundeliegende Annahme war, dass Experten Probleme aufgrund ihres tiefen Wissens effizienter lösen, jedoch wurden bald die Nachteile dieser Arbeitsteilung evident:
- Viele Kommunikationsschnittstellen zwischen den einzelnen Experten
- Langwierige Fehleranalysen unter Beteiligung mehrerer Experten
- Jede Person wird zum Flaschenhals für das ganze System und verursacht bei Abwesenheit oder zu hoher Auslastung lange Wartezeiten für das gesamte System
Mit der Verlagerung zu Full-Stack Entwicklung und T-Shaped oder M-Shaped Skills rückt auch die Zusammenarbeit stärker in den Vordergrund. Teams mit bewusst gestalteter Zusammenarbeit bauen gemeinsames Wissen auf und können gerade komplexe Probleme in Altanwendungen schneller lösen. Personalwechsel können so auch wesentlich leichter kompensiert werden. In Summe überwiegen die Vorteile der Zusammenarbeit nach agilen Prinzipien.
Fazit: Agile Teamarbeit unterstützt die hohen Anforderungen, die in der Softwarewartung an Reaktionsfähigkeit und Aufrechterhaltung des Wissens gestellt werden, besser als Expertentum.
Kein Mythos: die wahre Herausforderung für Agilität in der Softwarewartung
Die wahre Herausforderung für Agilität liegt bei Altanwendungen meistens in der Qualitätssicherung. Mangelnde Wissensteilung, geringe Abdeckung mit dokumentierten – am besten automatisierten – Tests und eine intransparente Schnittstelle zum Betrieb sind die unausgesprochenen Gründe, warum viele Entwickler nicht in der Wartung arbeiten wollen.
Hinzu kommt ein hoher Aufwand für die Qualitätssicherung auf allen festgelegten Ebenen (Stages). Es muss sichergestellt sein, dass Änderungen im Code keine unerwünschten Nebenwirkungen verursachen. Hierfür sind zahlreiche manuelle Schritte mit langen Wartezeiten und enormem Koordinationsaufwand notwendig.
Zu den wichtigsten agilen Prinzipien gehört, häufig zu releasen und inkrementelle Änderungen für die Benutzer bereitzustellen. Bei Altanwendungen hilft das agile Vorgehen oft, die Flaschenhälse zu identifizieren und Schritt für Schritt zu beseitigen.
Schlussendlich wird auch eine Releaseplanung mit fixen Releasezeitpunkten durch agiles Arbeiten unterstützt. Durch laufende Priorisierung wird sichergestellt, dass die jeweils wichtigsten Features (bzw. Fehlerbehebungen) umgesetzt werden und der Releasetermin eingehalten wird.
Wie schaut agiles Arbeiten in der Softwarewartung konkret aus?
Bei TechTalk arbeiten wir in der Wartung agil mit einem fixen Team. Das bedeutet für unsere Kunden geteiltes Wissen und garantierte Reaktionsfähigkeit – auch langfristig.
Wir kombinieren ein Kanbanboard mit regelmäßigen Retrospektiven und Plannings nach Scrum. Das Kanbanboard erlaubt einerseits flexible Reaktion, wenn ein dringender Fehler gemeldet wird, unterstützt aber andererseits auch jederzeit die Selbstorganisation des Teams. Die Prioritäten werden klar abgebildet, was kontinuierliche fokussierte Umsetzung bedeutet. Die sogenannte „Emergency Lane“ zeigt auf einen Blick, ob etwas Dringendes außerplanmäßig zu erledigen ist.
Sowohl Kanban als auch Scrum bieten einen Rahmen, in dem Entwickler fokussiert arbeiten können.
Die Elemente aus Scrum erleichtern den Abgleich mit der Roadmap aus der Planung und unterstützen die laufende Evaluierung und Anpassung der Prozesse. Durch die regelmäßige rollierende Planung haben auch unsere Kunden mehr Transparenz. Planänderungen können von beiden Seiten frühzeitig eingebracht und auf ihre Konsequenzen geprüft werden.
Im Umsetzungsteam sind agile Praktiken etabliert, mit denen ein durchgängiger Qualitätsstandard sichergestellt wird. Mehr Informationen dazu finden sich im Experteninterview mit Thomas Korosa.
Haben Sie eine Legacy Software im Einsatz, die modernisiert gehört?
Nutzen Sie unser Angebot der kostenlosen Analyse im Rahmen des TechTalk Relax Application Management Service.
