Product Owner’s guide to Agile Scrum Pt.2 – Single point of contact

Every time a Product Owner joins a Scrum team she is essentially the odd one out. The developers and Scrum Master, coming from the development company are old buddies – experienced and used to working together. Accepting a new team member into their midst is a challenge of facing the unknown and quite the unpredictable.

Table of contents

1. Definition of Single Point of Contact (SPoC)
2. Own it
   – The power of the Backlog
   – Only relevant information
   – Single Point of Contact – Communication, not a transmission
   – Our specialists know best
3. A product owner is not a stakeholder
4. Owning product for life (cycle)
   – SPoC – Multiple signals from outside = less control on project

As much as friendly getting along is not a necessary feature of a Scrum team, clearly defined responsibilities and accountability of particular team members are crucial for a project’s success.

Definition of Single Point of Contact (SPoC)

In relation to Scrum rules means that the Product owner (SPoC) should remain the only channel of communication between the Scrum team and all client-related external influences.  

To maintain a healthy, agile Scrum environment the Scrum team must remain, within itself – a hermetic environment. Meaning, any external influence on the project, be it from stakeholders, software house management or development specialist consultants, should be channeled through appropriate team members, not allowed to directly interfere with the Scrum team. Here’s where the matter/issue/problem of SPoC comes in.

Own it

Your job description as a Product Owner can be reduced to one core task – maintaining the Backlog. You are the one filling it up, reducing, adding, accepting, rejecting all the items within it. The Backlog is the focal point for the whole team. The direction, pace, and efficiency of the development depend primarily on the way it is managed. The backlog is not only the bible for the mobile app developers of your product. For you, it is the channel through which you communicate all decisions regarding the development.

The power of the Backlog

Do not underestimate the power of the Backlog. It’s not just a tool for you. It’s also the perfect defense from external interference on your side. How? Let’s say that as a Product Owner you answer to a group of stakeholders, a CEO and whoever else is putting money in the project. Obviously, throughout the process, they will want changes , adjustments, feedback. This is where being a steadfast SPoC becomes somewhat complicated. You will be tempted to share the concerns of the stakeholders with your Scrum Team. Don’t. These are 100% your problems to solve. Facts, tasks and backlog items are the way to communicate the external issues to the Scrum team. You must process the issues first and figure out how to translate them into Scrum-ready communication.

Only relevant information

Sharing info the likes of “My CEO must approve this first” or “We are still waiting for the board’s decision on this one” are, to be painfully honest, absolutely useless and hinder work to no one’s benefit. In a Scrum Team, you are the decision maker, so if you’re dependant on the external influence for those decisions, make sure you get answers on time to communicate to your team and allow them to work. Working in Scrum, when planning a new Sprint, you should have all the decision making power for that Sprint’s backlog.

If you don’t, your alternatives are to delay the Sprint’s start or to reduce it by the undecided items. The latter will allow the work to continue without delays, and once the decisions on top are made, you can include them in planning the works for the next Sprint.

Single Point of Contact – Communication, not a transmission

Communication goes two ways. Making decisions and accepting the effects of work is but a part of your job. Without listening to other team members your project will not go as smoothly as it could. Remember as Single Point of Contact you are there to tell them what is required, but it’s the developers’ thing to tell you how long it’s going to take to make it happen.

Sometimes they too will be facing challenges and obstacles. Concentrate on listening to all that is discussed during Scrum meetings and offer help in matters you can help with. Sitting and waiting for them to figure out something you have a solution to is not helping. Neither does it encourage the rest of your team to be understanding and open towards you.

Make sure though, that the matter of your communication is genuinely yours. Being the Single Point of Contact demands it. Concentrate on the product and on your team. Relay all the external suggestions, feedback, and requirements as your own input into the development. In short – own it.

Our specialists know best

Yes, your company (the client) probably has some IT specialists. They probably know their stuff and take really good care of your system maintenance and ad hoc “check your power plug” issues. They are not the ones to build your app though. Often your IT team will need to deliver bits and pieces to the professional app developer for the needs of your project. Some of them will be out of your area of expertise and you might be tempted to refer a Scrum team member directly to your specialist.

This may sound like a great idea for a shortcut, and a relief to your tight schedule, but can easily turn and bite you on the backside. If such communication is necessary, it should go through SPoC anyway. If you find yourself in this situation, first get the main requirements from the Scrum team in a document and take it to your specialist. Get the specialist to answer/deliver the solution in a document as well. This way you can maintain your position of SPoC and have a well-documented communication on the issue should anything go wrong.

Obviously, bending the rules a little will not tear the fabric of the Scrumverse. As long as the issue is documented and you, as well as your team, know what is happening, allowing some specialist to specialist direct contact to clear out details is not unheard of.

As long as you ensure that you are aware and document this communication, you will be able to keep the idea of SPoC going. One important thing to remember is that you don’t, for any reason relent or delegate any decision-making power to anyone.

A product owner is not a stakeholder

Now this one might seem a bit unclear. What if you’re both? Like in most startup projects, where the woman with the idea and money to make it happen becomes the Product Owner as well. Distinguishing these two roles is extremely important and actually very helpful in a Scrum team.

For one, the fact that you don’t need to put every hard decision in front of your real-life superiors makes it all the easier to get those decisions on time. Another upside is that you have the best possible feedback on how the project’s progress lines up with your vision and expectations – your own.

In terms of in-team communication though, the distinction of the roles is necessary. You will need to remain strictly the Product Owner when working with your Scrum team. Stick to the stuff that is important for your product’s development. In all matters unrelated, like contract negotiations, money issues etc. go to the IT company’s management.  

Back to Scrum work – if it’s not going in the Backlog, it’s not a matter for the Scrum team. As long as you can keep this occasional split personality going, you should be just fine.

Owning product for life (cycle)

Change, continuous adjustments, and on-going collaboration are all natural for agile software development. The structure and rules of the Scrum methodology allow this versatility to be kept in check. Keeping a Single Point of Contact for external communication is one of the core rules that allow proper coordination of an agile project.

SPoC – Multiple signals from outside = less control on project

To work efficiently, a Scrum team must have a complete clarity of the chain of responsibility and accountability. Disrupting the integrity of the team with external influence usually causes more issues than it solves. Especially when the disruption comes from multiple sources and goes on uncontrolled and undocumented. Too many cooks are sure to spoil this agile broth.

From a Product Owner’s perspective, the more outsiders you allow direct access to the project the less control you have over the development. In effect, you might end up with a product that is inconsistent with your grand vision.  

As obvious as it may sound, you must own your product. Knowing it through and through is your prime responsibility. Throughout the development, you will have the opportunity to learn all there is to know about it to the smallest detail. Your role as the Product Owner will not end with the launch of your app. You will own it through its whole application lifecycle. The knowledge acquired during development will be invaluable for future growth. Remaining the SPoC (Single Point of Contact) will ensure that you remain aware of every aspect, issue, and capability of your product. Having the whole development process well documented will make you the sole specialist in managing the app and the go-to woman in all things related to it.