Der Scrum Guide wählt das Wort "Accountability" bewusst. Nicht "Rolle", nicht "Verantwortung" im losen Sinn, nicht "Funktion". Accountability. Der Unterschied trägt Gewicht: Eine Accountability lässt sich nicht teilen oder wegdelegieren. Wer eine Accountability in Scrum trägt, besitzt das Ergebnis, unabhängig davon, ob die gesamte Arbeit selbst geleistet wird.
Der Scrum Master
Der Scrum Master ist verantwortlich für die Wirksamkeit des Scrum-Teams. Das umfasst zwei zusammenhängende Bereiche: sicherzustellen, dass Scrum wie definiert verstanden und umgesetzt wird, und das Team zu befähigen, seine Praktiken und Ergebnisse kontinuierlich zu verbessern.
Was das in der Praxis bedeutet, ist Coaching statt Management. Der Scrum Master trifft keine Produktentscheidungen, das obliegt der Product-Owner-Person. Der Scrum Master trifft keine technischen Entscheidungen, das obliegt den Developern. Was der Scrum Master tut, ist die Bedingungen zu schaffen, damit das Team diese Entscheidungen gut trifft: Events wirksam moderieren, Hindernisse außerhalb der Kontrolle des Teams beseitigen, und sowohl dem Team als auch der breiteren Organisation helfen zu verstehen, wie Scrum funktionieren soll und warum.
Der Scrum Master dient auch der Organisation, hilft ihr zu verstehen, was Scrum erfordert, und arbeitet mit Stakeholdern außerhalb des Teams, um strukturelle Hindernisse für die Wirksamkeit des Teams zu beseitigen. Dieser nach außen gerichtete Aspekt der Rolle wird oft unterschätzt. Ein Scrum Master, der sich ausschließlich auf das Team konzentriert und den organisatorischen Kontext ignoriert, arbeitet mit einer Hand auf dem Rücken.
Die Product-Owner-Person
Die Product-Owner-Person ist verantwortlich, den Wert zu maximieren, der aus der Arbeit des Teams entsteht. Das ist eine geschäftliche Verantwortung, keine technische. Die Product-Owner-Person besitzt den Product Backlog, seinen Inhalt, seine Reihenfolge und seine Kommunikation, und ist verantwortlich für die Entscheidungen darüber, woran das Team arbeitet und in welcher Reihenfolge.
Eine Person trägt diese Verantwortung, aber diese Person vertritt mehrere Stakeholder. Die Product-Owner-Person verbindet Geschäft und Entwicklungsteam. Sie übersetzt strategische Absicht in geordnete Backlog-Elemente. Sie trifft Abwägungsentscheidungen, wenn Kapazität begrenzt ist. Sie nimmt an Sprint Reviews teil und stellt sicher, dass das Gebaute tatsächlich das Benötigte widerspiegelt.
Die Wirksamkeit einer Product-Owner-Person hängt ebenso von Autorität wie von Fähigkeit ab. Eine Product-Owner-Person, die keine echten Entscheidungen über den Backlog treffen kann, weil diese Entscheidungen von einem Komitee, einer Führungskraft oder einer Steuerungsgruppe getroffen werden, kann die Accountability nicht sinnvoll tragen. Die Organisation muss genuin in die Product-Owner-Rolle investieren, damit sie wie vorgesehen funktioniert.
Die Developer
Die Developer sind verantwortlich, jeden Sprint ein nutzbares Increment zu erzeugen, etwas, das der Definition of Done entspricht und im Prinzip veröffentlicht werden könnte. "Developer" bedeutet in Scrum nicht ausschließlich Software-Ingenieur:innen: Der Begriff bezeichnet die Menschen, die Backlog-Elemente in gelieferten Wert verwandeln, in welcher Form auch immer.
Die Developer managen sich innerhalb des Sprints selbst. Sie entscheiden, wie die Arbeit erledigt wird, nicht nur was zu tun ist. Das ist ein bedeutsames Maß an Autonomie, das echtes Vertrauen seitens der Product-Owner-Person und der breiteren Organisation erfordert. Teams, denen sowohl gesagt wird, wie sie Dinge bauen sollen, als auch was sie bauen sollen, arbeiten nicht mit der vollen Scrum-Accountability-Struktur, sie arbeiten als Umsetzungsressource innerhalb eines nominellen Scrum-Prozesses.
Warum alle drei wichtig sind
Jede Accountability steht bewusst in Spannung zu den anderen. Die Product-Owner-Person braucht die Developer, die sich zur Wertlieferung verpflichten; die Developer brauchen die Product-Owner-Person, die sich zu klaren Prioritäten verpflichtet und echte Entscheidungen trifft; beide brauchen den Scrum Master, der die Bedingungen für eine produktive Beziehung schafft. Keine der drei Accountabilities funktioniert isoliert gut.
Scrum-Teams scheitern selten wegen schlechter individueller Leistung innerhalb dieser Accountabilities. Häufiger scheitern sie, weil die Accountability-Struktur kompromittiert wurde: eine Product-Owner-Person ohne Autorität, ein Scrum Master ohne Unabhängigkeit, oder Developer ohne Selbstmanagement. Die Accountabilities richtig zu gestalten, ist keine Prozessfrage. Es ist eine Frage des Organisationsdesigns.