Agile Software Engineering Seminar Report

BE IT - Seminar 2015-16
Seminar Report
On
“Agile Software Engineering”
Submitted for the partial fulfillment of BE Information Technology
Submitted By: Guide:

Ajay Kumar Gahalot Dr. Rajesh Purohit
Enroll. No. – 12/15601 Associate Professor
Roll No. – 15BIT70001
Department of Computer Science and Engineering

MBM Engineering College, Faculty of Engineering,
Jai Narain Vyas University
Jodhpur (Rajasthan)
Session 2015-16
CERTIFICATE
This is to certify that report entitled “Agile Software Engineering” submitted to

Department of Computer Science and Engineering, MBM Engineering College, JNV
University in partial fulfillment of the requirements for the award of the degree of B.E.
is the bonafied record of the work done by Mr. Ajay Kumar Gahalot under my
supervision and guidance.
Signature of guide
(Dr. Rajesh Purohit)
Associate Professor
DECLARATION
I, Ajay Kumar Gahalot hereby declare that this seminar titled “Agile Software
Engineering” is a record of original work done by me under the supervision and
guidance of Dr. Rajesh Purohit. We further certify that this project work has not
formed the basis for the award of the Degree/Diploma/Associateship/Fellowship or
similar work to any candidate of any university and no part of this report is
reproduced as it is from any other source without seeking permission.
Signature of student
(Ajay Kumar Gahalot)
Enroll. No. : 12/15601
Roll No: 15BIT70001

Table of contents
Abstract.................................................................................................................5
1. Introduction.......................................................................................................6
1.1 What is agile?..............................................................................................6
1.2 Where did agile come from?.......................................................................6
1.3 Why agile?..................................................................................................7
2. Agile Manifesto.................................................................................................8
2.1 Basic aspects of manifesto.........................................................................8
2.2 Agile principles..........................................................................................11
3. Agile Characteristics.......................................................................................12
3.1 Iterative, Incremental and Ready to Evolve..............................................12
3.2 Face-to-Face Communication...................................................................12
3.3 Feedback loop...........................................................................................12
3.4 Time-bound...............................................................................................13
3.5 Parsimony.................................................................................................13
3.6 Convergent................................................................................................13
3.7 People-oriented.........................................................................................13
4. Comparison of Agile and
Conventional...............................................................14
4.1 Shortcomings of conventional waterfall
approach.........................................14
4.2 Iterative and agile methods.......................................................................15
4.3 Agile vs.
Conventional...................................................................................16
5. Agile Methods.................................................................................................19
5.1 Adaptive software development................................................................19
5.2 Extreme Programming..............................................................................21
5.3 Scrum........................................................................................................27
5.4 Crystal.......................................................................................................32
6. Summary.........................................................................................................36
7. References......................................................................................................38
Agile Software Engineering Page 4

Abstract
Abstract
In software development process there is always a problem and tension about
quality of software, cost of software development, and time period of software
development process from planning to release. In today’s time, it is very difficult for
developers to deliver a good quality software in required time with cost efficient.
Conventional software development methods are plan-driven which means they
execute a predefined plan for development process in which they have lot of
documentations and these plans often are not applicable for every project for good
quality and fullfill user requirements.
In the past few years the interest in lightweight methods is growing continuously
which provide a way to useful compromise between no process and very much
process.
Agile methodologies or often called lightweight methods have less documentation

and emphasises more on coding for software development. These agile methods
state that source code for software is the document with most importance. Agile
methodologies define methods for software development process that focuses at
customer requirements fulfilment and satisfaction and delivering useful software
continuously and in rapid way. These methods are called agile because these
methods do not follow a specific plan and these methods are able to accept change
or we can say these are adaptable and not rigid. This document discusses some of
these Agile methods, the philosophy driving them and the challenges in
implementation.

Introduction
1. Introduction
Software development activity used to follow “code and fix” approach in earlier days.
This way worked well for systems which were small but it failed when the systems
grew larger, and when there was a need to add some new features. To avoid this
methodology of Engineering came into existence. The purpose of these methods
was to make the software methods more efficient and predictable and by having a
strong focus on planning activity. This way of implementation works also well for
other engineering fields. But the software market is always changing and brings
greater choices into market. Managers and users must deal with some issues for
example what to exclude and what types of technologies include in the software
product, what technologies to be used, what will give a competitive edge to the
company? These questions are difficult to answer and trying predict them in a fastly
changing market is more difficult.
As a reaction, to these methods, lightweight processes like agile processes

appeared on the scene. Agile processes try to compromise between too much
process and no process.
1.1 What is the meaning of agile?
Agile approach is an alternative to conventional project management, typically used

in software development. It helps teams respond to unpredictability through
incremental, iterative work cadences, known as sprints. Agile methodologies are an
alternative to waterfall, or conventional sequential development. Agile model
believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In agile the tasks are
divided to time boxes (small time frames) to deliver specific features for a release.
1.2 Where did agile come from?
In 1970, Dr. Winston Royce presented a document with title “the Development and
management of Large Software Systems,” which criticized the sequential methods of
development. He stated that the software should not be developed like an
automobile on the assembly line, in which every piece added in sequential phases.
In such type of sequential phases, each phase of project should be completed
compulsory before next phase begin. Dr. Royce suggested against phase based
approach inwhich developers first collect all the project’s requirements, then
complete all of its structure and the design, then write all the code, and so on
continuously. Royce objected specifically to this approach due to lack of the
communication between the specialized groups those complete each part of work.
A collection of lightweight software development processes came in
existence in the mid - 1990s in reaction to the observed heavy weight waterfall type
methods, which critics called heavily organised, controlled, and micro-managed;
although some partisans of these light weight processes contended that these were

Introduction
simply returning back to earlier software development practices. These light weight
processes include: from 1994, dynamic systems development method (DSDM) and
unified process; from 1995, scrum; 1996, extreme programming (also known as
"XP") and crystal clear; and from 1997, feature-driven development and adaptive
software development. Although these resulted before the publication of Agile
Manifesto in 2001, they are now together referred to as agile methodologies.
1.3 Why agile is required?
Agile development processes gives opportunities to assess direction of a project

through the software development lifecycle. This is achieved through regular tempo
of work, known as iterations or sprints, at the end of the which teams must present a
possibly shippable product increment. By emphasising on the iteration of
abbreviated work cycles, as well as functional product they yield, agile approach
described as “incremental” and “iterative.” In waterfall development method,
development teams have only one chance to get each form of a project right. In an
agile method, every aspect of development like requirements, design, etc. is
continually revisited throughout the lifecycle. When a team stops and re evaluates
direction of a project in every two weeks, there’s always time to drive it in other
direction.
Results of this type of “inspect-and-adapt” approach of development
largely decrease both, time to market and development costs. Because, the teams
can develop software at the same time when they’re gathering requirements, the
phenomenon known as “analysis-paralysis” is less likely to cut off a team from
making progress. The agile development process helps companies to build right
product. Instead of carry out to industry a piece of software that is not even been
written yet, agile empowers teams to replan continuously their release for optimize
value throughout the development, allowing them to be as competitive as possible in
marketplace.

