Home > Lifecycle > A Full Agile Delivery Lifecycle

A Full Agile Delivery Lifecycle

One of the key aspects of the Disciplined Agile Delivery (DAD) process decision framework is that it promotes a full, end-to-end, solution delivery lifecycle.  The figure below overviews a high-level view of the DAD 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 DAD 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 DAD 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.  DAD recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise.  DAD 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, 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.  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, strategic reuse, and more (for more details, see Enterprise Unified Process).  Having said this, these aspects of the overall lifecycle are not covered by DAD although do have an affect on how DAD teams work.

Earlier I said that the DAD 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 version.  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 three such versions of the lifecycle.

The Agile/Basic DAD 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 DAD, 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.  DAD 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. In includes explicit milestones.  Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD 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 with DAD.  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 DAD 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 DAD 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 DAD 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

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 DAD 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 DAD 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.
Process improvement

The Downside of Supporting Several Lifecycles

There is clearly a downside to explicitly supporting several lifecycles.   By doing so we explicitly admit that DAD 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 (DAD 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 DAD builds effective governance right into the framework.

About these ads
Categories: Lifecycle
  1. December 20, 2012 at 2:32 pm | #1

    “By doing so we explicitly admit that DAD 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”

    I understand why you categorize this as a downside, but it’s reality. Those organizations that refuse to believe in tailoring are like those that refuse to believe in gravity – they fall at the same velocity the believers do. Anyone who believes that the same process can be used to successfully produce embedded software for medical devices and the next big Facebook game are delusional.

  2. January 8, 2013 at 9:52 am | #2

    in re “more to the agile SDLC than just those phases”

    What distinctions exist between product lifecycle (PLC) and development lifecycle (SDLC)? What delimiters exist? At least with respect to DAD, where does the SDLC begin and end?

    Certainly projects, by definition, have a lifecycle, but a project is not a product, and with service oriented architectures and knowledge managed as an asset, software in use and its source code can be recognized as a form of Nonaka’s “explicit” knowledge. Nonaka’s spiral of knowledge (SECI) requires sequence nor begining or end. So I am beginning to wonder whether the term “lifecycle” (which implies birth and death or more generally beginning and end) is inappropriate to software evolution.

    in re “repeatable process”

    For nearly a century, the benchmark method for repeatable process has been Shewhart’s Statistical Process Control (SPC). SPC is useless in isolation, as a sufferer of OCD might find refolding a napkin useless but repeatable. The goal is not repeatable process but repeatable product. Except in undergraduate studies and corroborating research, repeatable product is not the goal of software engineering; the goal is always to provide something better than has existed. Even porting an app from iOS to Android with no change in functionality has the goal of fitting a product to a new context. That is by Juran’s “fitness for use” definition a quality improvement.

  3. January 8, 2013 at 11:41 am | #3

    Skip, although it isn’t clear in this posting, I think my Agile SDLC article at http://www.ambysoft.com/essays/agileLifecycle.html makes it clear that solutions/software do in fact have lifecycles. You need to consider the scope of what you’re looking at. If you look at just construction or just delivery (pretty much as this blog posting does) then it isn’t clear if there’s an end. If you look at the complete lifecycle of a solution, from initial idea to system retirement, then clearly it does.

  4. July 26, 2013 at 1:50 pm | #4

    This is a great overview and very interesting reading. And your way of embedding links to other blog postings is simple phenomenal, tying together a complete set of precise, enjoyable texts – together teaching the reader what DAD is and why it makes sense to use it.

  1. January 21, 2013 at 3:51 pm | #1
  2. February 22, 2013 at 3:05 pm | #2
  3. August 26, 2013 at 1:48 am | #3
  4. October 9, 2013 at 5:58 am | #4
  5. October 16, 2013 at 4:47 am | #5
  6. November 10, 2013 at 12:59 pm | #6
  7. November 28, 2013 at 4:00 am | #7
  8. January 3, 2014 at 4:43 am | #8
  9. February 10, 2014 at 7:28 am | #9
  10. March 3, 2014 at 7:37 am | #10

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 480 other followers