Agile Softwareentwicklung im SAP-Umfeld

Im SAP-Umfeld hat die agile Softwareentwicklung erst spät Einzug gehalten. Viele Jahre wurde nach dem klassischen linearen Wasserfall-Modell gearbeitet. Am Anfang stand die Erstellung eines Lastenheftes, in dem der Process-Owner idealer Weise den umzusetzenden Prozess und die dafür benötigte Funktionalität ausreichend detailliert beschrieben hat. In einem zweiten Schritt wurde durch die IT ein weiteres Konzept erstellt, in dem unter anderem die Software-Architektur und die Einbettung in die bestehende Systemlandschaft definiert wurden.

Man hat sich also eine Menge “(Be)Denk-Zeit” gelassen, bevor die erste Zeile Coding geschrieben wurde.

Mittlerweile geht es auch im SAP-Umfeld nicht mehr ohne “agil”. In diesem Artikel möchte ich einige Erfahrungen aus diesen Projekten zusammentragen. Hierbei lege ich den Fokus auf die Fehler, die hierbei gemacht werden. Das soll die Berechtigung dieser an sich guten Vorgehensmodelle (z.B. Scrum) nicht in Abrede stellen.

Warum ist agile Softwareentwicklung so beliebt?

Fachbereich

In den Fachbereichen gibt es häufig neue und gute Ideen, wie man die aktuellen Prozesse verbessern kann. Allerdings gibt es selten ausreichend Ressourcen, damit Fachbereichs-Mitarbeiter in ausreichendem Umfang an entsprechenden Umsetzungs-Projekten mitarbeiten können. Der Ausweg aus diesem Dilemma: “Wir machen das agil!”.

Damit ist die Vorstellung verbunden, dass man mit minimalem Zeitaufwand seine Projektidee umgesetzt bekommt. Man wirft die Idee bei der IT “über den Zaun”, möglichst detailarm beschrieben. Dann geht man einmal pro Woche für eine Stunde zu einem Meeting und am Ende ist die optimale Lösung fertig.

Außerdem versprechen agile Methoden schnelle Ergebnisse. Man muss also nicht, wie früher, ein halbes Jahr oder länger auf Ergebnisse warten.

IT

Warum die IT das am Ende mitmacht und sogar gut findet? Weil wir ITler tief im innersten Spielkinder sind. Wer beschäftigt sich schon gerne mit endlosen Lastenheften oder Fachkonzepten? Oder macht sich lange Gedanken über Software-Architektur, wenn es doch direkt mit der Umsetzung losgehen kann? Da fangen wir mit einem Proof of Concept an, oder wenigstens mit einem Prototyp oder einem Mock-up. Sonst kann sich ja der Fachbereich gar nicht vorstellen, wie das Ergebnis am Ende aussehen wird.

Häufige Fehler

Keine ausreichende Vorarbeit

Häufig wird keine ausreichende Vorarbeit für agile Projekte mehr geleistet, stattdessen wird schnell mit der Umsetzung begonnen.

Seitens des Fachbereiches muss zumindest definiert werden, wie der neue Prozess aussehen soll und wie er sich in bestehende Prozesse eingliedert. Darüber hinaus sollte gut beschrieben werden, welche Funktionalität benötigt wird, um den Prozess so umzusetzen.

Seitens der IT muss definiert werden, wie die Software strukturiert wird, um die angeforderte Funktionalität bereitzustellen. Das sollte zumindest auf grober Ebene ein Objektmodell (Geschäftsobjekte), eine Klassenstruktur ein Datenmodell, eine Schnittstellen-Übersicht und ggf. einen Aufbau der Dialoge enthalten.

Es sollte immer ein “Big Picture” (Generalbebauungsplan) geben. Und das möglichst nicht nur im Kopf einzelner Personen, sondern für das gesamte Team verfügbar und nachvollziehbar.

Festhalten an Prototypen

Häufig werden unter Zeitdruck und ohne ausreichendes Konzept und Struktur Prototypen oder Mock-ups gebaut. Und genauso häufig wird dafür mehr Zeit aufgewendet, als ursprünglich vorgesehen war. Daraus entsteht dann der Druck, diesen Prototypen für die folgende Entwicklung weiter zu verwenden, um dort die Zeit wieder einzusparen.

Am Ende baut damit bereits der Kern des neuen Produktes auf einem miserablen Design auf.

Fehlende Kenntnisse der Vorgehensmodelle

Häufig besteht der Wunsch, eine Softwareentwicklung “agil” umzusetzen. Allerdings hat niemand im Projekt Erfahrung mit einem entsprechenden Vorgehensmodell (z.B. Scrum) und den dazu passenden Tools (z.B. JIRA). Damit gehen dann noch die Vorteile über Bord, die ein solches Vorgehensmodell eigentlich bietet.

Wenn man einen Wechsel des Vorgehensmodells beschließt, sollten sich ausreichend viele Projektmitglieder auch mit diesem Vorgehensmodell auskennen oder sich intensiv damit beschäftigt haben.

Häufiges Ergebnis

Fachliche Anforderungen nicht umgesetzt

Häufig bleibt das Ergebnis aufgrund fehlender Anforderungen hinter dem erwarteten Ergebnis zurück. Oder der Prozess lässt sich mit der bereitgestellten Funktionalität nicht optimal abbilden.

Oft wird die Software dann in vielen Iterationen an den eigentlich erwarteten Stand angepasst. Dem Design der Software ist das nicht zuträglich und im Entwickler-Team macht sich Frust breit. Der zuvor eingesparte Aufwand wird dabei meist mehr als kompensiert.

Unwartbare Software

Normalerweise dauert es 15-25 Jahre, bis eine Software den Status “unwartbar” erreicht und dringend durch eine komplette Neuentwicklung ersetzt werden sollte. Das liegt unter anderem daran, dass Anpassungen oft unter Zeitdruck durch nicht eingearbeitete Entwickler durchgeführt werden, die das gesamte Design nicht kennen. Da ist man am Ende froh, dass die durchgeführte Anpassung irgendwie funktioniert.

Wenn die oben beschriebenen Fehler nicht konsequent vermieden werden, ist der Status “unwartbar” häufig bereits am Ende des Entwicklungsprojektes erreicht. Aber darauf liegt leider sehr selten ein Augenmerk – Hauptsache das Projekt wurde vordergründig erfolgreich umgesetzt.