Chapter Comments 4-1

Chapter 4
Agile Development

CHAPTER OVERVIEW AND COMMENTS

4.1 What is Agility?

The main point of this section is to introduce agility in the context of software
development. Agility is more than change management. Agility means that
customers and developers need to work together as collaborators on the
development team and try to build products that can be adapted to a rapidly
changing market place. Part of this adaptation is learning when and how to
streamline the production of work products and focus on the development of
incremental operational prototypes.

A manifesto is normally associated with an emerging political movement-one that

attacks the old guard and suggests revolutionary change.

We are uncovering better ways of developing software by doing it and helping

others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left
more. Kent Beck et al
Agility is todays buzzword when describing a modern software process. It is how
to appropriately respond to changes.
Change is what software development is very much about.
Changes in the software being built, changes to team members, changes b/c of
new technology that may have impact on the project that creates the product.
Agility encompasses the philosophy espoused in the manifesto noted earlier.
It adopts the customer as a part of the development team and works to eliminate
the us and them attitude that continue to pervade many software projects.
4-2 SEPA, 6/e Instructors Guide

The Agile Alliance http://www.agilealliance.org/home defines 12 principles for

those who want to achieve agility.

Principles behind the Agile Manifesto

We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
 Chapter Comments 4-3

4.2 What is an Agile Process?

Any agile software process is characterized in a manner that addresses three

key assumptions:
1. It is difficult to predict in advance which software requirements will persist
and which will change and which customer priorities will change.
2. Design and construction are interleaved. Both activities should be
performed in tandem so that design models are proven as they are
created.
3. Analysis, design, construction, and testing are not as predictable as we
might like.

An agile software process must adapt incrementally. To adapt incremental

adaptation, an agile team requires customer feedback.
An operational prototype is an effective catalyst for customer feedback. Hence,
incremental development strategy should be instituted.
Software increments (executable prototypes) must be delivered in short time so
that adaptation keeps pace with change.

4.2.1 The Politics of Agile Development

Check out the debate in the book on page 75.

4.2.2 Human Factors

Check out the debate in the book on page 76.

4.3 Agile Process Models

Is driven by customer descriptions of what is required (scenarios)
Recognizes that plans are short-lived
Develops software iteratively with a heavy emphasis on construction activities
Delivers multiple software increments
Adapts as changes occur
4-4 SEPA, 6/e Instructors Guide

4.3.1 Extreme Programming (XP)

http://www.extremeprogramming.org/rules/crccards.html
The most widely used agile process, originally proposed by Kent Beck. It
encompasses a set of rules and practices that occur within the context of four
framework activities: planning, design, coding and testing.
spike solutions
simple design
prototypes
CRC cards
user stories
values
acceptance test criteria
iteration plan

refactoring

pair
programming

Release
software increment
unit test
project velocity computed continuous integration

acceptance testing

Planning
Begins with the creation of user stories and then placed on an index card.
The customer assigns a value to the story based on the overall business value of
the function.
Agile XP team assesses each story and assigns a cost measured in
development weeks.
If stories take more than 3 weeks to develop, the customer is asked to split the
stories into smaller ones.
Stories are grouped to form a deliverable increment done by customer and XP
team.
Once a commitment is made on delivery date, the XP team orders the stories
that will be developed in one of three ways:
1. All stories will be implemented immediately within a few weeks.
2. The stories with the highest value will be moved up in the schedule and
implemented first.
 Chapter Comments 4-5

3. The riskiest stories will be moved up in the schedule and implemented

first.
After the first increment (project release), project velocity is used to help define
subsequent delivery dates for other increments.
Project velocity is the number of customer stories implemented during the first
release. http://www.extremeprogramming.org/rules/velocity.html
Project velocity can be used then to:
1. Help estimate delivery dates and schedule for subsequent releases, and
2. Determine whether an over-commitment has been made for all stories
across the entire development project.
Design
XP Follows the KIS(S) principle. A simple design is always preferred over a more
complex representation.
Encourage the use of CRC (class-responsibility collaboration) cards which
identify and organize the O-O classes that are relevant to the current software
increment.
For difficult design problems, suggests the creation of spike solutionsa design
prototype that is implemented and evaluated.
http://www.ironspeed.com/articles/Evolving%20With%20Extreme
%20Programming/Article.aspx
Encourages refactoringan iterative refinement of the internal program design
that controls the code modifications by suggesting small design changes that
may improve the design.
Coding
Recommends the construction of a unit test for a story before coding commences
Encourages pair programming where two programmers work together at one
workstation to create code for a story. Two heads better than one.
Testing
All unit tests are executed daily which provides the XP team with a continual
indication of progress and also can raise warning flags early if things are going
awry.
Acceptance tests are defined by the customer user stories and executed to
assess customer visible functionality
4-6 SEPA, 6/e Instructors Guide

4.3.2 Adaptive Software Development (ASD)

Was originally proposed by Jim Highsmith.
ASD: A technique that is used for building complex software and systems.
Highsmith defines ASD lifecycle that incorporates 3 phases: speculation,
collaboration, and learning.
Speculation: An adaptive cycle-planning is conducted where it uses the
customers mission statement, project constraints (delivery dates, user
description) and basic requirements.
Collaboration: People working together must trust one another to:
1. criticize without animosity
2. assist without resentment
3. work as hard or harder as they do
4. have the skill set to contribute to the work at hand
5. communicate problems or concerns in a way that leads to effective action
Learning
Learning will help them to improve their level of real understanding.

adaptive cycle planning Requirements gathering

uses mission statement J AD
project constraints mini-specs
basic requirements
time-boxed release plan

Release
software increment
adjustments for subsequent cycles
components implemented/ tested
focus groups for feedback
formal technical reviews
postmortems
 Chapter Comments 4-7

4.3.3 Dynamic System Development Method (DSDM)

Promoted by the DSDM Consortium (www.dsdm.org)
Dynamic System Development Method is an agile S/W development approach
that provides a framework for building and maintaining systems which meet tight
time constraints through the use of incremental prototyping in a controlled project
environment.

It defines three different iterative cycles preceded by two additional life cycles
activities:
Feasibility Study: Business requirements and constraints.
Business Study: Establishes req. that will allow the application to provide
business value.
Functional Model Iteration: Produce iterative prototypes.
Design and build iteration: Revisit prototyping.
Implementation: Include the latest prototype into the operational environment.
4-8 SEPA, 6/e Instructors Guide

4.3.4 Scrum
Originally proposed by Schwaber and Beedle; the name derived from an activity
that occurs during a rugby match.
Scrumdistinguishing features
Development work is partitioned into packets
Testing and documentation are on-going as the product is constructed
Work occurs in sprints framework activities and is derived from a backlog
requirements that provide business values of existing requirements
Meetings are very short and sometimes conducted without chairs
Demos are delivered to the customer with the time-box allocated

Scrum Process Flow (used with permission)