A Case for Agile Development. From Nothing, to Heavy, to Light (1) Most software development is a chaotic activity, often characterized by the phrase

A Case forAgile Development

From Nothing, to Heavy, to Light (1)

Most software development is a chaotic activity, often characterized by the phrase “code and fix”.

We’ve lived with this style of development for a long time, but we’ve also had an alternative for a long time: methodology.

The most frequent criticism of these methodologies is that they are bureaucratic (hence the name heavy methodologies).

From Nothing, to Heavy, to Light (2)

As a reaction to these methodologies, a new group of methodologies have appeared in the last few years – the light methodologies.

They are less document-oriented and more code-oriented.

Lack of documentation is just a symptom of two deeper differences: Light methods are adaptive rather than predictive. Light methods are people-oriented rather than

process‑oriented.

The Self-Adaptive Process

Adaptivity is not only in the context of a project adapting its software frequently to meet the changing requirements of its customers.

There’s another angle of adaptivity: that of the process changing over time.

The first part of self-adaptivity is regular reviews of the process.

A consequence of self-adaptivity is that you should never expect to find a single corporate methodology.

Agile Processes

Introduction to Agile Methodology Agile Manifesto Impact of Agile on Requirements Principles & Practices

Agile Communication Sweet Spots Self Adaptation

Specific Methods XP Crystal

Welcome to Agile Techniques

What Agile processes try to avoid:

Manifesto for Agile Software Development

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.

Robert C. MartinSteve Mellor

Ken SchwaberJeff SutherlandDave Thomas

James GrenningJim HighsmithAndrew HuntRon Jeffries

Jon KernBrian Marick

Kent BeckMike Beedle

Arie van BennekumAlistair Cockburn

Ward CunninghamMartin Fowler

© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customerthrough 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.

Principles behind the Agile Manifesto(continued)

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.

.

Principles behind the Agile Manifesto(continued)

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.

Agile Methodologies

XP (eXtreme Programming) Crystal DSDM (Dynamic Systems Development Method) SCRUM ASD (Agile Software Development) And others…

Impact of Agile on Requirements

Traditional software convention is based on the assumption that: A system should be clearly specified before

beginning design and implementation. A specification should be unambiguous,

consistent, concise, traceable and implementation independent.

… Impact of Agile on Requirements

Requirements and models are a valid expression of user needs

All requirements have equal value Cost of changing requirements becomes more

expensive as a project progresses.


But agile processes have little upfront analysis/design, minimal documentation and little structure for ensuring consistency and traceability, how can it work effectively as a software methodology?

After all, reports show that poor requirements gathering is responsible for 45% of cancelled projects.


Of delivered systems, most did not provide the expected business value.

Agile approaches allow requirements which provide the most value to the business emerge during development.

Most users cannot intelligently respond to only requirements and models.


Agile processes focus on business value :

Business value = f(cost,time,functionality,quality)

Example : DSDM supposes that 80% of a systems value is delivered by 20% of a systems requirements.


New development tools, testing tools, source management tools and version control tools allow for solid development environments which support the ability to rapidly generate high quality re-factored releases of a system.

Agile approaches have emerged in the past ten years.


To be successful, Agile techniques must possess tools to cope with a constantly changing and poorly defined environment.

Communication must be strongly supported, encouraged and practiced by all participants.

Self evaluation and modification is vital.

Agile Principles

Assume Simplicity Embrace Change Software is Your Primary Goal Enabling the Next Effort is your Secondary

Goal Incremental Change Maximize Stakeholder Investment Model with a Purpose

… Agile Principles

Multiple Models Quality Work Rapid Feedback Travel Light

Agile Practices

Active Stakeholder Participation Apply the Right Artifact(s)

An artifact is a modeling technique (graphical or textual) used during application development

Collective Ownership Consider Testability Create Several Models in Parallel

… Agile Practices

Create Simple Content Depict Models Simply Display Models Publicly Iterate to Another Artifact Model in Small Increments Model with Others Prove it with Code Use the Simplest Tools

Agile Communication

Sweet Spots

Two to Eight People in One Room Onsite Usage Experts One-Month Increments Fully Automated Regression Tests Experienced Developers

Self Adaptation

Traditional Software techniques, if at all, rarely do post-evaluations

Agile techniques use on-the-fly self adjustment to fine tune the methodology to the project.

Communication, trust, relevance and openness is key to success in agile processes.

A Self Adaptation Technique

When ? Right now At the start of the project In the middle of the first increment After each increment In the middle of subsequent increments

A Self Adaptation Technique

Ask to see one sample of each work product produced.

Ask for a short history of the project Ask what should be changed Ask what should be repeated Identify priorities Find Holes

Adaptation Conclusion

Post project Review ? Reflection Workshops.

Most important rule of stabilizing and maintaining communication in agile processes :

BOTHER TO REFLECT

Specific MethodsSpecific Agile methods and how they deal with requirements

XP (eXtreme Programming)Crystal

30

eXtreme Programming

(XP)

Extreme Programming

Not this kind of extreme…

Context

The roots of XP lie in the Smalltalk community, and in particular the close collaboration of Kent Beck and Ward Cunningham in the late 1980’s.

The crucial step from informal practice to a methodology occurred in the spring of 1996: The Chrysler C3 project (Chrysler

Comprehensive Compensation).

Values

Communication Simplicity Feedback Courage ... Respect

Fundamental Principles

Rapid feedback Assume simplicity Incremental change Embracing change Quality work

Activities

Coding Testing Listening Designing

Practices (1/2)

The Planning Game Small Releases Metaphor Simple Design Testing Refactoring

Practices (2/2)

