Full Delivery Lifecycles

Disciplined Agile Delivery (DAD), the solution delivery portion of the Disciplined Agile (DA)framework, supports several full delivery lifecycles.   It does this because solution delivery teams face different situations, so one lifecycle will not fit all.  This article explores the concept of what a full delivery lifecycle means, overviews each of the lifecycles supported by DA, overviews the waterfall/serial lifecycle (which is not explicitly supported by DA), and how to choose and evolve between the lifecycles.

Table of Contents

This article is organized into the following sections:

  1. The 30,000 ft. view
  2. Phases? Really?
  3. The DAD lifecycles
  4. What about waterfall?
  5. Choosing a lifecycle
  6. Lifecycles and continuous improvement
  7. Why support several lifecycles?
  8. The downside of supporting several lifecycles
  9. Get lifecycle posters
  10. Related reading

The 30,000 ft. View

One of the key aspects of Disciplined Agile Delivery (DAD) is that it promotes a full, beginning-to-end, solution delivery lifecycle.  Figure 1 below overviews a high-level view of a project-based delivery lifecycle. It is a three-phase lifecycle, more on this in a minute, where you incrementally build a consumable solution over time. We start with this high-level view so that we can explore several important concepts before diving into details.

Figure 1. A high-level view of the delivery lifecycle (click to expand).

DAD high-level delivery lifecycle

Granted, as you see in Figure 2 which depicts more of a system lifecycle there is more to the agile SDLC than just those phases. First, there are pre-project aspects to portfolio management where potential projects or products are identified, priortized, and sufficiently funded to start an Inception phase effort.   Furthermore, business and technical roadmaps may be available to guide the team’s efforts.  After Transition a solution is operated and supported in production (or the marketplace in the case of commercial products). Eventually, potentially after decades of use, a solution is retired (taken out of operation). If we were to look at things from the point of view of IT, there are also cross-product/project concerns at the enterprise level such as enterprise architecture, portfolio management, reuse engineering, and more that the DA toolkit now supports. Figure 2 also indicates how the Construction, Transition, and Production phases are what is typically considered the purview of Disciplined DevOps.

Figure 2. A high-level system lifecycle (click to expand).


High-level system lifecycle

Phases?  Really?

First, the DAD delivery lifecycle explicitly calls out three phases for agile project teams:

  1. Inception. Team initiation activities occur during this phase. Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2013 Agile Project Initiation survey found the average agile team spends about a month in Inception whereas the most common iteration/sprint length is two weeks). So in DAD’s Inception phase we do some very lightweight visioning activities to properly frame the project. It takes discipline to keep Inception short.
  2. Construction. During this phase a delivery team will produce a potentially consumable solution on an incremental basis. They may do so via a set of iterations (Sprints in Scrum parlance) or do so via a lean, continuous flow approach (different versions of the lifecycle are discussed later). The team applies a hybrid of practices from Scrum, XP, Agile Modeling, Agile Data, and other methods to deliver the solution.
  3. Transition. The DA recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise. Delivery teams, as well as the enterprise overall, will streamline their deployment processes so that over time this phase become shorters and ideally disappears from adopting continuous deployment strategies. It takes discipline to evolve Transition from a phase to an activity.

The DAD Lifecycles

The DA toolkit does not prescribe a single lifecycle, unlike other agile methods such as Scrum. In the DAD book we focused on two versions of the lifecycle, the agile (Scrum-based) and the lean (Kanban-based) versions, although since the2012 DAD book came out we’ve added four lifecycles, two supporting continuous delivery, an exploratory (Lean Startup) lifecycle, and a program (team of teams) lifecycle. The point is that every team is in a unique situation, so for the DA toolkit to be effective it must be flexible enough to support several versions of a lifecycle.

In this section we present overviews of each DAD lifecycle, each of which links to a more detailed article.  The DAD lifecycles are:

The Agile Lifecycle: A Scrum-based Project Lifecycle

Figure 3 presents a detailed view of DAD’s Agile lifecycle which extends Scrum’s construction lifecycle. We call this the basic/agile lifecycle because it’s likely where you’re going to start. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.

Figure 3. DAD’s Agile (Scrum based) lifecycle (click to expand).

DAD Agile Project LifecycleIn addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle:

  • It’s iteration based
  • It uses non-Scrum terminology
  • It shows inputs from outside the delivery lifecycle
  • There is a work item list, not a product backlog
  • It includes explicit milestones

The Lean Lifecycle: A Kanban-based Project Lifecycle

Figure 4 depicts what we call the Lean lifecycle.  This lifecycle promotes lean principles such as minimizing work in process, maximizing flow, a continuous stream of work (instead of fixed iterations), and reducing bottlenecks. New work is pulled from the work item pool when the team has capacity. While Scrum prescribes the use of a set of “ceremonies”, such as the daily co-ordination meeting (Scrum), iteration (sprint) planning sessions, retrospectives to be done on certain cadences within the iterations (sprints), Lean does not prescribe this overhead and instead suggests that it be done if and when necessary. This requires a degree of discipline and self-awareness not usually found on teams new to agile, hence this lifecycle is considered advanced. While the concepts of Lean and the Kanban system it uses are very easy to learn, it can be difficult to master the principles of lean flow and maximizing the throughput of the system.

Figure 4. DAD’s Lean lifecycle (click to expand).

DAD Lean Project Lifecycle

There are several interesting features to this lifecycle:

  1. It supports a continuous flow of development
  2. Practices are on their own cadences
  3. It has a work item pool

The Continuous Delivery: Agile DAD Lifecycle

The Continuous Delivery: Agile lifecycle is depicted in Figure 5. This lifecycle is a natural progression from the Agile lifecycle. Teams typically evolve to this lifecycle from the Agile lifecycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile lifecycle is that the continuous delivery lifecycle results in a release of new functionality at the end of each iteration rather than after a set of iterations.  Teams require a mature set of practices around continuous integration and continuous deployment and other Disciplined DevOps strategies.

Figure 5. DAD’s Continuous Delivery: Agile lifecycle (click to expand).

The Continuous Delivery: Lean DAD Lifecycle

Figure 6 depicts DAD’s Continuous Delivery: Lean lifecycle. It is basically a leaner version of the previous lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.  As with the agile version of the continuous delivery lifecycle, teams require a mature set of practices around continuous integration and continuous deployment and other Disciplined DevOps strategies.

Figure 6. DAD’s Continuous Delivery: Lean lifecycle (click to expand).

DAD Lean Continuous Delivery Lifecycle

The Exploratory (Lean Startup) Lifecycle

Figure 7 depicts DAD’s Exploratory lifecycle. This lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base. As a result they need to quickly explore what the market wants via a series of quick learning experiments. In effect this lifecycle can be a replacement for the Inception phase of other DAD lifecycles to validate the vision or used continuously throughout the lifecycle.

Figure 7: DAD’s Exploratory lifecycle (click to expand).

DAD Exploratory lifecycle

A Program Lifecycle for a Team of Teams

Figure 8 depicts DAD’s Program lifecycle. DAD’s Program lifecycle 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 8: DAD’s Program Lifecycle (click to expand).
DAD lifecycle - Program

And Don’t Forget Waterfall

Traditional development, also called serial or waterfall, is based on the idea that the delivery lifecycle should be organized into phases or stages. Figure 1 depicts a classic waterfall lifecycle, similar to what Winston Royce originally proposed (and recommended against) in his 1970 paper.  Figure 8 depicts the V-model version of the traditional approach where the test phase is depicted as multiple stages and there are clear indications of what each testing activity validates (for example, Integration Test validates your architecture).

Figure 9: The Waterfall Lifecycle – V-model depiction (click to expand).

V lifecycle

The DA toolkit does not support a traditional lifecycle. We have purposefully left traditional out of scope for DA. Having said that, we do recognize that in the vast majority of organizations you will have a multi-modal approach where some teams are following an agile approach, some are lean, some are taking a continuous delivery approach, and some are still following traditional. The more disciplined your organization, the more skilled your people, the less likely it is to have traditional teams in practice.  For more about the waterfall lifecycle, read the article When Does Traditional Development Make Sense?

How to Choose a Lifecycle

The team should choose it’s own lifecycle.  They will often do this with the guidance of an experienced Disciplined Agile coach, particularly when they are new to DA.  It’s tempting to have your portfolio management team to make this choice, and they may often make a (hopefully solid) suggestion when the first initiated an endeavour, but in the end it needs to be the choice of the team.  As you see in the table below there are common considerations for when to use each lifecycle, but the primary considerations are always the skill and preferences of the team itself.

The following table compares the lifecycles, suggesting when you would choose to follow each one.

Lifecycle Team Type Time to Market Advantages Disadvantages When to Use
Agile Project Medium
  • Straightforward lifecycle 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
Lean Project Fast
  • Functionality is released into production 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 lifecycle
Disciplined teams with quickly evolving requirements
Continuous Delivery: Agile Product (long lived) Fast
  • Functionality is released into production 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 into production 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 Experimental Fast
  • 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
Program (Team of Teams) Project Medium
  • Enables you to organize a large team of teams (yes, some problems require this)
  • Subteams/squads can choose their own WoWs
  • Coordination required between subteams
  • Requires solid experience with small teams first (if you can’t succeed with a small agile team, you have no hope with a large one)
When you have a very large agile project team that is organized into a “team of teams”
Waterfall/Serial Project Slow
  • Comfortable approach for experienced IT 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 lifecycle
  • 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 migrating an existing system to a new platform

Lifecycles and Continuous Improvement

Disciplined Agile teams are always striving to optimize flow, to improve their process and work environment as they learn through their experiences and through purposeful experimentation. An implication of this is that they may choose to improve their process so much that they effectively work their way into a more effective lifecycle.  Figure 10 shows common evolution paths that we’ve seen teams go through. Along the X-axis you see that over time teams will progress towards a continuous release strategy (along the lines of Disciplined DevOps), being long-lived stable teams as opposed to short-term project teams, towards shorter feedback cycles (due to improved collaboration), and towards automated regression testing.

Figure 10. Evolution paths for DAD lifecycles (click to expand).

Agile lifecycles and continuous improvement

What Figure 10 doesn’t show is how the Exploratory lifecycle fits in. This is because the Exploratory lifecycle isn’t a full solution development lifecycle in its own right. It is typically used to test out a hypothesis regarding a potential marketplace offering, and when the idea has been sufficiently fleshed out and appears the product will succeed then the team shifts into one of the delivery lifecycles of Figure 10. In that way it replaces a good portion of the Inception phase efforts for the team.  Another common scenario is that a team is in the middle of development and realizes that they have a new idea for a major feature that needs to be better explored before investing serious development effort into it.  So the team will shift into the Exploratory lifecycle for as long as it takes to either flesh out the feature idea or to disprove its market viability.

Why Support Several Lifecycles?

This is a good question. First, one lifecycle clearly does not fit all. Teams find themselves in a unique situation: team members are unique individuals with their own skills and preferences for working, let alone the scaling/tailoring factors such as team size, geographic distribution, domain complexity, organizational culture, and so on which vary by team. Because teams find themselves in a wide variety of situations shouldn’t a toolkit such as DA support several lifecycles? Furthermore, just from the raging debates on various agile discussion forums, in agile user groups, at agile conferences, and even within organizations themselves it’s very easy to empirically observe that agile teams are in fact following different types of lifecycles.

Second, we were uncomfortable with the idea of prescribing a single lifecycle. We wanted to avoid prescription in the DA toolkit to begin with, for all the rhetoric about the evils of prescription within the Scrum community it’s clear that Scrum is in fact quite prescriptive in practice. We’ve seen many teams get into trouble trying to follow agile methods such as Scrum to the letter of the law in an environment where “Scrum out of the box” really isn’t a good fit.

Third, we’re firm believers in process improvement. If you are in fact improving your process as you learn, is it not realistic that your lifecycle will evolve over time? Of course it will. We’ve seen teams start with something close to the basic/agile lifecycle that evolve it to the advanced/lean or continuous delivery lifecycles over time.

The Downside of Supporting Several Lifecycles

There is clearly a downside to explicitly supporting several lifecycles. By doing so we explicitly admit that DA teams will be follow a unique tailoring of the process that best fits their situation, a concept that can be antithetical in organizations still clinging to the notion of repeatable processes (DA promotes repeatable results over repeatable processes). It also makes it clear that enterprise professionals, such as enterprise architects or data management groups, need to be sufficiently flexible to support several delivery lifecycles. Instead of sub-optimizing around such enterprise processes (i.e. forcing all project teams to conform to a single data management strategy) you instead want to build enterprise teams that are sufficiently skilled and flexible to support delivery teams in a manner which best suits the delivery teams. Finally, it’s clear that governance needs to be results based, not artifact based. The good news is that DA builds effective governance right into the toolkit.

Get Lifecycle Posters

Would you like printable posters for the five lifecycles?  Disciplined Agile Consortium (DAC) members can download printable PDF files.  Not a member?  Don’t worry, you can sign up for free.

Related Reading

Have any Question or Comment?

31 comments on “Full Delivery Lifecycles



Should be, “It includes explicit milestones” not “In includes explicit milestones”.


1) Suppose your Team Size is 107 persons… and in the process goal “Form intial team” you decide to have 10 Teams of 7-12 Persons.
Is it possible that Team A does CD: Lean, Team B does the scrum based approach, Team C does the lean startup approach, Team D does the Kanban-like method…?

2) If question 1 is ‘yes’: With all these different approaches for an individial team…it feels like it is going to be very difficult to perform some kind of integration? Is it coverable just by adjusting the process goals?

Thank you 🙂


Here are my thoughts:
1. Yes, assuming that it makes sense for the teams to do so and that they have the skills required.
2. Yes, it will be a bit more difficult but not that much. The real issue is having a team of teams, and the need to integrate often and early. The goal Coordinate Activities has advice for coordinating between teams, so choose the options that make sense. We’re just about to release an update to that goal, likely in March, so stay tuned. You might also want to look at the article about large agile teams on the site as there’s a bit more to it than holding a daily “scrum of scrums”.


Question – how many companies have adopted DAD lifecycle?
I`m working agile for few years now and this is my first encounter with DAD. It seems like each lifecycle explained is actually one of the agile framework with a twist:
1. The Agile/Basic Lifecycle: Extending Scrum – is scrum that includes nonfunctional or zero-value task as part of your “to-do list” (action item list or product backlog). Ok. but this is nothing new. It is also nothing to do with the scrum framework as it states nowhere that you shouldn`t do it. Maybe I have misunderstood.
2. The Advanced/Lean DAD Lifecycle – is Kanban. Different swim lanes is part this.
Other 2 are advanced or leaner version of #2.
So what is the difference in approach here? The fact that team should be “agile” enough to work on different lifecycles based on the product demands?
I`m asking not because I have something better, but really to understand.


Oleg, good questions. First, we don’t track adoption rates at all. At the Agile 2015 conference earlier this month we ran into several companies that had been doing DAD for years yet had never contacted us.

As for Basic Lifecycle, any lifecycle in general, it’s the team’s choice as to what types of work items they choose to include or not. Scrum was very prescriptive years ago as to what could go on the backlog, but recently has gotten a bit more flexible once others had popularized the idea.

The Advanced/Lean lifecycle is Kanban based, yes. The Continuous Delivery lifecycle is an advancement over this lifecycle, the Exploratory lifecycle is based on Lean Startup.

The fundamental idea is that teams should choose a lifecycle that meets the needs of the situation that they find themselves in. Disciplined Agile is the first framework that makes this explicit, methods such as Scrum prescribe a single lifecycle making it rather inflexible in my opinion.

Valentin Tudor Mocanu

Basic Lifecycle seems to be pretty generic for Agile at least. XP life-cycle has “Release planning” (you could read Inception), rest of development iterations up to acceptance (you could read Construction), Acceptance and Release (read Transition).

IMPORTANT (imo) – DAD has adopted the most used Agile life-cycle with the name of Basic Life-cycle and has offered more useful guidance than the other Agile methods for the same life-cycle.
That mean Basic Life-cycle is already adopted, but with DAD could be improved and adopted better to the context,


Scott W. Ambler, i just want to seek your opinion on this. Is not this all just an elaboration of EUP (Phases / Disciplines) minus Elaboration Phase and Retirement Phase. It looks more like a sub-set of EUP, but not wrapper. In order to understand EUP Phases/Disciplines i study DA Processes. I feel like EUP is actually a superset of all methodologies which originally encompass everything required to Deliver in real agile way, like 17 disciplines categorized into three categories Development Disciplines, Support Disciplines and Enterprise Dsiciplines. Then there are 6 Phases, also Iterations in each phase. Rest in Agile Manifesto is verbose like unethical “Daily Stand-up Meetings”, “Self-organizing / Self-Managing and Cross-Functional Delivery Team”, “Interaction over Process” etc

Scott Ambler

Fakhar, a few thoughts:
1. Yes. there are some similarities between EUP and DA. DA is more comprehensive and has a stronger foundation in lean and agile principles though.
2. When it comes to the high-level lifecycle, products and particularly projects, go through similar phases (yes, the names may change).
3. Regarding your thoughts about the Agile Manifesto, you seem to be struggling to understand some fundamental concepts. The ideas that you label as unethical certainly are not. You would be well served to get involved with some conversations about agile on LinkedIn or Yahoogroups.

Dim Yang

Excellent detailed material. Thank you. The practice of application of life cycles, in one form or another, should be supported by the implementation of best practice processes of course, which with a certain level of adaptability will be adopted by the team gradually. We, in my company, tried several methods already. And as always it happens, the simplest has proved to be the most effective.

As it turned out, our programmers (the team has only 15 people) do not like long meetings, regular monitoring, and reports – it annoys them and distracts from working. So at the end of it, we concluded that we need only 2-3 techniques, which do not detract their attention away, while the project/product manager does the rest for them – analysis and grooming of tasks, prioritization of them, the implementation plan for new features, and so on.

So, we employ the following practices:

1. daily stand-ups, but not in the classic version, standing and alive, but through Slack. Even if the team is in the same office, they prefer this way of reporting and meetings
2. retrospectives at the end of the sprint
3. sometimes, quite rarely, we run polls on the current sprint or on the priority of tasks.

This is enough for us, that’s why guided by the principle of Occam’s razor, we do not multiply entities beyond necessity.


Buenas noches me gustaría ver una linea del tiempo desde la creación del DAD hasta la fecha, con su debida explicación de como a evolucionado a lo largo de este tiempo.

Me gustaría que el contenido de la informacion la suministraran en español, esto con el objetivo de difundir el conocimiento de DAD y que se pueda conocer en la comunidad hispana, esto podría ayudar a escoger este marco de trabajo como una opción de implementación en la organización.


Donaldo, there is a Spanish translation of the book Introduction to Disciplined Agile Delivery available on Amazon.

As far as other translations go, we invite people to get involved and translate existing materials that we’ve posted on the web.


Leave a Reply to Two dimensions: Just in time and Envisioning | Agile Design = Adaptive Design Cancel reply

Your email address will not be published. Required fields are marked *