AGILE METHODOLOGIES

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 1

 AGILE METHODOLOGIES
Whats Agility?
Why Agility?
Agile Manifesto and Principles
Whats Methodology and why?
Methodologies that promote agility
Conclusion

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 2

 AGILITY
Whats Agility?
Being agile
Whats Agile?
marked by ready ability to
move with quick easy grace
having a quick resourceful and
adaptable character
What does that mean?
I. Process has to be lightweight and sufficient
II. Lightweight helps us adapt and move
III. Sufficient recognizes our ineffectiveness to
be complete and relies on strong
communication

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 3

 AGILE METHODOLOGIES
Whats Agility?
Why Agility?
Agile Manifesto and Principles
Whats Methodology and why?
Methodologies that promote
agility
Conclusion

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 4

 EVOLUTION OF FIELDS
Bridge Construction

Medicine

Airplanes

Software Development

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 5

 BRIDGE CONSTRUCTION

Early Wood, Stone

Then Iron, Steel
Concrete Bridges
Constructing a bridge is different
from innovating a bridge (with new
material for instance) for the first
time
Engineers use well established
metrics to design bridges they do
not innovate at this stage

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 6

 MEDICINE
Health was thought to be
restored by purging,
starving, vomiting or
bloodletting
Both surgeons and barbers were
specializing in this bloody practice
Widely practiced in 18th and 19th
century
Declared quackery by 1900
Infection control
If patient survived surgery,
he most likely died out of infection
Germ theory and sterility came only in
late 1800s (Lister)
Current rate of infection < 2.5%

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 7

 AIRPLANES
400 BC Chinese fly kite aspiring
humans to fly
For centuries, we tried to fly like
birds disastrous
Steam powered, hot air
Gliders, single man
Engine powered
1903 Wright brothers first
flight 12 seconds, 120 feet, 10
feet altitude

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 8

 SOFTWARE DEVELOPMENT
Relatively nascent field in
comparison

Machines are getting faster or

more powerful

Are we getting better in

delivering software applications
though

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 9

 SUCCESS (OR LACK THERE
OF)
How successful are we in
developing software?

Less than 10% of software projects

succeed1
Criteria for success?: On time,
within budget, feature complete,
works (failure free)

Why is it so hard to get this right?

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 10

 SOFTWARE ENGINEERING?
Whats Engineering?2, 3
the application of science and mathematics by which
the properties of matter and the sources of energy in
nature are made useful to people
the design and manufacture of complex products
<software engineering>
If software engineering like manufacturing or
designing a manufacturing plant?
Is it like making another cell phone or making of cell
phones (took 37 years for commercialization)?
Manufacturing is predictive
You can measure and control quality, quantity
Designing a manufacturing plant is
creative/innovative
Most software development is innovative process
rather than predictive manufacturing
Requires great deal of innovation,
interaction/communication

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 11

 WHY IS IT HARD TO
COMMUNICATE?
Why not simply write good documents
to describe requirements and hand
them off to developers to create
software?

We have tried that, but we know it

does not work

3 factors influence
What you are communicating
Who is communicating
With whom

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 12

 A Picture is worth a
thousand words

Lets take a look at

this picture from
Stephen Coveys
7 Habits
of Highly Effective
People

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 13

 WHAT YOU SEE?

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 14

 WHAT YOU SEE?

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 15

 WHAT YOU SEE?

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 16

 REALIZING WHAT MAKES IT
HARD
Ceremony: Amount of method
weight for documentation, formal
steps, review,
Documents cant fully describe the
requirements
3 types of people make up your
team
Those with exceptional domain knowledge but
little software development expertise
Those with exceptional software dev.
experience, but little domain knowledge
Those with both domain and software
development skills
(we will ignore that 4th category)
Closer and frequent interaction is
a necessity

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 17

 PROCESS

Waterfall approach4
Actually specified iteration - largely
ignored
Customers mind is not frozen after
they give us the requirements
We are not able to fully understand
what is said
Show me a long project duration, I
will show you a project that is
already doomed

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 18

 ITERATIVE AND
