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).
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.
This team is responsible for requirements management activities within the program. This includes:
- 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.
- 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.
- 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.
- 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.
- 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.
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.