Die Ursprünge von Agile

Auch wenn Ihr Entwicklungsteam noch nicht zu agilen Methoden wie Scrum oder Extreme Programming übergegangen ist, ist es doch sehr wahrscheinlich, dass sie es zumindest in Erwägung ziehen. “Agile” nimmt tatsächlich einige der größten Probleme in Angriff, von denen Softwareteams schon seit Jahrzehnten geplagt werden. Viele Produktmanager, Designer und auch Leute aus der Qualitätssicherung sind jedoch erst einmal von Agile irritiert, weil sie noch nicht wirklich mit ihren Rollen bei den agilen Methoden vertraut sind. Diese Methoden erfordern auf jeden Fall diese Rollen, aber die Verwirrung schreibe ich den Ursprüngen der agilen Methoden zu. Um die Probleme zu beleuchten, die “Agile” lösen soll, und um herauszufinden, welche Herausforderungen weiterhin bestehen, ist es hilfreich, wenn ich die Ursprünge von Agile erkläre.

Viele Leute sind verwundert, wenn sie erfahren, wie lange es Scrum – die bekannteste agile Methode – schon gibt. Sie entstand 1986 in Japan. (Ein Beispiel dafür, wie lange es dauern kann, bis eine neue Idee endlich den Durchbruch schafft.)

Die Ursprünge von Agile liegen in der Individualsoftware

Am wichtigsten ist jedoch, dass diese Methoden aus der Welt der Individualsoftware (Custom Software) stammen.

Individualsoftware, also Software für einen bestimmten Zweck und für einen bestimmten Kunden zu entwickeln, war lange Zeit eine extrem schwierige Art der Softwareentwicklung. Zum Teil liegt das daran, dass Kunden bekannterweise nicht wissen, was sie genau wollen. Sie haben allerdings den Bedarf für etwas und so unterschreiben sie einen Vertrag mit einem Unternehmen für Individualsoftware oder setzen sich mit ihren internen IT-Leuten zusammen, die dann daran arbeiten sollen. Wenn dann aber etwas geliefert wird, sagen die Kunden grundsätzlich, dass das nicht das ist, was sie wollten und alles geht von vorne los, wobei die Frustration natürlich immer größer wird. Der grundsätzliche Bedarf besteht jedoch weiterhin und das hat unzähligen Softwareentwicklern, Unternehmen und Dienstleistern den Job gesichert.

Außerdem hat man bei der Entwicklung von Individualsoftware oft lange Zeit den Kürzeren gezogen, wenn es darum ging, Leute einzustellen und sich die besten Softwaretalente zu sichern. Das liegt wohl zum Teil daran, dass die Profis lieber in Firmen arbeiten, die Software für Tausende oder sogar Millionen von Kunden entwickeln. Der Grund dafür ist unter anderem, dass die Profis bei den Firmen eine höhere Bezahlung erhalten, bei denen das Produktteam Softwareprodukte entwickeln soll, die viele Menschen haben wollen, weil sie sonst kein Geld verdienen. Diese Firmen wissen, dass sie gute Leute einstellen müssen, um erfolgreiche Produkte zu schaffen und dementsprechend sieht natürlich auch die Bezahlung aus. Allerdings arbeitet nur ein geringer Prozentsatz von Softwareentwicklern an Standardsoftware, die meisten entwickeln Individualsoftware.

Der Vorteil von Agile?

Da der Kunde im Falle von Individualsoftware davon ausgeht, zu wissen, was er will, findet man dort nur selten die Rolle des Produktmanagers. Ebenso findet man so gut wie nie User Experience Designer. Die Gründe dafür sind recht komplex und beinhalten ein gewisses Maß an Unwissenheit (die wenigsten in der Welt der Individualsoftware wissen, was UX Designer tun und wofür man sie braucht) und Kostensensibilität (Kosten reduzieren, indem man die Entwickler das Design machen lässt). Gerechterweise muss man sagen, dass die wenigen Designer, die es in unserer Branche gibt, sofort von den Produktunternehmen weggeschnappt werden, die verstanden haben, wie wichtig die Designer sind. Daher bleiben für Teams, die Individualsoftware entwickeln, kaum noch Designer übrig, wenn die Führungskräfte endlich begriffen haben, dass sie sie brauchen. Genauso gibt es kaum Qualitätssicherung als eigene Disziplin bei Individualsoftware und so wird von den Entwicklern erwartet, dass sie auch das Testen übernehmen.

