Let’s consider the workflow implied by the Program life cycle in Figure 1 above given the team structure of Figure 2. Someone in the role of Program Manager coordinates the three leadership teams (described in greater detail in Large Agile Teams):
- Product coordination team. This team is responsible for dealing with cross-team “management issues” such as moving people between teams, resolving disputes that cross team boundaries, and any coordination issue that doesn’t fall under the purview of the other two leadership teams. The Program Manager often leads the product coordination team, which is made up of the Team Leads from the delivery sub-teams, and may even be a Team Lead of one of the delivery teams as well.
- Product owner team. This team is responsible for requirements management, prioritizing the work, and assigning work items to the various sub-teams. This team is led by a Chief Product Owner (CPO), not shown, who is often a Product Owner for one more more sub-teams.
- Architecture owner team. The AO team is responsible for facilitating the overall architectural direction of the program, for evolving that vision over time, and for negotiating technical dependencies within the architecture. This team is led by a Chief Architecture Owner (CAO), also not shown, who is often an Architecture Owner on one or more delivery sub-teams.
An important difference between the Disciplined Agile approach and many agile scaling frameworks is that the sub-teams may be following different life cycles. The Disciplined Agile (DA) toolkit supports several delivery life cycles, including the Scrum-based Agile and Continuous Delivery: Agile life cycles; the Kanban-based Lean and Continuous Delivery: Lean life cycles; and the Lean Startup-based Exploratory life cycle. Even when the sub teams are following the same life cycle they may be working to different cadences (or not).
The life cycle diagram of Figure 1 also shows that some programs may include a parallel independent testing effort in addition to the whole team testing efforts of the sub-teams. The delivery sub-teams will make their working builds available to the testers on a regular basis, who will integrate all of the builds into their testing environment. This independent testing effort often addresses end-to-end system integration testing as well as other forms of testing that make better economic sense when done in a centralized manner. Independent testing is common for large programs that are tackling complex domains or complex technologies or that find themselves in a regulatory environment that requires independent testing. The SAFe equivalent to a parallel independent test team would be called a system team, in this case one doing system integration plus independent testing. Same basic concept, slightly different wording.