Agile Manifesto
2. Agile Manifesto
In 2001, founders of the many of lightweight agile software development
methodologies came altogether with others who were also implementing many types
of agile methods in the field and they created an “Agile Manifesto” which summarize
their belief that there is a better approach to develop software. The Agile Manifesto
was a synthesis of some common beliefs that under lie the various methods that
they were practicing and promoting. It substantially boosted up the adoption of agile
methodologies in the industry because it provided common base for all who headed
down this way, and it did a very good job of integrating and defining the basic beliefs
that underlying the agile movement.
2.1 Basic Aspects of Agile Manifesto:

Agile manifesto states, in parts:
“We are uncovering better ways of developing software by doing it and

helping others do it. Through this work we come to value:
 Individuals and interactions over processes and tools.

 Working software over comprehensive documentation.
 Customer collaboration over contract negotiations.
 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.”
2.1.1 Individuals and Interactions
People form the base of agile software approach. Using adaptive process requires a
very effective team of developers. The team has to work well together to be more
effective. Teamwork is given high importance than using a specific methods and
tools. Any methods and tools should be used as to increase the team work except of
replacing it. Communication also plays a important role in upgrading the Teamwork.
The face to face meetings have some special importance in agile methodologies. It
is considered that people respond faster and transfer beliefs or concepts more fastly
when talking face to face, than they can while reading or writing documentation.
Extreme programming brings the idea of pair programming where two developers
code a module together to provide much quicker and better output than the same job
they done individually. The concept of synergy (i.e. the interaction of two or more
forces or agents, so that the together effect is greater than the sum of their individual
effects) takes hold because of a few designers, sharing a common space, working
together, can produce more code quicker than can produce the same individuals
working alone.

Agile Manifesto
In conventional methodologies treat people as resources that are as replaceable

part. Like stated earlier they tell that individuals are not so important as their roles
are. They fail to understand that each individual is unpredictable and dynamic. When
we are programming a computer, we are controlling a predictable device. But when
we are handling human beings, this approach fails. Treating like individuals are
replaceable resources decreases their spirit and they look for much better working
environments.
An other important point of individuals and interactions is that the team should be
provided rights to take all technical decisions. At the times fast decision making is
required, if we have to wait every time for the management to approve it then it slows
down the entire process of development. So the power of technical decisions taking
must rest in the hands of technical people.
2.1.2 Working Software

In agile methods, source code is the only most important document when in the
conventional approach (big design up front) the requirement’s document is the only
most important document. In big design upfront (BDUF), it is possible to collect all
the requirements upfront (beforehand) prior writing code. This is a classical way
which works good for mechanical industry where, we gather all requirements, get the
customer to agree on them, and then apply functions to restrict change. Collecting of
requirements beforehand gives the project a level of predictability. Thus this
predictability has a value and is very important when the systems in consideration
are Life critical systems where large requirements change could be a disaster. For all
other systems this predictability adds a layer of documentation.
It has been a practice, in the Waterfall model to deliver the design documents, the
architecture documents or the test plans, the test cases etc to customer before we
deliver real piece of the working software.
In this continuously changing industry it is not possible to collect the complete set of
customer requirements that are unchanging and stable. The customer is not always
sure of what does he want. He gets a better understanding only when he looks a
prototype of the system or a working model. That helps the customer to predict the
final system better. As the time passes customer may want to add some descriptions
which at that time looks important to have.
However agile methods link code and requirements together. Users of agile methods
view the requirements as changing and fluid. In agile practice of working, the
conventional practice of creating design documents, test plans, test cases, etc. to
customer before it should be substituted with giving piece of working software
increment iteration. It does not mean that we have to escape documentation
completely; but the only necessary documentation which is produced i.e. never

Agile Manifesto
produce document predicting future as they have the possibility of becoming

outdated. Valuable software should be handed over early and iteratively during
development. Agile development in a way, helps in decreasing the time taken for the
product or software to achieve the market giving scope for frequent response.
2.1.3 Customer Collaboration

Whenever a software development is done by separate firm customer prefers the fix
price contracts, in which he specify their needs, asks for a quotation of price, and
finally accepts a price and leave the development to firm. Agile methods need
customer to be on the site. They need the customer to play an active role in design
process. The customer effectively is on development team and works with
developers, to approve decisions and guiding project through his perspective. This
role is different from the conventional role of the customer and this change affects
business side of project also.
Agile methods say that the requirements can never be fixed so fixed price
development practice would not work in this condition. This doesn’t mean that we
can’t budget what the project made using agile methods would cost. Agile method is
to fix time, cost, and to allow the scope to change in a controlled way. As customer
has better control on project making changes based on feedback got. At the every
iteration, customer and the development team can check progress and can decide
with development team if to alter the direction of the project.
Writing contracts with customers is the profit motive and the collaboration is a
purpose oriented. The purpose motive should be given more importance than the
profit motive. Good agile softwares will build the something different and a better
than original plan foresaw.
2.1.4 Responding to Change
Today’s market is a volatile and, the ever changing making it impossible for a
predictive method to work on constant set of requirements. Responding to change
than following laid out plan makes agile software process successful in market today.
Software development is more of a design activity, so it’s hard to plan and cost. For
software development to be predictable there is need for plenty of time, a large team,
and stable requirements which is not possible in small projects. The problem with
predictive processes is their difficult to map new requirement to additional cost, as
they cannot predict how much it would cost to implement the new requirement.
Software is intangible in nature, it is difficult to see what value a software feature has
until we use it for real. Only after seeing the early prototype or version can one
understand what features are important what are not. So this means that

Agile Manifesto
requirements should be changeable. The flexibility to accommodate changes into the

plan is more significant than just writing a plan and following it.
The idea to respond to change is using an iterative approach while developing where
we produce working versions of final software frequently that handle subset of
requirements. These working systems should be integrated in the end to produce the
final system. This is better than having documents which can hide flaws. Untested
code can also hide certain flaws. But when we have people working on the system
we can unearth flaws faster.
2.2 Agile Principles

The manifesto is based on twelve principles:
1. Customer satisfaction by early and continuous delivery of valuable software

2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing
teams
12. Regularly, the team reflects on how to become more effective, and adjusts
accordingly

