Die ehrliche Antwort auf diese Frage ist verteilter und als griffiger Satz weniger befriedigend, als es sich die meisten Organisationen wünschen. Scrums Accountability-Struktur verteilt Leistungsverantwortung über das gesamte Team auf eine Weise, die sich gegen den Instinkt sträubt, einen einzelnen Verantwortlichen zu benennen, und zu verstehen, warum, klärt viel Verwirrung, die entsteht, wenn Leistungsprobleme tatsächlich auftauchen.
Warum es keine einzelne Antwort gibt
Die drei Accountabilities des Scrum Guide sind jeweils für eine andere Dimension der Leistung verantwortlich. Die Developer sind verantwortlich für technische Qualität und Fertigstellung der Arbeit: ob das Gebaute tatsächlich die Definition of Done erfüllt. Die Product-Owner-Person ist verantwortlich für Wert: ob das Team an den richtigen Dingen in der richtigen Reihenfolge arbeitet, um zu maximieren, was das Produkt liefert. Der Scrum Master ist verantwortlich für Wirksamkeit: ob Praktiken, Umgebung und organisatorischer Kontext des Teams ihm überhaupt erlauben, gut zu performen.
Ein Team kann in einer dieser Dimensionen scheitern, während es in den anderen erfolgreich ist: technisch exzellente Arbeit in falscher Prioritätsreihenfolge gebaut (eine Lücke bei der Product-Owner-Accountability), oder die richtigen Prioritäten durch einen dysfunktionalen Prozess verfolgt, der das Team ausbrennt (eine Lücke bei der Scrum-Master-Accountability), oder gute Prioritäten und guter Prozess durch inkonsistente technische Qualität untergraben (eine Lücke bei der Developer-Accountability).
Warum Organisationen trotzdem nach einem einzelnen Namen suchen
Traditionelle Managementstrukturen sind um individuelle Accountability herum aufgebaut (eine Führungskraft besitzt den Output eines Teams, Punkt), und es ist ein natürlicher Instinkt, das Scrum-Äquivalent zu suchen. Der Instinkt ist verständlich, und das Framework funktioniert genuin nicht so, was echte Reibung in Organisationen erzeugt, die sich von einer traditionellen Struktur wandeln, in denen Stakeholder immer wieder fragen "wen kann ich verantwortlich machen", und die ehrliche Antwort mehr Erklärung erfordert, als sie oft suchen.
Wie Leistungsgespräche tatsächlich aussehen sollten
Ein Leistungsproblem gut zu diagnostizieren, bedeutet zu identifizieren, welche der drei Dimensionen tatsächlich das Problem ist, bevor irgendeine Art von Eigentümerschaft für die Behebung zugewiesen wird. Ein Team, das konsequent seine Sprint Goals verfehlt, könnte ein Product-Owner-Problem haben (schlecht definierte Ziele, unklare Prioritäten), ein Scrum-Master-Problem (unadressierte Hindernisse, dysfunktionale Teamdynamik), oder ein Developer-Problem (Kompetenzlücken, unrealistische Selbsteinschätzung der Kapazität), und die Lösung sieht je nachdem völlig unterschiedlich aus.
Organisationen, die diese Diagnose überspringen und einfach "das Team" kollektiv für jedes Leistungsproblem verantwortlich machen, unabhängig von seiner tatsächlichen Quelle, wenden tendenziell öfter die falsche Intervention an: Developer zu Schätzung zu coachen, wenn das eigentliche Problem eine Product-Owner-Person mit unrealistischen Erwartungen ist, behebt beispielsweise nichts, weil es die falsche Accountability für die tatsächliche Lücke adressiert.
Scrums Antwort auf "wer ist verantwortlich" ist nicht ausweichend. Sie ist präzise darin, welche Accountability genau welche Leistungsdimension besitzt: Die Schwierigkeit ist, dass Präzision mehr Nuance erfordert als ein einzelner Name, und Organisationen, die an Strukturen mit einzelnem Verantwortlichen gewöhnt sind, sträuben sich oft länger gegen diese Nuance, als sie sollten.