Do you try to avoid a particular team member due to their proclivity to be a jerk? If so, there’s a good chance your team suffers from a lack of respect.
Let’s check first to see what words of wisdom the Scrum Guide provides.
“Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.”
Well, that sounds a bit like wishful thinking. My bigger question is: What if that’s not the case? Before we jump into solving that particular mystery, let’s look at other meanings of respect. If I’ve learned nothing else from researching the Scrum values, I’ve learned that I don’t always know the actual definition of some pretty common words.
Merriam-Webster provides two applicable definitions of respect:
Respect is a feeling of deep admiration for someone or something elicited by their abilities, qualities, or achievements.
I can say that I respect Mike Cohn in this way. Many of his teachings resonate with me; he’s a published author, can teach concepts in easy-to-understand ways, and generally seems like an all-around nice guy.
I believe the second definition of respect is more applicable in a Scrum setting.
Respect is due regard for the feelings, wishes, rights, or traditions of others.
To drive home the point, let’s look at some antonyms. These words represent what we’re trying to avoid when we leverage respect.
Throughout my career, I’ve been on several teams that possessed an “us versus them” mentality. Sometimes it was technology versus the business, and other times it was one manager versus another.
I’ve sat through meetings that made me cringe. I once saw a business process owner claim a statement as an absolute fact which a developer immediately refuted by running a report. Subsequently, the process owner’s clique admonished the developer for not being a team player.
Another time I witnessed one manager grill another manager on their plan to prevent a mistake from recurring. No information the second manager provided would satisfy the attack of the first manager because the intent was not to solve a process issue but rather to assign blame in front of a group of peers.
In one role, I had to formulate a list of trigger phrases to avoid because they were steeped in so much political drama that even uttering the specific series of words would set people off on a tirade.
The Head First Agile book said it succinctly:
“Respect and trust go hand in hand.”
-Heads First Agile
When a team lacks respect, it quickly breaks down into a group of individuals. The next thing you know, it’s everyone for themselves - the focus shifts from innovation and problem solving to personal power and position.
This culture is counter to what we’re hoping to accomplish with Scrum.
There are six primary benefits of respect in Scrum:
Radical candor is a way of having the difficult discussions required to coach teams.
Kim Scott defines four quadrants of communication types based on two axes. Without respect, we will slide to the “rage” end of the “give a damn” axis, which will land us in either the “obnoxious aggression” or “manipulative insincerity” quadrants of the Radical Candor framework.
Approaching any difficult conversations with a lack of respect will lead to disastrous results.
Respect makes it easier to make decisions. We’re free to focus on the pros and cons of our options and collaborate to reach the best decision given the information available to us at the time.
“Is there a word for the moment you win tug-of-war? When the weight gives, and all that extra rope comes hurtling towards you, how even though you’ve won, you still end up with muddy knees and burns on your hands? Is there a word for that? I wish there was.”
When there is a lack of respect, our team members feel the need to take sides or set themselves in opposition against those they view as adversaries. We’ll be unable to progress in such a perpetual tug of war. If we resort to forcing a decision, there will be a lack of commitment from the opposing side.
Psychological safety is the belief that one can speak up without the risk of punishment or humiliation. Respect is a vital ingredient for a safe environment. When there’s a lack of respect, you may fear admitting failure, prompting feelings of psychological danger and stifling innovation. When you can’t fail, you certainly aren’t going to want to try new things.
Sam Falco tells a story on the Agile Coaches’ Corner podcast about how he was able to turn conflict into innovation. When a team member criticized him for being the “least agile Agile Coach she’d ever met,” he had two options: take offense or take this as constructive criticism. He chose to accept the criticism and ask questions to clarify her stance. Although the disagreement was uncomfortable, the two were able to work through the situation, understand each other’s points of view, and eventually reach a mutually beneficial conclusion.
Taking the more common path, Sam would have chosen to feel personally attacked and, as a result, became defensive. This decision would be his first step toward developing a grudge that would affect all future conversations and destroy opportunities for innovation.
If there is a lack of respect on the team, it’s more common for individuals to feel attacked and defensive. Instead of resolving their differences, they’ll hold onto their resentment.
If we respect the opinions of others and seek to understand their point of view without judgment, it’s more likely that we can work together to reach a compromise that benefits both parties.
This impact goes further toward innovation than just solving personal differences. Think about how successful you’d be in a team with your arch-nemesis, your mother-in-law, and the person your first true love left you for. There’s no doubt that a lack of respect stifles innovation.
I used to have a bad habit of doing everything for my daughter when she was younger. It was almost as if she’d grown up without my noticing, and I still did things for her like she was a small child. My now-husband moved in with us when she was about 8-years-old, and he loves to tell stories about this transition period.
Not too long after we were all learning to live as a family, my daughter asked for help opening a new gallon of milk. Shocked, my heart-mate very quickly pointed out that she needed to learn to do this task for herself. It was a bit of a paradigm shift for both my daughter and me, but it benefited everyone. Thanks to his guidance, these days, not only can she open her milk, but she can also drive a car, do laundry, and cook.
When unskilled people need help, we’re inclined to do the work for them because we think it’s faster. If we’re a jerk, we might also belittle them or call them out in front of their peers. If we assume that everyone is competent, we approach this situation as helping someone else learn.
Helping teammates learn benefits them, their career paths, and the whole team.
As a Scrum Team, we need to focus on the skills that our team members possess, not the ones that they lack. In The 7 Habits of Highly Effective People, Stephen Covey talks about how his expectations negatively affected one of their son’s well-being. The more he and his wife wished for their son to succeed at baseball, the more the son struggled. It’s hard to thrive when you’re laboring under the expectations of others.
This also applies to our colleagues. Instead of focusing on a team member’s weaknesses, let’s learn to leverage their strengths.
We should always approach any situation, assuming our team members can get the job done. When team members need help, we should help them without judgment and ensure we give each other the tools required to succeed.
Don’t be a hero and take responsibility for all of the work. This type of mentality goes against the agile principle of sustainable pace and robs other team members of a chance to learn and make a more meaningful contribution to the team.
Out of respect for the shared commitment, be willing to share when you’re stuck so that others can offer to help and potentially be able to meet the Sprint Goal.
As a Product Owner, you will need to respect the Development Team’s right to decide what work they include in the Sprint Backlog. This respect will require you to learn to say no to stakeholders requesting urgent features. You can put the new features on the Product Backlog and evaluate them for the next Sprint if their value warrants.
When my daughter was younger, she was on Dave Ramsey’s commission plan. She didn’t get an allowance; she had to do chores to earn money. We paid her depending on how many tasks she completed. I coached her to split what money she made, some for spending and some for saving. The money she earmarked for spending she could spend on pretty much whatever she wanted.
I remember several instances where she was convinced by a commercial to purchase something useless. She almost immediately experienced buyer’s remorse and eventually learned to be more prudent with her money.
This same concept applies to Sprint Planning. We only have so much work that the development team will be able to complete. It’s up to the Product Owners to maximize that value. Out of respect, we’ll need to avoid developing features that users will never adopt.
As a Scrum Master, you’ll want to leverage radical candor to provide helpful guidance to the Scrum Team. Guiding a team to let their process emerge requires a lot of difficult conversations, and these conversations need respect to bring about lasting transformation.
To nurture proper interactions on a team, the Scrum Master can highlight the qualities and abilities that exemplify respect. Reinforcing respectful behavior helps to make everyone aware of the goal.
Sprint Planning is the Scrum event where the Development Team will decide what work to pull into the Sprint Backlog. Some teams experience pressure from the Product Owner to commit to more work than the team feels confident in completing.
Leveraging the Scrum values in this meeting would include respecting the Development Team’s right to make that decision. When a team over commits to work, no one will be happy. The development team that failed to meet the goal, the product owner that must deliver that message to the stakeholders, and the stakeholders that have to wait longer for desired functionality will all be displeased.
It’s a demonstration of respect when the entire team attends the Daily Scrum and is on time. This event is crucial to ensure that we’ll hit our Sprint Goal. Given that this is a collective commitment, everyone needs to participate in the daily planning required to accomplish the goal.
The Sprint Review is our opportunity as a Development Team to demonstrate the working product increment and receive feedback from interested stakeholders.
The Scrum Team shows respect by taking the feedback seriously and seeking to fix customer pain points instead of assuming we know better than the end users and building what we think they need.
Stakeholders show respect by acknowledging the Product Owner’s right to prioritize the backlog. In many cases, the Product Owner manages the requests of more than one customer and has to choose the priority that aligns with the product vision, not a specific customer’s demands.
The Sprint Retrospective is an opportunity to tweak our process and tools to become more efficient over time.
It doesn’t matter that we’ve just experienced the same two-week Sprint; we’ll have different opinions of what happened. We need to show respect for each point of view and not allow our biases to cause us to miss an opportunity for process improvement.
Having respect for team members and stakeholders is crucial to the success of a Scrum Team. Reward respectful conduct to encourage similar behavior in others. Everyone brings some value to the team; focus on the skills you can respect instead of getting hung up on someone’s weaknesses. Amplifying respect can make your co-workers be less of a jerk.