14

We're a governmental organization and we're contracting with software companies to implement our projects. We're adapting the Scrum framework.

Question: Should the Product Owner be from our organization or the company we are contracting with? What is the best practice? and why?

4
  • 1
    Not worth an answer, but I'd split the difference between the two answers to recontextualize the question " What are you contracting for?" If you know the solution well enough to act as the product owner, then let the contract for development & retain the role (and the risk). If not, then let the contract for the software, yield the role and price in the risk.
    – MCW
    Sep 28 '20 at 12:50
  • Hey askm, welcome to pmse. Just as a heads-up:as a general practice, consider waiting 24 hours before accepting an Answer. Otherwise you may scare off people in other timezones from providing alternative Answers.
    – Sarov
    Sep 28 '20 at 13:35
  • 1
    As a side note, you might want to consider swapping over from pure Scrum to a more structured project management methodology with a more formalized governance structure in the future; in Australia, most government contracts specify the use of a Prince2/DSDM hybrid methodology for that reason.
    – nick012000
    Sep 30 '20 at 7:29
  • What does the contract demand? Is this something being developed for use by your "governmental organization", or to be owned by your group? If it's merely something used by, the PO should be from the vendor. If it's to be owned by, the PO must be from your group.
    – warren
    Sep 30 '20 at 17:36
14

There is no canonical answer to this question, although as a rule of thumb, it would be better for the PO to be from the client side, not the contractor side.

The Scrum Guide says this about the PO role:

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

A PO on the customer side has more chances of fulfilling these attributes. I'm not saying a PO on the contracting side can't do that, but there might be some issues:

  • they need to learn if the domain isn't familiar to them already. This takes time so you might build the wrong things at first while they figure it out.
  • for the PO to succeed, the Scrum Guide says that the entire organization must respect their decisions. Your organization (especially a governmental organization) might not do that for an external PO. You risk the contractor PO to transform into a project manager, and you don't want that.
  • there might be some conflict of interest as the external PO might take the side of the contractor company and defend their interests instead of fighting for the value the product must bring.
  • etc.

Of course, there are also disadvantages to having the PO from your organization:

  • your PO might not sit with the development team making communication and collaboration harder.
  • your PO might treat the team as an execution unit that needs to to what they are told and start bossing them around. Combine this with the previous point and you risk less involvement from the PO.
  • with my experience with how governmental projects work, there might be no involvement whatsoever as thinking is "old school", i.e. Waterfall. So be careful about how the governmental organization does things (software development or otherwise).
  • etc.

There are pros and cons to both options, but both can work if you have the right people and the proper level of engagement. Ultimately:

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

... so think about the chances for this to happen if the PO is on one side or the other of the work being done, then go for the option which maximizes the value of the product. If you can have your PO at their location, inside their team, I think that would be the best combination.

15

And I'm going to take the middle ground between Bogdan and Thomas...

Whichever side has the more competent PO.

Bogdan already listed the responsibilities of a PO. To (over)simplify it in a single sentence, however, it would be:

The purpose of the PO is to act as a link between the customers and the Development Team.

As such, the PO is really the only role that can feasibly come from either side. Because s/he serves as the link between the two, s/he needs to be able to interact with both.

That, therefore, would be my largest concern - which is going to be easier - our PO interacting with their customers? Or their PO interacting with us? Most likely, it will come down to the communication skills and availability of the POs in question.

8

I'm going to disagree totally with Bogdan's answer. I believe that, in most cases, it's better for the developing organization to supply the Product Owner. There may be cases where it does work out, but I'm hesitant.

The first thing to consider is why you are contracting with a software company instead of building the software yourself, internally. It's most likely because your organization doesn't have deep expertise in software development, but the firms that you have contracts with have that expertise. The expertise would include product management, project management, and requirements engineering in addition to the design, build, and test aspects.

Generally, I'm concerned when customers dictate the development process. This is partially for the same reason as above - the customer is contracting out the work because they do not have the resources (usually staffing or knowledge) to do it on their own. The development organization should bid on the contract based on their ways of working and then execute on that way of working. It is helpful when the customer is willing to commit to Agile Software Development since frequent involvement can help to get to the right thing faster through rapid feedback loops.

The Product Owner role is also a full-time job of working with the development team. By taking on the Product Owner role, you are committing to working your entire time to supporting the development teams creating that product. You are looking at involvement in backlog refinement, Sprint Reviews, and Sprint Retrospectives - this could easily be (4 hours * weeks in Sprint) + 4 hours + 3 hours per Sprint, give or take. Your responsibilities to this team would come before other obligations, otherwise, you are a bottleneck to the team achieving their goals.

I'd also point out that the Product Owner coming from the customer will likely lead to a bespoke software product. There may be cases where this is appropriate, but there may be cases where you exclude potential contractors if the structure or contract prohibits building something that could be leveraged as a platform for future work.

Generally, the best thing to do is to have a Product Owner that is from the same organization as the development teams creating the product and is fully dedicated to them. Anything else runs the risk of slowing the team down. It may be necessary for a Product Owner to ramp up, but the long-term benefits of close alignment between the Product Owner and development team outweigh the necessary ramp-up time.

