This is the dysfunction of teams with Project Managers as well as Product Owners. Does your organisation have both Project Mangers as well as Product Owners? If so, to whom do your teams report? What does it depend on? Because if it does depend then you are doing a disservice to your teams and will have difficulty moving towards greater agility. I have a customer right now that has this situation with cross application teams however there are additional complications.

Figure: Project Hierarchy
Project Managers are assigned projects that might operate against multiple products. Product Owners are given products. This results in often an application that while it has a single Product Owner could have multiple teams run by multiple project managers. Unless all of the team members have ADHD they are going to have issues with multi-tasking.

Figure: Team A supports two masters
Here is where it then gets a little tricky. We have Product Owners that want a view of the work that is under way from the perspective of the Product, which is reasonable. But they definitely do not want the same view as the Project Manager who cares about work done that achieves his project. Since budget is done at the ‘project’ level this means that funding is in the hands of the Project Manager and there is no way that a Product Owner can be accountable and responsible for value delivery. So while the Project Manager owns a budget and work breakdown the Product Owner owns the Application and breakdown. While the PO is supposed to be accountable and responsible for the delivery of value within the scope of the Product a ‘Project’ might have a scope that transcends product and is the responsibility of the Project Manager. Man what a mess…
Figure: Team has no idea who to listen to
The result is a dysfunctional situation where a team can have many masters. Not only are they beholden unto a project manager, they may have to serve more than one Product Owner. This breaks one of the few golden rules of agile software development: The team should have but one master. If you are moving towards agility then you need to avoid having more than one person in the role of Product Owner as much as possible. The Team will end up context switching and having to split time between Product Owners backlogs even if they use one combined view to make it seam like they have one order.
Figure: Product Owner provides a single point of order
The only way to combat this is to reorganise the organisation so that the issue does not exist. You should reform the Teams around the Product Owners (and thus the products.) The Project Managers then become another set of stakeholders that the Product Owner must listen to. This is the only way to reach agility with all of those voices pulling the team is different directions.
However the customer is large, which is no excuse. However in large organisations these kinds of things do not change quickly. It will eventually, but that may take many years and a lot of courage from management to achieve. In the mean time you, like me, may still need still need to model this is TFS to allow Teams and Product Owners to work together and for Project Managers to understand the work that they are doing.
What to read next
Product Owners are not a myth
Explains the Product Owner role in Scrum, common challenges with proxies, and how support teams like Business Analysts can help manage large …
TFS for cross team and cross business line work item tracking
Explains how to use a single Team Project and Team Field in TFS to streamline cross-team work item tracking, reporting, and collaboration …
One Team Project to rule them all
Explains how to manage multiple teams and projects in Team Foundation Server using a single Team Project, with tips on Agile planning, …
Working within a single Team Project with Team Foundation Server 2012
Explains how to organise teams, products, and projects within a single Team Project in Team Foundation Server 2012, covering design, …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Getting Started with Objectives & Key Results
Learn how to successfully implement OKRs by aligning clear strategy, fostering transparency, empowering teams, focusing on outcomes, and …
OKR Guide - A Social Discipline for Shared Focus, Measurable Contribution, and Strategic Learning
A certification proves you’ve passed a test
Certifications show test-passing ability but don’t prove real-world product skills. Experience, judgement, and stakeholder influence matter …
Most companies still get Product Ownership wrong
Many organisations misunderstand Product Ownership, treating it as simple backlog management instead of a strategic, accountable role …
The Definition of Done is a Commitment to Quality
Defines the Definition of Done in Scrum as a clear, shared standard for quality, ensuring increments are releasable, transparent, and …
Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar
Is your team’s “done” really done? Discover how a clear, objective definition of done boosts quality, agility, and trust in product …
Acceptance Criteria vs Definition of Done: Why Getting This Right Builds Trust and Delivers Quality Faster
Stop confusing acceptance criteria with definition of done, learn the crucial difference to boost quality, speed, and trust in your agile …
How to Evolve Your Definition of Done: Start Small, Grow Smarter, and Build Lasting Momentum
Unlock a smarter Definition of Done, start small, evolve standards, and build team momentum without overwhelm. Discover how progress drives …
Why Most Transformations Fail Without Honest Conversations
Most transformations fail without open, honest conversations that address real issues, making transparency and tough dialogue essential for …
Why Your Definition of Done Is the Secret Weapon for Real Business Impact and Agile Growth
Transform your definition of done into a strategic advantage, deliver real value, reduce risk, and drive business impact with every sprint.