Standardsoftware
 |
| Bild: Wikimedia Commons / Bengt Oberger - CC BY-SA 4.0 |
Wer in seiner Firma agile Software-Entwicklung einführen will wird an verschiedenen, zum Teil unerwarteten Stellen Hürden antreffen. Eine davon sind die eingesetzten Anwendungen selbst, genauer gesagt eine spezielle Kategorie davon - die Rede ist von Standard-Software. Dort wo sie anzutreffen ist kommt es schlagartig zu Konflikten mit dem agilen Vorgehen, deren man sich bewusst sein sollte, wenn man nicht unschön überrascht werden will.
Zunächst eine kurze Erklärung: unter Standard-Software versteht man Anwendungen, die einen klar definierten Anwendungsbereich abdecken und fertig programmiert erworben werden können. Wer sie kauft will sich selbst den Entwicklungsaufwand ersparen und stattdessen ein sofort nutzbares Produkt haben, das nur noch installiert werden muss. Bekannte Hersteller von Standard-Softwares sind z.B. SAP, Microsoft, Adobe oder Salesforce.
Das damit verbundene Risiko ist, dass die erworbene Standard-Software nicht (oder nicht mehr) den Wünschen und Bedürfnissen der Anwender entspricht. Bis zu einem gewissen Grad liegt das in der Natur der Sache: es sollen möglicht viele Menschen oder Unternehmen als Käufer in Frage kommen, weshalb auf einzelfallspezifische Bedürfnisse nicht eingegangen werden kann. Das in der Agilität essenzielle Inspect & Adapt findet beim Hersteller daher nur noch sehr eingeschränkt statt.
Aber auch beim Kunden wird der agile Arbeitsmodus eingeschränkt. Theoretisch könnte die gekaufte Software zwar bei Bedarf angepasst werden (man spricht dann vom Customizing), allerdings geht dadurch die so genannte Updatefähigkeit verloren - neue Funktionen, Aktualisierungen und Bugfixes des Herstellers würden die Anpassungen überschreiben, weshalb sie entweder zeitaufwändig angepasst werden müssen oder sogar ganz auf sie verzichtet wird.
Ein weiterer, oft unterschätzter Aspekt ist der, dass Standard-Software im Normalfall als so genannter Big Bang Release eingeführt wird, also alles auf einmal. Da sie in einem bereits fertigen Zustand eingekauft wird ist das auch naheliegend, allerdings ist man dadurch gezwungen die Risiken von Gross-Releases in Kauf zu nehmen: Unübersichtlichkeit, Fehleranfälligkeit, Aufwändigkeit und Vernetztheit, was dann meistens durch eine möglichst detaillierte und dadurch schwerfällige Planung kompensiert werden soll.
Was durch diese Übersicht klar wird: Agilität und Standard-Software sind eine schwierige Kombination. Man kann zwar agile Arbeitsweisen einführen um bestimmte Arbeiten flexibler und schneller zu machen, etwa Customizing, Bugfixing und das Einspielen von Updates, der Einsatz eines agilen Frameworks in Reinform würde aber schnell zu so weitreichenden Änderungen führen, dass vom Produkt-Standard, und damit von den eigentlichen Vorteilen von Standard-Software nicht mehr viel übrig bleibt.
