Qualitätssicherung in agilen Methoden

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.

Agile goes Europe

While participating at a team development seminar provided by boris gloger in Munich I had the chance to join the just founded Munich Agile & Lean Network group. The idea of an agile and lean network with an european focus was spreaded by Jurgen Appelo who I met at his great Management 3.0 seminar in Hamburg earlier this year. As I am half dutch I appreciate his experience and connection to the community in the Netherlands pushing forward some new ideas for the agile community and so I decided to support his initiative and join this meeting.

At least 15 people met yesterday at a bar in Munich to find out in which ways we can interact and contribute to this network. Ilker, Christian and Wolfgang hosted the session and opened up a world café based on three items:

  • Connect Global
  • Stay Local
  • Call to action

So we discussed which elements were great to share with other european agile communities and how our local engagement could look like. The hosts will deliver and forward our content to our german ambassdor who will take Germanys contribution to the XP Days 2011 in Madrid.

To give a sneak peak on some ideas which I favored most:

  • Agile Couchsurfing
  • European ScrumMaster Exchange
  • Connecting to local communities of practice

I am looking forward to other countries and cities contributions. If you want to participate have a look at Jurgens blog for detailed information.