Agile Software Methodology
The Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and
helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.”
Kent Beck et al
2
What is “Agility”?
• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work performed
Yielding …
• Rapid, incremental delivery of software
3
Agility and the Cost of Change
4
An Agile Process
• Is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction
activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
5
Agility Principles
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to
and within a development team is face–to–face conversation.
6
Agility Principles – cntd.,
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is
essential.
11. The best architectures, requirements, and designs emerge from self–
organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
7
Human Factors
• the process molds to the needs of the people and team, not the other
way around
• key traits must exist among the people on an agile team and the
team itself:
– Competence.
– Common focus.
– Collaboration.
– Decision-making ability.
– Fuzzy problem-solving ability.
– Mutual trust and respect.
– Self-organization.
8
Extreme Programming
XP Values:
• Beck [Bec04a] defines a set of five values that establish a foundation
for all work performed as part of XP - communication, simplicity,
feedback, courage, and respect.
• Each of these values is used as a driver for specific XP activities,
actions, and tasks.
Communication:
• In order to achieve effective communication between software
engineers and other stakeholders (e.g., to establish required features
and functions for the software), XP emphasizes close, yet informal
(verbal) collaboration between customers and developers, the
establishment of effective metaphors for communicating important
concepts, continuous feedback, and the avoidance of voluminous
documentation as a communication medium.
9
Extreme Programming – cntd.,
Simplicity:
• To achieve simplicity, XP restricts developers to design only for
immediate needs, rather than consider future needs.
• The intent is to create a simple design that can be easily implemented in
code.
• If the design must be improved, it can be refactored at a later time.
Feedback:
• Feedback is derived from three sources:
• the implemented software itself,
• The customer
• other software team members.
10
Extreme Programming – cntd.,
Courage:
• A better word might be discipline.
• For example, there is often significant pressure to design for future
requirements.
• Most software teams succumb, arguing that “designing for tomorrow”
will save time and effort in the long run.
• An agile XP team must have the discipline (courage) to design for
today, recognizing that future requirements may change dramatically,
thereby demanding substantial rework of the design and implemented
code.
Respect:
• the agile team inculcates respect among it members, between other
stakeholders and team members, and indirectly, for the software itself
11
Extreme Programming – cntd.,
XP Process:
• 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.
12
Spike Solution and Prototype
A spike solution is a small, experimental piece of code written to explore a problem,
technology, or design approach. It’s not meant to be part of the final product but
helps the team learn quickly.
Example
• Suppose the team is unsure if a new payment gateway API works with their e-
commerce system. They write a spike solution to test connecting, sending dummy
transactions, and receiving responses before committing to full integration.
• A prototype is a preliminary version of the system (or part of it) created to
demonstrate functionality, gather feedback, or validate requirements with
customers.
Example
• Before building a full mobile banking app, the team builds a prototype showing:
• Login screen
• Account balance display
• Simple money transfer screen
This helps users give feedback: “The transfer button is hard to find” → allowing
corrections before coding the real system.
Extreme Programming – cntd.,
Planning:
• The planning activity (also called the planning game) 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.
• 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.
14
Extreme Programming – cntd.,
• Customers and developers work together to decide how to group stories
into the next release to be developed by the XP team.
• Once a basic commitment (agreement on stories to be included, delivery
date, and other project matters) 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
(3) the riskiest stories will be moved up in the schedule and
implemented first.
15
User story
• A user story is a short, simple description of a feature told from the
perspective of the end user. It is widely used in Agile methodologies
(XP, Scrum, etc.) to capture requirements in a way that focuses on user
value.
• Format: As a [type of user], I want [goal], so that [benefit].
• Purpose:
• Keeps focus on what the user needs, not just technical tasks.
• Serves as a conversation starter between developers, testers, and
customers.
• Forms the basis for acceptance criteria and testing.
• Example User Story (E-commerce system):
• As a customer, I want to add products to a shopping cart, so that I can
purchase multiple items at once.
• Acceptance Criteria:
• A product can be added to the cart.
• The cart should show updated total price.
• User can remove products from the cart.
Example: Mobile Banking App
User Story
As a bank customer, I want to transfer money to another
account, so that I can pay my bills easily.
Acceptance Criteria:
• User should be able to enter recipient’s account number and
amount.
• System should validate available balance before transfer.
• A confirmation message should be shown after a successful
transfer.
• A transaction receipt should be available for download or
email.
Extreme Programming – cntd.,
• Project velocity is the number of customer stories implemented during the
first release.
• Project velocity can then be used to
(1) help estimate delivery dates and schedule for subsequent
releases
(2) determine whether an over commitment has been made for all
stories across the entire development project
• If an over commitment occurs, the content of releases is modified or end
delivery dates are changed.
• 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. 18
Extreme Programming – cntd.,
Design:
• XP design rigorously follows the KIS (keep it simple) principle.
• A simple design is always preferred over a more complex representation.
• In addition, the design provides implementation guidance for a story as it is
written—nothing less, nothing more.
• The design of extra functionality is discouraged.
• XP encourages the use of CRC (CRC cards are simple index cards used in object-
oriented design to represent the responsibilities of classes and how they
collaborate with other classes) cards as an effective mechanism for thinking about
the software in an object-oriented context.
• 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
19
evaluated.
Example : CRC card for an Online Shopping
System
Class Responsibilities Collaborators
- Add/Remove items - Product, User,
ShoppingCart
Calculate total price PaymentProcessor
- Store product details -
Product ShoppingCart
Provide price info
- Process payments -
PaymentProcessor ShoppingCart, User
Validate transactions
Extreme Programming – cntd.,
• XP encourages refactoring is the process of changing a software system
in such a way that it does not alter the external behavior of the code yet
improves the internal structure.
• It is a disciplined way to clean up code that minimizes the chances of
introducing bugs.
• 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.
21
Refactoring
• The process of improving the internal
structure of the code without changing its
external behavior.
• XP encourages continuous refactoring to keep
the code clean, simple, and easy to maintain.
• Remove code duplication.
• Improve readability and maintainability.
• Optimize performance where needed.
• Make the code easier to extend in the future.
• public class Student {
• String name;
• int marks;
• public void printDetails() {
• [Link]("Name: " + name);
• [Link]("Marks: " + marks);
• [Link]("Result: " + getResult());
• }
• private String getResult() {
• return (marks >= 50) ? "Pass" : "Fail";
• }
• }
• Responsibilities are separated (printing vs.
result calculation).
• Code is cleaner and reusable
• (getResult() can be used elsewhere).
• Behavior remains the same (no change for the
end user).
Extreme Programming – cntd.,
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.
• 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 real time problem solving and real-time
quality assurance
25
Extreme Programming – cntd.,
• 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.
• This “continuous integration” strategy helps to avoid compatibility and
interfacing problems and provides a “smoke testing” environment hat
helps to uncover errors early.
26
Pair programming
• Two programmers working together on the same code, using a
single computer. One is the Driver (writes the code) and the other
is the Navigator (reviews the code, thinks about design, and spots
mistakes).They switch roles frequently.
• Improves code quality (continuous review).
• Promotes knowledge sharing between team members.
• Reduces bugs and misunderstandings.
• Encourages collaboration and learning.
• Example of Pair Programming:
• Imagine two developers building a login module for an app:
• Driver: Writes code for validating username and password.
• Navigator: Watches carefully, suggests improvements (e.g., “Add
input sanitization to prevent SQL injection”).
• After 20 minutes, they switch roles.
Extreme Programming – cntd.,
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” ,integration and validation testing of the system can occur on a daily basis.
• 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. 28
Extreme Programming – cntd.,
Industrial XP:
• IXP is an organic evolution of XP. It is imbued with XP’s minimalist,
customer-centric, test-driven spirit.
• IXP differs most from the original XP in its greater inclusion of
management, its expanded role for customers, and its upgraded technical
practices.
Six New Practices:
1. Readiness assessment:
• The assessment ascertains whether
an appropriate development environment exists to support IXP
the team will be populated by the proper set of stakeholders
the organization has a distinct quality program and supports
continuous improvement,
the organizational culture will support the new values of an agile
team
the broader project community will be populated appropriately. 29
Extreme Programming – cntd.,
2. Project community:
• A community may have a technologist and customers who are central to
the success of a project as well as many other stakeholders (e.g., legal
staff, quality auditors, manufacturing or sales types) who “are often at the
periphery of an IXP project yet they may play important roles on the
project”.
• In IXP, the community members and their roles should be explicitly
defined and mechanisms for communication and coordination between
community members should be established.
30
Extreme Programming – cntd.,
3. Project chartering:
• The IXP team assesses the project itself to determine whether an
appropriate business justification for the project exists and whether the
project will further the overall goals and objectives of the organization.
• Chartering also examines the context of the project to determine how it
complements, extends, or replaces existing systems or processes.
4. Test-driven management:
• It establishes a series of measurable “destinations” [Ker05] and then
defines mechanisms for determining whether or not these destinations
have been reached.
31
Extreme Programming – cntd.,
5. Retrospectives:
• An IXP team conducts a specialized technical review after a software
increment is delivered Called a retrospective, the review examines
“issues, events, and lessons-learned” across a software increment and/or
the entire software release.
• The intent is to improve the IXP process.
6. Continuous learning:
• Because learning is a vital part of continuous process improvement,
members of the XP team are encouraged to learn new methods and
techniques that can lead to a higher quality product.
32
Extreme Programming – cntd.,
Existing Practices:
• Story-driven development (SDD) insists that stories for acceptance tests
be written before a single line of code is generated.
• Domain-driven design (DDD) is an improvement on the “system
metaphor” concept used in XP. DDD suggests the evolutionary creation
of a domain model that “accurately represents how domain experts think
about their subject”.
• Pairing extends the XP pair programming concept to include managers
and other stakeholders. The intent is to improve knowledge sharing
among XP team members who may not be directly involved in technical
development.
33
Extreme Programming – cntd.,
• Iterative usability discourages front-loaded interface design in favor of
usability design that evolves as software increments are delivered and
users’ interaction with the software is studied.
XP Debate:
Some Critics:
1. Requirements volatility
2. Conflicting customer needs
3. Requirements are expressed informally
4. Lack of formal design
34
Scrum
• 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 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.
35
Scrum Process Flow
36
Scrum – cntd.,
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. 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-box 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.
37
Scrum – cntd.,
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.
• 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.
38
Feature Driven Development (FDD)
• FDD adopts
emphasizes collaboration among people on an FDD team;
manages problem and project complexity using feature-based
decomposition followed by the integration of software
increments
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.
• In the context of FDD, a feature “is a client-valued function that can
be implemented in two weeks or less” 39
Feature Driven Development (FDD) – cntd.,
Benefits of features:
• 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.
• 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.
40
Feature Driven Development (FDD) – cntd.,
Template for defining a feature:
<action> the <result> <by for of to> a(n) <object>
where an <object> is a person, place, or thing (including roles,
moments in time or intervals of time, or catalog-entry-like
descriptions)
Example:
• Add the product to shopping cart
• Display the technical-specifications of the product
• Store the shipping-information for the customer
• A feature set groups related features into business-related categories and is
defined as:
<action><-ing> a(n) <object>
• Example: Making a product sale is a feature set that would encompass the
features noted earlier and others.
41
Feature Driven Development Process
42
Lean Software Development (LSD)
• It has adapted the principles of lean manufacturing to the world of software
engineering.
• The lean principles that inspire the LSD process can be summarized as
eliminate waste, build quality in, create knowledge, defer commitment,
deliver fast, respect people, and optimize the whole.
• Each of these principles can be adapted to the software process. For
example, eliminate waste within the context of an agile software project
can be interpreted to mean:
adding no extraneous features or functions
assessing the cost and schedule impact of any newly requested
requirement
removing any superfluous process steps
43
Agile Design
• Symptoms of poor design:
Agile Design Principles
SRP
• SRP -
OCP
OCP
LSP
DIP
Violates DIP
DIP
ISP
Feature Driven Development
• FDD is an Agile, model-driven methodology that focuses on building
and delivering software features in short iterations.
• A feature is a small, client-valued function (e.g., “Calculate monthly
salary”).
• Work is organized around features instead of tasks.
• Process steps in FDD:
– Develop an overall model of the system.
– Build a feature list.
– Plan by feature.
– Design by feature.
– Build by feature.
• It’s especially useful for large projects with many teams, where
organizing by features ensures visible progress.
Example - 1
• Suppose we are developing a Library Management
System.
• Feature list might include:
– “Add a new book to catalog”
– “Issue book to member”
– “Calculate overdue fine”
• Each feature is designed, coded, and tested separately.
The team completes “Issue book to member” in a 2-week
iteration and delivers it for client feedback before moving
to the next feature.
Example - 2
• Building an Online Shopping Application
• Feature list may include:
– “Register a new customer”
– “Add product to cart”
– “Apply discount coupon”
– “Track order shipment”
In FDD, the team would design, code, and test one feature at a time.
• For the first iteration, they deliver “Add product to cart”.
• After review and feedback, they move to “Apply discount
coupon”.
• This way, customers see visible progress feature by feature.
Lean Software Development
• LSD is inspired by Lean Manufacturing (Toyota Production System).
• Goal: deliver value quickly, reduce waste, and optimize efficiency.
• Seven key principles:
– Eliminate waste
– Build quality in
– Create knowledge
– Defer commitment
– Deliver fast
– Respect people
– Optimize the whole
• It focuses on removing anything that does not add value to the
customer (like unnecessary documentation, delays, or rework).
Example
• Library Management System:
• Instead of writing a 300-page requirement document,
the team talks directly to users, gathers only necessary
requirements, and builds a minimal working system
quickly.
• Waste (like unnecessary features such as “3D animated
dashboard”) is avoided.
• They deliver a working “Search books by title/author”
feature in the first week, so users start using it
immediately, while other features are being developed.
Example - 2
• Developing a Food Delivery App (like Swiggy/Zomato)
• Instead of building everything (chat support, ratings, referral program,
etc.) upfront, the team focuses only on what brings immediate value:
– “Search nearby restaurants”
– “Place an order”
– “Track delivery”
• Non-essential features (like dark mode or loyalty program) are
postponed to avoid waste.
• The first release delivers a minimal working app with just ordering +
tracking.
• Customers start using it right away, giving feedback while other features
are added later.
• This avoids wasted time and ensures faster delivery with continuous
improvement.
• FDD (Shopping app): Break down into features
→ build step by step.
• LSD (Food delivery app): Focus on value, cut
waste, and deliver the minimum valuable
system first.