Oft wird versucht, diesem Thema durch die Metapher der technischen Schulden in Scrum Sichtbarkeit und Verständnis zu geben, das halte ich aber für unpassend.
In dieser Folge spreche ich darüber,
- warum es so wichtig ist, ein gemeinsames Verständnis für das richtige Maß an Qualität zu haben.
- warum ich den Begriff der technischen Schuld dafür als nicht zielführend empfinde.
- warum wir uns schwertun, das richtige Level an Qualität zu definieren.
- und wie wir aus dem Dialog im Sprint Review unser gemeinsames Verständnis schärfen können.
Ich wünsche dir jetzt viel Spaß beim zuhören 🙂
Der ein oder andere mag sich wundern, warum wir in dieser Folge nicht direkt über das Thema technische Schuld sprechen. Die einfache Antwort ist: Ich halte den Begriff für unglücklich gewählt und nicht zielführend.
Was sind technische Schulden?
Unter der technischen Schuld versteht man den zusätzlichen Aufwand, den man für Änderungen und Erweiterungen an schlecht geschriebener Software im Vergleich zu gut geschriebener Software einplanen muss.
Das ist eine sehr gelungene bildliche Beschreibung eines Problems, was wir haben. Wir sollten aber eine gelungene Beschreibung eines Problems nicht mit dessen Lösung verwechseln.
Auch wenn dieser Begriff inzwischen sogar einen Wikipedia-Artikel hat und auch Leute aus dem Umfeld nicken, wenn man das Problem auf Basis dieser Metapher darstellt, heißt es noch lange nicht, dass wir so der Lösung näher kommen.
Das Problem selbst: Was ist das richtige Level an Qualität?
Wir sagen in Scrum, dass die Entwickler verantwortlich dafür sind, Qualität zu liefern. Dies funktioniert aber nicht, wenn eigentlich keiner weiß, was das richtige Level an Qualität überhaupt ist.
Swatch wäre mit einer Rolex-Qualität Pleite und andersherum auch. Deswegen wäre es so wichtig zu wissen, welches Level an Qualität wir eigentlich haben und dazu passende nachhaltige Lösungen zu entwickeln.
Aus dem gemeinsamen Verständnis, wie sehr wartbar, performant, leicht zu benutzen unser Produkt idealerweise sein sollte, könnte dann unser Scrum Team eine klare Orientierung in Richtung Nachhaltigkeit, aber eben auch zweckgebundene Ausgestaltung unserer Produktes ziehen. Wir wären in der Lage die Konsequenzen aufzuzeigen, wenn wir an den richtigen Stellen nicht investieren und so eben auch die Stakeholder bei diesem schwierigen Thema abholen.
Genau dieses Verständnis fehlt aber den meisten Scrum Umgebungen und ist der der eigentliche Elephant im Raum.
Das Sprint Review ist die Plattform, in der das Gespräch zum richtigen Level an Qualität stattfinden sollte
In kaum einer Umgebung findet ein wirklicher Dialog statt, um das richtige Level an Qualität zu definieren. Wir tun uns schwer zu nennen was Qualität ist und sprechen auch nicht wirklich drüber. Was zu dem im vorherigen Abschnitt dargestellten Problem führt.
Das Sprint Review ist das Scrum Event in dem wir idealerweise diesen Dialog und Diskurs zur Qualität integrieren sollten.
