Agile Development

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 today’s 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.

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.

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.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.

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.
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 solutions”—a design prototype that is implemented and evaluated.  http://www.ironspeed.com/articles/Evolving%20With%20Extreme%20Programming/Article.aspx
Encourages “refactoring”—an 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.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 customer’s 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. 

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.3.4 Scrum
Originally proposed by Schwaber and Beedle; the name derived from an activity that occurs during a rugby match.
Scrum—distinguishing 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