Line of Respect

For those of you familiar with Scrum, you might be wondering what the dotted line is in this picture, just northeast of the Product Backlog. We call it the “Line of Respect”.

I’ve seen a similar line drawn, called the “heat shield”, the “s#$% umbrella”, the “wall”.  We have a few reasons for calling this the Line of Respect (LOR) which is a bit more bi-directional than a shield, an umbrella or a wall. And we have a few reasons for drawing this line where we draw it.

What the Line of Respect is, is a place (doesn’t have to be physical) where we can respectfully discuss where the needs of the business might conflict with the needs of the team and vice versa.

Business context is everything, and we’re sharing a few contexts that might cause you to jump on the Line of Respect.

The Product Owner is responsible for the “why” of the vision (and backlog contents), and the “what” of what ends up at the top of the backlog.  The Product Owner is also supposed to have one foot in the business arena and one foot with the team. And the Product Owner is supposed to set Release dates. For this to work, the team has to respect the PO owns the “why”, the order of the backlog, and delivery dates. What if the PO is wrong about the vision? That the vision, if updated, might yield a new customer market?

There’s also this idea that when the development team says “go” on a Sprint, they’ve pulled the work from the top of the backlog, and they’re uninterrupted and fully responsible for doing whatever it takes to meet the Sprint goal.  For this to work, the PO has to respect that the team is heads-down during the Sprint, and interrupting them will seriously affect the results. What if there’s a customer bug that the team has to fix immediately - like today-  or else we’ll lose a customer?

If there are relative sizes of effort and complexity provided, it’s the team who is doing the work that will provide this.  For this to work, (even if the PO used to be a developer) the PO has to respect that the team doing the work will only achieve fine attention to detail, owning the best results possible, if they fully own the “how.”  What if the PO has a colleague visiting town during that Sprint who’s truly a resident expert in {whatever technology} they are working on?

Business context is everything, and perhaps you don’t need to remind folks of a line of respect (they’re already respectful in all cases), but if you do find you do get interrupted as a team (seemingly too much), or your PO isn’t ordering the backlog correctly (and you’re not able to comment on this, perhaps not privy to meetings where this occurs), or- or- or, the Line of Respect offers you a quick way to have this respectful conversation, without having to have the conversation after the fact at a Retrospective, where you’re dealing with the consequences.

A couple of hints to make it work:

It doesn’t have to be a physical space. We end up hearing “hey I’d like to have a conversation with you and for this conversation I’d like to jump on the line of respect.”

But you could also make this a visible, physical space. Demark an area near the team room, where whenever you’re in that space you’re in the respect zone. What we hear is “lets walk over to the respect zone and have this conversation.”

Here’s a recent example:  The PO was invited by the team to the Line of Respect (in this case it was a physical space) to change the Release date. The team surprised the PO with opportunity to finish 2 Sprints ahead.  The PO’s awesome answer, with a dead-pan face:  I will NOT change the Release date!. There was a 60 second pregnant pause, then he continued with “Let’s celebrate!  Feel free to code whatever you want to code between now and then!"

Catherine Louis

Catherine Louis is a Certified Scrum TrainerTM, independent Agile coach, and co-founder of the #PoDojo, who lives in North Carolina. With over 20 years of experience in complex product development in both software & hardware, Catherine has previously led Agile transition efforts in top telecommunications firms and worked with North Carolina State University to conduct research on Agile Test-Driven development. She has conducted years of research and training on “building security” into your product, verifying that security protection mechanisms are in place and working before it’s too late. Catherine regularly speaks at Agile20XX conferences, is a lead for the “Working With Customers” track, and runs the AgileRTP meetup group, one of the largest Agile meetup groups in the US.

https://twitter.com/catherinelouis
Previous
Previous

How to: Empathy Map

Next
Next

Why should your Product Owner be a Servant Leader?