Renoviert Eure Software ... und beschäftigt Euch deshalb mit Lean und Agil

Für viele Firmen ist es immer noch ein Businessvorteil für die eigenen Kerngeschäftsprozesse eine eigene Software zu haben. Sie können schneller reagieren, wenn sich die Prozesse ändern. Sie müssen nicht auf einen Hersteller oder externe Programmierpartner warten. Aber was ist, wenn sich die Software nicht mehr so einfach ändern lässt? Und wo kommt die Zeit für die neue Software her? Das wäre ein guter Anlass, um sich mit Lean und Agil zu beschäftigen.

• 2

Werbung

(Das Headerbild wurde von KI erzeugt.)

Software veraltet - immer

Die Firma Stack Overflow befragt jährlich Entwickler. In diesem Jahr melden die Entwickler ihre größte Sorge zurück: technische Schulden. Technische Schulden führen dazu, dass man immer mehr Zeit braucht, um eigentlich Kleinigkeiten zu ändern. Mein Bruder führt immer ein schönes Beispiel dafür an: Man kauft ein neues technisches Gerät für die Küche. Leider sind an die Steckerleiste schon mehrere Mehrfachstecker angeschlossen und es kein Platz mehr frei. Man kann das neue Gerät nicht eben schnell mal anschließen. Jetzt muss gründlich aufgeräumt werden.

So ist es auch mit Software. Es gibt verschiedene Gründe, warum Software veraltet: die Architektur ist schnell aber unflexibel; viele (unbekannte) Abhängigkeiten; es werden externe Module verwendet, für die es keine Updates mehr gibt; es gibt keine Dokumentation usw. Die Experten sprechen hier von sog. Legacy Software. (Für Legacy Code gibt es eine einfache Definition von Michael C. Feathers: alles, was sich nicht automatisch testen lässt, ist Legacy Code.) Eigentlich müsste man jedes Jahr einen bestimmten Anteil seiner Software aufräumen. Aber das macht halt keiner. Und nach 15-25 Jahren steht man vor einer grundsätzlichen Entscheidung: Schreiben wir eine neue Software oder kaufen wir eine ein?

Alte Software ist ein erhebliches Business-Risiko

Normalerweise kümmert sich die IT oder die Entwicklung um die eigene Software. Aber in den letzten Jahren wurde gerade bei der IT und Entwicklung erheblich gespart. Diese Abteilungen brauchen nun fast ihre ganze Energie, um die Software am Laufen zu halten. Neue Funktionen gibt es nur, wenn ein wichtiger Stakeholder Ärger macht.

Bei diesen Systemen handelt es sich übrigens nicht um Nebensysteme. Es sind wichtige Systeme, über die ein Großteil des Umsatzes läuft. Und damit brauchen diese Systeme mehr Aufmerksamkeit vom Management. Wenn diese Systeme ausfallen, ist das Unternehmen sofort im Krisenmodus. Alle müssen in solch einer Situation alles stehen und liegen lassen, damit das Business weiter geht.

Wir können für diesen Fall Notfallpläne erstellen und üben. Die bessere Lösung wäre eine zuverlässige Software. Doch wie bekommen wir die Zeit dafür? Hier kommen Lean und Agil ins Spiel.

Lean und Agil helfen, wenn man KEINE Zeit hat

Wir kennen diese Situation schon aus den 1940er Jahren in den USA. Die Amerikaner mussten die Alliierten mit kriegswichtigen Gütern versorgen. Ihre Wirtschaftsleistung war dafür zu gering. Wie kann man das schaffen, wenn man nicht mehr Fachkräfte und nicht mehr Material bekommt? In diesem Fall muss man systematisch die eigenen Prozesse hinterfragen und verbessern, um sich Luft zu verschaffen.

Mit dem TWI-Programm wurden Teamleiter darin ausgebildet, Verwantwortung für die eigenen Prozesse zu übernehmen:

• Zuerst musste sichergestellt werden, dass alle vernünftig ausgebildet wurden.
• Dann sollte auf ein gutes Arbeitsklima geachtet werden.
• Erst dann konnte man anfangen, täglich die Abläufe systematisch zu hinterfragen.

Etwas Ähnliche erlebe ich heute in IT- und Entwicklungsabteilungen:

• Es gibt erhebliche Wissensinseln. Mit einer Skillmatrix könnten diese Abteilungen Wissenslücken identifizieren. Sie brauchen eine Strategie, wie sie diese Lücken schließen. Es wäre gut, wenn jede Woche etwas passiert.
• Das Arbeitsklima ist schwierig. Es gibt viel Druck und Stress. Man hört den Mitarbeiter:innen und Expert:innen nicht zu. Die Probleme werden ausgesessen. Mit Gemba-Walks können sich Führungskräfte sich selbst ein Bild der Lage verschaffen.
• Es fehlt immer die Zeit, um Dinge zu verbessern. Es wäre aber ein Leichtes mit Zielbedingungen und kleinen Verbesserungen anzufangen. Dazu müssen die Beteiligten einmal verstehen, wie ein Verbesserungsprozess abläuft. Zudem brauchen wir ein Commitment der Beteiligten, dass sie etwas tun wollen. Führungskräfte können Mitarbeiter:innen täglich coachen (siehe Toyota Kata oder Agile Kata).

Die gegenseitige Ausbildung macht die Teams flexibler. Das bessere Arbeitsklima reduziert Fehler. Die kleinen Verbesserungen summieren sich zu großen Ersparnissen auf. Nun bekommen wir Zeit für die nächste Version unserer wichtigen Software.

Scrum ist gut geeignet, für einen längeren Zeitraum am Stück an einer neuen Version zu arbeiten. Die Beteiligten könnten in einer Hackweek oder einem Hackathon die Grundlagen legen.

Man muss sich auch im Klaren sein: alte und neue Software müssen noch über Jahre parallel betrieben werden. Eine Umstellung von der alten auf die neue Version zu einem Tag ist sehr unrealistisch. Die Entwicklungsleiter:innen oder Product Owner:innen müssen eine Strategie entwickeln, wie sie die neue Funktionalität schrittweise aufbauen, testen und in Betrieb nehmen.

Wer sich weiter mit dem Thema beschäftigen will, findet wertvolle Informationen in den folgenden Büchern:

• Feathers, Michael: Working Effectively with Legacy Code. New Jersey: Prentice Hall Professional, 2004. (Deutsche Ausgabe: Feathers, Michael C.: Effektives Arbeiten mit Legacy Code : Refactoring und Testen bestehender Software. Norderstedt: BoD – Books on Demand, 2023.)
• Humble, Jez ; Farley, David: Continuous Delivery : Reliable Software Releases through Build, Test, and Deployment Automation. Amsterdam: Pearson Education, 2010.
• Annett, Robert: Working with Legacy Systems : A practical guide to looking after and maintaining the systems we inherit. Birmingham: Packt Publishing Ltd, 2019.