Scrum sagt, produziere potenziell auslieferbare Software in jedem Sprint, Kanban hat als Prinzip „Fokussiere Dich auf hohe Qualität„.
Leicht erkennbar ist, dass agile Methoden Anforderungen an die zu produzierende Qualität einer Software treffen. Was bedeutet dies nun in der konkreten Anwendung im Unternehmen?
In der perfekten agilen Welt liefern wir einen kontinuierlichen Fluss von Funktionalitäten aus: Auf der Ebene einer jeden Story ist diese getestet auf ihre Qualität und im Kontext des Gesamtsystems validiert, im Extremfall nicht nur auf den Test- sondern auch auf den Produktivserver verteilt.
Um soetwas tun zu können, müssen wir in der Lage sein, mit geringem Aufwand zu prüfen, ob eine User Story funktioniert und die Erstellung der Story eine Auswirkung auf einen anderen Teil des Systems hatte. Schließlich wollen wir ja keine neuen Defekte hinzufügen, weil neue Funktionen hinzukommen. Mittlerweile gibt es ja eine ganze Hand voll Best Practices in diesem Bereich. Specification By Example, TDD, Integrations- und Unittests oder Konfigurationsmanagementtools sind einige von Ihnen.
Schaffen wir es, den Automatisationsgrad von Tests und Deployment so weit zu bringen, dass es im Sprint möglich ist, die Qualität zu sichern, die wir gerne hätten, haben wir Feedback dann zur Hand, wenn es am wichtigsten ist: Kurz nach der Produktion, wenn Entwickler noch wissen, wo der Defekt zu finden ist oder wie das Feature leicht zu modifizieren ist, damit es das tut, was der Kunde wirklich will. Denn wir wollen Fehler beheben, statt sie zu verwalten.
Abhängig von den Fähigkeiten im Team, den bisher verwendeten Tools, der Testbarkeit des Codes und der eigenen Disziplin ist die Erreichbarkeit solch einer Qualitätskontrolle für das eine Unternehmen eine überschaubare Strecke, für das andere ein Ultramarathon, der schnell als unmöglich schaffbar bezeichnet wird.
Ein befreundeter Agile Coach, der aus Leidenschaft extrem lange Strecken läuft, hat mir einmal erzählt, wie man eine 116km-Strecke angeht:
Viel Training, die Vorstellung des nächsten kleinen Abschnitts statt der ganzen Riesenstrecke im Kopf und: man sollte Lust darauf haben.
Wenn ihr Team sich gerne die Finger schmutzig macht, versuchen Sie es mit kleinen kontinuierlichen Schritten: Erweitern Sie die Definition of Done regelmäßig in der Form, dass mehr Aspekte auf Story- und Sprintebene fertiggestellt werden und weniger je Release. Das wird vielleicht zeitweilig anstrengend sein, aber Schritt für Schritt gelingt so auch der lange Lauf – wenn man darauf Lust hat.
While participating at a team development seminar provided by