Kaum ein Unternehmen, das sich nicht schon seit Jahren mit agiler Softwareentwicklung beschäftigt. Gut für die Kunden, denn agile Softwareentwicklung hat einen starken Focus auf Qualität. Bereits das agile Manifest spricht von funktionierender(!) Software und viele agile Techniken wie TDD, BDD, CI/CD, Refactoring, pair- und mob-programming … unterstützen fachliche und technische Qualität. Und das schon seit 20+ Jahren. Offensichtlich erfolglos:

In kaum einer anderen Branche wird ungeniert so schlechte Qualität produziert wie in der Informatik. In den USA beliefen sich 2022 die auf geringe Softwarequalität zurückführbaren Schäden auf ca. 15 % des GDPs. Bereits die Hälfte der Schäden machen technische Schulden aus und diese steigen Jahr für Jahr rasant an. Kommerzielle Software hat eine druchschnittliche Fehlerrate von 20–30, stabile Software sollte aber weniger als 1/10tel davon haben.
Ist die agile Softwareentwicklung schuld daran, dass eine ganze Branche immer schlechtere Qualität liefert? Wer weiß: Vielleicht führt shift-left zu einer Kultur, wo Testen weniger ernst genommen wird. Vielleicht führt CI/CD dazu, dass Reviews statt blocking einfach gar nicht gemacht werden. Vielleicht ist pair- und mob-programming kein qualitativer Ersatz für formale Reviews. Vielleicht werden aber die agilen Techniken nur einfach nicht korrekt umgesetzt?
Auf jeden Fall ist agile Softwareentwicklung per se kein Garant für den Erfolg eines Projektes. Niemand garantiert, dass mit agilen Techniken eine akzeptable Qualität geliefert wird (was ja s.o. auch offensichtlich nicht der Fall ist). Niemand garantiert, dass agile Techniken effektiver oder effizienter als früher dafür eingesetzte Techniken sind.

Und die Auftraggeber/Kunden? Müssen die mit den schlechten Ergebnissen leben? Nein, denn sie können sich mit juristischen Mitteln wehren. Fehlerfreie Software gibt es nicht, aber es gibt rechtlich haltbare Vorgaben für die Fehlerdichte. Genauso gibt es auch rechtlich haltbare Vorgaben für jede andere Eigenschaft der Software und auch die Tools, Technologien und Techniken, die bei der Erstellung der Software verwendet wurden.
Dieser Vortrag geht folgenden Fragen nach:
Wie ein Gerichtssachverständiger bei agiler Softwareentwicklung prüft, ob bei der Erstellung einer Software gepfuscht wurde.
Wie jeder selbst prüfen kann, ob man nur glaubt gut zu sein oder ob das auch tatsächlich der Fall ist.
Wie man erkennt, welche agilen Techniken man einsetzen soll und welche rechtlich problematisch sind, da sie Auftraggeber/Kunden benachteiligen.
Und ob das alles nicht nur im rechtlichen, oder auch im wirtschaftlichen Interesse des Auftragnehmers ist.
Und auch woran es liegt, dass Entwickler und Hersteller der geprüften Software schlussendlich oft froh sind, dass ein Sachverständiger Fehler gefunden hat.