Wer ist eigentlich verantwortlich für die Produktqualität?
Ich bekomme relativ häufig mit, dass die Frage nach Verantwortlichkeiten in Scrum Teams gestellt wird. Relativ schnell kommen dann Antworten, die sich auf Tätigkeiten beziehen und damit die einzelnen Rollen sehr stark reduzieren. Ich möchte hier die Betrachtung einer möglichen Antwort von den Tätigkeiten absehen und die Verantwortung aus Qualitätssicht betrachten.
Also: wer ist denn nun verantwortlich?
Der Product Owner – so heißt es vieler Orts. Das ist so aber nicht ganz korrekt. Produktqualität hat mehrere Aspekte und die Rolle des Product Owners ist nur für einen davon verantwortlich. Ich unterscheide zwischen drei Qualitätsaspekten, die sich auf die drei Scrumrollen abbilden lassen. Diese drei Qualitätsaspekten bilden zusammen genommen die Produktqualität und damit ist die Beantwortung der Frage, wer für die Produktqualität verantwortlich ist, klar: das Scrum Team. Keine Rolle allein. Aber was sind die drei unterschiedlichen Qualitätsaspekte, die ich oben angesprochen habe?
Aspekt #01: Äußere Qualität
Die äußere Qualität definiert, wie ein Produkt erfühl- und erlebbar ist. Damit ist es zum sehr großen Teil verantwortlich für die Akzeptanz des Produkts am Markt und somit für den Produkterfolg. Und genau hier gibt es in Scrum auch eine Rolle, die sich dafür verantwortlich fühlt: der Product Owner.
Um die äußere Qualität zu definieren, bedient sich der Product Owner mehrer Werkzeuge. Zum einen sind es auf Nutzer konzentrierte Product Backlog Einträge, die in vielen Fällen in Form von User Stories vorliegen. Dazu kommt die Verwendung von Akzeptanzkriterien, die aus Sicht des Nutzers des zu entwickelnden Systems formuliert sind. Der Product Owner formuliert hier keine technischen Umsetzungsanweisungen.
Aspekt #02: Innere Qualität
Im Kontrast zur äußeren Qualität eines Produkts steht das, was ich als innere Qualität bezeichne. Darunter verstehe ich alles, was dazu dient, die Product Backlog Einträge zum “Leben” zu erwecken, also das Überführen von Theorie in Praxis. Auch dazu gibt es eine Rolle in Scrum: das Development Team. Häufig wird das als reines Softwareentwicklungsteam und damit als ein Haufen von ProgrammierInnen gesehen. Das ist aber nicht ganz korrekt. Es handelt sich bei dem Development Team vielmehr um ein Product Development Team, das alle Kompetenzen beinhalten muss, um am Ende eines Sprints ein Produktinkrement zu haben, das potentiell ausgeliefert werden kann. Darum gehören in das Development Team ganz unterschiedliche Kompetenzen wie z.B. Entwickler, Qualitätssicherer, Designer, User Experience Experten, Operations, Security etc. Nun kann man argumentieren, dass ja UX und UI eher zur äußeren als zur inneren Qualität beitragen. Das stimmt auch. Wenn man Scrum jedoch konsequent weiter denkt, dann spricht ja nichts dagegen, dass aus dem Development Team Kompetenz kommt, die eng mit dem Product Owner zusammenarbeitet. So etwas ist sogar eher wünschenswert.
Aspekt #03: Kollaborative Qualität
Und damit bin ich auch schon beim Punkt: Zusammenarbeit. Diese will gelernt sein und Scrum ist ein Kollaborationsframework, dass die Rollen, Artefakten, Events usw. definiert hat, um Kollaboration zu fördern (und zu fordern). Der Scrum-Guide beschreibt an sich das, was nötig ist, um ein eher “unreifes” Team (im Sinne von agilem Mindset) sich hin zu einem “reifen” Team entwickeln zu lassen. Es geht also um das Schaffen von Umgebungen, die das Lernen unterstützen, wo Selbstorganisation und Übernahme von Verantwortung kein Problem ist. Und auch hier gibt es eine Rollen in Scrum, die dafür verantwortlich ist: den Scrum Master.
Fazit
Wenn man also die Frage nach Verantwortlichkeiten klären möchte, habe ich hier eine Betrachtungsweise dargestellt:
- Der Product Owner ist verantwortlich für die äußere Qualität.
- Das Development Team ist verantwortlich für die innere Qualität.
- Der Scrum Master ist verantwortlich für die kollaborative Qualität.
- Das Scrum Team und damit alle drei Rollen sind gemeinsam für die Produktqualität verantwortlich.
Letztendlich gilt, dass in Scrum etwas konsequent weitergedacht wird, dass man in eXtreme Programming als “Collective Code-Ownership” bezeichnet hat. Nur das wir in Scrum das auf das Produkt ausdehnen und damit ganz allgemein von “Collective Ownership” sprechen. Und jede Rolle kümmert sich um die entsprechende Perspektive und unterstützt die anderen Rollen in den ihren.