INCREMENTAL
How to foster
innovation and
communication?
Isolation does not
help
Interaction is key
among developers and
with customers
But will that not
take more time?

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 19

 THE TIME/SCHEDULING
HYPOCRISY
What can you tell me about the
next project, you ask?
It is due on November 1st tells your
manager

We hold deadlines too dearly

Of course, time to market is
critical

But what generally happens on

projects when you hit that
deadline?

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 20

 PICK TWO
Ask your customers to pick two
out of the following, you decide
the third:

Time
Scope
Quality

Reality often ignored in project

planning

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 21

 AGILE DEVELOPMENT
PROCESS
Iterative and evolutionary
development
Timeboxing
Set amount of time for iteration
Adapt future iteration based on the realities
Adaptive planning
Incremental delivery
Agility
More focused on success than
sticking with a plan
Working software is valued and
considered measure of progress

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 22

 AGILE METHODOLOGIES

Whats Agility?
Why Agility?
Agile Manifesto and Principles
Whats Methodology and why?
Methodologies that promote
agility
Conclusion

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 23

 AGILE MANIFESTO

Venkat Subramaniam (svenkat@cs.uh.edu) http://agilemanifesto.org Agile Methodologies - 24

PRINCIPLES BEHIND THE AGILE
MANIFESTO
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.
.

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 25

PRINCIPLES BEHIND THE AGILE
MANIFESTO
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.
Simplicitythe art of maximizing the
amount of work not doneis 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 .

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 26

 AGILE METHODOLOGIES

Whats Agility?
Why Agility?
Agile Manifesto and Principles
Whats Methodology and why?
Methodologies that promote
agility
Conclusion

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 27

 METHODOLOGY

Methodology

Its what you dowhatever that is

to create software

Series of related methods to

coordinate peoples activities on a
team

How work is done

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 28

 WHY METHODOLOGY?

Helps to explain how your team

works

Helps us understand responsibilities

and priorities

Helps measure progress and show

progress

Serves as a framework to learn from

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 29

 AGILE METHODOLOGIES

Whats Agility?
Why Agility?
Agile Manifesto and Principles
Whats Methodology and why?
Methodologies that promote
agility
Conclusion

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 30

 METHODOLOGIES
1. Methodologies share common
principles,
2. but differ in practices
3. eXtreme Programming (XP)
4. Scrum
5. Evolutionary Project Management (Evo)
6. Unified Process (UP)
7. Crystal
8. Lean Development (LD)
9. Adaptive Software Development (ASD)
10.Dynamic System Development Method
(DSDM)
11.Feature Driven Development (FDD)

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 31

 EXTREME PROGRAMMING
(XP)

http://www.extremeprogramming.org

http://www.xprogramming.com
Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 32
 XP
Kent Beck, Ward Cunningham, Ron Jeffries based
on experience from C3 project
XP has nothing new, yet it has something new!
Four values, Twelve practices
Based on what has worked on projects, taking them to
extreme
If something is good why not do it all the time?
Small teams (under 20)
Onsite customer presence
Planning game
Negotiate requirements in form of stories captured on
index cards
2 to 3 weeks iteration
Scales well for problem size within limits, but does
not scale well for team size
But, a competent smaller team is better than a large team
following heavier methodologies
Deemphasizes documentation
Accelerates development, but may be a problem for
transition later on

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 33

 CONTROL VARIABLES
Cost
Too little, does not solve problems
Too much, some times more of a problem
Time
More time can improve quality and increase scope.
Too much time hurts as well
Feedback from system in production is imperative
Quality
Sacrificing this may result in short term gains
Over the long haul, lost is enormous
Scope
Lesser the scope, better the quality
You can deliver sooner as well
Assuming it meets the business needs

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 34

 SET OF VALUES
Communication
Communicate critical change in requirements, design,
etc.
Put in place practices that will enhance communication
Simplicity
Find simplest thing that will work
Build some thing simple today and pay a little to change
tomorrow than build some thing complicated today that
may never be used
Feedback
Unit tests provide feedback
Corrected in minutes and days, not weeks
System that stays out of the hands of users is trouble
waiting to happen
Courage
Dont hesitate to throw code away if you find better
simpler way
Do not hesitate to call attention to problems if they are
significant and will benefit from reworking

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 35

TAKING IT TO EXTREME
It takes good commonsense principles
and practices to extreme levels
If code review is good, well review code all the time
Pair programming
If testing is good, every body will test all the time
Unit testing by developers, functional testing by
customers
If design is good, well make it part of everybodys
daily business
Refactoring
If simplicity is good, well make it part of the system
with simplest design that supports its current
functionality
If architecture is important, everybody will work
defining and refining the architecture all the time
metaphor
If integration testing is important, then well
integrate and test several times a day
Continuous integration
If short iterations are good, well make the iterations
really, really short seconds and minutes and
minutes and hours, not weeks and months and years
The planning game

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 36

 XP PRINCIPLES
The Planning Game
Scope next release with business priorities, technical
estimates
Update the plan based on reality
Small Releases
Put simply system into production quickly
Release new version in short cycle
Metaphor
Guide development with simple shared story of how
the whole system works
Simple Design
Design as simple as possible at any given moment.
Testing
Continually write and run unit tests

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 37

 XP PRINCIPLES
Refactoring
Restructure system without changing its behavior to remove
duplication, improve communication, add flexibility and
simplify
Pair Programming
Two programmers, one machine, four eyes are better than
two
Collective Ownership
Anyone can change code anywhere in the system at any time
Continuous Integration
Integrate and build the system many times a day, every time
a talk is completed.
40-hour Week
Never work overtime a second week in a row
On-site Customer
Real, live user on the team, available full-time to answer
questions
Coding Standards
All code written accordance with rules emphasizing
communication through the code

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 38

 WHERE DOES XP WORK?
Culture
Business culture
How change is accepted? Need to work long
hours? Goal oriented? Heavy on paper work?
Size
Team size of around 10 is ideal
Technology
Must be able to make change quickly and get
feedback
Work environment
Should promote closer interaction and
communication

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 39

 SCRUM

http://en.wikipedia.org/wiki/Image:Rugby_union_scrummage.jpg

http://www.controlchaos.com

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 40

 SCRUM
Developed by Ken Schwaber and Jeff Sutherland
Name derived from Rugby
Groups effort to move quickly to counter the opposite team,
adjusting the move along progress
Scrum Master coach for the team
Looks outward keeping distractions out
Trusts the self-managed team to get work done
Sprint 30 days iteration cycle with pre-sprint
and post-sprint activities
Scrum meeting Short standup meeting to
communicate and monitor progress
Backlog used for planning
Features and estimate of duration for each task
Task for sprint picked from the pool of tasks
Used to decide features for sprint and plan out the work
Sprint Goal minimum success criterion to steer
and keep focus

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 41

 SCRUM
Leaves documentation depth to
specifics of projects may need more or
less
aim for as little as possible
Self-directed and self-organized team
Competent focused people
Demo to stakeholder at iteration end
Client-driven adaptive planning
No work added during iteration
Lends itself to experimenting on certain
parts of the application development

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 42

 SCRUM LIFECYCLE
Planning
Vision, expectations, funding
Staging
Identify requirements, prioritize
iteration
Development
Implement system ready for release in
each sprint
Release
Operational deployment

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 43

 SCRUM VALUES
Commitment
Team takes responsibility to complete the
Sprint. To avoid things that will stand in its
way
Focus
Teams focus is maintained. Distractions,
interruptions are fielded
Openness
Overall and individual status and
commitments kept open.
Respect
Team responsibility rather than scapegoating.
Courage
Management and team have the courage to
take responsibility to do what is necessary

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 44

EVOLUTIONARY PROJECT MANAGEMENT (EVO)

http://www.gilb.com

http://www.gilb.com

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 45

 EVO
Oldest iterative and incremental
method
introduced in 1960s by Tom Gilb, published 1976
Short (5 days) iteration
Evolutionary requirements and
design
Recommends measurable short list
of project objectives
Avoids big up-front specification
Evolving requirements
Recommends use of a Planguage a
specification language that could
make it ceremonial
Emphasizes measurable progress
Frequent delivery to stakeholders
Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 46
 UNIFIED PROCESS (UP)

http://www-306.ibm.com/software/awdtools/rup

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 47

 UP
Developed by Rational Software Corp (now
part of IBM), lead by 3 amigos
Grady Booch, James Rumbaugh, Ivar Jacobson
Derived from several methodologies at
that time
Micro and Macro development process
Micro deals with tactical issues (daily
activities)
Macro process has inception, elaboration,
construction, and transition
Generally viewed as heavy weight process
Agile in sprit, but can get very ceremonial
Emphasizes iterative cycles, constant feedback
Developed along with UML which provides for several
forms of documentation
Comes from disciplined process oriented
angle
Not easy to tailor for small projects

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 48

 CRYSTAL

http://alistair.cockburn.us

http://alistair.cockburn.us

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 49

 CRYSTAL FAMILY
Alistair Cockburn
Framework of related methods
addressing variability of environment
and specific characteristics of projects
Size of development team
Project criticality
Loss - due to defect - of comfort, essential money,
discretionary money, life
Crystal a metaphor for color and
hardness
Clear, yellow, orange, red
People and Communication centric
Lighter (color) is better as long as it
lasts
See/show significant consequence or risk before
implementing a harder/darker version
Project specific methodologies

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 50

 CORE PROPERTIES
Frequent delivery/integration using
time-boxed iterations
Reflect and improve, criticize and fix
Osmotic (passive) knowledge
acquisition and communication
through office organization and
open channels
Personal Safety, safe to be honest,
confidence to court criticism
Stay focused, clear tasks, priorities
on work, limit the workload
Access to expert users, fast, quality
feedback
The usual agile stuff: automated
testing, CM, continuous integration

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 51

 LEAN DEVELOPMENT (LD)

http://www.itabhi.com/ld.htm

http://www.itabhi.com/ld.htm
Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 52
 LD
Developed by Robert Charette based
on lean manufacturing - proprietary
Risk entrepreneurship turn risk into
opportunity
Phases:
Startup
Planning, business cases, feasibility studies
steady state
Series of short spirals
transition-renewal
Doc developed and delivered
More business strategies and
project management approach
Involves everyone, not just developers
Focused on accessing and achieving business value
LD is strategic, business-down
approach whereas most agile
approaches are tactical, program
team-oriented in nature.

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 53

 LD PRINCIPLES
Satisfying the customer is the highest priority
of the organization
Always provide the best value for money
Success depends on active customer
participation
Every lean development is a team effort
Everything is changeable
Domain, not point solutions
Complete, dont construct
Minimalism is essential
Needs determine technology
Product growth is feature growth, not size
growth
Never pushlean developmentbeyond its
limits

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 54

 ADAPTIVE SOFTWARE
DEVELOPMENT

http://www.adaptivesd.com

http://www.adaptivesd.com
Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 55
 ASD
Developed by Jim Highsmith and
Sam Bayer based on rapid
application development (RAD)
Emphasizes continuous
adaptation of the process
Speculate, Collaborate, and learn
cycles
Continuous learning and
adaptation as project emerges
Mission focused, feature based,
iterative, timeboxed, risk driven,
and change tolerant
Non prescriptive in nature not
much on how to do things, more
of opportunities to take to meet
the goal

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 56

 DYNAMIC SYSTEMS DEVELOPMENT
METHOD (DSDM)

http://www.dsdm.org

http://www.dsdm.org

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 57

 DSDM

Developed by DSDM consortium

Mostly European
Five phases: feasibility, business
study, functional model iteration,
design and build iteration,
implementation
Strong emphasis for project
management activities
10 project roles (a person may play
more than one role)
Plans evolve based on increments
Timeboxing means for planning,
monitoring, controlling
Prioritized using MoSCow
Must have, Should have, Could have, Want
Designed for small teams, but scales
up

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 58

 FEATURE DRIVEN DEVELOPMENT
