Chapter 3

Agile Software Development

 Topics Covered
• Agile Methods
• Plan-driven and Agile Development
• Extreme Programming
• Agile Project Management
• Scaling Agile Methods
Rapid Software Development
 Rapid Development & Delivery:
– Software must evolve quickly to meet changing business needs.
 How Rapid Software Development Works:
– Specification, design, and implementation happen together (inter-
leaved).
– System is developed in versions, with feedback from stakeholders after
each version.
– User interfaces are often built using IDEs(Integrated Development
Environments) and graphical tools.
Agile Methods
• Agile Methods Focus On:
– Focus on code rather than detailed design.
– Use an iterative approach to software development.
– Deliver working software quickly and evolve it to meet
changing requirements.
• Goals of Agile Methods:
– Reduce overheads (e.g., limit documentation).
– Respond quickly to changing requirements with minimal
rework.
Agile Manifesto
• Core Values:
– Individuals and Interactions over processes and tools
– Working Software over comprehensive documentation
– Customer Collaboration over contract negotiation
– Responding to Change over following a plan

• Note: While there is value in the items on the right, the

items on the left are valued more.
Principles of Agile Methods
Principles Description
Customer Involvement Customers should be involved throughout, prioritizing new
requirements and evaluating iterations.

Incremental Delivery Software is developed in increments, with each one based on

customer-defined requirements.

People, Not Process Focus on the skills of the development team, allowing them to work in
their own ways.

Embrace Change Design systems to expect and accommodate changes in requirements.

Maintain Simplicity Focus on simplicity in both software being developed and the
development process.
Agile Method Applicability
• When to Use Agile Methods:
– Product development for small/medium products.
– Custom system development with active customer involvement.

– Not suitable for large systems due to scaling challenges.

Problems with Agile Methods
• Challenges:
– Keeping customers engaged throughout the process.
– Team members may struggle with the intense involvement
required.
– Prioritizing changes when there are multiple stakeholders.
– Maintaining simplicity can be extra work.
– Contracts may be problematic in iterative development.
Agile Methods & Software Maintenance
 Key Issues in Maintenance:
• Most organizations spend more on maintaining software
than developing new ones.
– Can systems developed with Agile be maintainable without
formal documentation?
– Can Agile methods handle evolving systems based on
customer feedback?
• Problems arise if the original development team is not
available.
Plan-Driven and Agile Development
• Plan-Driven Development:
– Separate development stages with planned outputs at each stage.
– Can use incremental development, not necessarily waterfall.
• Agile Development:
– Specification, design, implementation, and testing are interleaved.
– Outputs are decided through negotiation during development

• Agile Development: Focuses on iteration and incremental progress, where requirements

and design evolve collaboratively throughout the development cycle. Agile emphasizes
flexibility and continuous feedback.
• Plan-Drive Software Development: Often follows a predictable and structured approach,
where requirements are defined early. While it can support incremental delivery, it is
generally less flexible than Agile.
Plan-driven and agile specification
Technical, Human, Organizational Issues
• Choosing Between Plan-Driven and Agile Methods:
– Need for detailed specification: Plan-driven approach.
– Incremental delivery: Agile methods.
– System size: Agile works best for small, co-located teams.
Plan-driven may be needed for large systems.
More Technical, Human, Organizational Issues

• Factors to Consider:
– Type of system: Plan-driven for complex systems.
– System lifetime: Long-lifetime systems may need more
documentation.
– Available technologies: Agile methods rely on good tools.
– Team organization: If the team is distributed, design documents
may be necessary.
Additional Technical, Human, Organizational Issues

