Das dritte Prinzip des Agilen Manifests lautet: „Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“
Mit Continuous Integration/Delivery als Idealbild kommen wir so zu einem Zustand, in dem für Integrationen oder Deployment keine zusätzliche Arbeit mehr entsteht. Damit muss man auch keinen Extra-Aufwand dafür einplanen. Und wie David Anderson in „Kanban“ schreibt, erlangt man mit qualitativ hochwertiger Software Vertrauen, wenn sie früh ausgeliefert wird. Auch wenn sie nur kleine Fortschritte enthält, wichtig sind Qualität und regelmäßige Auslieferung. Dieses Vertrauen ist politisches Kapital, das man für die Firmenziele einsetzen kann, indem man den Prozess weiter verbessert, bis er den Ansprüchen genügt.
Wenn Software ausgeliefert wurde, heißt das aber auch, dass auf einmal ein neuer Stakeholder im Boot ist, möglicherweise der anspruchsvollste überhaupt: Der User. Fehler, die ein User meldet, haben oft eine höhere Priorität, da nicht nur die Softwarefunktion sondern auch das Ansehen davon abhängen. Die Priorisierung wird dadurch unwägbarer. Dennoch ist es wohl besser, die von Benutzern bemerkten Fehler frühzeitig und ebenso stetig gemeldet zu bekommen, als nach dem Big Bang-Release alle auf einmal auf dem Tisch zu haben.
Meldet ein User einen Fehler, ist das ein sicheres Zeichen dafür, dass die Software produktiv genutzt wird. Und produktiv genutzte Software ist nicht mehr in der Entwicklung, sondern bereits in der Wartung. Somit dürfen wir schlussfolgern, dass agile Softwareentwicklung darauf abzielt, möglichst schnell vom bisher als solchen bekannten Entwicklungsstadium in die Wartung überzugehen. Oder anders ausgedrückt: Nach der ersten Auslieferung findet in der agilen Softwareetwicklung Software Maintenance statt. Das gilt auch dann (bei Betrachtung eines anderen Geschäftsmodells), wenn die Auslieferung an einen Kunden „nur“ zu QS-Zwecken geschieht, und er die Software noch nicht produktiv nutzt. In dem Fall nimmt der Kunde die Rolle des Benutzers ein, das Resultat bleibt das gleiche: Es testet jemand, der das Produkt vorher noch nicht in der Hand hatte, und der findet üblicherweise auch andere Fehler, die anders priorisiert werden. Aus der Perspektive dessen, der die Maintenance übernimmt, ist das Produkt damit beim Kunden und muss gewartet werden.
Eine Einschränkung müssen wir dabei machen: Für Maintenance (oder Wartung) darf nicht die von Bommer, Spindler und Barr gewählte Definition gelten, bei der die Weiterentwicklung explizit ausgeschlossen wird. Das in deren Buch vorgeschlagene Prozessmodell scheint mir also auf den ersten Blick der agilen Entwicklung entgegenzustehen. Ist die Weiterentwicklung jedoch Teil der Maintenance, wird offensichtlich, warum Maintenance und agile Entwicklung sich so gut vertragen.