Agile-characteristics
3. Agile-Characteristics
There are many specific agile development methods. Most promote development,
teamwork, collaboration, and process adaptability throughout the life-cycle of the
project. Some characteristics of agile methods are:
3.1 Iterative, Incremental and Ready to Evolve
Most of the agile development methods break a problem into smaller tasks. There is
no direct long-term planning for any requirement. Normally, iterations are planned
which are of vary short period of time, for example, 1 to 4 weeks. A cross-functional
team is created for each iteration that works in all functions of software development
like planning, requirements analysis, design, coding, unit testing, and acceptance
testing. The result at the end of the iteration is a working product and it is
demonstrated to the stakeholders at the end of an iteration. This minimizes overall
risk and allows the project to adapt to changes quickly. An iteration might not add
enough functionality to warrant a market release, but the goal is to have an available
release (with minimal bugs) at the end of each iteration. Multiple iterations might be
required to release a product or new features.
Working software is the primary measure of progress.
3.2 Face-to-Face Communication

No matter what development disciplines are required, each agile team should
include a customer representative (product owner in scrum). This person is
appointed by stakeholders to act on their behalf and makes a personal commitment
to being available for developers to answer mid-iteration questions. At the end of
each iteration, stakeholders and the customer representative review progress and
re-evaluate priorities with a view to optimizing the return on investment (ROI) and
ensuring alignment with customer needs and company goals.
In agile software development, an information radiator (physical display) is normally

located prominently in an office, where passers-by can see the progress of the agile
team. This information radiator shows an up-to-date summary of the status of a
project. A build light indicator may be used to inform a team about the current status
of their project.
3.3 Feedback Loop
A common characteristic in agile is the daily "stand-up", also known as the daily
scrum. It is a kind of a brief session where each team member reports to each other
regarding the status of what they have done, what to do next, and any issues they
are facing.

Agile-characteristics
3.4 Time-Bound
Iterations become the perfect unit for planning the software development project. We
can set time limits (between one and six weeks is normal) on each iteration and
schedule them accordingly. Chances are, we will not (unless the process contains
very few activities) schedule all of the activities of our process in a single iteration.
Instead, we will only attempt those activities necessary to achieve the goals set out
at the beginning of the iteration. Functionality may be reduced or activities may be
rescheduled if they cannot be completed within the allotted time period.
3.5 Parsimony
Agile processes are more than just a conventional software development process
with some time constraints. Attempting to create impossible deadlines under a
process not suited for rapid delivery puts the onus on the software developers. This
leads to burnout and poor quality. Instead, agile software processes focus on
parsimony. That is, they require a minimal number of activities necessary to mitigate
risks and achieve their goals. By minimizing the number of activities, they allow
developers to deliver systems against an aggressive schedule.
3.6 Convergent
Convergence states that we are actively attacking all of the risks worth attacking. As
a result, the system becomes closer to the reality that we seek with each iteration.
As risks are being proactively attacked, the system is being delivered in increments.
We are doing everything within our power to ensure success in the most rapid
fashion.
3.7 People-Oriented
Agile processes favour people over process and technology. They evolve through
adaptation in an organic manner. Developers that are empowered raise their
productivity, quality, and performance. After all, they are the best individuals in the
organization to know how to make these changes.
Conclusion
Agile processes are not a new phenomenon. They are the evolution of the
best practices which have been refined over the past thirty years. They are not a
silver bullet which will cure your project of all of its ills or guarantee success.
Successfully delivering a project requires hard work and the understanding of the
potential pitfalls. No single process will work for every project. Yet, most projects
would agree that they would like to be more agile. Developing a more agile process
for your project requires an understanding of the dynamics of these projects. It also
requires a certain amount of common sense.

Comparison of Agile and Traditional
4. Comparison of Agile and Conventional
Conventional development approaches have been around for a very long time.
Since its introduction the waterfall model (Royce 1970) has been widely used in both
large and small software projects and has been reported to be successful to many
projects. Despite the success it has a lot of drawbacks, like linearity, inflexibility in
changing requirements, and high formal processes irrespective of the size of the
project. Kent Beck took these drawbacks into account and introduced Extreme
Programming, the first agile methodology produced. Agile methods deal with
unstable and volatile requirements by using a number of techniques, focusing on
collaboration between developers and customers and support early product delivery.
4.1 Shortcomings of Conventional Waterfall Approach
The essence of waterfall software development is that complex software systems

can be built in a sequential, phase-wise manner where all of the requirements are
gathered at the beginning, all of the design is completed next, and finally the master
design is implemented into production quality software.
This approach holds that complex systems can be built in a single pass, without
going back and revisiting requirements or design ideas in light of changing business
or technology conditions. It was first introduced in an article written by Winston
Royce in 1970, primarily intended for use in government projects. Waterfall equates
software development to a production line conveyor belt. “Requirements analysts”
compile the system specifications until they pass the finished requirements
specification document to “software designers” who plan the software system and
create diagrams documenting how the code should be written. The design diagrams
are then passed to the “developers” who implement the code from the design.
Some of the drawbacks of this model are:
 some requirements may arise after the initial requirement gathering was
completed, which influences negatively the product development;
 not all problems detected during a stage are completely solved during the
same stage;
 there is no flexibility in partitioning the project into stages;
 new requirements added by the client lead to additional costs, because they
cannot be solved in the current edition of the product;
 it is difficult to estimate the time and budget for each stage;
 there are no prototypes until the life cycle is finished;
 if testing detects some problems, it is very difficult to return to design stage;
 there is a high risk and uncertainty;
 it is not recommended for complex and object oriented projects.