• Factors to Consider:
– Cultural or organizational issues: Traditional engineering
cultures may lean toward plan-driven methods.
– Skill level of designers/programmers: Agile methods often
require higher skill levels.
– External regulations: Systems needing approval from regulators
require detailed documentation.
Extreme Programming (XP)
• Overview:
– A well-known and widely used Agile method.
• XP Features:
– New versions may be built several times per day.
– Increments delivered to customers every 2 weeks.
– Tests must be passed before the build is accepted.
XP and Agile Principles
• XP Supports Agile Principles:
– Incremental Development: Small, frequent releases.
– Customer Involvement: Full-time customer engagement.
– People, Not Process: Pair programming, collective ownership,
and avoiding long hours.
– Change Support: Regular system releases.
– Simplicity: Constant code refactoring.
The extreme programming release cycle
Extreme Programming (XP) Practices
(A) Development Practices
1. Incremental Planning – Requirements are written on story cards, and
developers break them into tasks based on priority and available time.
2. Small Releases – The first version includes the most valuable features,
with frequent updates adding functionality.
3. Simple Design – Only design what is needed for the current
requirements, avoiding unnecessary complexity.
4. Test-First Development – Write automated tests before coding the
actual functionality.
5. Refactoring – Continuously improve code for simplicity and
maintainability.
(B) Team Practices

6. Pair Programming – Two developers work together, reviewing

each other's code in real time.
7. Collective Ownership – Everyone is responsible for all code,
allowing any developer to make changes.
8. Continuous Integration – New code is merged into the system
frequently, ensuring all tests pass.
9. Sustainable Pace – Avoid excessive overtime to maintain long-
term productivity and code quality.
10. On-Site Customer – A customer representative is part of the
team, providing real-time feedback.
Requirements in Extreme Programming (XP)
1. Customer Involvement – A customer or user is part of
the XP team and decides on requirements.
2. User Stories – Requirements are written as simple user
stories or scenarios.
3. Task Breakdown – Developers break stories into smaller
tasks, which help estimate time and cost.
4. Prioritization – The customer selects which stories to
include in the next release based on priorities and schedule
estimates.
A ‘prescribing medication’ story
Examples of task cards for prescribing medication
XP and Change
• Traditional software engineering emphasizes designing
for future changes to reduce long-term costs.

• XP argues that predicting changes is unreliable, so it

focuses on continuous refactoring to make future changes
easier.
Refactoring in XP
• Developers continuously improve code, even if there’s
no immediate need.

• This keeps the code clean, understandable, and easier

to modify, reducing reliance on documentation.

• However, major architectural refactoring can be costly.

Examples of Refactoring:
1. Removing Duplicate Code – Restructuring class
hierarchies to avoid redundancy.
2. Improving Readability – Renaming variables and
methods for clarity.
3. Encapsulating Repeated Code – Replacing repeated
inline code with reusable functions.
Key Points
•  Agile Methods focus on incremental development,
frequent releases, minimal process overhead, and high-
quality code. Customers are actively involved.
•  Choosing Agile vs. Plan-Driven depends on the type of
software, team capabilities, and company culture.
•  Extreme Programming (XP) is a popular agile method
that emphasizes frequent releases, continuous code
improvement (refactoring), and customer collaboration.
 Chapter 3

Agile Software Development

LECTURE 2
Testing in Extreme Programming (XP)
 Continuous Testing – The program is tested after every
change.
 Key Features of XP Testing:
• Test-First Development – Write tests before writing code.
• Incremental Testing – Tests are developed alongside user stories.
• User Involvement – Users help define and validate tests.
• Automated Testing – Automated test suites run all component tests with
each new release.
Test-First Development in XP
 Clarifies Requirements – Writing tests first ensures clear
understanding before coding.
 Automated Tests – Tests are written as executable programs,
not just data.
 Uses Testing Frameworks – Common frameworks include
JUnit for Java.
 Continuous Testing – Running all tests after each code change
ensures new updates don’t break existing functionality.
Customer Involvement in Testing (XP)
 Defining Acceptance Tests – Customers help create tests to
ensure implemented features meet their needs.
 Continuous Validation – As development progresses,
customers write and review tests to verify functionality.
 Challenges:
