From the point of view of defining and understanding this concept, the Scrum Guide has this to say :
'Scrum Team members respect each other to be capable, independent people.'
I struggle to extract any real, actionable, meaning from this statement. Capable of what ? Independent of what or who ? How should 'independence' be reconciled with the need for teamwork ? What is the point of this type of respect ? It narrows the scope of 'respect' down to interpersonal relations, but that's not saying very much. The statement as it stands raises more questions than answers.
The gist of the problem I have with this value is simply that the type of respect I understand and believe in must be earned. I can easily accept the idea of gaining respect by doing good work and being a friendly and helpful colleague. This can be seen as an important objective for any professional in any context including Scrum. Of course, this implies that respect should be given if these conditions are met. However, dishing out respect by default in the absence of any evidence that it is warranted, doesn't work for me.
Indeed, my experience as a team leader has indicated that one very good way to annoy a team is by giving too much respect to members who have not, in the eyes of their colleagues, done enough to deserve it.
What I see when I look at Gunther Verheyen's description of respect is a very very broad definition indeed. The term seems to be used as a net to capture things that might otherwise escape, rather than as a specific behaviour.
So let's turn again to the Agile values and principles, and see if we can find something that may illuminate the question of 'respect'. In contrast to Openness, this is very much harder work.
The first Agile value tells us to value 'Individuals and interactions over process and tools'. This 'valuing of individuals' might be the root of Scrum's 'respect'. But I can't help but feel that the intent of this value was not to stress the importance of 'respect' a la Scrum, but simply to observe that processes and tools will not save your ass if you do not have individuals with the right skills and communication abilities. With this, I can completely agree.
In the Principles, the only word I can find which seems to relate to respect is the word 'trust', which is used in Principle 5. But this principle is really directed at those building an Agile development environment, rather than directly at the participants.
So from an Agile Manifesto perspective, I find no special place for 'respect'. This seems to be a thing that Schwaber and Beedle have introduced into Scrum. Somewhat paradoxically, this makes it the most interesting of the Scrum values.
It's easily possible, from a very generic team building point of view, to create an argument for the importance of respect in the sense I refer to it above - 'professional respect', if you like. Team members should be encouraged to want this sort of respect, and supported in their endeavour to achieve it.
If Scrum's 'respect' is simply an acknowledgement of the importance of this type of respect, i.e. this type of respect is that intended by Schwaber and Beedle, then the pieces fall into place quite neatly. Teams will tend to become higher functioning if individuals are motivated to achieve this respect by improving their technical and personal skills. Of course, they are unlikely to be so motivated if people do not evince respect despite their efforts.
But every attempt I have seen to describe Scrum's Respect value does not seem to deal with this sort of respect at all. Instead, we again seem to be in a realm where the term 'respect' is used in a very trivial sense where it refers to normal professional standards of behaviour, including a clear recognition of Scrum's roles and responsibilities. Just to pick a few examples I've come across :
Apparently turning up on time for the Scrum meeting is an act of respect. Well, timely attendance at important meetings has always, even in pre-Agile days, been a simple professional obligation ( although the concept of 'timeliness' definitely has a cultural dimension to it ).
Apparently respect is shown to stakeholders by ensuring that progress is visible to them. I don't believe I've ever worked on a project where the stakeholders - customers and senior management - did not consider it important to know the state of the project they were paying for. Again, it's not a case of showing respect, as if there were some degree of choice involved, it's a case of satisfying a key requirement that goes with the territory.
Apparently respect is shown to the business when the team selects backlog items with significant business value as opposed to lower business value. What ??? Well, there are complexities to consider when asking the question 'what is the business value of this backlog item ?'. This is fundamentally the question that the Product Owner is charged with addressing, and getting answers is not trivial.
But it is nonsensical to suppose that the team actually has the option of deliberately choosing lower business value items when they are free to choose higher ones. This is not a question of respect - a team that does this simply does not understand it's obligations to the business.
Therefore it is difficult to see a meaning for Scrum's respect by attempting to reverse engineer it from examples of usage.
Some light is cast on Scrum's notion of respect by returning to Lean Thinking. Respect is a key concept for Lean thinking ( one of its 'two pillars' ). This is not to say that all of Lean Thinking's take on respect is equally practical or well defined. There is still a strong tendency to overload 'respect' with meanings that seem difficult to justify.
However, one important meaning of respect in Lean Thinking is to understand your customers and give them what they actually need, rather than what you may want to give them. Taken together with a view of organisational structure which sees stakeholders as customers, this definition is usefully unambiguous. I'm still not convinced that I would choose the term 'respect' to describe this behaviour, but at least it's clear what behaviour is being referred to, and it's clear how it might serve to benefit the business.
The Lean Thinking perspective is important as far as it goes, and it's obvious that Lean Thinking has been influential in defining some of Scrum's theory and values, but it is not the whole picture. It is not obvious, for instance, how the 'respect for the customer' perspective relates to the Scrum Guide's definition of respect. The XP definition of respect here is equally hard to fathom. Indeed, as given it's barely grammatical.
I have wondered, but will not pursue here, if the root of this problem relates to the fact that Lean Thinking is essentially a Japanese invention. The concept of respect in Japanese culture is a key one, and the Japanese language has many features that relate to respect and it's expression in different contexts, even to the point of having different linguistic forms for various respect related purposes. One interesting aspect exposed in the Japanese language is the relationship between respect and humility. So I wonder if this is at least partly a case of a concept getting lost or confused in translation.
Confusing the picture still further is the fact that, beyond the world of Agile, the term 'respect' has become used far more commonly in Western culture in the decades ( ! ) since Scrum was invented. Respect, whatever it is, is frequently demanded, as if it were some sort of basic human right - an approach entirely at odds with the notion that respect is something which is earned as a result of particular achievements. Despite this common usage, there is little clarity about the practical interpretation.
Ultimately I'm forced to conclude that Scrum's 'Respect' is mostly used as an over-abstracted label for a multitude of different behaviours, each of which can almost always be described more accurately in much more practical and less emotive terms.
This is not to say that these behaviours are unimportant, far from it. But diluting the concept of respect to breaking point and beyond simply in order to provide a convenient bucket for an otherwise complex and heterogeneous set of things is not Scrum's finest achievement.
© Mark de Roussier 2022, all rights reserved.