Disciplined Agile

How to Choose a Disciplined Agile Life Cycle

Disciplined Agile teams choose the best-fit life cycle for them.

Disciplined Agile (DA) teams choose their own life cycle. They will often do this with the guidance of an experienced Disciplined Agile Coach, particularly when they are new to DA. From a standardization point of view, it can be tempting to have your portfolio management team make this choice when they first initiate the endeavor. In the end, though, it needs to be the choice of the team as they are the ones working in the context that life cycle must fit.

Figure 1 depicts a flowchart for the logic of how to choose the right life cycle for your team. 

Life Cycle Choice

Figure 1. A flowchart for choosing an initial life cycle. 

Factors to Consider When Choosing a Life Cycle

Of course, there’s a bit more to it than the flowchart of Figure 1. Constraining factors we keep in mind when choosing a delivery life cycle include:

  1. Team skills. The two continuous delivery (CD) life cycles require the team to have a lot of skill and discipline. The other life cycles also require skill and discipline, although the two CD life cycles stand out. With a serial life cycle, you can get away with lower skilled people—due to the handoff-oriented nature of serial, you can staff each phase with narrowly skilled specialists. Having said that, we have seen many traditional teams with very skilled people on them.
  2. Team and organization culture. The Agile and Continuous Delivery life cycles require flexibility within the team and within the parts of the organization that the team interacts with. Lean strategies can be applied in organizations with a varying range of flexibility. Serial life cycles can, and often are, applied in very rigid situations.
  3. The nature of the problem. The Continuous Delivery life cycles work very well when you can build and release in very small increments. The other life cycles work very well in small increments. Serial is really geared for big releases.
  4. Business constraints. The key issue here is stakeholder availability and willingness, although financial/funding flexibility is also critical. The Exploratory life cycle requires a flexible, customer-oriented, and experimental mindset on the part of stakeholders. Agile, because it tends to release functionality in terms of complete features, also requires flexibility in the way that we interact with stakeholders. Surprisingly, the Continuous Delivery life cycles require less stakeholder flexibility due to being able to release functionality that is turned off, thereby providing greater control over when something is released (by simply toggling it on).

Comparing Life Cycles

The following table compares the life cycles, suggesting when you would choose to follow each one.  As you see in the table below there are common considerations for when to use each life cycle, but the primary considerations are always the skill and preferences of the team itself.

Life Cycle

Team Type

Time to Market



When to Use




  • Straightforward life cycle based on Scrum that is easy to learn due to its prescription
  • Iterations (sprints) motivate teams to build functionality in multi-week batches
  • Releases into production typically months apart
  • Tends to fall apart when requirements change often

Teams new to agile




  • Functionality is released when it`s ready to go
  • Work can be prioritized via a variety of criteria
  • Small batches of work lead to quick flow
  • Requires greater skill and discipline compared to the Agile life cycle

Disciplined teams with quickly evolving requirements

Continuous Delivery: Agile

Product (long lived)


  • Functionality is released regularly at a steady flow (typically weekly)
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment

Long-running teams

Continuous Delivery: Lean

Product (long lived)

Very Fast

  • Functionality is released continuously, typically one or more times a day
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment

Long-running, disciplined teams

Exploratory/Lean Startup



  • Quick and inexpensive way to run business experiments
  • Low-risk approach to validating potential new business strategies
  • Requires a way to target a subset of your (potential) customer base
  • Often not applicable in regulatory compliance situations
  • Often perceived as a strategy for startup companies only

Identification of a new product or service offering for the marketplace where there is a high risk of misunderstanding the needs of potential end users




  • Enables you to organize a large initiative comprises of related initiatives
  • Subteams/squads can choose their own WoWs
  • Coordination required between subteams
  • Requires solid experience with small teams first (if you can’t succeed with small agile team, you have no hope with a large agile initiative)

When you have a very large initiative




  • Comfortable approach for experienced professionals who have not yet transitioned to an agile or lean way of working
  • Tends to be very high-risk in practice due to long feedback cycles and delivery of a solution only at the end of the life cycle
  • Associated risks are often overlooked by management due to façade of predictability and control provided by the paperwork produced

Low-risk situations where the requirements are stable and the problem has a well-known solution. For example, upgrading the workstations of a large number of users or constructing an office building

February 2022