Agile Lifecycle
The key to
success with this approach is to focus on technical excellence
throughout the development process.
This requires
deploying skilled developers who have a thorough under
standing of how to mix an match best practices.
Programs that adopt
short iterative cycles without focusing on the production of
quality software frequently fail to achieve the benefits
associated with an Agile approach.
Tailoring the Agile Lifecycle for a
Large Program
While the life
cycle above is still at the heart of the Agile Life Cycle for
a larger program, several modifications are needed to scale
the Agile approach to accommodate the work of multiple teams.
These include:
·
Establishment
of program plans to support Agile development within the
larger program context.
Within a
development program, it is often the case that Agile will be
used only for a portion of the development effort.
When that is the case, the program plan and supporting
plans (SEMP, SDP, Master Test Plan, etc) need to define how
the Agile activities will interact with and support the rest
of the program.
This includes defining how requirements traceability will be
handled, how the Agile products will be integrated with the
rest of the system, what the Agile role is in program reviews,
and how interfaces between Agile and non-Agile components will
be managed.
See Agile Estimate and
Planning Quick Reference Sheet.
·
Establishment
of a system architecture definition.
With only a
single small team, it is common to establish the system
architecture during the first iteration, and refine it over
time. On larger
programs, it is recommended that a system architecture be
created to define the major components of the system and the
boundaries within which the individual Agile teams will work
prior to beginning iterative work by multiple teams.
The initial architecture will still evolve over time,
but that evolution must be managed across the teams more
formally than if there is only a single team.
·
Establishment
of a Program Release Plan.
Frequently small teams release capability to their
customer at the end of each iteration.
In such a case, there may be no need for a release plan
since each iteration is a release.
On a larger program, there is frequently a need to
group several iterations together for release to a customer.
In that case, the release plan defines the capability
that will be released at the end of the group of iterations.
On very large programs with multiple releases, the
release plan guides the content of the series of releases that
are needed to deliver full program capability.
The program needs to consider what capabilities will be
released in what order and must ensure that the system
architecture supports a phased release of capabilities.
·
On a large
program, major development aspects are iteratively broken down
to a level that identifies cross-team dependencies.
It is a common
practice for acceptance tests for a feature to be completed
one or more iterations before implementation begins.
This contrasts with the practice of completing the
acceptance tests as part of an iteration, which is frequently
the approach used on smaller projects.
On large projects,
product backlog items also require more formal means of
capture and collaboration. Communication has to be in clearly
documented when developments teams are not collocated, this
includes the requirements database and a current schedule.
·
Additional
integration.
While team members can integrate their work within the
team on a daily basis, it is often a good idea to integrate
between teams less often.
A common approach is for each team to deliver their
integrated product to a program-level integration team at the
end of the iteration for integration with the work of other
teams. As a rule
of thumb, the more dependencies, the more often integration is
needed. If two
teams have substantial dependencies, they may need to
integrate daily or every few days rather than wait until the
end of an iteration.
Architectural partitioning of the system should be done
in such a way as to minimize dependencies as much as possible
to facilitate integration.
·
Additional
levels of testing.
While a single-team project can usually do adequate
testing within the scope of an iteration, it is quite common
for large programs to need a period for system testing to
address issues that cross teams, such as performance,
security, reliability, etc.
·
Additional
formality and documentation.
Since all of the individuals on a large program cannot be
collocated, larger programs will need to rely more on
documentation and will need some degree of formality for
approving development progress.
When adding formality and documentation it needs to be
kept to a minimum, and based on standard templates identifying
the documentation requirements.
Larger programs traditionally have formal reviews such
as PDR and CDR (DR3) that require more documentation than is
traditional for an Agile program.
When such documentation is needed, it should be
prioritized along with the rest of the items in the product
backlog and scheduled as part of the work in iterations
leading up to the reviews.
·
Iterative
development of user documentation.
Include backlog tasks to create / update. every
iteration in order to keep documents up to date and ready to
deliver. It is
sometimes not possible to create System Administrator Manuals,
User Manuals, Training Manuals, etc until new product features
have been incorporated.
If the demonstrations at the end of an iteration
usually result in many changes, you may want to update the
documents one iteration after the product is demonstrated, but
you should usually not defer all documentation to the last
iteration.
For each
individual release, the life cycle for the release would be as
shown in
Figure 4. Release
contents are refined through the Continuous Planning and
System Evolution activities.
During that time, the teams update release plans with
additional detail, tentatively allocate capability to cycles
or iterations, and identify dependencies between teams.
Maintaining
the same iteration length for all teams on a project greatly
simplifies coordination between teams and provides multiple
synchronized opportunities for integrating across teams.
This may be balanced
by calculating the man hours for an iterations and structuring
the team size accordingly.
In order to keep a consistent iteration duration across
teams, it may be necessary to break up large features into
multiple features that can be implemented in successive
iterations to reduce the work allocated to a team for a single
iteration, or to pull in related but lower priority features
to give a team enough work for the duration of the iteration.
It is highly
recommended that all teams start/stop their iteration in the
same week but due to unforeseen development problems it will
not always be possible.
The iteration integration can be managed by allocating
a period for verification starting with the development team
that finished first leaving additional time to address issues.
CMMI Ltd would support the verification being undertake and
approved by someone other than the development team.
AGILE APPROACH
Scrum
Scrum comes from the rugby term
and represents
getting
in a
tight group heads down
to
solve a problem as a team.
The Scrum methodology focuses on the management and
control of software products using an incremental/iterative
approach. Key roles
for Scrum include:
-
Stakeholder, who represents the voice of the customer.
-
Scrum
Master, who facilitates team activities and removes
impediments to the ability of the team to deliver the
iteration goal.
-
Team, with the responsibility to deliver the product.
Once a team
starts working on the tasks for an iteration (a Sprint in
Scrum terminology) no external interruptions or changes of
direction are allowed.
This allows the team to focus their attention on
completing the tasks needed to accomplish the goals of the
iteration. The
stakeholders working with the team provide clarification
throughout the iteration, and are considered part of the team.
Scrum makes it
possible to wrap an organization’s existing engineering
methods into a controlled, iterative process.
It fact this is vital and it means all the teem need to
understand the documented best practices.
Scrum does this by combining existing methods with
Agile methods to provide a simple and balanced approach to
Agile development.
Scrum has also been proven to be able to scale to
multiple teams across programs consisting of over 800 people.
For the above
reasons, Scrum has become very popular in the commercial
software community and is the basis for many of the Agile
practices defined in this document.
For Scrum to
succeed long-term, teams must produce maintainable software;
otherwise, they are often not able to sustain the
velocity needed to achieve program goals.
For additional information see
http://www.scrumalliance.org/.
Extreme Programming (XP)
XP is the one
of the earliest and most familiar of all Agile methodologies.
Introduced in 1999 as an alternative to the traditional
heavyweight approaches that are often-times overkill for
smaller programs, XP strictly adheres to the Agile principles
while embracing sound software engineering principles, XP
focuses on delivering timely software that meets customer
requirements rather than focusing on the processes that often
accompany large development efforts.
The underlying assumption for XP is that the high cost of
change has been addressed by technologies such as objects,
patterns, relational databases, information hiding, etc.
Because of this, XP focuses on rapid feedback,
simplicity, incremental change, embracing change and quality
work.
.
XP rigorously adheres to the 11
XP practice.
-
The
planning game:
determine the scope of the next release, based on
business priorities and technical estimates.
-
Small
releases:
every release should be as small as possible, containing
the most valuable business requirements.
-
Metaphor:
guide all development with a simple, shared story
of how the whole system works.
-
Simple
design:
design for the current functionality, not future needs and
make the design as simple as possible for that
functionality.
CMMI Ltd would however advocate that whilst a modular
approach is applied this does not preclude starting with
the end in mind.
-
Refactoring:
ongoing redesign of software to improve its responsiveness
to change.
Again without a long term aim this approach can become
costly without delivering new functionality.
-
Test-Driven Development:
developers write the unit tests before the code;
unit tests are run “continuously”; customers write the
functional tests.
The key to achieving this is to have the
requirements clearly documented a the ability to record
traceability.
-
Pair
programming:
an extreme form of inspection; two people sit in front of
the same terminal to write test cases and code.
-
Collective
ownership:
anyone can change any code anywhere in the system at any
time.
-
40-hour
week: Be
smart let the software developers work where they want and
when some may work well at 2am.
Work no more than 40 hours as a rule; never work
overtime two weeks in a row.
-
On-site
customer:
have a real user on the team full time.
-
Coding
standards:
must be adhered to rigorously because all communication is
through code.
This requires developers undertaking code reviews against
a defined standard.
As its name
indicates, XP is an extreme implementation of Agile principles
and practices, geared towards small programs.
For this reason limit the use of XP to small programs
unless they wrap XP in another methodology such as Scrum.
For additional
information see
http://wiht.link/extreme_programming .
Dynamic System Development Method
(DSDM)
DSDM emerged
from a pre-Agile approach to software development called Rapid
Application Development (RAD).
DSDM consists of 3 phases:
pre-project phase, project life cycle phase, and
post-project phase.
The project life cycle phase is subdivided into 5
stages:
feasibility study, business study, functional model iteration,
design and build iteration, and implementation.
DSDM has 9 underlying principles:
-
Active
user involvement is imperative.
-
The team
must be empowered to make decisions.
-
The focus
is on frequent delivery of products.
-
Fitness
for business purpose is the essential criterion for
acceptance of deliverables.
-
Iterative
and incremental development is necessary to converge on an
accurate business solution.
-
All
changes during development are reversible.
-
High level
scope and requirements are baseline before the project
starts. This
requires ensuring the customer has a clear understanding
of the project aims.
Utilize UDI presentations to obtain sign up.
-
Testing is
integrated throughout the project lifecycle.
-
Communication and cooperation among all project
stakeholders is required.
A
distinguishing characteristic of DSDM is its emphasis on
rapidly delivering the features that provide the most value to
the customer, and deferring any other work until a later time.
DSDM specifically focuses on the 80% of useful features
that can be delivered in 20% of the time of the overall
program.
DSDM may be
useful on Information Systems projects that are characterized
by tight schedules and budgets.
For additional information see
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method.
Feature Driven Development
FDD is client-centric, architecture centric, and pragmatic.
It provides just enough process to ensure scalability
and repeatability and encourage creativity and innovation
along the way. FDD
uses a five step process that focuses on developing an overall
“shape” object model, building a features list, and then
planning-by-feature followed by iterative design-by-feature
and build-by-feature steps.
FDD
is unique from the other methodologies in that it balances the
waterfall approach with the iterative Agile approach.
The result is an approach that begins with up-front
domain modeling from a client-valued functionality
perspective. The
models are decomposed into lists of small features.
Once the features have been identified, a series of
short iterations begin in which a two week design phase is
followed by a two week implementation phase.
One of the advantages of
FDD is that the management process allows easy visibility into
the progress of features under construction.
Proponents also claim that FDD is the easiest Agile
methodology to scale up to large programs.
Therefore, FDD may appeal to larger programs that
need tighter control over the planning and managing aspects of
a program.
For additional
information see
http://en.wikipedia.org/wiki/Feature_Driven_Development .
Lean Software Development
Lean Software
Development is an approach that translates lean manufacturing
practices and principles to the software development domain.
The Lean approach is very consistent with the
principles and practices outlined in the Agile Manifesto.
With Lean, work is driven using a “pull” approach,
where features are only built in response to customer request.
In order to respond quickly to the customer, Lean
places particular emphasis on the reduction of wasteful,
non-value added activities that slow down the workflow.
The Lean approach advocates organizing into small,
collaborative autonomous teams that produce batches of
features in short iterations.
Key principles behind
Lean Software Development, and a set of tools for implementing
those principles, have been defined by Mary and Tom
Poppendieck in their book
Lean Software
Development.
These principles, with associated tools, include:
-
Eliminate waste, using the tools
Seeing Waste
and Value Stream
Mapping
-
Amplify learning, using the tools
Feedback,
Iterations, Synchronization
and Set-based
Development
-
Decide as
late as possible, using the tools
Options Thinking,
the Last Responsible Moment and
Making Decisions
-
Deliver as
fast as possible, using the tools
Pull Systems,
Queuing Theory and
Cost of Delay
-
Empower the
team, using the tools
Self Determination,
Motivation, Leadership and
Expertise
-
Build
integrity in, using the tools
Perceived
Integrity, Conceptual Integrity, Refactoring and
Testing
-
See the
whole, using the tools Measurements and Contracts.
Consider using lean
principles and tools in conjunction with other Agile
methodologies.
For additional information see
http://en.wikipedia.org/wiki/Lean_software_development.
Adaptive Software Development
Traditional
methodologies often employ a “plan-deliver-review” approach
based on the assumption that system functionality is
reasonably predictable and changes can be managed in order to
achieve the original plan.
The ASD methodology offers an alternative
“speculate-collaborate-learn” approach for environments where
change is the norm.
Rather than unrealistically attempting to initially
plan the final system state and then doing whatever it takes
to “make plan”, ASD places emphasis on developing loose plans
and then skillfully adapting to changing requirements.
Its underlying philosophy is that adaptation is more
important than optimization.
Another key aspect of ASD is its focus on favoring a
leadership-collaboration management style over command and
control management.
Figure below
shows a high-level perspective of
the ASD Life Cycle.
ASD may be appropriate
for programs with domains where requirements are likely to
change frequently
For additional information see
Adaptive Software
Development by James A Highsmith III.
Agile Unified Process
The Agile Unified
Process is a simplified version of the Rational Unified
Process (RUP). It
provides an approach for developing business application
software using Agile techniques and concepts while still
following the RUP framework.
AUP is serial in the
large, with the traditional four RUP phases of Inception,
Elaboration, Construction and Transition.
In the small, however AUP is iterative.
Modeling, Implementation, Testing, Deployment,
Configuration Management, Project Management and Environment
Support are performed iteratively to build, validate and
deliver working software.
AUP teams deliver
development releases into pre-production staging area(s) at
the end of each iteration.
A development release of an application is software
that is potentially releasable after it has been through the
pre-production quality assurance, testing and deployment
processes.
-
The principles
behind AUP include:
-
Your staff knows what they are doing
-
Simplicity
-
Agility
-
Focus on high-value activities
-
Tool independence
-
Tailor AUP to your own needs
A high level view of the AUP Life Cycle is shown
below
AUP is a good choice for
programs that want a process in between XP and traditional
RUP.
For additional
information see
http://www.ambysoft.com/unifiedprocess/agileUP.html .
Further Agile References
An
Introduction to Agile Concepts:
Wikipedia has a very
good description of Agile principles, practices and
methodologies. It
is a good starting place for anyone with little or no
knowledge of Agile.
http://en.wikipedia.org/wiki/Agile_software_development.
The Agile Alliance (http://www.agilealliance.org/)
is also a good source for information. For a list
of alternative best practices the agile modeling by Scott W
Ambler provides a good source of information.
www.agilemodeling.com
Scrum:
Scrum is one of the most popular Agile methodologies.
Mike Cohn’s web site has a lot of training material for
individuals new to Scrum, as well as several good articles on
various Agile topics.
Mike Cohn’s classes are recommended for individuals
seeking certification as Scrum Masters.
http://www.mountaingoatsoftware.com.
The Scrum Alliance (http://www.scrumalliance.org/)
is also a good source for information.
Lean:
Mary and Tom Poppendieck’s web site has excellent
information about Lean Software Development and Agile
management.
http://www.poppendieck.com
AGILE PRACTICES
Go to
CMMI Ltd Agile
Approach
|
