3 Schritte vor und 5 zurück? Wie Qualität uns schneller macht

Führt man Qualitätsmaßnahmen wie TDD, Pair Programming und generell agile Praktiken in Entwicklungsteams ein, wird oft befürchtet, man werde langsamer. Zusätzlich zu der „eigentlichen Aufgabe“ müsse man nun noch Tests schreiben, Reviews durchführen und dann auch noch so viele Meetings …

Dies scheint intuitiv Sinn zu ergeben: Bessere Qualität muss eben teuer erkauft werden. Die Management-Zahlen scheinen diesen Verdacht dann auch noch zu bestätigen: „Wo wir vorher acht Tickets geschafft haben, schaffen wir nun nur noch fünf!“

Dabei werden meine Kolleg*innen und ich nicht müde zu betonen, dass die Steigerung der Qualität dazu führt, dass Teams *schneller* werden. Wie passt das mit den vermeintlichen Fakten zusammen?

Schaut man sich an, was ein Team qualitativ macht, stellt man fest, dass es sich eigentlich „rückwärts bewegt“:

Mit jedem Feature erzeugen sie neue Bugs und Code Smells oder arbeiten an den eigentlichen Anforderungen der Kund*innen vorbei. Die Arbeit für die nächsten Wochen beschafft man sich so selbst. Man hat immer etwas zu tun, schafft vermeintlich viel, kommt aber eigentlich nicht voran.

Deshalb zielt z. B. Scrum darauf ab, dass Teams effektiv zusammenarbeiten und wertvolle Features ausliefern, statt möglichst viel abzuarbeiten. Es gilt, die „Menge nicht getaner Arbeit“ zu maximieren und gezielt das umzusetzen, was wirklich Wert schafft. Aus diesem Blickwinkel ist das Team nach Einführung der Maßnahmen deutlich besser aufgestellt:

Es gibt vielfältige praktische Ausprägungen dieser Rückwärtsbewegung:

• Bugs
• unnötige Features
• unnötige Prozessschritte
• Missverständnisse
• Operative Notfälle
• …

In der Regel fallen mehrere Faktoren zusammen. Ich möchte zur Verdeutlichung ein konkretes Beispiel bringen: Ein Team wendet 50 % seiner Zeit zum Bugfixing auf und schafft in einer Woche zehn Tickets, also fünf Bugfixes und fünf Features. Innerhalb der gleichen Zeit entstehen acht neue Bugs. Hier läuft also etwas grundsätzlich falsch, obwohl das Team oberflächlich betrachtet mit der Geschwindigkeit von zehn Tickets sogar zufrieden ist und 50 % „Bugzeit“ suggerieren, dass man in Qualität investiert.

Nur auf die Auslastung der einzelnen Teammitglieder und die Menge getaner Arbeit zu schauen, ist also keine sinnvolle Metrik. Wichtig ist, dass sich Teams gezielt in die richtige Richtung bewegen und dabei hochwertige, nützliche Software an den Start bringen.