Imagine the following scenario:

A Scrum product owner (PO) is on leave, and the customer has a pressing matter to discuss. Who should she contact? The developers? The Scrum Master (SM)? Wait for the PO to come back? Other?

I saw this question on LinkedIn yesterday, and I was appalled by the religious answers I read. Time for some Scrum-heresy: I don't like how the Scrum Guide presents the PO and SM roles.

The Scrum team is always responsible

Agility is about empowerment and responsibility. It is about behaving like adults and doing the best we can to help our customers do their work. Artificial barriers like mine/yours way of thinking tend to become problems in the long run.

A genuinely agile team owns the responsibility of defining their product, managing their backlog, talking to the customers, delivering value, improving their processes, etc. They are an empowered, self-organizing entity. In theory, they don't need a PO, and they don't need an SM either. Everyone feels responsible for the whole and acts accordingly. But it is not practical. Beyond the apparent skillsets problems, more often than not, it helps to define those roles.

What if?

Let's play it through. What if a team were to work without assigning someone the role of a product owner? This team would soon face some (not insurmountable) challenges:

  • Conflicts will appear over which direction the product should take.
  • Focus, creativity, and context-swapping problems will emerge. This effect is best described by Paul Graham in the article "Maker's schedule, manager's schedule".
  • Communication and synchronization needs will increase.
  • Making decisions will take longer.
  • More skills to acquire for the whole team.

Thus, it is indeed a best practice to have one person take over most of those PO activities and be accountable for the team. But the Scrum team remains responsible.

The same goes for the SM role. Thee who has tried to be both an individual contributor (IC) and an SM at the same time can relate. Working in parallel "in" and "on" the system is an arduous task. You face exciting challenges:

  • Priority conflicts. What takes precedence, my IC work or my SM work for the team?
  • Being in the system, the SM cannot step back and observe the system dynamics from outside.
  • Being part of the system, the SM loses objectivity and impartiality.

Thus, it is indeed a best practice to remove one person from individual contribution and let them take over the accountability for the activities gravitating around the team. But the Scrum team remains responsible.

Why is this so important to me?

There is but a fine line between those two explanations. But an important one. I have seen one too many developer disengaging from their responsibility by saying, "our work on the product backlog is taking us too much time. It's the responsibility of the PO to do so, not us." Passively watching a preventable disaster happen, is unacceptable. I have seen one too many PO/SM behaving more like an "entitled project manager" than an "elected-individual". The SM and PO do not have divine powers over the process and product, respectively. You do as a Scrum team. Two of you agreed to be accountable, but you all are still responsible.

So, who should the customer contact?

So let's come back to this LinkedIn poll. Who should the customer contact?

Anyone on the scrum team is a good starting point. The team is responsible; let them handle this as responsible adults.

No, SMs shouldn't shield the developers from external distractions at this point. They shouldn't prevent the customer from asking a question directly to the developers. They should recognize when it is too much and then intervene. Preventing communication upfront is a religious belief that I loathe.

No, SMs are not a preferred choice. They are not project managers. They are not leading the team in this sense. They are not a communication filter. The customer should contact the Scrum team as a whole and let all the Scrum team members decide how to handle it.

Conclusion: please, oh! please, dismantle the barriers you built between the developers and the customers. And it starts with trusting them with the gift of empowered communication.

PS: the new (November 2020) version of the Scrum-Guide brought several changes. Among others, and this is the most crucial one, entire chapters were re-written to be less directive and start with WHY, not HOW. This change is a significant step in the right direction. It removes the focus on "how the SM and PO should behave" and brings it to "why we all decided to act like this." But it is not enough. I'd love to see this problem addressed in the next version of the Scrum guide.

Photo by Austin Distel on Unsplash