• Limited Availability – Customers often lack time to fully engage in
testing.
• Reluctance to Participate – Some feel their job is done after
providing requirements.
Test case description for dose checking
Test Automation in XP
 Tests are written before implementation – Ensures clear
requirements and validation.
 Standalone test components – Simulate input, check output,
and run independently.
 Automated test frameworks – Tools like JUnit (Java), pytest
(Python), and Selenium (web testing) simplify test execution.
 Continuous Testing – Every time new functionality is added,
all tests run to catch errors immediately.
Challenges in XP Testing
1.Programmers Prefer Coding Over Testing
a.Developers may take shortcuts by writing incomplete tests.
b.Example: A login function test may check valid credentials but ignore edge cases like
SQL injection or empty inputs.
2.Difficulties in Writing Incremental Tests
a.Complex UI testing is challenging since display logic and screen transitions are hard
to automate.
b.Example: Testing a drag-and-drop interface or dynamic form validation requires
specialized UI testing tools (e.g., Selenium).
3.Incomplete Test Coverage
a.Even with many tests, some critical edge cases may be missed.
b.Example: A test suite for an e-commerce app might cover payment processing but
miss race conditions when two users purchase the last item simultaneously.
Solution Approaches:
✅ Encourage thorough testing by integrating testing into
developer workflows.

✅ Use UI testing frameworks (e.g., Selenium, Cypress) for

complex front-end testing.

✅ Measure test coverage with tools like JaCoCo (Java) or

coverage.py (Python) to find gaps.
Pair programming
– In XP, programmers work in pairs, sitting together to develop
code.
– This helps develop common ownership of code and spreads
knowledge across the team.
– It serves as an informal review process as each line of code is
looked at by more than 1 person.
– It encourages refactoring as the whole team can benefit from this.
– Measurements suggest that development productivity with pair
programming is similar to that of two people working
independently.
Pair programming
In pair programming, programmers sit together at the same
workstation to develop the software.
Pairs are created dynamically so that all team members work
with each other during the development process.
The sharing of knowledge that happens during pair
programming is very important as it reduces the overall risks to
a project when team members leave.
Pair programming is not necessarily inefficient and there is
evidence that a pair working together is more efficient than 2
programmers working separately.
Advantages of pair programming
 It supports the idea of collective ownership and responsibility for
the system.
- Individuals are not held responsible for problems with the code. Instead,
the team has collective responsibility for resolving these problems.
  It acts as an informal review process because each line of code
is looked at by at least two people.
  It helps support refactoring, which is a process of software
improvement.
- Where pair programming and collective ownership are used, others benefit
immediately from the refactoring so they are likely to support the process.
Agile project management
  The principal responsibility of software project managers is to
manage the project so that the software is delivered on time and
within the planned budget for the project.
  The standard approach to project management is plandriven.
Managers draw up a plan for the project showing what should be
delivered, when it should be delivered and who will work on the
development of the project deliverables.
  Agile project management requires a different approach, which
is adapted to incremental development and the particular
strengths of agile methods.
Scrum
 The Scrum approach is a general agile method but its focus is on
managing iterative development rather than specific agile
practices.
 There are three phases in Scrum.
 The initial phase is an outline planning phase where you establish the
general objectives for the project and design the software architecture.
 This is followed by a series of sprint cycles, where each cycle develops
an increment of the system.
 The project closure phase wraps up the project, completes required
documentation such as system help frames and user manuals and
assesses the lessons learned from the project.
The Scrum process
The Sprint cycle
 Sprints are fixed length, normally 2–4 weeks. They
correspond to the development of a release of the system
in XP.
 The starting point for planning is the product backlog,
which is the list of work to be done on the project.
 The selection phase involves all of the project team who
work with the customer to select the features and
functionality to be developed during the sprint.
The Sprint cycle
 Once these are agreed, the team organize themselves to
