DAD’s Program life cycle, shown below, describes how to organize a team of teams. Large agile teams are rare in practice, but they do happen. This is exactly the situation that scaling frameworks such as SAFe, LeSS, and Nexus address.
Figure 1. DAD’s Program Life Cycle.
Features of This Life Cycle
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.
- Subteams/squads choose and then evolve their WoW. Subteams, 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.
- Subteams 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 subteams 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. The Product Owners of each subteam will self-organize and address work/requirements management issues amongst themselves, ensuring the 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 subteams 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 suggest that it occurs quarterly. We suggest 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 ideally entirely automated in time. 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 subteams. Having said that we’ve found that usability testing across the product as a whole, and similarly user acceptance testing (UAT), requires a separate effort for logistical reasons.
- Subteams are as whole as they can be. The majority of the testing effort should occur within the subteams 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. A process blade captures the options for a process area – just like process goals are described using process goal diagrams, so are process blades.
When to Apply This Life Cycle
This life cycle is applied when:
- You need a large, team of teams. Some problems require a large team, and in some cases you may even decide to organize that large team into a team of teams. When that occurs, you need a life cycle such as this.
- You have the skills to do agile at scale. To succeed you need to know what you’re doing – if you’re struggling with small-team agile then you’re not ready for large-team agile.