(FDD)

http://www.nebulon.com/fdd

http://www.nebulon.com/fdd

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 59

 FDD
Jeff DeLuca and Peter Coad
Simple process, modeling, short
iteration cycle
Good people for domain knowledge,
design, and development
Expects requirements to be well
captured and understood
Expects classes to be assigned to
individuals
Emphases on getting the
architecture right
Suitable for stable systems with
predictable evolution

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 60

 QUICK COMPARISON

Ceremony and Iteration

Competency Level
Expectations

Emphasis

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 61

 CEREMONY AND ITERATION

Fewer More
documents/steps documents/steps
Scrum

UP
XP
Evo

Craig Larmans: Agile & Iterative Development A Managers Guide

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 62
COMPETENCY LEVEL
EXPECTATIONS
Cockburn Levels: following (level1), detaching
(level2), fluent (level3)
The Dreyfus Model of Skills Acquisition (level 1
to 5) [Herding racehorses and racing sheep
Dave Thomas]

UP XP Scrum
LD ASD
FDD
Highly
Competent

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 63

 XP Scrum Evo UP Crystal
Iteration 2/3weeks 30days 5days Short Short
CustomerParticipation Strong Strong Strong Reco Strong
TDD Strong Strong Reco
BusinessProcess Medium Medium High Med/High
TeamSize Small Small Med/large Varies
Ceremonial Low Flexible Med/high High Varies
Feature PairProg, Scrum Customer Varies
Collective meeting, driven, basedon
ownership, Timeboxing, frequent criticality,
strong Backlog, delivery, highfocus,

EMPHASI

customer Selfdirected short

participation, team,open iteration,


domain
expert
S
constant communi- oneofthe presence
refactoring, cation first
40hours
workweek
Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 64
 AGILE METHODOLOGIES
Whats Agility?
Why Agility?
Agile Manifesto and Principles
Whats Methodology and why?
Methodologies that promote
agility
Conclusion

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 65

REFERENCES
1. "Software Project Management Practices: Failure Versus Success," Capers Jones
(http://www.stsc.hill.af.mil/crosstalk/2004/10/0410Jones.html)
2. "Agile Software Development," Alister Cockburn, Addison-Wesley.
3. "Agile and Iterative Development: A Manager's Guide," Craig Larman, Addison-Wesley.
4. "Iterative and Incremental Development: A Brief History," Craig Larman, IEEE Computer, June
2003.
5. "Planning Extreme Programming," Kent Beck, Martin Fowler, Addison-Wesley.
6. "Agile Software Development, Principles, Patterns, and Practices," by Robert C. Martin,
Prentice Hall.
7. "Agile Software Development with SCRUM," Ken Schwaber, Mike Beedle, Prentice Hall.
8. "Information Radiator," http://c2.com/cgi-bin/wiki?InformationRadiator.
9. "Test Driven Development: By Example," Kent Beck, Addison-Wesley.
10. "Pragmatic Unit Testing in Java with JUnit," Andy Hunt, Dave Thomas, Pragmatic
Programmers.
11. "Refactoring: Improving the Design of Existing Code," Martin Fowler,
Kent Beck, John Brant, William Opdyke, Don Roberts, Addison-Wesley.
12. "Continuous Integration," Martin Fowler, Matthew Foemmel,
http://www.martinfowler.com/articles/continuousIntegration.html.
13. "Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps," Mike Clark,
Pragmatic Programmers.
14. "Continuous Integration Server Feature Matrix,"
http://docs.codehaus.org/display/DAMAGECONTROL/Continuous+Integration+Server+Featu
re+Matrix.
15. "The Pragmatic Programmer: From Journeyman to Master," Andrew Hunt, David Thomas,
Addison-Wesley.
16. Some interesting articles to read - http://tinyurl.com/drnor

Venkat Subramaniam (svenkat@cs.uh.edu) Agile Methodologies - 66