develop the software. During this stage the team is isolated
from the customer and the organization, with all
communications channelled through the so-called ‘Scrum
master’.
 The role of the Scrum master is to protect the development
team from external distractions.
 At the end of the sprint, the work done is reviewed and
presented to stakeholders. The next sprint cycle then begins.
Teamwork in Scrum
 The ‘Scrum master’ is a facilitator who arranges daily meetings,
tracks the backlog of work to be done, records decisions,
measures progress against the backlog and communicates with
customers and management outside of the team.
 The whole team attends short daily meetings where all team
members share information, describe their progress since the last
meeting, problems that have arisen and what is planned for the
following day.
• This means that everyone on the team knows what is going on and, if
problems arise, can re-plan short-term work to cope with them.
Scrum benefits
  The product is broken down into a set of manageable and
understandable chunks.
  Unstable requirements do not hold up progress.
  The whole team have visibility of everything and consequently
team communication is improved.
  Customers see on-time delivery of increments and gain
feedback on how the product works.
  Trust between customers and developers is established and a
positive culture is created in which everyone expects the project
to succeed.
Scaling agile methods
 Agile methods have proved to be successful for small and
medium sized projects that can be developed by a small co-
located team.
 It is sometimes argued that the success of these methods comes
because of improved communications which is possible when
everyone is working together.
 Scaling up agile methods involves changing these to cope with
larger, longer projects where there are multiple development
teams, perhaps working in different locations.
Large systems development
  Large systems are usually collections of separate, communicating
systems, where separate teams develop each system. Frequently,
these teams are working in different places, sometimes in different time
zones.
  Large systems are ‘brownfield systems’, that is they include and
interact with a number of existing systems. Many of the system
requirements are concerned with this interaction and so don’t really
lend themselves to flexibility and incremental development.
  Where several systems are integrated to create a system, a
significant fraction of the development is concerned with system
configuration rather than original code development.
Large system development
 Large systems and their development processes are
often constrained by external rules and regulations
limiting the way that they can be developed.
 Large systems have a long procurement and
development time. It is difficult to maintain coherent teams
who know about the system over that period as,
inevitably, people move on to other jobs and projects.
 Large systems usually have a diverse set of
stakeholders. It is practically impossible to involve all of
these different stakeholders in the development process.
Scaling out and scaling up
 ‘Scaling up’ is concerned with using agile methods for developing
large software systems that cannot be developed by a small team.
 ‘Scaling out’ is concerned with how agile methods can be
introduced across a large organization with many years of
software development experience.
 When scaling agile methods it is essential to maintain agile
fundamentals
• Flexible planning, frequent system releases, continuous integration, test-
driven development and good team communications.
Scaling up to large systems
  For large systems development, it is not possible to focus only
on the code of the system. You need to do more up-front design
and system documentation
  Cross-team communication mechanisms have to be designed
and used. This should involve regular phone and video
conferences between team members and frequent, short
electronic meetings where teams update each other on progress.
  Continuous integration, where the whole system is built every
time any developer checks in a change, is practically impossible.
However, it is essential to maintain frequent system builds and
regular releases of the system.
Scaling out to large companies
  Project managers who do not have experience of agile methods may be
reluctant to accept the risk of a new approach.
  Large organizations often have quality procedures and standards that all
projects are expected to follow and, because of their bureaucratic nature,
these are likely to be incompatible with agile methods.
  Agile methods seem to work best when team members have a relatively
high skill level. However, within large organizations, there are likely to be a
wide range of skills and abilities.
  There may be cultural resistance to agile methods, especially in those
organizations that have a long history of using conventional systems
engineering processes.
Key points
 A particular strength of extreme programming is the development
of automated tests before a program feature is created. All tests
must successfully execute when an increment is integrated into a
system.
 The Scrum method is an agile method that provides a project
management framework. It is centred round a set of sprints, which
are fixed time periods when a system increment is developed.
 Scaling agile methods for large systems is difficult. Large
systems need up-front design and some documentation.