Wie Scrum die Softwarequalität erhöht und warum der ScrumMaster selten Quellcode liest

Wenn man Scrum erklärt, biegt bei vielen Beschreibungen irgendwann das magische Projektmanagementviereck um die Ecke. Während bei Projekten generell die vier Eckpfeiler Kosten, Funktionsumfang, Zeit und Qualität zur Disposition stehen, sagt Scrum von sich selbst, das Qualität keine verhandelbare Option ist. Unter Projektdruck ist es nicht ungewöhnlich, dass Refactorings unter den Tisch fallen, Dokumentationen weggelassen und Umbauten vermieden werden. Hier sagt diese agile Methode, dass dies nicht passieren darf, um auch langfristig Wert zu schaffen.

Wer korrekt nach Scrum produziert, baut also keine schlechte Software mehr? So einfach ist es natürlich nicht. Hier lohnt es sich, einmal genauer hinzusehen: Wie kann ein solches Framework technische Qualität sicherstellen? Ist ein ScrumMaster ein getarnter Tester, der heimlich beim Abnahmemeeting für den fachlich Verantwortlichen in den Quelltext schaut, ein Code Review macht und mit einem dezenten Lächeln oder mürrigem Dreinblicken dem Product Owner heimlich mitteilt, wie das Team gearbeitet hat?

Guckt man in die Literatur, so hat der ScrumMaster erstmal die Verantwortung für die Prozessqualität. Von technischen Fähigkeiten oder gar Quellcodelesen steht da nichts. Wie kann also durch eine hohe Prozessqualität eine hohe Softwarequalität erreicht werden? Klare Sache: Die Antwort muss in den Prozessbestandteilen zu finden sein.

Bestandteil 1: Potentiell auslieferbare Produkt- / Projektinkremente
Nach dem Ende einer Iteration (also in der Regel nach zwei oder vier Wochen) hat ein Scrum Team eine potenziell auslieferbare Software produziert. Was bedeutet das? Der Anspruch ist hier: Auf CD brennbar, ausrollbar, verkaufbar… Alles, was die Software betrifft, muss erledigt sein. Der ScrumMaster bestärkt den Product Owner darin, Unfertiges abzulehnen und zur Nacharbeit zu geben.

Die “offensichtliche Ware” ist also sauber. Wie sieht es nun mit dem Innenleben aus?
Hier hängt es maßgeblich vom Team und seiner Erfahrung ab, inwieweit Refactorings durchgeführt wurden, Quellcode bereinigt ist, Module getestet sind. Um so weniger technisches Qualitätsbewußtsein im Team vorherrscht, umso weniger Qualität wird ein Team liefern.

Ist es Aufgabe vom ScrumMaster, sein Team zu mehr technischer Qualität zu bewegen? Jein.  “Technische Schulden”, versäumte Refactorings, schlechte Architekturen  – sie werden durch Scrum sichtbar. Die Geschwindigkeit des Teams wird zum Beispiel geringer, einfache Features liefern riesige Schätzwerte, der Burndowngraph stagniert, am Iterationsende wird nicht geliefert.

Die Aufgabe des ScrumMasters ist es dann, dem Team zum Erkenntnisgewinn zu verhelfen und es darin zu unterstützen, besser zu werden. Findet das Team dann eine gute technische Lösung und die richtigen Maßnahmen? Wir vertrauen ihm und bitten es um Ideen, verfolgen die Umsetzung.

Bestandteil 2: Regelmäßige Auslieferung
Wer verteilte Systeme, interagierende Komponenten, unterschiedliche Bestandteile konstruiert, muss diese irgendwann integrieren und testen.  Hier können viele Probleme im Detail liegen. Um so häufiger hier eine Integration durchgeführt wird, um so sicherer kann das Team sein: Das läuft in der Praxis.

Bestandteil 3: Kanalisierte Kommunikation
Scrum definiert Kommunikationswege und Besprechungen, bringt Ideen für Artefakte mit, die helfen sollen, Anforderungen zu transportieren. Wenn Entwickler keinen Zugang zu weiteren Informationen einer Problemstellung haben, bleibt ihnen häufig nichts anderes übrig, als Annahmen zu treffen.

Scrum minimiert die Anzahl getroffener Annahmen auf ein Minimum, indem es die Kommunikation zwischen Product Owner und Team forciert. Geht man davon aus, dass intensivere Kommunikation eher zu dem gewünschten Produkt führt als ratende Entwickler, erhöht Scrum auch hier die Qualität.

Unbestandteil:  Automatisiertes Testen, kontinuierliche Integration
Scrum schreibt keine technischen Praktiken vor. Das viele der agilen Praktiken aus Extreme Programming eine sinnvolle Ergänzung sind, ist mittlerweile klar. Aber wer bringt nun dem Team TDD, kontinuierliche Integration, Collective Code Ownership und Buildmanagement bei?

Der ScrumMaster ist hiermit zu Recht in der Regel überfordert. Kann er das wissen vermitteln: Prima. Ansonsten kann zum Beispiel auch ein externer Coach mit einem starken Entwicklungshintergrund dazugezogen werden.

Fazit: Scrum sichert Softwarequalität durch seine Prozesselemente. Wie es dem Innenleben einer Software geht, wird nicht durchleuchtet. Die entstehenden Graphen zum Projektfortschritt spiegeln jedoch diese Qualität wieder. Der Rest ist Vertrauen in die Mannschaft. Wünscht das Team bei gewählten Maßnahmen Unterstützung, gibt es viele Lernarten, wie zum Beispiel die Study Group oder ein externer Coach.