SEPM [BCS501]

MODULE 3

Agile Methodology
What is agility?

Agility means characteristics of being dynamic, content specific, aggressively change embracing
and growth oriented.

Agile Software engineering

Agile software engineering combines a philosophy and a set of development guidelines. The
philosophy encourages customer satisfaction and early incremental delivery of software, small
highly motivated project teams, informal methods, minimal software engineering work products
and overall development simplicity. The development guidelines stress delivery over analysis
and design and active continuous communication between developers and customers. The team
of software engineers and other project stakeholders work together as an agile team (a team that
is self organizing and in control of its own destiny. An agile team fosters communication and
collaboration among all who serve on it.

Agile Process

The Processes which are adaptable of changes in requirements, which have incrementality and
work on unpredictability. These processes are based on threeassumptions which all do refer to
the unpredictability in different stages of software process development such unpredictability
at time requirements, at analysis and design or at time [Link] these processes are
adaptable at allstages on SDLC.

Agile Process models

1. Extreme Programming(XP)
2. Adaptive Software development(ASD)
3. Dynamic software Development Method(DSDM)
4. Scrum
5. Crystal
6. Feature Driven development (FDD)
7. Agile Modeling(AM)
 SEPM [BCS501]

1. Extreme Programming(XP)

Extreme Programming uses an object-oriented approach as its preferred development

paradigm and encompasses a set of rules and practices that occur within the context of
four framework activities: planning, design, coding, and testing. Key XP activities are
summarized in the paragraphs that follow

Planning. The planning activity begins with listening—a requirements gathering

activity that enables the technical members of the XP team to understand the business
context for the software and to get a broad feel for required output and major features
and functionality.
Listening leads to the creation of a set of “stories” or user stories that describe required
output, features, and functionality for software to be built. Each story is written by the
customer and is placed on an index card. The customer assigns a value (i.e., a priority) to
the story based on the overall business value of the feature or function. Members of the
XP team then assess each story and assign a cost—measured in development weeks—to
it. If the story is estimated to require more than three development weeks, the customer is
asked to split the story into smaller stories and the assignment of value and cost occurs
again. It is important to note that new stories can be written at any time. Customers and
developers work together to decide how to group stories into the next release (the next
software increment) to be developed by the XP team. Once a basic commitment is made
for a release, the XP team orders the stories that will be developed in one of three ways:
(1) all stories will be implemented immediately (within a few weeks), (2) the stories with
highest value will be moved up in the schedule and implemented first, or (3) the riskiest
stories will be moved up in the schedule and implemented first.
After the first project release (also called a software increment) has been delivered, the
XP team computes project velocity. Stated simply, project velocity is the number of
 SEPM [BCS501]

customer stories
implemented during the first release. Project velocity can then be used to (1) help
estimate delivery dates and schedule for subsequent releases and (2) determine whether
an overcommitment has been made for all stories across the entire development project.
As development work proceeds, the customer can add stories, change the value of an
existing story, split stories, or eliminate them. The XP team then reconsiders all
remaining releases and modifies its plans accordingly.

Design. XP design rigorously follows the KIS (keep it simple) principle. A simple
design is always preferred over a more complex representation. XP encourages the use
of CRC cards as an effective mechanism for thinking about the software in an object-
oriented context. CRC (class- responsibility collaborator) cards identify and organize the
object-oriented classes that are relevant to the current software increment. The CRC
cards are the only design work product produced as part of the XP process.
If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of the
design. Called a spike solution, the design prototype is implemented and evaluated. The
intent is to lower risk when true implementation starts and to validate the original
estimates for the story containing the design problem
A central notion in XP is that design occurs both before and after coding commences.
Refactoring means that design occurs continuously as the system is constructed. In fact,
the construction activity itself will provide the XP team with guidance on how to improve
the design.

Coding. After stories are developed and preliminary design work is done, the team does
not move to code, but rather develops a series of unit tests that will exercise each of the
stories that is to be included in the current release (software increment).8 Once the unit
test9 has been created, the developer is better able to focus on what must be implemented
to pass the test.
Nothing extraneous is added (KIS). Once the code is complete, it can be unit-tested
immediately, thereby providing instantaneous feedback to the developers. A key concept
during the coding activity is pair programming. XP recommends that two people work
together at one computer workstation to create code for a story. This provides a
mechanism for realtime problem solving and real-time quality assurance It also keeps the
developers focused on the problem at hand. In practice, each person takes on a slightly
different role. For example, one person might think about the coding details of a
particular portion of the design while the other ensures that coding standards are being
followed or that the code for the story will satisfy the unit test that has been developed to
validate the code against the story.
As pair programmers complete their work, the code they develop is integrated with the
work of others. In some cases this is performed on a daily basis by an integration team.
In other cases, the pair programmers have integration responsibility. This “continuous
integration” strategy
helps to avoid compatibility and interfacing problems and provides a “smoke
 SEPM [BCS501]

testing” environment that helps to uncover errors early.

Testing The unit tests that are created should be implemented using a framework that
enables them to be automated This encourages a regression testing strategy whenever
code is modified As the individual unit tests are organized into a “universal testing suite”
[Wel99], integration and validation testing of the system can occur on a daily basis. This
provides the XP team with a continual indication of progress and also can raise warning
flags early if things go awry. Wells
[Wel99] states: “Fixing small problems every few hours takes less time than fixing huge
problems just before the deadline.” XP acceptance tests, also called customer tests, are
specified by the customer and focus on overall system features and functionality that are
visible and reviewable by the customer. Acceptance tests are derived from user stories
that have been implemented as part of a software release.

2. Adaptive Software development(ASD):

Adaptive Software Development (ASD) has
been proposed by Jim Highsmith, as a technique for building complex software and
systems. The philosophical underpinnings of ASD focus on human collaboration and
team self-organization. He defines an ASD “life cycle” that incorporates three phases,
speculation, collaboration, and learning.

During speculation, the project is initiated and adaptive cycle planning is conducted.
Adaptive cycle planning uses project initiation information—the customer’s mission
statement, project constraints , and basic requirements—to define the set of release cycles
that will be required for the project. No matter how complete and farsighted the cycle
plan, it will invariably change.
Based on information obtained at the completion of the first cycle, the plan is
reviewed and adjusted so that planned work better fits the reality in which an ASD
 SEPM [BCS501]

team is working.
Motivated people use collaboration in a way that multiplies their talent and creative
output beyond their absolute numbers. This approach is a recurring theme in all agile
methods. But collaboration is not easy. It encompasses communication and teamwork,
but it also emphasizes individualism, because individual creativity plays an important
role in collaborative thinking. It is, above all, a matter of trust. People working together
must trust one another to (1) criticize without animosity, (2) assist without resentment, (3)
work as hard as or harder than they do, (4) have the skill set to contribute to the work at
hand, and (5) communicate problems or concerns in a way that leads to effective action.

As members of an ASD team begin to develop the components that are part of an
adaptive cycle, the emphasis is on “learning” as much as it is on progress toward a
completed cycle. software developers often overestimate their own understanding (of
the technology, the process, and the project) and that learning will help them to
improve their level of real
understanding. ASD teams learn in three ways: focus groups , technical reviews, , and
project postmortems.
The ASD philosophy has merit regardless of the process model that is used. ASD’s
overall emphasis on the dynamics of self-organizing teams, interpersonal collaboration,
and individual and team learning yield software project teams that have a much higher
likelihood of success.

3. Dynamic software Development Method (DSDM) :

The Dynamic Systems Development Method is an agile software development approach
that “provides a framework for building and maintaining systems which meet tight time
constraints through the use of incremental prototyping in a controlled project
environment”. The DSDM philosophy is borrowed from a modified version of the Pareto
principle—80 percent of an application can be delivered in 20 percent of the time it
would take to deliver the complete application. DSDM is an iterative software process in
which each iteration follows the 80 percent rule. That is, only enough work is required
for each increment to facilitate movement to the next increment. The remaining detail
can be completed later when more business requirements are known or changes have
been requested and accommodated. The DSDM Consortium is a worldwide group of
member
companies that collectively take on the role of “keeper” of the method. The consortium
has defined an agile process model, called the DSDM life cycle that defines three
different iterative cycles, preceded by two additional life cycle activities:

Feasibility study—establishes the basic business requirements and constraints

associated with the application to be built and then assesses whether the application is a
viable candidate for the DSDM process.
Business study—establishes the functional and information requirements that will
allow the application to provide business value; also, defines the basic application
architecture and identifies the maintainability requirements for the application.
 SEPM [BCS501]

Functional model iteration—produces a set of incremental prototypes that

demonstrate functionality for the customer. The intent during this iterative cycle is
to gather additional requirements by eliciting feedback from users as they exercise
the prototype.

Design and build iteration—revisits prototypes built during functional model iteration to
ensure that each has been engineered in a manner that will enable it to provide
operational business value for end users. In some cases, functional model iteration and
design and build iteration occur concurrently.

Implementation—places the latest software increment into the operational environment.

It should be noted that (1) the increment may not be 100 percent complete or (2) changes
may be requested as the increment is put into place. In either case, DSDM development
work continues by returning to the functional model iteration activity.

DSDM can be combined with XP to provide a combination approach that defines a solid
process model with the nuts and bolts practices (XP) that are required to build software
increments. In addition, the ASD concepts of collaboration and self-organizing teams can
be adapted to a combined process model.

4. Scrum :
 SEPM [BCS501]

Scrum (the name is derived from an activity that occurs during a rugby match) is an agile
software development method that was conceived by Jeff Sutherland and his development
team in the early 1990s. In recent years, further development on the Scrum methods has been
performed by Schwaber and Beedle.

Scrum principles are consistent with the agile manifesto and are used to guide development
activities within a process that incorporates the following framework activities: requirements,
analysis, design, evolution, and delivery. Within each framework activity, work tasks occur
within a process pattern called a sprint. The work conducted within a sprint (the number of sprints
required for each framework activity will vary depending on product complexity and size) is
adapted to the problem at hand and is defined and often modified in real time by the Scrum team.

Scrum emphasizes the use of a set of software process patterns that have proven effective for
projects with tight timelines, changing requirements, and business criticality. Each of these
process patterns defines a set of development actions:

Backlog—a prioritized list of project requirements or features that provide business value
for the customer. Items can be added to the backlog at any time (this is how changes are
introduced). The product manager assesses the backlog and updates priorities as required.

Sprints—consist of work units that are required to achieve a requirement defined in the
backlog that must be fit into a predefined time-box14 (typically 30 days).

Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint
allows team members to work in a short-term, but stable environment. Scrum meetings—are
short (typically 15 minutes) meetings held daily by the Scrum team. Three key questions are
asked and answered by all team members.

• What did you do since the last team meeting?

• What obstacles are you encountering?

• What do you plan to accomplish by the next team meeting?

A team leader, called a Scrum master, leads the meeting and assesses the responses from each
person. The Scrum meeting helps the team to uncover potential problems as early as possible.
Also, these daily meetings lead to “knowledge socialization” [Bee99] and thereby promote a
self-organizing team structure.

Demos—deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer. It is important to note that the
demo may not contain all planned functionality, but rather those functions that can be delivered
within the time-box that was established.
 SEPM [BCS501]

The Scrum process patterns enable a software team to work successfully in a world
where the elimination of uncertainty is impossible.

5. Crystal :
Alistair Cockburn and Jim Highsmith created the Crystal family of agile
methods15 in
order to achieve a software development approach that puts a premium on
“maneuverability” during what Cockburn characterizes as “a resource limited,
cooperative game of invention and communication, with a primary goal of delivering
useful, working software and a secondary goal of setting up for the next game”.
To achieve maneuverability, Cockburn and Highsmith have defined a set of
methodologies, each with core elements that are common to all, and roles, process
patterns, work products, and practice that are unique to each. The Crystal family is
actually a set of example agile processes that have been proven effective for different
types of projects. The intent is to allow agile teams to select the member of the crystal
family that is most appropriate for their project and environment.

6. Feature Driven Development (FDD):

The FDD approach defines five “collaborating” framework activities (in FDD these are
called
“processes”). FDD provides greater emphasis on project management guidelines and
techniques than many other agile methods. As projects grow in size and complexity, ad
hoc project management is often inadequate. It is essential for developers, their
managers, and other stakeholders to understand project status—what accomplishments
have been made and problems have been encountered. If deadline pressure is significant,
it is critical to determine if software increments (features) are properly scheduled. To
accomplish this, FDD defines six
milestones during the design and implementation of a feature: “design walkthrough,
design, design inspection, code, code inspection, promote to build”.
Feature Driven Development (FDD) was originally conceived by Peter Coad and his
colleagues as a practical process model for object-oriented software engineering. Stephen
 SEPM [BCS501]

Palmer and John Felsing have extended and improved Coad’s work, describing an
adaptive, agile process that can be applied to moderately sized and larger software
projects.

Like other agile approaches, FDD adopts a philosophy that (1) emphasizes collaboration
among people on an FDD team; (2) manages problem and project complexity using
feature-based decomposition followed by the integration of software increments, and (3)
communication of technical detail using verbal, graphical, and text-based means. FDD
emphasizes software quality assurance activities by encouraging an incremental
development strategy, the use of design and code inspections, the application of software
quality assurance audits the collection of metrics, and the use of patterns (for analysis,
design, and construction).
FDD has following benefits:
• Because features are small blocks of deliverable functionality, users can describe
them more easily; understand how they relate to one another more readily; and better
review them for ambiguity, error, or omissions.
• Features can be organized into a hierarchical business-related grouping.
• Since a feature is the FDD deliverable software increment, the team develops
operational features every two weeks.
• Because features are small, their design and code representations are easier to
inspect effectively.
• Project planning, scheduling, and tracking are driven by the feature hierarchy, rather
than an arbitrarily adopted software engineering task set.
7. Agile Modeling: (AM) :
There are many situations in which software engineers must build large,
businesscritical systems. The scope and complexity of such systems must be
modeled so that
(1) all constituencies can better understand what needs to be accomplished,
(2) the problem can be partitioned effectively among the people who must solve it, and
(3) quality can be assessed as the system is being engineered and built.

Agile Modeling (AM) is a practice-based methodology for effective modeling and

documentation of software-based systems. Simply put, Agile Modeling (AM) is a
collection of values, principles, and practices for modeling software that can be applied
on a software development project in an effective and light-weight manner. Agile models
are more effective than traditional models because they are just barely good, they don’t
have to be perfect.

Agile modeling adopts all of the values that are consistent with the agile manifesto.
The agile modeling philosophy recognizes that an agile team must have the courage to
make decisions that may cause it to reject a design and refactor. The team must also
have the humility to recognize that technologists do not have all the answers and that
business experts and other stakeholders should be respected and embraced.
 SEPM [BCS501]

Principles that Guide Process – I & II

 Principle #1. Be agile. Whether the process model you choose is prescriptive or agile,
the basic tenets of agile development should govern your approach.
 Principle #2. Focus on quality at every step. The exit condition for every process
activity, action, and task should focus on the quality of the work product that has been
produced.
 Principle #3. Be ready to adapt. Process is not a religious experience and dogma has
no place in it. When necessary, adapt your approach to constraints imposed by the
problem, the people, and the project itself.
 Principle #4. Build an effective team. Software engineering process and practice are
important, but the bottom line is people. Build a self-organizing team that has mutual
trust and respect.
 Principle #5. Establish mechanisms for communication and coordination. Projects
fail because important information falls into the cracks and/or stakeholders fail to
coordinate their efforts to create a successful end product.
 Principle #6. Manage change. The approach may be either formal or informal, but
mechanisms must be established to manage the way changes are requested, assessed,
approved and implemented.
 Principle #7. Assess risk. Lots of things can go wrong as software is being developed.
It’s essential that you establish contingency plans.
 Principle #8. Create work products that provide value for others. Create only those
work products that provide value for other process activities, actions or tasks.

Principles that Guide Practice

 Principle #1. Divide and conquer. Stated in a more technical manner, analysis and
design should always emphasize separation of concerns (SoC).
 Principle #2. Understand the use of abstraction. At it core, an abstraction is a
simplification of some complex element of a system used to communication meaning
in a single phrase.
 Principle #3. Strive for consistency. A familiar context makes software easier to use.
 Principle #4. Focus on the transfer of information. Pay special attention to the
analysis, design, construction, and testing of interfaces.
 Principle #5. Build software that exhibits effective modularity. Separation of
concerns (Principle #1) establishes a philosophy for software. Modularity provides a
mechanism for realizing the philosophy.
 Principle #6. Look for patterns. Brad Appleton [App00] suggests that: “The goal of
patterns within the software community is to create a body of literature to help
software developers resolve recurring problems encountered throughout all of software
development.
 Principle #7. When possible, represent the problem and its solution from a number
 SEPM [BCS501]

of different perspectives.

 Principle #8. Remember that someone will maintain the software

Communication Principles

 Principle #1. Listen. Try to focus on the speaker’s words, rather than formulating
your response to those words.
 Principle # 2. Prepare before you communicate. Spend the time to understand the
problem before you meet with others.
 Principle # 3. Someone should facilitate the activity. Every communication meeting
should have a leader (a facilitator) to keep the conversation moving in a productive
direction; (2) to mediate any conflict that does occur, and (3) to ensure than other
principles are followed.
 Principle #4. Face-to-face communication is best. But it usually works better when
some other representation of the relevant information is present.
 Principle # 5. Take notes and document decisions. Someone participating in the
communication should serve as a “recorder” and write down all important points and
decisions.
 Principle # 6. Strive for collaboration. Collaboration and consensus occur when the
collective knowledge of members of the team is combined …
 Principle # 7. Stay focused, modularize your discussion. The more people involved
in any communication, the more likely that discussion will bounce from one topic to
the next.
 Principle # 8. If something is unclear, draw a picture.
 Principle # 9. (a) Once you agree to something, move on; (b) If you can’t agree to
something, move on; (c) If a feature or function is unclear and cannot be clarified at
the moment, move on.
 Principle # 10. Negotiation is not a contest or a game. It works best when both
parties win.

Planning Principles:

 Principle #1. Understand the scope of the project. It’s impossible to use a
roadmap if you don’t know where you’re going. Scope provides the software team
with a destination.
 Principle #2. Involve the customer in the planning activity. The customer defines
priorities and establishes project constraints.
 Principle #3. Recognize that planning is iterative. A project plan is never engraved
in stone. As work begins, it very likely that things will change.
 Principle #4. Estimate based on what you know. The intent of estimation is to
provide an indication of effort, cost, and task duration, based on the team’s current
understanding of the work to be done.
 Principle #5. Consider risk as you define the plan. If you have identified risks that
 SEPM [BCS501]

have high impact and high probability, contingency planning is necessary.

 Principle #6. Be realistic. People don’t work 100 percent of every day.
 Principle #7. Adjust granularity as you define the plan. Granularity refers to the level
of detail that is introduced as a project plan is developed.
 Principle #8. Define how you intend to ensure quality. The plan should identify how
the software team intends to ensure quality.
 Principle #9. Describe how you intend to accommodate change. Even the best
planning can be obviated by uncontrolled change.
 Principle #10. Track the plan frequently and make adjustments as required.
Software projects fall behind schedule one day at a time.

Requirements Modeling Principles

 Principle #1. The information domain of a problem must be represented and

understood.
 Principle #2. The functions that the software performs must be defined.
 Principle #3. The behavior of the software (as a consequence of external events)
must be represented.
 Principle #4. The models that depict information, function, and behavior must be
partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion.
 Principle #5. The analysis task should move from essential information toward
implementation detail.

Design Modeling Principles

 Principle #1. Design should be traceable to the requirements model.

 Principle #2. Always consider the architecture of the system to be built.
 Principle #3. Design of data is as important as design of processing functions.
 Principle #5. User interface design should be tuned to the needs of the end-user.
However, in every case, it should stress ease of use.
 Principle #6. Component-level design should be functionally independent.
 Principle #7. Components should be loosely coupled to one another and to the
external environment.
 Principle #8. Design representations (models) should be easily understandable.
 Principle #9. The design should be developed iteratively. With each iteration, the
designer should strive for greater simplicity.

Agile Modeling Principles

 Principle #1. The primary goal of the software team is to build software, not create
models.
 Principle #2. Travel light—don’t create more models than you need.
 Principle #3. Strive to produce the simplest model that will describe the problem or
the software.
 SEPM [BCS501]

 Principle #4. Build models in a way that makes them amenable to change.
 Principle #5. Be able to state an explicit purpose for each model that is created.
 Principle #6. Adapt the models you develop to the system at hand.
 Principle #7. Try to build useful models, but forget about building perfect models.
 Principle #8. Don’t become dogmatic about the syntax of the model. If it
communicates content successfully, representation is secondary.
 Principle #9. If your instincts tell you a model isn’t right even though it seems okay
on paper, you probably have reason to be concerned.
 Principle #10. Get feedback as soon as you can.

Construction Principles

 Coding principles and concepts are closely aligned programming style,

programming languages, and programming methods.
 Testing principles and concepts lead to the design of tests that systematically
uncover different classes of errors and to do so with a minimum amount of time
and effort.

Coding Principles

 Constrain your algorithms by following structured programming [Boh00]

practice.
 Consider the use of pair programming
 Select data structures that will meet the needs of the design.
 Understand the software architecture and create interfaces that are consistent
with it.
 Keep conditional logic as simple as possible.
 Create nested loops in a way that makes them easily testable.
 Select meaningful variable names and follow other local coding standards.
 Write code that is self-documenting.
 Create a visual layout (e.g., indentation and blank lines) that aids understanding.

Validation Principles

 Conduct a code walkthrough when appropriate.

 Perform unit tests and correct errors you’ve uncovered.
 Refactor the code

Testing Principles

 Principle #1. All tests should be traceable to customer requirements.

 Principle #2. Tests should be planned long before testing begins.
 Principle #3. The Pareto principle applies to software testing.
 SEPM [BCS501]

 Principle #4. Testing should begin “in the small” and progress toward
testing “in the large.”
 Principle #5. Exhaustive testing is not possible

Deployment Principles

 Principle #1. Customer expectations for the software must be managed. Too often,
the customer expects more than the team has promised to deliver, and
disappointment occurs immediately.
 Principle #2. A complete delivery package should be assembled and tested.
 Principle #3. A support regime must be established before the software is delivered.
An end-user expects responsiveness and accurate information when a question or
problem arises.
 Principle #4. Appropriate instructional materials must be provided to end-users.
 Principle #5. Buggy software should be fixed first, delivered later.