Disciplined Agile® (DA)’s Program life cycle, shown in Figure 1, depicts the flow within an agile program. Agile programs are rare in practice, but they do occur. This is exactly the situation that agile scaling frameworks such as SAFe®, LeSS, and Nexus address, as well as DA.
Figure 1. DAD’s Program life cycle for a team of teams (click to expand).
There are several critical aspects to this life cycle:
- There’s an explicit Inception phase. Like it or not, when a team is new we need to invest some up front time getting organized, and this is particularly true for large teams given the additional risk we face. We should do so as quickly as possible, and the best way is to explicitly recognize what we need to do and how we’ll go about doing so. SAFe has a similar concept called program increment (PI) planning, although Inception is more robust as it includes potential activities around forming teams, explicit requirements and architecture modeling, test strategizing, and more.
- Sub-teams/squads choose and then evolve their WoW. Sub-teams, sometimes referred to as squads, should be allowed to choose their own WoW just like any other team would. This includes choosing their own life cycles as well as their own practices. We may choose to impose some constraints on the teams, such as following common guidance and common strategies around coordinating within the program.
- Sub-teams can be either feature teams or component teams. A feature team works vertical slices of functionality, implementing a story or addressing a change request from the user interface all the way through to the database. A component team works on a specific aspect of a system, such as security functionality, transaction processing, or logging. Our experience is both types of teams have their place, they are applicable in certain contexts but not others, and the strategies can and often are combined in practice.
- Coordination occurs at three levels. When we’re coordinating between sub-teams there are three issues we need to be concerned about: Coordinating the work to be done, coordinating technical/architectural issues, and coordinating people issues. This coordination is respectively performed by the Product Owners, the Architecture Owners, and the Team Leads as you see in Figure 2. The Product Owners of each sub-team will self-organize and address work/requirements management issues amongst themselves, ensuring that each team is doing the appropriate work at the appropriate time. Similarly, the Architecture Ownership team will self-organize to evolve the architecture over time and the Team Leads will self-organize to manage people issues occurring cross teams. The three leadership sub-teams are able to handle the type of small course corrections that are typical over time. The team may find that they need to get together occasionally to plan out the next block of work – this is a technique that SAFe refers to as program increment (PI) planning and suggests that it occurs quarterly. DA™ suggests that you do it when and if it makes sense.
- System integration and testing occurs in parallel. The life cycle shows that there is a separate team to perform overall system integration and cross-team testing. Ideally this work should be minimal and better yet entirely automated. We often need a separate team at first, often due to lack of automation, but our goal should be to automate as much of this work as possible and push the rest into the sub-teams. Having said that we’ve found that usability testing across the product as a whole, and similarly user acceptance testing (UAT), often requires a separate effort for logistical reasons.
- Sub-teams are as whole as they can be. The majority of the testing effort should occur within the sub-teams just like it would on a normal agile team, along with continuous integration (CI) and continuous deployment (CD).
- We can deploy any time we want. We prefer a CD approach to this, although teams new to agile programs may start by releasing quarterly (or even less often) and then improve the release cadence over time. Teams who are new to this will likely need a Transition phase, some people call these “hardening sprints” or “deployment sprints” the first few times. The Accelerate Value Delivery process goal captures various release options for delivery teams and the Release Management process blade for organizations as a whole.
Figure 2. Team structure for a large program (click to expand).
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.