3
  • I would agree here that if the contracting company is really using Scrum, they should already have a strong product owner and part of that person's job is making sure your needs are met. If you were going to have a representative from your organization working closely with the development team, you'd probably be better served with how XP approaches that.
    – Daniel
    Sep 28 '20 at 15:38
  • 2
    @Marcus The idea that the PO must be a current or former software engineer is absolutely wrong. I've worked with many good product managers and Product Owners who were never software engineers. The PO is also not "in charge" of anything. I'd also point out that the developing organization is always responsible for eliciting and understanding requirements.
    – Thomas Owens
    Sep 29 '20 at 18:24
  • 1
    @Marcus Strongly disagree. The PO needs to speak the language of the users as much as possible. There will be lots of people on the contract side who can work with the PO to translate that into development. (This may be flexible if your usage is in common situations but the more specialized the application is, the less likely it is that you will have anyone on the contracting team who has enough background. E.g. scientific software, legal software, etc.) Sep 29 '20 at 23:34
3

Client side. The PO needs to be able to identify the business priorities, provide subject-matter expertise and justify his or her decisions to the client organisation. Most software probably requires organisational or procedural changes at the client so it's also an advantage if the PO is in a position to make such changes happen. Finally, it's to both parties' advantage if the PO controls and accounts for costs - the PO makes decisions which may impact the cost of the work and if the client is paying then they will want to have control of those costs.

3

I am in the same situation, I am a PO on the client-side. To me, that is the only option because most times the contractors are after their selfish interest. The PO has to defend the customer and business objectives in delivering business value. The PO needs to be able to make strategic decisions in view of the overarching business strategy. The contractors are not in the position to do so but just to make money and move on.

1
  • This is a good point. As someone who is more often on the "contractor" side of the equation I will also say that I would not want to be in the position of PO. An employee of the client is in a much stronger position to identify the right priorities, to justify decisions to other stakeholders and to make sure the project is perceived as a success. Having a good PO on their side is good for customer relations.
    – nvogel
    Sep 30 '20 at 16:14
2

Actually, there's another strategy: "cooperating de facto 'product owners' on both sides!"

On the customer side, this person is tasked with directly representing the business interests of the company as they relate to this software. This person can most easily put himself or herself into the "proxy position" of representing the actual system user community, while also possessing the requisite software-development know-how.

Meanwhile, on your side, you have what might be "the actual" PO, who is most aware of exactly what your teams are doing.

These two persons are tasked to be in constant and direct communication with one another in order to best fulfill the Product Owner's role in the project ... collectively!

To me, "Product Owner" is probably the single most-important role in assuring the smooth deployment and business acceptance of the project, and yet it is also the most vulnerable to being torpedoed by "assumptions" or failures of communication – especially where more than one company or business unit is involved. This is a very efficient way to avoid these snares. Plus, it helps to reinforce the idea that the client really does play an active, participative role in what they're ultimately paying for.

4
  • 5
    From the Scrum Guide: "The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner."
    – Sarov
    Sep 28 '20 at 16:05
  • Yes, but in my scenario there are two people "working together in one role." One of them really is inside the client organization; the other one is in yours. Both of them are equally aware, in detail, of the Product Owner perspective and they are collectively performing it. Communications misunderstandings are now much less likely to occur. One person might always overlook something, but two cooperating people probably won't. To me, "PO" is the most vital role of all. Sep 29 '20 at 15:03
  • 1
    The problem is two people can disagree. That's why the Scrum Guide mandates that there is one PO. The PO may delegate if s/he wishes, but always retains the final, inarguable authority over the product.
    – Sarov
    Sep 29 '20 at 16:06
  • 1
    I've been a part of a project (that involved a government organization) that was setup like this, and it worked surprisingly well. But that may have been because the two PO's had known each other a long time and worked extremely well together. They were really in sync.
    – ouflak
    Oct 1 '20 at 8:26
2

In the one governmental scrum project I worked in, the government agency used an external IT consultant as Product Owner.

This ensures that the product owner has no split loyalties while having the necessary expertise. On the negative side, the product owner needs significant ramp up time to understand the requirements, and the possibility of disagreement between the product owner and the users of the product is amplified due to physical and organizational distance.

1

I am supporting Mike's answer to utilize PO's advantages from both sides.

To be more specific, PO from your org should be the real single PO to make final decisions, maximize product value.

On the vendor side, we can have a proxy PO (or in my context can be called as Business Analyst) who works more closely with Development team to clarify requirements and prepare future stories (which will be approved by real PO).

3
  • 1
    PO makes the decisions on scope and priorities and you are saying you would have only one person doing that, not two. A BA who clarifies requirements and prepares future stores is not doing the job of a PO.
    – nvogel
    Oct 3 '20 at 16:12
  • 1
    proxy PO/ BA can help on 2 specific PO's responsibilities: clearly express backlog items (as it's her/ his core skill), & ensure Development team understands properly (as they are physically closer to each other) This is even more effective if the real single PO is part time or new to this role (which I experienced several times) Oct 3 '20 at 16:31
  • 1
    That's a fair point. I think you have nailed the reason why there is even room for doubt here: dev perspective vs stakeholder perspective. My doubt about the proxy PO idea would be that it seems to suggest the real PO may not be working closely enough with the dev team.
    – nvogel
    Oct 3 '20 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.