Disciplined Agile Program Management – The Product Owner Team

Large solution delivery teams, let’s say fifty or more people, are often referred to as programs (programmes in UK English). Such teams are often organized into teams of teams, as depicted in the diagram below.  Each of the sub teams will work on their part of the overall solution and to do so effectively there needs to be coordination between the sub teams.  On large agile teams this coordination often proves to be complex, which is why a leadership team is introduced.  This leadership team coordinates:

  • Requirements. Requirements are managed by the Product Management (also called a Product Owner) team.  This team is made up of the Product Owners from each sub team.  They will meet as needed, typically several times a week. This group is the focus of this blog posting.
  • Technical concerns. The Architecture (or Architecture Owner) team, comprised of the Architecture Owners from each sub team, is responsible for identifying and then governing the architectural strategy for the program.  Activities of this group include negotiating changes to the architecture vision over time, resolving disputes about technical issues between sub teams, and sharing technical learnings across sub teams.  It is common for this team to meet weekly with ad-hoc discussions occurring on an as-needed basis.
  • Management concerns.  Management concerns, such as members of different teams not getting along, transfers of people between teams, and schedule dependencies will be coordinated by the Team Leads from the sub teams.  This team is often called the Product Delivery team or simply the Management team (yuck).  As with the Product Management and Architecture teams this team will meet regularly as appropriate.
  • Itself.  This is the responsibility of the Program Manager. This person may be a Team Lead on one of the sub teams, although more often than not fulfilling this role proves to be a full time job.  The Program Manager will guide the overall program team, ensuring that the three leadership sub teams are working together effectively and that they are meeting to coordinate their own activities as appropriate (and typically on different schedules).

Large Agile Team Structure

Product Management/Ownership Team Organization

The Product Owner in each sub team is a member of the Product Owner team for the program, as depicted in the following diagram.  Individual Product Owners will typically spend 80-90% of their time on activities that are directly related to supporting their sub teams and the rest of the time to requirements management activities at the program level.  The Product Owner team is lead by a Chief Product Owner (CPO).  The CPO may be a PO on a delivery team, this is common on small programs, although for larger programs the responsibility of leading the Product Owner team will prove to be full time work.  In organizations with a strong Product Management culture, the Chief Product Owner may be a senior Product Manager.

Product Owner team for a large agile program

This team is responsible for requirements management activities within the program.  This includes:

  1. Identifying the initial scope of the program.  The PO team will perform just enough initial requirements modelling, with active stakeholder participation where possible, to identify the initial scope of the program.  This scope is very likely to evolve over time, but for now the goal is to explore the scope sufficiently to get the program headed in the right direction.  See the process goal Explore Initial Scope for more details.
  2. Ongoing requirements elicitation.  A primary job responsibility of anyone in the Product Owner role is to elicit and explore stakeholder requirements.  In the case of a program the entire PO team must coordinate their requirements elicitation efforts.
  3. Assigning requirements to sub teams.  As new requirements are identified the PO team will collaborate to identify the appropriate sub team to perform the work and then assign the work to that team.
  4. Managing requirements dependencies.  There are always dependencies between requirements, and these dependencies should be managed by the appropriate Product Owners.  For example, if a requirement (R1) assigned to sub team A depends on a requirement (R2) assigned to sub team B then ideally R2 should be implemented either before or at the same time as R1.  Otherwise the people implementing R1 will need to mock/stub out the missing functionality until it becomes available.  Read Managing Requirements Dependencies Between Agile Teams  for more details.
  5. Developing a product roadmap.  The PO team is responsible for developing a product roadmap for the program which lays out a high-level business direction for the product. This roadmap should reflect your organization’s overall business roadmap, if you have one.

The Product Owner team will meet as often as they need to.  We’ve seen some PO teams meet on a daily basis for 30 minutes each to manage requirements between sub teams.  We’ve also seen PO teams that meet weekly for two hours to do this work.  The important thing is that they self organize to determine what works best for them.

The Product Owner team may include business analysts (an example of a specialist role in DAD) who supports the POs in working with stakeholders to understand their requirements.  This is particularly important whenever the team is addressing significant domain complexity or whenever stakeholders are geographically dispersed.

Tailoring Considerations

In medium-sized enterprises this Product Owner team approach may be applied to your entire IT department.  In this case the focus of the PO team is that of your entire portfolio of ongoing IT solution delivery efforts and not just a single program of interdependent teams.

In large enterprises the Product Owner team for a program may be part of a larger Product Management team for the entire organization.  More on this in a future blog posting.

Have any Question or Comment?

2 comments on “Disciplined Agile Program Management – The Product Owner Team

Valentin Tudor Mocanu

This organization seems to be logic and natural. I have seen these kind of teams of teams working very well.

There are several aspects that could be very difficult to manage, not because of the organization, but because are parts of the problem complexity. Mostly are related to integration aspects and overall planning.
– Integration risks are high, starting with requirements; if something is missing for a team could affect the work of all teams
– Solution integration aspects mus be managed early
– Delays on intermediate results of some teams could affect many others
– Overall plans are difficult to manage

From the start, this organization offer support for these kind of problems:
– PO based approach could eliminate some of the above risks
– The overall product roadmap will also be very useful

Just a note: beyond requirements dependencies, that will induce also dependencies on the solution part, the solution dependencies must be also managed in order to not introduce not desired problems. Flexibility and adaptability must be attributes of these solutions, considering also clear (and clean) interfaces between parts.

Maybe one of the interesting aspects are the criteria to allocate work/responsibilities to the teams. The possible trap is the effects of the Conway Law, that could destroy tin time the effectiveness and the efficiency by inducing low an decreasing adaptability, The methods proposed by Scrum for teams of teams, for example, from what I know, have still no answer for such problems.

Seems to be an interesting subject, because it is useful and in most of the cases it is too superficial described.


Valentin, you make great points. I’d like to respond to some of them:
1. Integration. This is definitely a challenge. The DAD framework suggests several strategies for addressing this, including the individual teams handling integration on their own (this can have scaling challenges, particularly with legacy systems involved); having someone(s) responsible for overall system integration (DAD calls this out as a secondary role that can occur at scale); and/or having a parallel independent test team that addresses system integration testing (and other issues).
2. Solution/technical dependencies. That’s typically addressed by the Architecture Owner team, the topic of a future blog posting.
3. Allocating work to teams is the topic of my next blog. And yes, it’s interesting.


Leave a Reply to Valentin Tudor Mocanu Cancel reply

Your email address will not be published. Required fields are marked *