Wie übersetzt man das denn nun richtig?
November 2020. Eine kleine Gruppe freiwilliger Enthusiasten macht sich daran, den Scrum Guide, der in seiner neuen Version Mitte November veröffentlicht wird, ins Deutsche zu übersetzen. Dabei gibt es einige Dinge, die uns als Team vom Übersetzer:innen wichtig sind. So ist es zum einen, den inklusiven Sprachgebrauch wie im Original zu benutzen. Doch das “Gendern” kommt nicht überall gut an. Das ist jedoch nur eine von mehreren Baustellen.
Eine weitere Baustelle ist die Übersetzung der Begriffe “Accountability” und “Responsibility” ins Deutsche. Immer wieder kommt es hier zu Diskussionen. Wir aus dem Übersetzerteam haben uns dazu entschlossen, “Accountability” mit Ergebnisverantwortung und “Responsibility” mit Umsetzungsverantwortung zu übersetzen, um damit der Diskussion eine weitere Richtung zu geben. Und wie es halt so ist: die Übersetzung wird veröffentlicht und es hagelt Feedback. Viel Positives, viel Konstruktives und auch viel Negatives. Doch das war uns im Team von Anfang an klar.
Eine Sache, die mir in Erinnerung geblieben ist, war ein Kommentar unseres geschätzten CST-Kollegen und Berater für Organisationale Transformation in Sachen Agilität und Beta, Ilker Demirel, der unsere Übersetzung als falsch bewertete. Zusätzlich zum CST war Ilker auch Teil des Leadershift-Gift-Programms von Christopher Avery. Christopher kenne ich seit 2011 und ich bin froh, dass ich ihn als Co-Chair für das Global Scrum Gathering München 2016 als Keynote-Speaker und einen Workshop zu “seinem” Responsibility – Process, den ich sehr schätze, begrüßen durfte. Damit ist Ilker jemand, der sich mit “Responsibility” wirklich auskennt. Was liegt also näher, als sich mit Ilker an einem verschneiten Dienstagnachmittag im Februar zu verabreden, um genau dieses Thema unter die Lupe zu nehmen 🙂
Björn: Ilker, schön dass Du Zeit hast. Wie geht’s Dir?
Ilker: Sehr gut, danke!
Björn: Wir hatten grad schon gesprochen und glücklicherweise hast Du mich darauf aufmerksam gemacht, dass Du unsere Übersetzung an sich recht gelungen findest. Jedoch stehst Du der Einführung der Begriffe “Accountability” und “Responsibility” in den Scrum Guide eher kritisch gegenüber. Warum?
Ilker: Lass uns mal auf das Wort Verantwortung an sich schauen: Verantwortung wird übernommen, Verantwortlichkeit, also verantwortlich sein, wird einem übergeben (accountability “PUSH”). Daher wird bei Letzterem jemand zur Verantwortung gezogen (jemand wird seinen Kopf hinhalten müssen). Accountability ist eigentlich nur im Englischen gegeben und dient eigentlich dem Tayloristischen Management Prinzip “Command and Control”.
Björn: Okay. Mir kommt dabei auch in den Sinn, dass derartige Strukturen ja eher “Rechtfertigung” und “Melonen-Management” begünstigen. Was ist denn aus Deiner Sicht im Kontext “Verantwortung und Agilität” zu berücksichtigen?
Ilker: Was wir im agilen Kontext haben möchten, ist die freiwillige Übernahme (“PULL”) von Verantwortung. In Scrum bedeutet das konkret, sich als Teil des Scrum Teams zu sehen und für das WOZU, WAS, und WIE Verantwortung zu übernehmen. Wenn ein Scrum Team Verantwortung über eine Strecke von Ende zu Ende übernommen hat, dann muss das Hand in Hand gehen mit der Bevollmächtigung, Entscheidungen treffen zu können – und zu wollen. Wo das Team etwas verantwortet, dort hat es auch die Entscheidungen zu treffen. Accountability gefällt mir aus einem weiteren Grund nicht so gut. Ich verbinde damit Autorität, was für mich ein eher altes Gedankengut ist. Verantwortlich gemacht zu werden hat für mich auch immer was mit “jemanden Rechenschaft schuldig zu sein” zu tun. Und der Begriff der Schuld ist fragwürdig. Primär finde ich den Terminus “Accountability” in den Alpha-Unternehmen, die nach Weisung und Kontrolle funktionieren. Aus meiner Sicht trägt das nicht zur Entfaltung des vollen Potentials “freier” Menschen bei. Es ist gepaart mit Angst. Ein Scrum Team, deren Rollen vollgestopft sind mit Rechenschaftspflichten gegenüber Außenstehenden, kann nicht selbstmanagend sein. Es ist fremdgesteuert, von daher kann und wird keine Verantwortung für eigene Ergebnisse übernommen werden.
Björn: Was ist aus Deiner Sicht denn ein Ansatz, der hier helfen kann?
Ilker: Helfen kann auf jeden Fall, wenn man wegkommt vom Statusdenken oder einem personenbezogenen Rollenverständnis. Und das ist ja in Scrum nach wie vor da. Rollen sind vorhanden (auch wenn sie jetzt Verantwortlichkeiten heißen) und werden immer da sein. Die Zweckmäßigkeit des Rolleneinsatzes sollte im Fokus stehen. Die Scrum Master Rolle wird und muss mit der Zeit auf Null gehen, wenn das Scrum Team Scrum gemeistert hat. Hier passt ganz gut das betacodex-Prinzip #11: Ressourcendisziplin – Zweckdienlichkeit statt Statusorientierung.
Björn: Da habe ich eine leicht andere Perspektive und ich glaube, unsere Gedanken gehen in die gleiche Richtung. Ich denke, dass in einem erfahrenen Scrum Team das Scrum Mastering nicht mehr nur von einer Person übernommen wird, sondern dass es im Team aufgeht. Jede:r wird Scrum Mastering machen. Das Gleiche gilt im Grunde auch für Product Ownership, denn letztendlich möchten wir ja etwas haben, was man als Collective Ownership bezeichnet. Doch lass uns noch mal zum Thema “Scrum Guide” kommen: wenn Du an der nächsten Ausgabe aktiv mitschreiben würdest, was würdest Du wie anders machen?
Ilker: Lass mich noch kurz zu Deinem Gedanken von eben kommen. Da passt nämlich ebenfalls ein betacodex-Prinzip: #10 Könnerentscheidung – Konsequenz statt Bürokratie. Nun zu Deiner Frage hinsichtlich des Scrum Guides. Was würde ich wie anders machen? Nun, das nächste Update wäre noch schlanker und noch mehr auf Prinzipien basierend. Selbst der aktuelle Scrum Guide ist mir noch zu präskriptiv, insbesondere was die Rollen angeht.
Björn: Spannend. Ich würde aber gern noch mal zum anfänglichen Thema zurückkommen. Wir haben uns im Team der Übersetzer:innen des Scrum Guide 2020 ja nun dazu entschieden, von “Ergebnisverantwortung” und “Umsetzungsverantwortung” zu sprechen. Vielleicht dazu ein wenig Hintergrund, warum wir das gemacht haben. Aus unserer Sicht werden die Begriffe “Accountability” und “Responsibility” nicht wirklich trennscharf und einheitlich verwendet. Häufig findet sich “nur” der schwammige Begriff “Verantwortlichkeit”. Doch wofür? Zwei unterschiedliche Wörter werden ja nicht ohne Grund verwendet. Und da haben wir uns gefragt, wie wir der Verwendung dieser beiden Wörter im Deutschen eine deutlichere Richtung geben können. Und das führte zur Wahl der o.g. beiden Wörter. Damit sind wir sehr nah an der wortwörtlichen Übersetzung, so, wie wir es uns vorgenommen haben. Auch wenn sich die Übersetzung dadurch ein wenig holpriger liest 😉 Deine Meinung dazu?
Ilker: Ich finde eure Übersetzung ganz gelungen. Und sie passt auch ziemlich gut zu dem, was Richard Hackman in seinem Buch “Leading Teams” in der Autoritäts-Matrix darstellt:
Nach der Definition von Hackman und der Veranschaulichung durch die o.g. Matrix hat ein selbstmanagendes Team die Verantwortung über die Arbeitsprozesse und -ergebnisse. Und damit geht das wunderbar einher mit mindestens drei der agilen Prinzipien:
- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
- Funktionierende Software ist das wichtigste Fortschrittsmaß.
- Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
Und das kann meiner Meinung nach nur durch selbstmanagende Teams gelebt werden. Selbstorganisation bedeutet, dass etwas von innen heraus ohne von außen wirkende Faktoren bildet. Zum Thema, was der Unterschied zwischen Selbstorganisation und Selbstmanagement ist, habe ich auch auf meiner Seite einen Artikel veröffentlicht. Wer daran interessiert ist, findet diesen hier.
Björn: Vielen Dank, Ilker, für Deine Zeit und Deinen Input. Ich habe das Gefühl, dass man dazu noch viel mehr schreiben könnte. Vielleicht vertiefen wir das in Zukunft noch ein wenig. Würde mich freuen! Hab noch eine schöne Restwoche 🙂
Ilker: Danke für die Initiative! Und auch Dir und Deinem Team eine schöne Restwoche und bis bald mal wieder.
Weiterführende Informationen:
