Full Agile Delivery Lifecycles

One of the key aspects of the Disciplined Agile (DA) process decision framework is that it promotes a full, beginning-to-end, solution delivery lifecycle. The figure below overviews a high-level view of the DA 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.

Disciplined Agile Lifecycle - High Level

First, the DA lifecycle explicitly calls out three phases:

  1. Inception. During this phase project initiation activities occur. 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.

Granted, as you see in the following figure 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 framework now supports.

Disciplined Agile Lifecycle - High Level System


The DA framework 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 basic/agile and the advanced/lean versions, although since the first version came out we’ve also described a continuous delivery and an exploratory (Lean Startup) lifecycle. The point is that every team is in a unique situation, so for the DAD framework to be effective it must be flexible enough to support several versions of a lifecycle. Let’s explore four such versions of the lifecycle:

The Agile/Basic Lifecycle: Extending Scrum

The figure below presents a more detailed view of what we call the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle:

  1. It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls sprints).
  2. It uses non-Scrum terminology. Although the lifecycle is Scrum-based we chose to use non-branded terminology in DA, in the case of this diagram the term iteration instead of sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminology use that instead.
  3. It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle.
  4. There is a work item list, not a product backlog. DA has a greater scope than Scrum, and when you take this greater scope into account you begin to realize you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements. For more on this, read Agile Best Practice: Prioritized Requirements.
  5. It includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that delivery teams should strive to meet. Such milestones are an important aspect of agile governance.

Disciplined Agile Lifecycle Basic

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.

The Advanced/Lean DAD Lifecycle

The figure below depicts what we call the Advanced/Lean lifecycle. There are several interesting features to this lifecycle:

  1. It supports a continuous flow of delivery. In this lifecycle the solution is deployed as often, and whenever, it makes sense to do so. Work is pulled into the team when there is capacity to do it, not on the regular heartbeat of an iteration.
  2. Practices are on their own cadences. With iterations/sprints many practices (detailed planning, retrospectives, demos, detailed modeling, and so on) are effectively put on the same cadence, that of the iteration. With a lean approach the observation is that you should do something when it makes sense to do it, not when the calendar indicates that you’re scheduled to do it.
  3. It has a work item pool. All work items are not created equal. Although you may choose to prioritize some work in the “standard” manner, either a value-driven approach as Scrum suggests or a risk-value driven approach as both DA and RUP suggests, but other work may fit this strategy. Some work, particularly that resulting from legislation, is date driven. Some work must be expedited, such as fixing a severity one production problem. So, a work item pool and not a prioritized stack makes a bit more sense when you recognize these realities.

Disciplined Agile Lifecycle Advanced

We call this the advanced/lean lifecycle because it’s something we see teams evolve to over time. They often start with the basic lifecycle described earlier but as they learn, as they improve the way that they work, the lifecycle they follow becomes leaner.

The Continuous Delivery DAD Lifecycle

The figure below depicts a Continuous Delivery version of the DA 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.

Disciplined Agile Lifecycle Continuous Delivery

The Exploratory (Lean Startup) Lifecycle

The following diagram overviews the DA 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 DA lifecycles to validate the vision or used continuously throughout the lifecycle.

Disciplined Agile Lifecycle Exploratory


Now let’s describe how the Exploratory lifecycle works.  There are six activities to this lifecycle:

  1. Envision.  Your team will explore the idea and identify a potential implementation strategy for implementing it.  This could be as simple as getting a few people together in a room to model storm both the business vision and your technical options on whiteboard and paper.  You want to do just enough thinking to identify a viable hypothesis for what your customers actually want.  This hypothesis needs to be testable, which implies that you need to identify how you are going to measure the effectiveness of the new functionality that you produce.
  2. Build a little.  Your team should invest just enough effort to build a solution that tests the hypothesis.  In lean parlance you want to build what’s known as a minimally viable product (MVP).  The amount of effort will vary, from several days to several weeks – your goal is to make something available very quickly so that you can test your hypothesis.
  3. Deploy.  Once your current solution is ready it is deployed into an environment where you can test your hypothesis. This deployment may be to a subset of your customers, in many ways what used to be called an “alpha” or “beta” release, so that you can determine whether the solution is of interest to them.
  4. Observe & measure.  Once the solution is available in production you want to determine what aspects of it, if any, are of interest to your user base.  To do this you will need to instrument your solution so that it logs data regarding important events within it.  For example, you may decide to record when a screen/page is accessed, when a sale occurs, when certain business functions are invoked, and so on.  The idea is that you want to understand which functionality end users find useful, which functionality leads to customer retention, which functionality leads to greater sales, … whatever is important to you.  Generation of this data enables you to monitor, to observe and measure, how well the new functionality is received by your user base.  This in turn allows you to make a fact-based go-forward decision.  If the functionality is well received then you may choose to continue with the existing strategy and add more functionality.  Or your strategy may be so successful that you decide that you’re ready to productize the development of this solution. If the functionality wasn’t well received your team might choose to pivot and continue in another direction or even give up completely.
  5. Cancel.  Sometimes you discover that the product idea isn’t going to work out after all.  In fact, this is particularly common in research and development (R&D) environments as well as start ups.  The advantage is that if an idea is going to fail, then it is better that you learn that it’s a failure quickly so that you can devote your energies into other strategies.
  6. Productize.  After several iterations of building a little, deploying, and then observing & measuring that you’ve identifying a product that will be successful in the marketplace (or in the case of internal application development successful with your user base).  As described above, although you may choose to continue following this lifecycle, a common decision is for the team to adopt one of the other DA lifecycles – such as the Scrum-based agile lifecycle, the Kanban-based Lean lifecycle, or the Continuous Delivery lifecycle – and effectively treat the time they spent following this lifecycle as their Inception phase.

For more information, read the article The Exploratory “Lean Startup” Lifecycle.


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 framework 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 framework 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 ant-thetical 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 suboptimizing 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 framework.

26 thoughts on “Full Agile Delivery Lifecycles

  1. Pingback: An Exploratory “Lean Startup” Lifecycle | Disciplined Agile Delivery

  2. Pingback: Evolving the Goals Overview Diagram | Disciplined Agile Delivery

  3. Pingback: A Full Agile Delivery Lifecycle | Disciplined Agile Delivery

  4. Pingback: Comparing DAD to the Rational Unified Process (RUP) – Part 2 | Disciplined Agile Delivery

  5. Pingback: Just a delivery lifecycle? | Disciplined Agile Delivery

  6. Pingback: Adopting a Full Lifecycle Requires Discipline | Disciplined Agile Delivery

  7. Pingback: Managing Requirements Dependencies Between Agile Teams | Disciplined Agile Delivery

  8. Pingback: Disciplined Agile Lifecycle Posters | Disciplined Agile Delivery

  9. Pingback: What is Disciplined Agile | Reedy Feggins Jr.

  10. Pingback: Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams | Disciplined Agile Delivery

  11. Pingback: JIT – Just in time and Software Development | Agile Design = Adaptive Design

  12. Pingback: The Missing Pieces Of The System! | Seeding The Landscape….Agility For Agile Minds

  13. Pingback: Two dimensions: Just in time and Envisioning | Agile Design = Adaptive Design

  14. Pingback: Does your team own its process or merely rent it? | Disciplined Agile Delivery

  15. Pingback: Otra estrategia para escalar Scrum: Disciplined Agile Delivery (DAD) - Javier Garzás | Javier Garzás

  16. Pingback: Disciplined Agile Delivery » Just a delivery lifecycle?

  17. Pingback: Disciplined Agile Delivery » Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams

  18. Pingback: Disciplined Agile Delivery » Disciplined Agile Lifecycle Posters

  19. Pingback: Disciplined Agile Delivery » Managing Requirements Dependencies Between Agile Teams

  20. Oleg

    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.

  21. Scott Ambler Post author

    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.

  22. 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,

  23. Fakhar Anwar

    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

  24. 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.


Leave a Reply

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