Ein weiterer wichtiger Punkt, um die Welt der Individualsoftware zu verstehen, ist, dass die meisten Projekte für Individualsoftware relativ klein sind und die internen Tätigkeiten eines Unternehmens unterstützen sollen – z. B. die Personalabteilung, Abrechnungen, Produktion usw. Also alles Bereiche, in denen es nur eine begrenzte Anzahl von Nutzern gibt und Dinge wie Skalierbarkeit und Leistungsfähigkeit normalerweise nicht ganz so wichtig sind.

Der Wasserfallprozess

Früher benötigte man bei der Individualsoftware den Wasserfallprozess, weil die verschiedenen Stakeholder eine Möglichkeit brauchten, um den Fortschritt während des langen Entwicklungsprozesses der gewünschten Anwendungen verfolgen zu können. Genau genommen hat auch die Wasserfallmethode hier ihren Ursprung.

Bei der Standardsoftware, die wegen ihrer Leistung und ihrer Vorzüge gekauft wird, wurden einige Rollen eingeführt. Der Produktmanager soll die Bedürfnisse aller Kunden sammeln und repräsentieren. Designer sollen nutzbare und begehrenswerte User Experience schaffen und die Tester aus der Qualitätssicherung sollen überprüfen, ob die Software auch so funktioniert, wie es dem Kunden in der Werbung versprochen wurde.

Die Lösung der Wasserfallprobleme kam mit agilen Methoden

Bei der Individualsoftware kamen jedoch weiterhin die gleichen Probleme auf, wenn es darum ging, etwas zu erschaffen, das den Kunden zufriedenstellt. Besonders für diese Teams bedeuten die agilen Methoden eine starke Verbesserung. Die Kommunikation zwischen Kunden und Entwicklern verbessert sich. Das Risiko wird durch kleinere und häufigere Iterationen erheblich gesenkt. Die Kunden können so viel schneller herausfinden, ob sie etwas gut finden, als wenn sie weiterhin auf das Ende eines langen Prozesses warten müssten. Außerdem helfen die agilen Methoden dabei, moderne Konzepte zum Testen von Software einzuführen und den Teams das stundenlange Erstellen von Dokumenten zu ersparen, die sowieso kaum gelesen werden und schnell nicht mehr aktuell sind.

Agile für Individual- & Standardsoftware

Grundsätzlich treffen diese Vorteile natürlich auch auf Standardsoftware zu, aber ich betone immer, dass dann einige Dinge angepasst werden müssen. Ein weiterer Bereich, in dem es Schwierigkeiten gab, ist die Softwarearchitektur bzw. das Softwaredesign.

Die agilen Methoden bestärken die Entwickler darin, sich nicht zu sehr auf ihre Art der Umsetzung zu versteifen, denn alles soll schnell und einfach überarbeitet oder umgestellt werden können. Auch wenn das bei Individualsoftware häufig gut funktioniert, ist diese Vorgehensweise beispielsweise für große Internet-Dienste, die Hunderte, Tausende oder Millionen von Nutzern haben, zu naiv.

Es ist also keine Überraschung, dass viele Teams für Standardsoftware Probleme mit den agilen Methoden hatten, weil die Ursprünge agiler Methoden bei der Individualsoftware zu finden sind. Die vielen Bücher, Artikel und Kurse, die weder Produktmanager noch User Experience Designer (Interaction Designer und Visual Designer) erwähnen, sind nicht für die Entwicklung von Standardsoftware gedacht.

Teams, die zu agilen Methoden in der Softwareentwicklung wechseln wollen, sollten also vorab überprüfen, ob das Unternehmen, das ihrer Organisation helfen soll, auch versteht, was für Standardsoftware erforderlich ist. Das ist nicht immer der Fall, aber oft genug.