Eine hohe Produktqualität ist Dreh- und Angelpunkt von Scrum. Der Massstab von Produktqualität in Scrum ist die „Definition of Done (DoD)“.
Diese macht transparent, welche Charakteristiken das Produkt aufweisen muss, damit es in einem releasefähigen zustand ist. Das Ziel in Scrum ist, spätestens am Ende eines Sprints über einen solchen releasefähigen Produktinkrement zu verfügen, welcher der entsprechenden DoD genügt. Ohne releasefähigen Inkrement besteht keine Transparenz über den Fortschritt der Produktentwicklung. Diese Transparenz ist jedoch essentiell wichtige Grundlage für empirische Prozesskontrolle.
Häufig wird eine DoD für eine gesamte Entwicklungsorganisation definiert. So wird gewährleistet, dass in der ganzen Organisation die gleichen Qualitätsmassstäbe gelten, was die Zusammenarbeit der Teams signifikant vereinfacht. Beispielsweise kann sich ein Team, das auf eine Schnittstelle aus einem anderen Team angewiesen ist, darauf verlassen, dass diese Schnittstelle ein gewisses Set von Tests durchlaufen hat und somit die Produktqualität als Ganzes nicht aufs Spiel setzt.
Besteht keine DoD oder ist diese nicht transparent, besteht grosse Unsicherheit über die Qualität der Schnittstelle, bspw.:
- Reagiert die Schnittstelle auch unter (definierter) Last performant genug?
- Hält die Schnittstelle Regeln zur Datensicherheit ein?
- Geschieht ein korrektes Logging?
- etc.
Eine DoD einer ganzen Organisation kann durchaus von gewissen Teams um weitere Punkte ergänzt werden. Allenfalls werden diese Ergänzungen später in die allgemeine DoD aufgenommen.
Anpassung der Definition of Done
Mögliche Erweiterungen/Anpassungen an der Definition of Done werden vom Scrum Team in der Sprint Retrospektive besprochen. Dabei bringen alle Rollen des Scrum Teams ihre Perspektive mit ein: Das gesamte Scrum Team ist für die Produktqualität verantwortlich!
Während das Development Team eher die technische Qualität gewährleistet („doing things right“), ordnet der Product Owner das Backlog nach Priorität („doing the right thing“) und unterstützt der Scrum Master beide Rollen darin, die Wichtigkeit von Qualität zu verstehen und diese Qualität im Rahmen des Scrum Frameworks zu erreichen.
Beispielsweise würde ein PO, der dem Abbau von technischen Schulden oder dem Aufbau von automatisiertem Testing keine entsprechende Priorität einräumt, die Produktqualität aufs Spiel setzen. Hier kann ein Scrum Master unterstützen, das Verständnis für dieses Risiko zu erlangen.
Fazit
Regelmässig spätestens am Ende eines Sprints über einen releasefähigen Produktinkrement zu verfügen, erscheint zu Beginn für ein Scrum Team sehr ambitioniert. Dieses Ziel zu verfolgen zeigt einem Team jedoch sehr klar auf, was die Agilität des Teams behindert und welche Hindernisse aus dem Weg geräumt werden müssen. Der Scrum Master unterstützt das Team gegebenenfalls darin.
Letztlich wird der Wert eines Produktes erst mit einem Release generiert. Ohne Release fehlt die Validierung durch den Markt und besteht somit ein (grosses) Risiko, dass das Produkt nicht den erhofften Wert für Kunden und Unternehmen generiert.
Verfügt euer Team über eine Definition of Done? Wiederspiegelt eure DoD die Releasefähigkeit eures Produkts?
Interessiert daran, euer Team in solchen Fragen besser unterstützen zu können? Jetzt für den nächsten Scrum Master-Kurs anmelden