The Agile System Development Life Cycle (SDLC)
The Agile System
Development Life Cycle (SDLC)
I'm often asked by clients to facilitate workshops
overviewing the ideas presented in the
and agile techniques such as
. One issue that many people
seem to struggle with is how all of these ideas fit together, and
invariably I found myself sketching one or more pictures which overview
the life cycle for agile software development projects.
I typically
need one or more pictures because the scope of life cycles change -- some
life cycles address just the construction life cycle, some address the
full development life cycle, and some even address the full IT life
Depending on your scope, and how disciplined your approach to agile
software development is, you will get different life cycle diagrams.
Your experience and team culture will also have an affect on the
lifecycle you follow, something that we explicitly address in the
process decision framework.
The goal of this article is to describe the agile system development
life cycle (SDLC), putting it in context from what you may have heard
about within the agile community and more importantly within the context
of your overall IT efforts.
This article covers:
As we described in the book
the scope of life cycles can vary
dramatically.
For example,
depicts the
Scrum construction life cycle whereas
depicts an extended version of that diagram which covers the full system
development life cycle (SDLC).
Later in this article we talk about an .
My points are:
Solution development is complicated.
it's comforting to think that development is as simple as
makes it out to be, the fact is that we
know that it's not.
If you adopt a development process that doesn't
actually address the full development cycle then you've adopted little more
than consultantware in the end.
My experience is that you need to go
beyond the construction life cycle of Figure 1 to the full SDLC of
(ok, Retirement may not be
all that critical) if you're to be successful.
There's more to IT than development.
successful at IT you must take a multi-system, multi-life cycle stage view as
we show in the discussion of the .
The reality is that
organizations have many potential endeavours in the planning stage (which I'll
in this article), many
in development, and many in .
uses the terminology of the
Scrum methodology.
The rest of this article uses the terminology
popularized in the mid-1990s by the
(Sprint = Iteration, Backlog = Stack, Daily Scrum Meeting = Daily
Meeting) and also adopted by .
Figure 1 shows how agilists treat requirements like a
, pulling just enough work off the stack for the current
iteration (in Scrum iterations/sprints are often 2-4 weeks long, although this can
At the end of the iteration the system is demoed to the
stakeholders to verify that the work that the team promised to do at the
beginning of the iteration was in fact accomplished.
. The Scrum construction
life cycle.
The Scrum construction life cycle of , although attractive proves to be clearly insufficient in practice.
Where does the product backlog come from?
Does it get beamed down from the
Starship Enterprise?
Of course not, it's actually the result of
early in the project.
You don't only
implement requirements during an iteration, you also fix defects (disciplined
agile teams, particularly working at scale, may have a parallel testing effort during construction iterations where
these defects are found), go on training, support other teams (perhaps as
of their work), and so on.
So you really need to expand the
product backlog into a full work items list.
your system into , often a
complex endeavor.
A more realistic life cycle is captured
overviewing the full agile SDLC.
This SDLC is comprised of six phases:
Although many agile developers may balk at the idea of phases, perhaps
Gary Evan's analogy of development seasons may be a bit more palatable,
the fact is that it's been recognized that
does in fact have phases (for
a diagram, see
. A detailed agile SDLC.
depicts the agile/basic lifecycle described by the
Disciplined Agile Delivery (DAD) framework.
This lifecycle originated from earlier versions
of . Because DAD isn't prescriptive it
The lifecycle of
is DAD's Scrum-based, or "basic",
agile delivery lifecycle but it also supports a lean/Kanban type of lifecycle and a continuous delivery
lifecycle (shown in ) as well.
The idea is that your team should adopt the lifecycle that makes the most sense
for the situation that you face.
. The DAD agile life cycle.
. The DAD continuous delivery life cycle.
On the surface, the agile SDLC of
looks very
much like a traditional SDLC, but when you dive
deeper you quickly discover that this isn't the case.
This is particularly
true when you consider the detailed view of .
Because the agile SDLC is highly collaborative, iterative, and
incremental the roles which people take are much more robust than on traditional
In the traditional world a
that is handed off to an
who creates
models that are
handed off to a coder who writes programs which are handed off to a
On an agile project, developers work closely with their stakeholders to
understand their needs, they pair together to implement and test their solution,
and the solution is shown to the stakeholder for quick feedback.
Instead of
specialists handing artifacts to one another, and thereby injecting defects at
every step along the way, agile developers are
with full life cycle skills.
. The Agile SDLC (high-level).
2. : Pre-Project
The Concept Phase, sometimes called Iteration -1, is the pre-project aspects of
During this phase you will:
Define the business opportunity.
You must consider the
bigger business picture and focus on market concerns.
This includes
exploring how the new functionality will improve your organization's
presence in the market, how it will impact profitability, and how it will
impact the people within your organization.
This exploration effort should
be brief, not all projects will make the initial cut so you only want to
invest enough effort at this point to get a good gut feel for the business
potential.
A good strategy is to follow
's focus on identifying the potential stakeholders
and their goals, key information to help identify the scope of the effort.
Identify a viable for the project.
There are several issues
to consider when identifying a potential strategy for the project.
example, do you build a new system or buy an existing package and modify
If you decide to build, do you do so onshore or offshore?
work be solely done by your own development team, by a team from a system
integrator (SI), or in partnership with the SI?
What development paradigm –
traditional/waterfall, iterative, or agile – will you follow?
Will the team
be co-located, near-located within the same geographic region, or
far-located around the world?
As you can see there are many combinations
of strategy available to you, and at this point in time you may only be able
to narrow the range of the possibilities but be forced to leave the final
decision to the project team in future iterations.
Assess the feasibility. During the Concept Phase you will want to do
just enough feasibility analysis to determine if it makes sense to invest in
the potential project.
Depending on the situation you may choose to invest
very little effort in considering feasibility, for many systems just
considering these issues for a few minutes is sufficient for now, and for
some systems you may choose to invest days if not weeks exploring
feasibility.
Many organizations choose to do just a little bit of
feasibility analysis during the Concept Phase, and then if they decide to fund
the project they will invest more effort during
In my experience you need to consider four issues when
: economic feasibility, technical feasibility, operational
feasibility, and political feasibility.
Your feasibility analysis efforts
should also produce a list of potential risks and criteria against which to
make go/no-go decisions at key milestone points during your project.
Remember that agile teams only have a s, compared to 63% for traditional projects, implying that
almost 30% of agile projects are considered either challenged or failures.
Therefore you should
question the feasibility of the project throughout the life cycle to reduce
overall project risk.
Concept Phase activities can and should be as agile as you can possibly make
it – you should collaborate with stakeholders who are knowledgeable enough and
motivated enough to consider this potential project and invest in just enough
effort to decide whether to consider funding the effort further.
3. /Warm Up: Project Initiation
The first week or so of an agile project is often referred to as "Iteration 0"
(or "Cycle 0") or in The Eclipse Way the "Warm Up" iteration.
Your goal during this period
the project by:
Garnering initial support and funding for the project.
may have been already achieved via your
, but realistically at some point somebody
is going to ask what are we going to get, how much is it going to cost, and
how long is it going to take. You need to be able to provide reasonable,
although potentially evolving, answers to these questions if you're going to
get permission to work on the project.
You may need to
Actively working with stakeholders to
initially model the scope of the system.
As you see in
, during Iteration 0 agilists will do some
with their stakeholders to identify the
initial, albeit high-level, requirements for the system.
To promote
you should use
such as index cards and white boards to do this modeling – our goal is to
understand the problem and solution domain, not to create mounds of
documentation.
The details of these requirements are modeled on a just
in time (JIT) basis in
sessions during the .
Starting to build the team.
Although your team will evolve
over time, at the beginning of a development project you will need to start
identifying key team members and start bringing them onto the team.
this point you will want to have at least one or two senior developers, the
project coach/manager, and one or more stakeholder representatives.
Modeling an
for the system.
Early in the project
you need to have at least a general idea of how you're going to build the
Is it a mainframe COBOL application?
A .Net application?
Something else?
As you see in , the developers on the project will get together in a room,
often around a whiteboard, discuss and then sketch out a potential
architecture for the system.
This architecture will likely evolve over
time, it will not be very detailed yet (it just needs to be
for now), and very little documentation (if any) needs to be
The goal is to identify an architectural strategy, not write
mounds of documentation.
You will work through the design details
later during
sessions and via
Setting up the environment.
You need workstations,
development tools, a work area, ... for the team.
You don't need
access to all of these resources right away, although at the start of the
project you will need most of them.
Estimating the project.
You'll need to put together an
based on the initial requirements, the initial
architecture, and the skills of your team.
This estimate will evolve
throughout the project.
: The Agile Model Driven Development (AMDD)
life cycle.
found that the average time to initiate
an agile project took 4.6 weeks.
depicts the range of initiation periods.
Differences are the results of
the complexity of the domain/problem space, technical complexity of what you're
trying to accomplish, availability of stakeholders, ability of stakeholders to
come to agreement as to the scope. and ability of the team to form itself and to
obtain necessary resources.
. How long did it take to initiate an agile
Iterations
During construction iterations agilists incrementally deliver
high-quality working software which meets the changing needs of our
stakeholders, as overviewed in .
software development process during a construction iteration.
We achieve this by:
Collaborating closely with both our
stakeholders and with other developers.
We do this to reduce risk through
and by improving
Implementing functionality in priority order.
We allow our stakeholders to
to meet their exact needs as they see
The stakeholders are given complete control over the s – they get what they want and spend as much as they want for as long as
they're willing to do so.
Analyzing and designing. We analyze individual requirements by
on a just-in-time (JIT) basis for a few minutes before spending several hours or
days implementing the requirement.
Guided by our architecture models, often
hand-sketched diagrams, we take a highly-collaborative,
approach to development (see ) where we iteratively write a test and then write just
enough production code to fulfill that test.
Sometimes, particularly for
complex requirements or for design issues requiring significant forethought,
to ensure that the developers don't need to wait for information.
Ensuring quality.
Disciplined agilists are firm believers in following guidance such as
Furthermore, we
our application code and/or our
as required to ensure that we have the best design
Regularly delivering working solutions.
the end of each development cycle/iteration you should have a partial,
working solution to show people.
Better yet, you should be able to
deploy this solution into a
pre-production testing/QA sandbox for system integration testing.
The sooner, and
more often, you can do such testing the better.
for more thoughts.
Testing, testing, and yes, testing.
can see in
do a significant amount of
throughout construction.
As part of
construction we do confirmatory testing, a combination of developer testing
at the design level
and agile acceptance testing at the requirements level.
In many ways confirmatory testing is the
agile equivalent of "testing against the specification" because it confirms
that the software which we've built to date works according to the intent of
our stakeholders as we understand it today. This isn't the complete testing
picture: Because we are producing working software on a regular basis, at
least at the end of each iteration although ideally more often, we're in a position to deliver that
working software to an independent test team for investigative testing.
Investigative testing is done by test professionals who are good at finding
defects which the developers have missed.
These defects might pertain
to usability or integration problems, sometimes they pertain to requirements
which we missed or simply haven't implemented yet, and sometimes they
pertain to things we simply didn't think to test for.
. Taking a "test first" approach to construction.
. Testing during construction iterations.
I would rather fail three
weeks into a six-month project than ten months into a six-month
5. : The "End Game"
During Transition, also known as the "end game" or deployment, we release the solution into
Not that for complex systems the end
game may prove to be several iterations, although if you've done system and user
testing during construction iterations (as indicated by )
this likely won't be the case.
There are several important
aspects to this effort:
Final testing of the
Final system and acceptance testing should be performed at
this point, although as I pointed out earlier the majority of testing should
be done during construction iterations (ideally, you just need to
rerun your regression test suite to see that it works).
You may choose to pilot/beta test your system with a subset of the eventual end users.
See the article
for more thoughts on testing.
There is no value testing the
system if you don't plan to act on the defects that you find.
not address all defects, but you should expect to fix some of them.
Finalization of any system and user documentation.
may have been written during construction iterations, but it
typically isn't finalized until the system release itself has been finalized
to avoid unnecessary rework
Note that documentation is treated like
any other requirement: it should be costed, prioritized, and created only if
stakeholders are willing to invest in it.
Agilists believe that if stakeholders are smart enough to earn the money then
they must also be smart enough to spend it appropriately.
We train end users,
operations staff, and support staff to work effectively with our system.
Deploy the system.
See my article entitled
As you can see in ,
on average agile teams take 4.6 weeks to transition their system into production
according to the
As you can see in the
figure there is a wide range of time taken.
I believe this variance ranges
based on the complexity of the solution, the amount of deployment automation
(teams that have adopted a continuous deployment strategy automate many of the
technical aspects of transition), the comprehensiveness of the
effort during construction, the need for manual efforts such as
training and educating end users (or support or operations staff), and the
organizational complexity of your environment.
. Amount of time experienced agile teams
invested in releasing/transitioning their solution into production.
The goal of the
is to keep systems useful and productive after they have
been deployed to the user community. This process will differ from organization
to organization and perhaps even from system to system, but the fundamental goal
remains the same: keep the system running and help users to use it.
Shrink-wrapped software, for example, will not require operational support but
will typically require a help desk to assist users. Organizations that implement
systems for internal use will usually require an operational staff to run and
monitor systems.
This phase ends when the release of a system has been slated for retirement
or when support for that release has ended. The latter may occur immediately
upon the release of a newer version, some time after the release of a newer
version, or simply on a date that the business has decided to end support.
This phase typically has one iteration because it applies to the operational
lifetime of a single release of your software. There may be multiple iterations,
however, if you defined multiple levels of support that your software will have
over time.
The goal of the
is the removal of a system release from production, and
occasionally even the complete system itself, an activity also known as system
decommissioning or system sunsetting.
Retirement of systems is a serious issue
faced by many organizations today as legacy systems are removed and replaced by
new systems.
You must strive to complete this effort with minimal impact to
business operations.
If you have tried this in the past, you know how complex
it can be to execute successfully.
System releases are removed from
production for several reasons, including:
The system is being complete replaced.
not uncommon to see homegrown systems for human resource functions being
replaced by COTS systems such as SAP or Oracle Financials.
The release is no longer to be supported.
Sometimes organizations will have several releases in production at the same
time, and over time older releases are dropped.
The system no longer needed to support the current
business model.
A organization may explore a new business area by
developing new systems only to discover that it is not cost effective.
The system is redundant.
Organizations that
grow by mergers and/or acquisitions often end up with redundant systems as
they consolidate their operations.
The system has become obsolete.
In most cases, the retirement of older releases is a handled during the
deployment of a newer version of the system and is a relatively simple
Typically, the deployment of the new release includes steps to remove
the previous release.
There are times, however, when you do not retire a
release simply because you deploy a newer version.
This may happen if you can
not require users to migrate to the new release or if you must maintain an older
system for backward compatibility.
I'd like to end with a discussion of the Enterprise IT lifecycle.
One way to depict this is
shown in , the
This lifecycle explicitly shows that there is a wide range of activities involved in Enterprise IT that
go far beyond solution delivery.
This is something the agile community is currently working to address.
. The Enterprise Unified Process (EUP) lifecycle.
9. Recommended Reading
This book,
describes the
(DAD) process decision framework.
The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for .
This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting.
Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process.
Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams.
Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer.
description of what we do, and how to contact us, can be
found at .
This site owned by