The PO as SPoC towards the software vendor
For a heavily customized Commercial off-the-Shelf (COTS) application, a new Product Owner (PO) role will be established. I learnt that the new role will be acting as a Single Point of Contact (SPoC) towards the software vendor. In addition to this, the PO will have a corresponding SPoC on the vendor side. Therefore all communication between the two organizations will be channeled through those two roles.
A SPoC, a single point of contact, is a means to establish a clear contact point to channel information flow. This is a helpful concept, for example known from ITIL. In ITIL the Service Desk is defined as the SPoC to contact the IT service provider. That makes sense as it is impossible for a user to understand the IT service provider's organization well enough to find the correct contact. It could be said that a SPoC is an entry point into an organization that should be treated as a black box.
My agile heart skipped a beat when learnt about that setup. Why? Because I am convinced that enabling direct communication is key to any agile setup and that such a SPoC based setup will not enable but massively hinder communication. Almost every Scrum Team member will need one or more communication channels to the software vendor.
There is only one domain where the Scrum Guide sees the PO role as a designed bottleneck. The PO is the sole person responsible for managing the Product Backlog and the PO may do the above work, or have the Development Team do it. That limitation clearly is on backlog responsibility only [no item can enter or leave the Backlog without PO's consent and all priorities have to be set with PO's agreement]. There is no limitation on the communication channels to be used.
Ok, the PO will start soon but has not started yet, there might still be time to make corrections to the setup. My proposition is to drop the concept of a Single Point of Contact in Scrum Teams altogether.
What is your view on this and what propositions would you make?
Check first that the intent is indeed to limit communication through the SPoC channels. If so then you may well have a valid concern. However, it might be the case that the intention is to provide clear accountability for a consistent message (i.e. someone with the final say should there be conflicting opinions), which is not the same thing.
When I learnt about the new setup I have immediately checked the motivation behind the decision. Yes, the intent was to channel all communication. If I read the reactions to my discussion correctly, that setup might be reconsidered.
Ian, you have a valid point there. I fully agree that accountability for a consistent message and a final decision in conflict situations might well be with the PO. I know that the person taking the PO role is a trusted expert and accepted by all parties involved, so I assume that's what will happen anyway.
I'm not convinced that a single point of communication would hinder communication. I fully believe that it would improve communication between the Scrum Team and various stakeholders outside of the Scrum Team to have a single point of communication (although I would want redundancy - one point of communication at a time, but with an alternate to account for any unforeseen absences).
It also makes sense for the Product Owner to be that single point of communication between the Scrum Team and the outside world from a product perspective. Depending on the situation, the Scrum Master may also need to reach outside the Scrum Team to remove impediments and to provide all of their services to the organization. But the Scrum Master's focus is more on the way of working and not the product itself.
Why the Product Owner? The Product Owner is already communicating with stakeholders outside of the Scrum Team. It's almost a requirement in order to be able to optimize the value of the work. The Scrum Team doesn't typically decide what work is valuable - outside stakeholders have needs that are being met by the work done. So there should be open lines of communications between the Product Owner and these stakeholders.
Why is it not anti-Agile or anti-Scrum? One of the duties of the Scrum Master is to remove impediments to the Development Team's progress. Unnecessary communication can take the Development Team away from their work of delivering value. Of course, the keyword there is unnecessary. Some communication between the Development Team and external stakeholders can help the Development Team deliver greater value. The Scrum Master should be working closely with both the Product Owner and the Development Team to help them manage communication and ensure that the right people are having the right conversations.
I would say that channeling all communication and forbidding direct communication except through the single point of communication would be wasteful (in the Lean sense - it's additional movement of information that can lead to defects if the message is poorly understood by the different parties involved). Plus, it just leads to the telephone game. Since that is something that would slow the Development Team from delivering value, I would discourage that kind of behavior.
Yes, the intent was to channel all communication. If I read the reactions to my discussion correctly, that setup might be reconsidered.
What is the actual problem a SPoC is meant to solve? What really is the motivation behind it?
For example, there may be a history or reasonably grounded fear of the team being interrupted by stakeholders, and establishing a SPoC may be an attempt to mitigate this concern.
Just as an example: A Development Team member needs to clarify how a shell script will be implemented and how it will interface with application monitoring. Forwarding this question to the PO who then forwards this to the vendors SPoC to forward it to the developer on the vendor side would be inefficient, slow and error prone.
If the full canneling of all communication is dropped and technical people continue to directly communicate with one another over the company boundaries, I agree there are many reasons why a PO should/will get involved.
I am not sure what the motivation was to bring up this concept of channeling communication through two SPoCs.
You really can't dictate how the vendor manages their side of communication. Your organization (through whoever manages the vendors, or perhaps the Scrum Team's Scrum Master) can give suggestions to help them better integrate with your workflow, but if the vendor wishes to funnel all communication through a SPoC, then that's their decision.
As far as going through your PO, that makes sense. Especially when working with vendors and across organizational lines, there may be controlled interfaces between components being built by different organizations. The PO should know about these. If one exists, then the PO may not even need to go to the vendor but can simply ensure that the team has the information they need. Ideally, the need for this information comes up at a Backlog Refinement session before the work begins and the PO has time to contact the right people to get the information or determine when it will be available before the Product Backlog Item is included in a Sprint.
In the event that the PO doesn't have the information needed and a technical conversation between both parties is required, I would expect the PO to facilitate technical discussions between the Development Team and someone at the vendor. Who that is at the vendor is up to the vendor to determine, and perhaps the Scrum Master can get involved to help them understand the impacts of their decision and structure on the ability to have a successful collaboration.