How do you translate that correctly?
November 2020. A small group of volunteer enthusiasts set about translating the Scrum Guide, the new version of which will be published in mid-November, into German. There are a few things that are important to us as a team of translators. For example, using inclusive language like in the original. But “gendering” is not well received everywhere. However, that is only one of several obstacles.
Another issue is the translation of the terms “accountability” and “responsibility” into German. Again and again we had discussions about this. We in the translation team have decided to translate “accountability” as “Ergebnisverantwortung” (responsibility for results) and “responsibility” as “Umsetzungsverantwortung” (responsibility for implementation) in order to give the discussion a direction. And as it goes: the translation has been published and we got a lot of feedback. Lot’s of positive, constructive but also negative feedback. But we in the team knew that from the beginning.
One thing that stuck in my mind was a comment by our dear CST colleague Ilker Demirel, organisational transformation consultant for the topics agile and beta, who said our translation was wrong. In addition to being CST, Ilker was also part of Christopher Avery’s Leadershift Gift programme. I have known Christopher since 2011 and I was happy to welcome him for the Global Scrum Gathering Munich 2016 as co-chair, keynote speaker and for his workshop on “his” responsibility-process, which I really like. This makes Ilker an expert for the topic of “responsibility”. So what could be better than to arrange a meeting with Ilker on a snowy Tuesday afternoon in February to take a closer look at this very issue?
Björn: Ilker, it’s great that you have time for me. How are you?
Ilker: I am fine, thank you!
Björn: We had just talked and fortunately you drew my attention to the fact that you think our translation is pretty good. However, you are rather critical of the introduction of the terms “accountability” and “responsibility” in the Scrum Guide in general. Why?
Ilker: Let’s look at the wording in English and German: you can take over responsibility (Verantwortung), but accountability (Verantwortlichkeiten) – i.e. being responsible – is handed over to you (“PUSH”). Therefore, in the latter, someone is held accountable (someone will have to take the blame). Accountability is actually only given in English and serves the Taylorist management principle of “command and control”.
Björn: Okay. It also comes to my mind that such structures tend to favour “justification” and “melon management” (green on the outside, red on the inside). What do you think needs to be considered when talking about this topic in the context of agility?
Ilker: What we want in the agile context is voluntarily taking responsibility (“PULL”). In Scrum, this specifically means seeing oneself as part of the Scrum team and taking responsibility for WHY, WHAT, and HOW. If a Scrum team has taken responsibility over sth. from end to end, then this must go hand in hand with the empowerment to be able – and willing – to make decisions. When the team is responsible for something, it also has to be able to make the decisions. I don’t like the English word accountability for another reason. I associate it with authority, which for me is a rather old way of thinking. For me, being held responsible always has something to do with “having to give account” and this concept is really questionable. And the concept of guilt is questionable. Primarily, I find the term “accountability” in alpha companies that operate by command and control. From my point of view, this does not contribute to the development of the full potential of “free” people. It is accompanied by fear. A Scrum team whose roles are crammed with accountability to other people cannot be self-managing. It is externally controlled, and therefore cannot and will not take responsibility for its own results.
Björn: What do you think is an approach that can help here?
Ilker: It can definitely help to get away from status thinking or a person-related understanding of roles. And we still have that in Scrum. Roles are there (even if they are now called responsibilities) and will always be there. The expediency of the roles should be the focus. The ScrumMaster role will and must go to zero over time when the Scrum Team has mastered Scrum. Here the betacodex principle #11 fits quite well: resource discipline – expedience instead of status orientation.
Björn: I have a slightly different perspective but I think our thoughts go in the same direction. I think that in an experienced Scrum team, Scrum Mastery is no longer done by just one person, but that it is shared by the team. Everyone will do Scrum Mastering. The same is basically true for Product Ownership, because ultimately we want to have something called collective Ownership. But let’s come back to the Scrum Guide: if you were actively involved in writing the next edition, what would you do differently?
Ilker: Let me briefly add to your thought from a moment ago. A betacodex principle also fits in here: #10 Mastery-based decision – consequence instead of bureaucracy. Now I’ll come to your question regarding the Scrum Guide. What would I do differently and how? Well, the next update would be even leaner and more principles-based. Even the current Scrum Guide is still too prescriptive for me, especially regarding the roles.
Björn: Interesting. But I would like to come back to the initial topic. In the team of translators of the Scrum Guide 2020, we have now decided to use the terms “Ergebnisverantwortung” (responsibility for results) and “Umsetzungsverantwortung” (responsibility for implementation). Perhaps a little background on why we have done this. From our point of view, the terms “accountability” and “responsibility” are not really used in a clear and uniform way. Often “only” the vague term “Verantwortlichkeit” is used. But why is that? In English we do not use two different terms without a reason. And so we asked ourselves how we could give the use of these two words a clearer direction in German. And that led to the choice of the two terms mentioned above. With this, we are very close to the literal translation, as we had intended. Even if this makes the translation a little bumpier to read😉 Your opinion on that?
Ilker: I think your translation is quite good. And it also fits quite well with what Richard Hackman presents in his book “Leading Teams” in the authority matrix:
According to Hackman’s definition and the illustration in the above matrix, a self-managing team holds responsibility for work processes and results. And this perfectly matches at least three of the agile principles:
- The best architectures, requirements, and designs emerge from self-organizing teams.
- Working software is the primary measure of progress.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
In my opinion, this can only be achieved with self-managing teams. Self-organisation means that something forms from within without factors acting from outside. I have also published an article on my website about the difference between self-organisation and self-management. If you are interested, you can find it here.
Björn: Thank you, Ilker, for your time and input. I have the feeling that much more could be written about this. Maybe we’ll delve into it a bit more in the future. I would be pleased! Have a nice rest of the week!
Ilker: Thank you for the initiative! A nice week to you and your team too, and see you again soon.
More information:
