Full Delivery Life Cycles

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

Table of Contents
This article is organized into the following sections:

1. The 30,000 ft. View

2. Phases? Really?
3. The DAD Life Cycles
4. Why Support Several Life Cycles?
5. The Downside of Supporting Several Life Cycles
6. Get Life Cycle Posters

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 life cycle. Figure 1 below overviews a
high-level view of a project-based delivery life cycle. It is a three-phase life
cycle, 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 life cycle (click to expand)

Granted, as you see in Figure 2 which depicts more of a system life cycle there
is more to the agile SDLCthan 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
tool kit 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 life cycle (click to expand)

Phases? Really?
First, the DAD delivery life cycle 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 surveyfound 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 life cycle
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 Life Cycles

The DA tool kit does not prescribe a single life cycle, unlike other agile methods
such as Scrum. Every team is in a unique situation, therefore the DA tool kit
supports several life cycles to choose from.

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

 The Agile Life Cycle: A Scrum-based Project Life Cycle

 The Lean Life Cycle: A Kanban-based Project Life Cycle
  The Continuous Delivery:Agile Life Cycle
 The Continuous Delivery:Lean Life Cycle
 The Exploratory (Lean Startup) Life Cycle
 The Program Life Cycle for a Team of Teams

The Agile Life Cycle: A Scrum-based Project Life

Cycle
Figure 3 presents a detailed view of DAD’s Agile life cycle which extends
Scrum’s construction life cycle. We call this the basic/agile life cycle because it’s
likely where you’re going to start. Common scenarios for adopting this version
of the life cycle 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) life cycle (click to expand)

In addition to this being a more detailed view of the life cycle, there are several
interesting aspects to this life cycle:

 It’s iteration based

 It uses non-Scrum terminology
 It shows inputs from outside the delivery life cycle
 There is a work item list, not a product backlog
 It includes explicit milestones
The Lean Life Cycle: A Kanban-based Project Life
Cycle
Figure 4 depicts what we call the Lean life cycle. This life cycle 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 life cycle 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 life cycle (click to expand)

There are several interesting features to this life cycle:

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 Life Cycle

The Continuous Delivery: Agile life cycle is depicted in Figure 5. This life cycle
is a natural progression from the Agile life cycle. Teams typically evolve to this
life cycle from the Agile life cycle, often adopting iteration lengths of one-week
or less. The key difference between this and the Agile life cycle is that the
continuous delivery life cycle 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 life cycle (click to expand)

The Continuous Delivery: Lean DAD Life Cycle

Figure 6 depicts DAD’s Continuous Delivery: Lean life cycle. It is basically a
leaner version of the previous life cycle 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 life cycle, 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 life cycle (click to expand)

The Exploratory (Lean Startup) Life Cycle

Figure 7 depicts DAD’s Exploratory life cycle. This life cycle 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
life cycle can be a replacement for the Inception phase of other DAD life cycles
to validate the vision or used continuously throughout the life cycle.
Figure 7: DAD’s Exploratory life cycle (click to expand)

A Program Life Cycle for a Team of Teams

Figure 8 depicts DAD’s Program life cycle. DAD’s Program life cycle 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 Life Cycle (click to expand).

Why Support Several Life Cycles?

This is a good question. First, one life cycle 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 tool kit such as DA support
several life cycles? 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 life cycles.

Second, we were uncomfortable with the idea of prescribing a single life cycle.
We wanted to avoid prescription in the DA tool kit 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 life cycle will evolve over
time? Of course it will. We’ve seen teams start with something close to the
basic/agile life cycle that evolve it to the advanced/lean or continuous delivery
life cycles over time.

The Downside of Supporting Several Life Cycles

There is clearly a downside to explicitly supporting several life cycles. 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 life cycles.
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 tool kit.