Figure 4.1: Agile vs. Conventional (http://www.tutorialspoint.com)
The waterfall model is recommended for the following cases:
 requirements are well understood, clear and final;

 product definition is stable;
 technology is understood;
 there are no ambiguous requirements;
 resources that involve expertise are freely available;
 it is a short project.
4.2 Iterative and Agile methods
Incremental and Iterative Development
The idea of revisiting phases over and over is called “incremental and iterative
development” (IID). The development lifecycle is cut up into increments or
“iterations” and each iteration touches on each of the conventional “phases” of
development. For example, with IID requirements is an ongoing process that is
periodically revisited. IID allows for multiple “passes”, or iterations, over a project
lifecycle to properly address complexities and risk factors.

In the incremental model the requirements are divided into subsets. The model
involves multiple development cycles, which makes the life cycle look like a “multiple
waterfall” model. The cycles are again divided into smaller cycles, modules easier to
manage. Each module goes through requirement analysis, design, implementation
and testing. During the first module, a working version of the software is created.
Each following version adds new features and functionalities to the previous one.
The process continues until the system is completed.
Some of the advantages of this model are:
 each stage delivers a working product, that meets some of the client
requirements;
 prototypes are delivered to the client;
 client feed-back is distributed throughout the entire development process;
 it is more flexible – involves lower costs when purpose and requirements
change;
 it is easy to test and debug during a small iteration; cuts down on initial
delivery costs;
 the risk is easier to manage because all risks are identified and managed
during the iteration;
 when there are new requirements, they can be introduces in the next
prototype
4.3 Agile vs. Conventional
Adaptive vs. predictive
Development methods exist on a continuum from adaptive to predictive. Agile

methods lie on the adaptive side of this continuum. Adaptive methods focus on
adapting quickly to changing realities. When the needs of a project change, an
adaptive team changes as well. An adaptive team has difficulty describing exactly
what will happen in the future. The further away a date is, the more vague an
adaptive method is about what will happen on that date. An adaptive team cannot
report exactly what tasks they will do next week, but only which features they plan
for next month. When asked about a release six months from now, an adaptive team
might be able to report only the mission statement for the release, or a statement of
expected value vs. cost.
Predictive methods, in contrast, focus on analysing and planning the future in detail
and cater for known risks. In the extremes, a predictive team can report exactly what
features and tasks are planned for the entire length of the development process.
Predictive methods rely on effective early phase analysis and if this goes very
wrong, the project may have difficulty changing direction. Predictive teams often

institute a change control board to ensure they consider only the most valuable
changes.
Iterative vs. waterfall
One of the differences between agile and waterfall is the approach to quality and
testing. In the waterfall model, there is always a separate testing phase after a build
phase; however, in agile development testing is usually done concurrently with, or at
least in the same iteration as, programming.
Because testing is done in every iteration which develops a small piece of the
software, users can frequently use those new pieces of software and validate the
value.
After the users know the real value of the updated piece of software, they can make
better decisions about the software's future. Having a value retrospective and
software re-planning session in each iteration, scrum typically has iterations of just
two weeks that helps the team continuously adapt its plans so as to maximize the
value it delivers.
This iterative practice also introduces a product mindset rather than the waterfall
model's project mindset. Software can be seen as a living organism, which actively
changes due to environmental change. As long as the software is being used,
especially when it has competition, iterations in agile software development drive the
change.
Because of the short iteration style of agile software development, it also has strong
connections with the lean start-up concept.
Code vs. documentation
In a letter to IEEE Computer, Steven Rakitin expressed cynicism about agile

development, calling it "yet another attempt to undermine the discipline of software
engineering" and translating "Working software over comprehensive documentation"
as "We want to spend all our time coding. Remember, real programmers don't write
documentation."
This is disputed by proponents of agile software development, who state that

developers should write documentation if that's the best way to achieve the relevant
goals, but that there are often better ways to achieve those goals than writing static
documentation. Scott Ambler states that documentation should be "Just Barely Good
Enough" (JBGE), that too much or comprehensive documentation would usually
cause waste, and developers rarely trust detailed documentation because it's usually
out of sync with code, while too little documentation may also cause problems for
maintenance, communication, learning and knowledge sharing. Alistair
Cockburn wrote of the Crystal Clear method:

Crystal considers development a series of co-operative games, and intends that the
documentation is enough to help the next win at the next game. The work products
for Crystal include use cases, risk list, iteration plan, core domain models, and
design notes to inform on choices...however there are no templates for these
documents and descriptions are necessarily vague, but the objective is clear, just
enough documentation for the next game. I always tend to characterize this to my
team as: what would you want to know if you joined the team tomorrow.

Agile Methods
5. Agile Methods
Agile is a whole methodology. You can call, it is a type of project management, it is a
way of working as a team. For example, comparing with playing basketball,
sometimes you want to play man-to-man and other times you want to play a zone.
Thus we can say there are two ways of executing game of basketball. Similarly, we
can say that Agile is a way of executing software development project management.
So it is a project methodology. Here the word ‘methodology’ can be referred as "A
series of related methods or techniques." A method is a "systematic procedure,"
similar to a technique.
Popular agile software development methods and/or process frameworks include

(but are not limited to):
 Adaptive software development (ASD)

 Agile Unified Process (AUP)
 Business analyst designer method (BADM)
 Crystal Clear Methods
 Disciplined agile delivery
 Dynamic systems development method (DSDM)
 Extreme programming (XP)
 Feature-driven development (FDD)
 Lean software development
 Kanban (development)
 Scrum
 Scrumban
In this paper we will discuss some commonly used agile methodologies:
5.1 Adaptive Software Development
ASD, developed by Jim Highsmith1 does not provide the details often associated
with a process. Milestones, methods, and deliverables are not specific elements
discussed by ASD. Instead, ASD places its emphasis on applying ideas originating
in the world of complex adaptive systems (i.e. Chaos theory). ASD provides the
fundamental base to develop adaptive systems from which arise agile and adaptive
processes.
Jim Highsmith states that the premise of ASD is that outcomes are naturally
unpredictable and, therefore, planning is a paradox. It is not possible to plan
successfully in a fast moving and unpredictable business environment. Adaptive
development is essential when you have developers, customer, vendors,
competitors and, stockholders all attempting to interact with one another at such a
pace that linear cause and effect rules cannot assure success. ASD replaces the

Agile Methods
evolutionary life cycle model with the adaptive cycle model as shown in following
figure:
Figure 5.1: Evolutionary Life Cycle and Adaptive Life Cycle

(http://www.adaptivesd.com/index.html)
5.1.1 Process
An Adaptive Software Development Project is carried out in three-phase cycles. The

phases of the cycles are Speculate, Collaborate and Learn (as shown in above
figure).
Speculate:
ASD recognizes the fact that there is no point in experimenting endlessly in search
of success. So the first phase of ASD is named “speculate” rather than planning
which is not suitable for unpredictable world. Speculation means developing the
good idea of where the project is heading, and put mechanisms in place to adapt to
changing customer needs, changing technology and a changing market.
Collaborate:
Collaboration replaces build because of ASD’s recognition that people are essential
while making a successful product. The customer collaborates in all activities of the
software creation to get what he needs from the system. Collaboration is the activity
of balancing: managing a project, such as configuration control and change
management, with creativity the act of trusting people to find creative answers in an
unpredictable environment.
Learn:
Learning replaces revise because revise is backward looking. In the evolutionary life
cycle revise means that while change is necessary it should be based on original
plan i.e. change cannot question original plan, it has to be in conformance with

Agile Methods
original plan. Learning is the act of gaining knowledge through experience. Learning
is often discouraged in predictable environments; we may lay out things in advance
and then follow then in design. In learning we can question all previous assumptions,
using the results to decide in which direction to move.
5.1.2 Roles and Responsibilities
The ASD largely originates from organisational and management culture and,
especially, the importance of collaborating teams and teamwork. The approach does
not, however, describe team structures in detail. Likewise, very few roles or
responsibilities are listed. An "executive sponsor" is named as the person with
overall responsibility for the product being developed.
5.1.3 Practices
ASD provides very few practices for day-to-day software development work.
Basically, (Highsmith 2002) expressly names three: iterative development, feature-
based (component based) planning and customer focus group reviews.
5.2 Extreme Programming
Extreme Programming (XP) is a high profile agile process known to many advocates
and novices alike and is likely the most widely used. Extreme Programming (XP)
originators aimed at developing a methodology suitable for “object-oriented projects
using teams of a dozen or fewer programmers in one location.”
The methodology is based upon five underlying values: communication, simplicity,

feedback, courage, and respect.
 Communication – Without communications project schedules slip, quality

suffers, and the customer’s wants and needs are misinterpreted or
overlooked.
 Feedback – The need to check our results is important. Without feedback, a
project will most likely fail. Feedback tells how a project is doing while
providing direction for future iterations.
 Simplicity – Do not add unnecessary artifacts or activities to a project.
Eliminate everything not completely justified.
 Courage – Putting faith in the people over the process requires courage. It is
important to realize, however, that if processes do become more important
than the people do, a project is headed toward failure.
 Respect – Team members need to care about each other and about the
project.
5.2.1 Process

Agile Methods
The life cycle of XP consists of five phases: Exploration, Planning, Productionizing,

Maintenance and Death as shown in the following figure:
Figure 5.2: Life cycle of the XP process (http://www.wiki.amachu.in)
Exploration Phase:
The customers write out the story cards that they wish to be included in the first
release. Each story card describes a feature to be added into the program. At the
same time the project team familiarize themselves with the tools, technology and
practices they will be using in the project.
Planning Phase:
The planning phase sets the priority order for the stories and an agreement of the
contents of the first small release is made. The programmers first estimate how
much effort each story requires and the schedule is then agreed upon.
Iterations to Release Phase:
This phase includes several iterations of the systems before the first release. The
schedule set in the planning stage is broken down to a number of iterations. The first
iteration creates a system with the architecture of the whole system. The customer
decides the stories to be selected for each iteration. The functional tests created by
the customer are run at the end of every iteration. At the end of last iteration the
system is ready for production.

Agile Methods
Productionizing Phase:
This phase requires extra testing and checking of the performance of the system
before the system can be released to the customer. At this phase, new changes may
still be found and the decision has to be made if they are included in the current
release.
Maintenance Phase:
After the first release of the product, the project must both keep the system in the
production running while also producing new iterations. In order to do this, the
Maintenance phase requires an effort for the customer support tasks. This phase
may require incorporating new people into the team and changing the team
structure.
Death Phase:
The Death phase is near when the customer does no longer have any stories to be
implemented. This requires that the system satisfies customer needs also in other
aspects (e.g., concerning performance and reliability). This is the time when the
necessary documentation of the system is finally written. Death may also occur if the
system is not delivering the desired outcomes, or if it becomes too expensive for the
further development.
5.2.2 Roles and Responsibilities
There are different roles in XP for different tasks and purposes during the process
and its practices. These are as following:
 Manager – The manager owns the team and its problems. He or she forms
the team, obtain resources, and manage people and problems, and interfaces
with external groups.
 Coach – The coach teaches team members about the XP process as
necessary, intervenes in case of issues; monitors whether the XP process is
being followed. The coach is typically a programmer and not a manager.
 Tracker – The tracker regularly collects user story and acceptance test case
progress from the developers to create the visible wall graphs. The tracker is
a programmer, not a manager or customer.
 Programme – The programmer writes tests, design, and code; refactors;
identifies and estimates tasks and stories (this person may also be a tester) o
Tester, helps customers write and develop tests (this person may also be a
programmer).
 Customer – The customer writes stories and acceptance tests; picks stories
for a release and for iteration. A common misconception is that the role of the

Agile Methods
customer must be played by one individual from the customer organization.

Conversely, a group of customers can be involved or a customer
representative can be chosen from within the development organization (but
external to the development team).
 Consultant – The consultant is an external member possessing the specific
technical knowledge needed. The consultant guides the team in solving their
specific problems.
5.2.3 Practices
XP is a collection of ideas and practices drawn from already existing methodologies.

XP aims at enabling successful software development despite vague or constantly
changing requirement in small to medium sized teams. Short iterations with small
releases and rapid feedback, customer participation, communication and
coordination, continuous integration and testing, collective ownership of the code,
limited documentation and pair programming are among the main characteristics of
XP. The practices of XP are presented as follows:
 Sit together – The whole team develops in one open space.

 Whole team – XP utilize a cross-functional team of all those necessary for the
product to succeed.
 Informative workspace – place visible wall graphs around the workspace so
that team members (or other interested observers) can get a general idea of
how the project is going.
 Energized work – XP teams do not work excessive overtime for long periods
of time. The motivation behind this practice is to keep the code of high quality
(tired programmers inject more defects) and the programmers happy (to
reduce employee turnover). Tom DeMarco contends that, “Extended overtime
is a productivity reducing technique.”
 Pair programming – refers to the practice whereby two programmers work
together at one computer, collaborating on the same design, algorithm, code,
or test.
 Stories – the team write short statements of customer-visible functionality
desired in the product. The developers estimate the story; the customer
prioritizes the story.
 Weekly cycle – at the beginning of each week a meeting is held to review
progress to date, have the customer pick a week’s worth of stories to
implement that week (based upon developer estimates and their own priority),
and to break the stories into tasks to be completed that week. By the end of
the week, acceptance test cases for the chosen stories should be running for
demonstration to the customer to drive the next weekly cycle.
 Quarterly cycle – the whole team should pick a theme or themes of stories for
a quarter’s worth of stories. Themes help the team reflect on the bigger
picture. At the end of the quarter, deliver this business value.

Agile Methods
 Slack – in every iteration, plan some lower-priority tasks that can be dropped
if the team gets behind such that the customer will still be delivered their most
important functionality.
 Ten-minute build – structure the project and its associated tests such that the
whole system can be built and all the tests can be run in ten minutes so that
the system will be built and the tests will be run often.
 Test-first programming – all stories have at least one acceptance test,
preferably automated. When the acceptance test(s) for a user story all pass,
the story is considered to be fulfilled. Additionally, automated unit tests are
incrementally written using the test-driven development (TDD) practice in
which code and automated unit tests are alternately and incrementally written
on a minute-by-minute basis.
 Continuous integration – programmers check in to the code base completed
code and its associated tests several times a day. Code may only be checked
in if all its associated unit tests and all of unit tests of the entire code base
pass.
 Incremental design – rather than develop an anticipatory detailed design prior
to implementation, invest in the design of the system every day in light of the
experience of the past. The viability and prudence of anticipatory design has
changed dramatically in our volatile business environment. Refactoring to
improve the design of previously-written code is essential. Teams with robust
unit tests can safely experiment with refactorings because a safety net is in
place.
The architecture of XP has following components:
 Spike
 Metaphor
 First Iteration
 Small Releases
 Refactoring
 Team Practices
Spike
During the release planning game, the team has the opportunity to do spikes: quick
throw away (and thrown away) exploration into the nature of the solution.
We decide the system approach based on the stories and spikes. For example is the
story is about managing orders on the Internet then the solution we might think of
contains an application server, a web server, a database and a pair of firewalls. The
spikes one does in the early phase guides us to the Deployment phase. Because
spikes begin early on one can be prepared with the installation of hardware and
software needed, so that project doesn’t get halted because of inadequate
resources.

Agile Methods
Metaphor
An effective Metaphor helps guide your solution. In XP metaphor acts as a

conceptual framework and provides a descriptive system of names. It identifies the
key objects and their interactions. The metaphor may change as one’s understand
the system better.
First iteration
The first iteration is the key in making the system come together. From Extreme
Programming explained (Kent Beck)
“The first iteration puts the system in place. Pick stories for the first iteration that will
force one to create “the whole system” even if it is in skeletal form. “
Small releases
XP’s small releases help jell the architecture quickly. As we are installing a few
months work, we are forced to get the essential structure together. We deliver the
stories most important to the user first. So we get immediate feedback from the user
which will help us correct the weak areas in the architecture.
Refactoring
Refactoring is improving a computer program by re-organizing its internal structure

without altering its external behaviour. It helps us manage design without changing
the system’s behaviour; therefore, we don’t risk the functionality of our program
while we improve its architecture.
Team Practices
The software architecture document is useful only if it tells how developers

implement the things the system is supposed to do. XP forges the Software
Architecture Document that RUP (Rational unified process) values, but still has
architecture. Pair programming helps ensure that the people know and use the
approach the team is using.
Though not one of the “official” XP practices, essentially all XP teams also have
short Stand-Up Meetings daily. In these meetings, the team stands in a circle
(standing is intentional to motivate the team to keep the meeting short). In turn,
each member of the team tells the group:
 What he or she accomplished the prior day?

 What he or she plans to do today?
 Any obstacles or difficulties he or she is experiencing?

Agile Methods
Often the pair-programming pairs are dynamically formed during the daily meeting
as the tasks for the day are discussed and the two programmers that are best
equipped to handle the task join together.
A “courageous” XP manager will keep a record of such meetings in order to turn

them into quantitative progress measures of the project.
5.3 Scrum
In the Scrum process puts a project management “wrapper” around a software
development methodology. The methodology is flexible on how much/how little
ceremony but the Scrum philosophy would guide a team towards as little ceremony
as possible. Usually a Scrum teams works co-located. However, there have been
Scrum teams that work geographically distributed whereby team members
participate in daily meeting via speakerphone. Scrum teams are self-directed and
self-organizing teams. The team commits to a defined goal for an iteration and is
given the authority, autonomy, and responsibility to decide how best to meet it.
With Scrum, projects progress via a series of iterations called sprints. Each sprint is
typically 2-4 weeks long. Scrum is ideally suited for projects with rapidly changing or
highly emergent requirements.
5.3.1 Documents
Product backlog
The product backlog is a high-level document for the entire project. It contains broad
descriptions of all required features, wish-list items, etc. It is the "What" that will be
built. It is open and editable by anyone. It contains rough estimates, usually in days.
This estimate helps the Product Owner to gauge the timeline and, to a limited extent,
priority (e.g. if "add spell-check" feature is estimated at 3 days vs. 3 months, that
may affect the Product Owner's desire).
Sprint backlog
The sprint backlog is a greatly detailed document containing information about how
the team is going to implement the requirements for the upcoming sprint. Tasks are
broken down into hours with no task being more than 16 hours. If a task is greater
than 16 hours, it should be broken down further. For each task in the backlog, the
spreadsheet contains a short task description, who originated the task, who owns
the task, the status and the number of hours remaining to complete the task. The
Sprint Backlog is updated each day by a daily tracker who visits the team members
to obtain the latest estimates of the work remaining to complete the task. Estimates
can increase when the team member realizes that the work was underestimated.
Tasks on the sprint backlog are never assigned; rather tasks are signed-up for by
the team members as they like.

Agile Methods
Burn down Chart
The Burn down chart is a publicly displayed chart showing the number of tasks
remaining for the current sprint or the number of items on the product backlog. The
hours remaining to complete Sprint tasks are graphed and predominantly displayed
for the team. It should not be confused with an earned value chart. A burn down
chart could be flat for most of the period covered by a sprint and yet the project
could still be on schedule.
5.3.2 Scrum Roles
Several roles are defined in Scrum; these are divided into two groups; pigs and
chickens, based on a joke about a pig and a chicken.
The pigs are committed to building software regularly and frequently, while everyone
else are chickens that are interested in the project but are really irrelevant because if
it fails they're not a pig, that is they weren't the ones that committed to doing it. The
needs, desires, ideas and influences of the chicken roles are taken into account, but
not in any way letting it affect or distort or get in the way of the actual Scrum project.
"Pig" Roles
Pigs are the ones committed to the project and the Scrum process; they are the
ones with "their bacon on the line."
 Product Owner
The Product Owner represents the voice of the customer. They ensure that
the Scrum Team works with the right things from a business perspective. The
Product Owner writes User Stories, prioritizes them, then places them in the
Product Backlog.
 Scrum Master (or Facilitator)
Scrum is facilitated by a Scrum Master, whose primary job is to remove

impediments to the ability of the team to deliver the sprint goal. The Scrum
Master is not the leader of the team (as they are self-organizing) but acts as a
buffer between the team and any distracting influences. The Scrum Master
ensures that the Scrum process is used as intended. The Scrum Master is the
enforcer of rules and sprints of practice.
 Team
The team has the responsibility to deliver the product. A small team of 5-9
people with cross-functional skills to do the actual work (designer, developer
etc.).

Agile Methods
"Chicken" Roles
Chicken roles are not part of the actual Scrum process, but must be taken into
account. An important aspect of agile approach is the practice of involving users,
business and stakeholders into part of the process. It is important for these people to
be engaged and provide feedback into the outputs for review and planning of each
sprint.
 Users
The software is being built for someone! Never forget that software that is not
used is like a tree falling in the forest - was it ever written?
 Stakeholders (Customers, Vendors)
The people that will enable the project, but are not directly involved in the
process.
 Managers
People that will set up the environment for the product development
organization.
5.3.3 Process
Figure 5.3: Scrum Process (http://en.wikipedia.org)
Above figure is an introduction to everything essential in Scrum agile software

development. On the left, we see the product backlog, which has been prioritized by
the product owner and contains everything wanted in the product that’s known at the
time. The 2-4 week sprints are shown by the larger green circle.
Sprint Planning Meeting

Agile Methods
The Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the
entire Scrum Team, and any interested and appropriate management or customer
representatives.
During the sprint planning meeting the product owner describes the highest priority
features to the team. The team asks enough questions during this meeting so that
they can go off after the meeting and determine which tasks they will move from the
product backlog to the sprint backlog.
The product owner doesn't have to describe every item being tracked on the product
backlog. Depending on the size of the backlog and the speed of the team it may be
sufficient to describe only the high priority items, saving the discussion of lower
priority items for the next sprint planning meeting. Typically, the Scrum team will
provide guidance when they start to get further into the backlog list than they know
could be done in the next sprint.
Collectively, the Scrum team and the product owner define a sprint goal, which is a
short description of what the sprint will attempt to achieve. The success of the sprint
will later be assessed during the Sprint Review Meeting against the sprint goal,
rather than against each specific item selected from the product backlog.
After the sprint planning meeting, the Scrum team meets separately to discuss what
they heard and decide how much they can commit to during the coming sprint. In
some cases there will be negotiation with the product owner but it will always be up
to the team to determine how much they can commit to completing.
Daily Scrum Meetings
On each day of a sprint, the team holds daily meetings (“the daily scrum”). Meetings
are typically held in the same location and at the same time each day. Ideally the
daily scrums are held in the morning as they help set the context for the coming
day's work.
Scrum affords special status to those who are committed and many teams enforce a
rule in which only those who are committed are allowed to talk during the daily
scrum.
All team members are required to attend the daily scrum. Anyone else (for example,
a departmental VP, a salesperson, or a developer from another project) is allowed to
attend but is there only to listen. This makes the daily scrums an excellent way for a
Scrum team to disseminate status information--if you're interested in hearing where
things are at, attend that day's meeting.
The daily scrum is not used as a problem-solving or issue resolution meeting. Issues
that are raised are taken offline and usually dealt with by the relevant sub-group

Agile Methods
immediately after the daily scrum. During the daily scrum each team member
provides answers to the following three questions:
 What did you do yesterday?

 What will you do today?
 Are there any impediments in your way?
By focusing on what each person accomplished yesterday and will accomplish today
the team gains an excellent understanding of what work has been done and what
work remains. The daily scrum is not a status update meeting in which a boss is
collecting information about who is behind schedule. Rather, it is a meeting in which
team members make commitments to each other. If a programmer stands up and
says "Today I will finish the data storage module" everyone knows that in tomorrow's
meeting he will say whether or not he did finish. This has the wonderful effect of
helping a team realize the significance of these commitments and that their
commitments are to each other, not to some far-off customer or salesman.
Any impediments that are raised become the Scrum Master's responsibility to
resolve as quickly as possible. In cases where the Scrum Master cannot remove
these impediments directly himself (e.g., usually the more technical issues) he still
takes responsibility for making sure someone on the team does quickly resolve the
issue.
Sprint Review Meeting
At the end of each sprint a sprint review meeting is held. During this meeting the
Scrum team shows what they accomplished during the sprint. Typically this takes
the form of a demo of the new features.
The sprint review meeting is intentionally kept very informal, typically with rules
forbidding the use of PowerPoint slides and allowing no more than two hours of
preparation time for the meeting. A sprint review meeting should not become a
distraction or significant detour for the team; rather, it should be a natural result of
the sprint.
Participants in the sprint review typically include the Product Owner, the Scrum
team, the Scrum Master, management, customers, and engineers from other
projects.
During the sprint review the project is assessed against the sprint goal determined
during the Sprint planning meeting. Ideally the team has completed each product
backlog item brought into the sprint, but it is more important that they achieve the
overall goal of the sprint.
5.3.4 Practices

Agile Methods
Following are some general practices of Scrum:
 Customers become a part of the development team. (i.e., the customer must
be genuinely interested in the output.)
 Like all other forms of agile software processes, Scrum has frequent
intermediate deliveries with working functionality. This enables the customer
to get working software earlier and enables the project to change its
requirements according to changing needs.
 Frequent risk and mitigation plans developed by the development team itself.
– Risk Mitigation, Monitoring and Management (risk analysis) at every stage
and with genuinity.
 Transparency in planning and module development – Let everyone know who
is accountable for what and by when.
 Frequent stakeholder meetings to monitor progress – Balanced (Delivery,
Customer, Employee, and Process) Dashboard updates – Stakeholders'
update – You have to have Advance Warning Mechanism, i.e. visibility to
potential slippage / deviation ahead of time.
 No problems are swept under the carpet. No one is penalized for recognizing
or describing any unforeseen problem.
Workplaces and working hours must be energized. – "Working more hours" does not
necessarily mean "producing more output."
5.4 Crystal
Crystal is a family of processes each applied to different kinds of projects. Crystal

approach includes principles for tailoring the methodologies to fit the varying
circumstances of different projects. The idea of having multiple processes stems
from the thinking that some projects require fewer rigors than others do. Small and
non-critical projects can be developed using less rigorous Crystal methods. Larger
and more critical projects, however, demand more attention and therefore, a more
rigorous Crystal process used.
Selecting a Crystal process requires that a project be matched to one of four

criticality levels.
 Comfort
 Discretionary money
 Essential money
 Life A system failure for the first
As such, the different methods are assigned colors arranged in ascending opacity;
the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange,
and Crystal Red.

Agile Methods
5.4.1 Crystal Clear
Crystal Clear is designed for very small projects comprising up to six developers.
Crystal Clear should be located in a shared office space due to the limitation in its
communication structure. The property of close communication is strengthened to
“osmotic” communication meaning that people overhear each other discussing
project priorities, status, requirements, and design on a daily basis.
Crystal Clear’s model elements are as follows:
 Documents and artifacts: release plan, schedule of reviews, informal/low-

ceremony use cases, design sketches, running code, common object model,
test cases, and user manual.
 Roles: project sponsor/customer, senior designer-programmer, designer
programmer, and user (part time at least)
 Process: incremental delivery, releases less than two to three months, some
automated testing, direct user involvement, two user reviews per release, and
methodology-tuning retrospectives. Progress is tracked by software delivered
or major decisions reached, not by documents completed.
5.4.2 Crystal Orange
Crystal Orange is designed for medium sized projects, with a total of 10 to 40 project
members, and with a project duration of one to two years .In Crystal Orange the
project is split up for several teams with cross-functional groups . It emphasizes the
importance of the time to market issue.
Crystal Clear’s model elements are as follows:
 Documents and artifacts: requirements document, release plan, schedule,

status reports, UI design document, inter-team specs, running code, common
object model, test cases, migration code, and user manual.
 Roles: project sponsor, business expert, usage expert, technical facilitator,
business analyst, project manager, architect, design mentor, lead designer
programmer, designer-programmer, UI designer, reuse point, writer, and
tester.
 Process: incremental delivery, releases less than three to four months, some
automated testing, direct user involvement, two user reviews per release, and
methodology-tuning retrospectives.

Agile Methods
Figure 5.4: One Crystal Orange Increment
5.4.3 Practices
All Crystal methodologies involve a number of practices, such as incremental

development. The increment of a Crystal Orange includes activities such as staging,
monitoring, reviewing, along with parallelism and flux.
Monitoring
The progress is monitored regarding the team deliverables during the development
process with respect to their progress and stability .Monitoring is required in both
Crystal Clear and Crystal Orange.
Parallelism and flux
Once the monitoring of stability gives the positive result for the deliverables the next
task can start. In Crystal Orange this means that the multiple teams can proceed
with maximum parallelism successfully.
Holistic diversity strategy
Crystal Orange includes this method for splitting large functional teams into cross-
functional groups. The central idea of this is to include multiple specialities in one
team
User viewings
Two user viewings are suggested for Crystal Clear per one release. In Crystal
Orange, user reviews must be organized three times for each increment.

Agile Methods
Methodology tuning technique
It is one of the basic tuning techniques for Crystal Clear and Orange. It uses project
interviews and team work shops for working out a specific Crystal methodology for
each individual project.
Staging
Staging includes the planning of the next increment of the system. It should be
scheduled to produce a working release in every 3 to 4 months at the maximum. The
team selects the requirements to be implemented in the increment and schedules
what they feel they are able to deliver.
Revision and review
Each increment includes several iterations. Each iteration includes the following
activities: construction, demonstration and review of the objectives of the increment.
While each of the Crystal processes share the standards the rigor involved is
dependent on the project and the chosen process. For example, less critical projects
suggest two-month incremental delivery time spans whereas critical projects,
demanding a rigorous process, may extend time-to-delivery increments to a
maximum of four months. Projects are comprised of multiple increments. Crystal
processes define the functions contained in an increment.

References
6. Summary
Agile process tell that the organisation that implement these in software
development processes and the softwares that are built using these methods are
acceptable to change as per user requirements . A method is agile if it is one which
supports and accepts the change without any hesitation or reluctance.
Large organizations prefer heavyweight methods over agile processes as they have
the contracts with fixed price and an strong tendency for following software
engineering concepts. They have a big investment in big design up front methods.
Life critical systems project have the severity to use BDUF processes, which also
increases their cost and time to produce. But now a days these organizations
learning to use agile methods for their existence in the industry and to compete with
other organisations.
We summarize following factors which are following, that suggest an adaptive

method
 If requirements are not certain and variant with time

 Responsible and motivated developers
 Customers who understand and want to get involved in development process.
Following factors suggest a predictable process
 A team of fixed size, for example size is hundred

 Contracts with fixed cost and having a fixed scope.
One of the biggest challenges undercoming is that how they handle larger projects
and systems. Extreme programming clearly says that it has creates teams for
software development process having around 20 people. The message is one
should implement agile when the user requirements are not constant and one can
not have a fixed design and cannot follow a planned process.
The software development method can be agile if it is:
 Incremental
 Cooperative
 Straight forward
 Adaptive to changeable requirements
“Agile methods are more people centric except than plan-centric.” Agile methods are
not defined by a small set of principles, practices and techniques. It creates a
strategy which has capability of responding to change, capability of innovation and
creations through development team and uncertainty, capability to balance the
project structure and flexibility.

References
We also have discussed about some different Agile Software development methods
as following:
 Adaptive Software Development (ASD)

 XP (Extreme programming)
 Scrum
 Crystal

References
7. References
 Manifesto for Agile software development; http://agilealliance.com
 New methodology; Fowler; Martin;
http://www.martinfowler.com/articles/newMethodology.html
 Highsmith Jim (2002) Agile Software Development ecosystems. Boston, MA
Pearson Education
 Extreme Programming Explored; Wake, William; Addison Wesley ISBN 0-
201-73397-8; July 2001; Chapter 5
 www.extremeprogramming.org; Last modified January 26, 2003;
 The Agile Manifesto is online at http://www.agilemanifesto.org/
 Agile Software Development
https://en.wikipedia.org/wiki/Agile_software_development

Agile Software Engineering Seminar Report

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Software Engineering Seminar Report

Uploaded by

Copyright:

Available Formats

BE IT - Seminar 2015-16

“Agile Software Engineering”

Submitted for the partial fulfillment of BE Information Technology

Submitted By: Guide:

Department of Computer Science and Engineering

This is to certify that report entitled “Agile Software Engineering” submitted to

(Dr. Rajesh Purohit)

(Ajay Kumar Gahalot)

Enroll. No. : 12/15601

Roll No: 15BIT70001

Agile Software Engineering Page 4

Agile methodologies or often called lightweight methods have less documentation

Agile Software Engineering Page 5

As a reaction, to these methods, lightweight processes like agile processes

1.1 What is the meaning of agile?

Agile approach is an alternative to conventional project management, typically used

1.2 Where did agile come from?

Agile Software Engineering Page 6

1.3 Why agile is required?

Agile development processes gives opportunities to assess direction of a project

Agile Software Engineering Page 7

2.1 Basic Aspects of Agile Manifesto:

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

 Individuals and interactions over processes and tools.

2.1.1 Individuals and Interactions

Agile Software Engineering Page 8

In conventional methodologies treat people as resources that are as replaceable

2.1.2 Working Software

Agile Software Engineering Page 9

produce document predicting future as they have the possibility of becoming

2.1.3 Customer Collaboration

2.1.4 Responding to Change

Agile Software Engineering Page 10

requirements should be changeable. The flexibility to accommodate changes into the

2.2 Agile Principles

1. Customer satisfaction by early and continuous delivery of valuable software

Agile Software Engineering Page 11

3.1 Iterative, Incremental and Ready to Evolve

3.2 Face-to-Face Communication

In agile software development, an information radiator (physical display) is normally

3.3 Feedback Loop

Agile Software Engineering Page 12

Agile Software Engineering Page 13

4. Comparison of Agile and Conventional

4.1 Shortcomings of Conventional Waterfall Approach

The essence of waterfall software development is that complex software systems

Some of the drawbacks of this model are:

Agile Software Engineering Page 14

Figure 4.1: Agile vs. Conventional (http://www.tutorialspoint.com)

The waterfall model is recommended for the following cases:

 requirements are well understood, clear and final;

4.2 Iterative and Agile methods

Incremental and Iterative Development

Agile Software Engineering Page 15

Some of the advantages of this model are:

4.3 Agile vs. Conventional

Adaptive vs. predictive

Development methods exist on a continuum from adaptive to predictive. Agile

Agile Software Engineering Page 16

Iterative vs. waterfall

Code vs. documentation

In a letter to IEEE Computer, Steven Rakitin expressed cynicism about agile