Pair Programming Collective Ownership Continuous Integration 40-Hour Week On-Site Customer Coding Standards

Strategies

Management Strategy Facilities Strategy Splitting Business and Technical

Responsibility Planning Strategy Development Strategy Design Strategy Testing Strategy

XP: User Stories

One thing the customer wants the system to do

1-5 programming weeks Should be testable

XP: Types of Risk addressed

Scheduling slips Project canceled System goes sour Defect rate Business misunderstood Business changes False feature rich

XP: Strengths

Negotiation and Cooperation, not Adversarial Customer Involvement Customer Ownership

XP: Weaknesses

Requires a lot of customer’s time Absence of documentation Restriction to small teams Allegiance to current project

45

Crystal Clear

Crystal: Goals & Core values

“Software development is viewed as cooperative game of intervention and communication, with a primary goal of delivering useful, working software and setting up the next game”

Cockburn, 2001 Family of shrink-to-fit, human-powered software development

methodologies

Number of people involved

C

riti

cali

ty(d

efec

ts c

ause

loss

of.

..)

Comfort(C)

Essentialmoney

(E)

Life(L)

+20%

. . . Prioritized for Legal Liability

1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000

C6 C20 C40 C100 C200 C500 C1000

D6 D20 D40 D100 D200 D500 D1000

E6 E20 E40 E100 E200 E500 E1000

L6 L20 L40 L100 L200 L500 L1000

Prioritized for Productivity & Tolerance

The Crystal Family

Discretionarymoney

(D)

Crystal Clear

The Crystal Family of Methodologies

The Crystal family of methodologies is predicated in two things: Capturing the elements that successful projects

repeatedly cite as cause for their success Give the team members the most latitude possible in

doing their work

Different kinds of projects require different kinds of methodologies. Typically, projects differ in: The number of people in the project The consequences of errors

Crystal ClearCrystal Clear

What’s Crystal Clear?

The Crystal Clear methodology addresses 4‑6 person projects.

Pretends to be the lightest full methodology that will still produce good results.

Recommendations from project members on these types of projects include: Reduce the bureaucratic load Increase communication Increase the rate of feedback back to the team


Values

Strong on communications. Light on deliverables. Keep the communications paths short,

rich and informal. Deliver frequently. Reduce overhead.


In compliance with Crystal Clear (1/2)

You have short, rich communication paths.

You deliver increments regularly, no longer than 3 months apart.

You have a real user on the project, even if only part time.

You have a project mission statement, you are using usage-based requirements, probably use cases, and you have a description of the system design.


In compliance with Crystal Clear (2/2)

You have a clear ownership model for your work products.

There is a regression testing framework and you have regression tests for your system. You do some form of code peer reviewing.


Crystal Clear (2)

Workproducts: release sequence schedule of user viewings use cases or feature descriptions design sketches common object model running code migration code test cases user manual

Sample Lightweight Documentation

Crystal: Requirements Techniques

Use Cases Communication tools Anything from other methods…

Crystal: Strengths

Scalable Variable project risk Adaptable Based on human communication

Crystal: Weaknesses

Lack of defined structure Does not optimize production or

documentation

Comparison of Agile Processes

Agile and SASD

Agile SASD

Business value for the customer/user

Business value for the customer/user

Develop as quickly and cheaply as possible

Use models and work products to ensure quality

Involve the user in development

User is involved early on, but not during development

Iteratively elicit requirements (negotiation/emergence)

With req’ts established, sequentially follow process model

Priority on eliminating unneeded req’ts

Priority on traceability and work products

60

Conclusions

Should you go light?

The following factors suggest an adaptive process: Uncertain or volatile requirements Responsible and motivated developers Customer who understands and will get involved

These factors suggest a predictive process: A team over fifty Fixed price, or more correctly a fixed scope, contract

Which Adaptive Process?

Team size and discipline. XP imposes a stronger discipline than any

of the others. ASD focus on developing good-enough

software. Crystal Clear appears to be the “lightest

of the light”. Take charge of your process, monitor it and

adapt it to your circumstances.

63

References

References (1/3)

Martin Fowler. “The New Methodology”. Abridged version published in Software Development Magazine, December 2000. http://www.martinfowler.com

Dirk Riehle. “A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other”. SKYVA International, 2000. http://www.riehle.org

References (2/3)

Jim Highsmith. “Messy, Exciting and Anxiety-Ridden: Adaptive Software Development”. Published in American Programmer Magazine, April 1997. http://www.adaptivesd.com/

Jim Highsmith. “Adaptive Software Development”. Presented at OOPSLA 2000.

Kent Beck. Extreme Programming Explained: Embrace Change. Addison‑Wesley, 2000.

References (3/3)

Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherland. “SCRUM: A Pattern Language for Hyperproductive Software Development.” In Pattern Languages of Program Design 4. Edited by Neil Harrison, Brian Foote, and Hans Rohnert. Addison‑Wesley, 2000. Page 637-652.

Alistair Cockburn. Crystal “Clear”. AOL, 2000. http://alistair.cockburn.us/crystal/index.html

Sources

Adapted from

• “Lightweight Methodologies” by Dias

http://www.esw.inesc-id.pt/~pmigmd/docs/LightweightMethodologies.ppt

(Slides 2-4, 32-38, 48-53, 61-62,64-66)

• “Requirements Engineering in Agile Approaches” by Balas, Fournie, & Luo http://pages.cpsc.ucalgary.ca/~laf/613/Group/presentation.ppt

(Slides 5-6, 12-28, 31, 39-44, 46, 54-59)

Documents

A Case for Agile Development. From Nothing, to Heavy, to Light (1) Most software development is a chaotic activity, often characterized by the phrase