Agile Structures and Frameworks

CDV2001

Module 3

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Extreme Programming (XP): Method Overview

• Extreme Programming (XP) is one of the earliest and most influential Agile methodologies, focusing primarily on engineering
excellence and code quality.
• While Scrum emphasizes process and collaboration, XP emphasizes technical practices and clean, maintainable code — a core belief
shared by Uncle Bob.
• XP provides developers with concrete practices to manage changing requirements effectively through frequent delivery,
communication, simplicity, and feedback.
1. Introduction to XP: Core Idea

XP aims to make software development flexible and responsive to change by promoting technical discipline, collaboration, and
simplicity.

It follows the philosophy:

“Do the simplest thing that could possibly work.” — Uncle Bob

XP helps teams:
Respond quickly to changing requirements.
Deliver high-quality software frequently.
Reduce technical debt through continuous improvement.

Mike Cohn describes XP as complementing Scrum — Scrum manages workflow and delivery, while XP strengthens engineering and
development practices.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. XP Values

XP is built on five fundamental values that guide team behavior and decision-making:

Value Explanation Example

Encourages open and continuous dialogue between Daily stand-ups and pair programming
Communication
developers, testers, and customers. foster shared understanding.

Focus on solving today’s problem only — avoid over- Design only what’s needed for the current
Simplicity
engineering. sprint.

Regular feedback from tests, code reviews, and Continuous integration detects defects
Feedback
customers improves quality. immediately.

Courage to refactor code, accept criticism, or change Deleting poor code and redesigning to
Courage
course when needed. improve quality.

Team members trust and value each other’s Developers and customers collaborate
Respect
contributions. equally on decisions.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

3. XP Principles

XP translates its values into a set of guiding principles:

1. Rapid feedback: Testing and customer validation after every small change.
2. Assume simplicity: Start simple and evolve designs as needed.
3. Incremental change: Continuous small improvements instead of big redesigns.
4. Embrace change: Change is expected and welcomed, not feared.
5. Quality work: Technical excellence leads to sustainable productivity.

Mike Cohn reinforces that XP’s incremental feedback and adaptability are key drivers of Agile success — ensuring business and technical
alignment throughout.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. XP Core Practices

XP defines 12 key practices to implement its philosophy effectively. These practices are often called “Extreme” because they take good
development practices to their limit.
Category XP Practice Explanation

Customers and developers collaboratively decide which features to

Planning & Collaboration Planning Game
implement next based on value and effort.

Small Releases Deliver working software frequently (every few weeks).

Design & Coding Simple Design Design only for current needs; evolve later.

Pair Programming Two developers work together — one writes, the other reviews.

Continuously improve existing code structure without changing

Refactoring
behavior.

Testing & Feedback Test-Driven Development (TDD) Write tests before writing the code.

Continuous Integration Integrate and test code frequently to detect defects early.

Customer Tests Customers define acceptance tests for each story.

Team Practices Collective Code Ownership Any developer can improve any part of the code.

Coding Standards Maintain consistent, readable code across the team.

Sustainable Pace (40-hour week) Avoid burnout; maintain long-term productivity.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Uncle Bob’s View:
XP practices (especially TDD, refactoring, and pair programming) directly align with his principles of Clean Code and SOLID design.
He believes XP is the engineering foundation of Agile — without it, Agile becomes “process without craftsmanship.”

5. When and Why XP is a Suitable Choice

XP is ideal when:
• Requirements change frequently.
• Teams need to deliver high-quality software fast.
• Developers are co-located and communicate frequently.
• Technical excellence and maintainability are critical.

Example:
A fintech startup building an online payment platform adopts XP to deliver updates every week. Using TDD and continuous integration,
they ensure secure and bug-free code while quickly adapting to new banking regulations.

Mike Cohn’s insight: XP fits best for teams that already follow Scrum but need to improve how they build software — XP strengthens
Scrum’s “how” to complement its “what.”

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

6. How XP Differs from Other Agile Frameworks

Aspect XP Scrum
Technical excellence and Process management and team
Focus
engineering discipline collaboration
Short cycles (1–2 weeks) with
Iteration Fixed-length sprints (2–4 weeks)
continuous feedback
TDD, pair programming, Sprint planning, review,
Practices
refactoring, CI retrospective
Customer is part of the team (on- Customer represented by Product
Customer Involvement
site customer) Owner
Maintain code quality and Deliver business value through
Goal
adaptability collaboration

Uncle Bob: XP ensures developers write clean, maintainable code — the true heart of Agile craftsmanship.
Mike Cohn: XP complements Scrum by providing the technical backbone that makes Agile sustainable.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Example Summary

Case: A mobile banking application team applies XP practices.

• Planning Game: Business and tech collaborate on priorities.
• TDD + Continuous Integration: Code tested at every change.
• Pair Programming: Improves design and code readability.
• Small Releases: Weekly functional builds shared with users.
• Result: Faster feedback, fewer bugs, and a maintainable codebase — embodying the Agile spirit of responding
to change with confidence.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

XP: Lifecycle Phases and Planning

Extreme Programming (XP) focuses on delivering high-quality software through short iterations, continuous feedback, and embracing
change.
Where Scrum provides a management framework, XP provides technical and planning practices that make agility possible in real
software engineering.
The XP lifecycle revolves around planning, developing, integrating, and releasing software in frequent, customer-validated cycles.
1. XP Lifecycle Overview
XP follows a cyclic, iterative, and evolutionary process, where the software grows through frequent iterations and releases.
The lifecycle consists of three main stages:

Phase Description Key Activities

Understand customer requirements at a Create user stories, prioritize business
Exploration Phase
high level. goals, prototype critical features.
Developers and customers collaborate Conduct Planning Game, estimate
Planning Phase
to plan the next release. effort, set release goals.
Implement features, test continuously,
Development progresses through
Iterations to Release integrate, refactor, and release working
multiple short iterations (1–2 weeks).
software.
Each iteration delivers a small increment of working software, while each release delivers a customer-ready product.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Iterations and Releases
Iteration:
• Typically lasts 1–2 weeks.
• Includes planning, development, testing, and integration.
• Ends with a working product increment.
Release:
• A combination of several successful iterations.
• Represents a version ready for customer use or market delivery.

Key principles:
• Deliver working software early and often.
• Incorporate feedback into the next iteration.
• Maintain continuous integration and refactoring to ensure code quality.

Example:
An online shopping team releases new features every two weeks — like “Add to Cart,” “Wishlist,” and “Order Tracking.” Each release
builds upon earlier iterations, guided by customer feedback.

Role Responsibility
Customer (Business) Defines what to build by writing and prioritizing user stories.
Developers Estimate how much effort is required to implement each story.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

The Planning Game occurs in two main contexts:

1. Release Planning
• Determines which features (user stories) will go into the upcoming release.
• Customers select features based on business value; developers commit based on velocity (past performance).
• The goal is to balance value, risk, and effort.

2. Iteration Planning
• At the start of each iteration, developers choose a subset of user stories from the release plan.
• Tasks are defined, estimated, and assigned.
• Developers self-organize to deliver working software by the end of the iteration.

Uncle Bob: “The Planning Game reflects respect between business and developers — each side contributes its expertise to a shared
plan.”
Mike Cohn: “This collaborative planning embodies the Agile principle of customer collaboration over contract negotiation.”

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. User Stories and Estimation

User Stories
•User stories are short, simple descriptions of desired functionality.
•Format:
•“As a [user role], I want [goal] so that [benefit].”
Example:
“As a shopper, I want to receive SMS order confirmations so that I can track my delivery.”
Stories are prioritized by business value and sized by effort.

Estimation
• Estimation in XP uses relative effort, often measured in Story Points or Ideal Days.
• Developers provide estimates collaboratively using the Planning Game.
• Business uses these estimates and past velocity to predict future delivery.

Uncle Bob’s View:

Estimation should guide, not control. The true goal is to deliver value early, not to fix scope rigidly.
Mike Cohn’s View:
Planning Poker and velocity tracking make XP estimation reliable, transparent, and motivating for teams.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Handling Changing Requirements

XP is built around embracing change — not resisting it.

How XP Handles Change Explanation

Changes can be introduced at the end of each
Short Iterations
iteration.
Customers are part of the team, clarifying new needs
Customer On-site
immediately.
Code is continuously improved, making it easier to
Refactoring
accommodate change.
Ensure that new changes don’t break existing
Automated Tests (TDD)
functionality.

Uncle Bob: “Change is not a failure of planning; it’s a natural part of software evolution.”
Mike Cohn: “XP’s adaptability ensures business priorities are always reflected in what’s delivered.”

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

6. Example – XP Lifecycle in Action

Project: Online Banking System

[Link]: Customer defines user stories like “View balance,” “Transfer funds.”
[Link] Game: Team estimates effort; business selects highest-value stories for first release.
[Link]:
1. Iteration 1: Basic login + balance display
2. Iteration 2: Fund transfer + transaction history
3. Iteration 3: Bill payments
[Link] Feedback: Customer tests features and requests changes.
[Link] + CI: Developers improve code and keep the build stable after each change.
[Link]: Every few iterations, a stable version is deployed for user testing.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Summary Table
Concept Description T1 (Uncle Bob) T2 (Mike Cohn)
Short cycles producing Encourage incremental, clean Enable rapid feedback and
Iterations
working software design learning
Larger deliverables Demonstrate progress to
Releases Deliver value early and often
combining multiple iterations stakeholders
Collaborative planning of Balance between business Shared ownership and
Planning Game
value vs. effort and tech priorities realistic planning
Simple representation of Keep communication simple
User Stories Focus on customer value
requirements and direct
Adapt easily through Code flexibility supports Change welcomed as
Change Handling
refactoring and TDD evolution feedback

Key Takeaways
•XP’s lifecycle is iterative and evolutionary, focused on continuous value delivery.
•The Planning Game ensures collaboration between business and developers.
•User stories and short iterations make it easy to adapt to change.
•Uncle Bob emphasizes clean, simple, maintainable code as the foundation for agility.
•Mike Cohn emphasizes transparency, customer involvement, and learning through feedback.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

XP: Roles and Team Structure
Extreme Programming (XP) promotes a collaborative, cross-functional team environment where everyone contributes to delivering high-
quality software.
Unlike traditional models that separate analysts, coders, and testers, XP treats all members as part of one whole team — sharing
responsibility for product quality, communication, and delivery.

1. The Philosophy of the “Whole Team”

The “Whole Team” concept is central to XP. It means that everyone necessary to deliver a successful software product works together
as one unit, usually in a shared physical (or virtual) space.
There is no hierarchy — each role adds unique value but collaborates continuously.
Uncle Bob: XP’s “whole team” embodies professionalism — every team member owns the code, quality, and process.
Mike Cohn: Strong cross-functional collaboration is a hallmark of successful Agile teams — shared goals lead to shared success.

Key characteristics of the Whole Team:

•Shared workspace and visibility of work.
•Direct communication and quick decision-making.
•Mutual accountability for success or failure.
•Collective code ownership — anyone can improve any part of the code.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Key Roles in an XP Team
XP defines five core roles, each with distinct but interconnected responsibilities.

Role Responsibilities Uncle Bob’s View Mike Cohn’s View

Write, refactor, and test code using Programmers are craftsmen — they Emphasizes technical excellence and
1. Programmer XP practices like TDD and pair must maintain clean, simple, and shared ownership to maintain
programming. tested code. velocity.

Represents business needs; writes Essential for short feedback loops — Continuous customer involvement
2. Customer (On-Site Customer) and prioritizes user stories; clarifies ensures technical work always aligns ensures that the team builds the
requirements daily. with real user value. right product.

Designs automated and manual

Testing drives design clarity and Testing is a key feedback mechanism
3. Tester tests; validates that user stories
defect prevention, not detection. for learning and adaptation.
meet acceptance criteria.

Monitors progress and velocity; Encourages transparency —

Tracking helps predict future
4. Tracker ensures commitments match actual progress metrics should help, not
capacity and plan adaptively.
delivery. punish.

Guides the team in applying XP Helps programmers develop Acts as Scrum Master-like role —
5. Coach practices and Agile principles discipline, maintain clean code, and facilitates continuous improvement
effectively. uphold Agile values. and team cohesion.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

3. How XP Roles Interact

1. Programmer Customer
•Constant interaction — customers provide stories, programmers deliver working software for review.
•Daily collaboration ensures feedback and clarification are immediate.
Example: The customer asks for a “refund process”; programmers discuss edge cases directly, ensuring shared understanding.

2. Programmer Tester
•Programmers use Test-Driven Development (TDD) to build unit tests.
•Testers complement this by writing acceptance tests based on user stories.
•Together, they ensure both technical and functional quality.

3. Customer Tester
•Customers define “what success looks like” through acceptance criteria.
•Testers convert those criteria into executable acceptance tests.
•This guarantees that business requirements are met precisely.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. Tracker Entire Team
•Tracks team velocity and helps in making realistic commitments during the Planning Game.
•Provides transparency — if productivity drops, helps identify root causes (e.g., excessive defects, unclear requirements).

5. Coach Team
•Mentors the team in applying XP principles: communication, simplicity, feedback, courage, and respect.
•Encourages pair programming, refactoring, and continuous improvement.
•Acts as the guardian of XP values, similar to the Scrum Master role in Scrum.

Uncle Bob: “The coach does not command; they remind the team of their discipline.”
Mike Cohn: “An Agile coach nurtures self-organization — guiding without authority.”

4. The Concept of Collaboration and Shared Understanding

XP breaks silos by emphasizing:

Face-to-face communication over documents.
Pair programming to share knowledge and skill.
Collective code ownership so anyone can fix or improve any module.
Shared responsibility — everyone owns success and failure.

Uncle Bob: XP’s collaborative model ensures continuous learning; knowledge isn’t trapped with individuals.
Mike Cohn: Collaboration reduces defects and increases team morale, key to long-term success.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Example – XP Team in Action

Scenario: Developing a real-time chat application.

Role Contribution
Writes stories like “As a user, I want to see when
Customer
others are typing.”
Implement this with TDD; one writes code, the other
Programmers
reviews (pair programming).
Creates automated acceptance tests to confirm that
Tester
typing status updates correctly.
Notes that team velocity has improved by 10% since
Tracker
automating tests.
Encourages regular retrospectives and maintains
Coach
adherence to XP practices.

Outcome: Continuous feedback and open communication lead to fast, high-quality releases with minimal rework.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

6. XP Roles vs. Scrum Roles

XP Role Closest Scrum Equivalent Key Difference

XP customer is on-site and interacts
Customer Product Owner
daily.
XP coach focuses more on technical
Coach Scrum Master
discipline and practice mentoring.
XP programmers follow strict
Programmer Developer engineering practices like TDD and
pair programming.
Often handled by Scrum Master or XP tracker is more metrics-focused,
Tracker
tools ensuring transparency.
XP tester plays a distinct role
Tester Part of Dev Team in Scrum emphasizing automated and
acceptance testing.

Integration Insight:
Mike Cohn often recommends combining Scrum for project management and XP for engineering discipline — the best
of both worlds.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

7. Summary Table

Aspect Description Uncle Bob’s Emphasis Mike Cohn’s Emphasis

Everyone needed to build
Professionalism and Self-organizing, cross-
Whole Team the product works
shared ownership functional teams
together
Collaboration and
Programmer Code, test, refactor Clean, maintainable code
technical excellence
Defines requirements and Continuous involvement
Customer Clear feedback loops
priorities and visibility
Early validation and
Tester Ensures functional quality Tests guide design
learning
Tracks metrics and
Tracker Transparency, no blame Adaptive planning
progress
Upholds discipline and Facilitates continuous
Coach Mentors the team
Agile principles improvement

8. Key Takeaways
XP’s whole team approach eliminates hierarchy and promotes shared accountability.
Each role contributes to communication, simplicity, feedback, and respect — XP’s five values.
XP’s roles align closely with Scrum’s, but place more focus on technical rigor and real-time collaboration.
Uncle Bob: XP is the craftsmanship backbone of Agile.
Mike Cohn: XP’s collaborative roles build the culture necessary for sustainable agility.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

XP: Core Practices – Development Fundamentals

Two of the most important engineering practices in Extreme Programming (XP) are
[Link] Programming and
[Link]-Driven Development (TDD).
These are the backbone of XP’s technical discipline, ensuring that software is clean, reliable, and adaptable to change.

While Scrum focuses on managing work, XP focuses on how to build quality software effectively.
Both Uncle Bob and Mike Cohn emphasize that without solid engineering foundations, agility cannot be sustained.

1. Pair Programming

Definition
Pair programming is an XP practice where two programmers work together at one workstation.
•One acts as the Driver — writing code.
•The other acts as the Navigator — reviewing each line, thinking ahead, and suggesting improvements.
They frequently switch roles.

Uncle Bob: “Pair programming is not two people doing one person’s job — it’s two brains collaborating on clean, thoughtful code.”
Mike Cohn: “Pair programming improves code quality and team learning, reducing the cost of defects and rework.”

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Key Objectives

• Improve code quality and design clarity.

• Encourage continuous peer review and learning.
• Spread knowledge across the team (no single point of failure).
• Reduce defects early, before code reaches testing.

How It Works (Execution)

[Link] and Navigator setup:

1. Driver writes the actual code.
2. Navigator reviews logic, structure, and possible pitfalls.
[Link] switching:
1. Pairs rotate every few hours or stories to avoid fatigue.
[Link] of TDD:
1. Most XP teams combine pairing with TDD to write test cases together.
Example:
Two developers are implementing a “Login” feature.
• The driver writes the authentication logic.
• The navigator reviews for edge cases like invalid passwords or SQL injection.
They switch roles after the function passes tests.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Benefits of Pair Programming

Benefit Description
Improved Quality Continuous review prevents defects early.
Skills spread among team members, reducing Uncle Bob: Pair programming
Knowledge Sharing
dependency on individuals. enforces clean code principles —
Two perspectives lead to simpler, cleaner naming clarity, small functions, and
Better Design Decisions single responsibility.
design.
Promotes communication and shared
Enhanced Team Cohesion Mike Cohn: Pairs produce fewer
ownership of code.
defects, often leading to higher long-
Two minds can identify solutions faster during term velocity despite a slight short-
Faster Problem Solving
complex challenges. term cost.

When to Use Pair Programming

• For complex code or critical modules (e.g., security logic, APIs).

• When mentoring new developers.
• During refactoring sessions or when introducing new technologies.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Test-Driven Development (TDD)
Definition

TDD is a software development practice where tests are written before the code that implements the functionality.
It follows a short, repeatable cycle:
Red → Green → Refactor

Step Description
Write a small failing test for new
Red
functionality.
Write just enough code to make the
Green
test pass.
Clean up the code, ensuring all tests
Refactor
still pass.

Purpose of TDD

Guides clean and modular design.

Ensures high test coverage and prevents regressions.
Encourages simplicity — only code needed to pass tests is written.
Provides living documentation of system behavior.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Benefits of TDD
Benefit Description
Improved Design Quality Forces modular, loosely coupled code.
Issues are caught immediately when new code breaks
Early Defect Detection
a test.
Confidence in Refactoring Safe to modify code because tests act as safety nets.
Better Documentation Tests describe expected system behavior.
Higher Maintainability Clean, simple, and predictable code structure.

TDD in XP Lifecycle

TDD integrates seamlessly with XP practices:

•Used during pair programming sessions.
•Applied continuously in short iterations.
•Forms the foundation for continuous integration.
•Enables refactoring without fear.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

3. Pair Programming and TDD Together

Aspect Pair Programming TDD

Collaboration and shared
Focus Code design and correctness
ownership
Knowledge sharing and defect Continuous verification and
Goal
prevention improvement
Improves design and collective Ensures correctness and modular
Primary Benefit
learning design
XP Value Supported Communication, Respect Feedback, Simplicity
Uncle Bob’s View Code is a shared craft Tests define the contract of design
Mike Cohn’s View Collaboration increases quality Testing supports adaptive planning

Together, these practices promote continuous feedback, simplicity, and technical excellence — the foundation of Agile
craftsmanship.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. Example – XP Development Fundamentals in Practice

Scenario: An e-commerce team is building a “Discount Calculation” feature. 6. Key Takeaways

•Two developers (pair programming) write a failing test for a 10% discount rule (TDD).
•They implement the simplest logic to pass the test. •Pair Programming → Focuses on
•They refactor the discount logic into a reusable method. people and collaboration.
•Tests confirm behavior after each change. •TDD → Focuses on code design and
Outcome: quality.
•Minimal bugs during integration. •Both embody XP’s core values:
•Both developers understand the logic deeply. communication, feedback, simplicity,
•Code is clean, simple, and maintainable. and respect.

5. Summary Table

Practice Purpose Key Benefits T1 – Uncle Bob T2 – Mike Cohn

Collaborative coding Encourages clean, Builds trust and
Higher code quality,
Pair Programming with real-time collective improves team
shared learning
review craftsmanship knowledge
Cleaner design, Supports adaptive
Test-Driven Write tests before Tests guide design,
fewer defects, easy planning and fast
Development (TDD) code not verify it
refactoring delivery

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

XP: Core Practices – Design and Refactoring

Extreme Programming (XP) emphasizes technical excellence — the belief that high-quality software design and clean code enable rapid,
flexible change.

Three XP practices embody this philosophy:

[Link] Design
[Link]
[Link] Code Ownership

Together, they ensure that software remains adaptable, maintainable, and collaboratively developed.

1. Simple Design

Concept

Simple Design means keeping the design of the system as simple as possible, implementing only what is necessary to meet current
requirements — no more, no less.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

 XP Rules for Simple Design
Kent Beck and Uncle Bob both describe four principles that define a simple design (in priority order):

Rule Explanation
The system must be fully functional and correct — nothing is
1. Runs All Tests
“broken.”
Avoid redundant logic; every piece of knowledge should have
2. No Duplication
one representation.
Code should clearly express intent — understandable by
3. Expressive Code
other developers.
Keep the design as small and focused as possible — no
4. Minimal Classes and Methods
unnecessary abstractions.

Why Simple Design Matters

• Enables faster change — less code to modify.
• Prevents “Big Design Up Front” (BDUF) pitfalls common in Waterfall.
• Encourages clean architecture that evolves naturally.
• Reduces technical debt over time.
Example:
A developer needs to implement user login. Instead of designing a complex authentication framework, they write only what’s needed for
username-password verification. If future sprints require multi-factor authentication, it’s added then — not prematurely.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Refactoring
Concept
Refactoring is the process of improving the internal structure of existing code without changing its external behavior.
Purpose of Refactoring
•Maintain code readability and quality.
•Remove duplication and bad smells in code.
•Make future modifications easier and safer.
•Support continuous improvement and technical excellence.

Common Refactoring Techniques

Technique Purpose
Extract Method Break large functions into smaller, meaningful units.
Rename Variable/Method Improve clarity and readability.
Simplify Conditionals Replace complex logic with simpler expressions.
Remove Duplication Consolidate repeated code into reusable components.
Replace Magic Numbers Use named constants for clarity.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

The TDD + Refactoring Cycle
Refactoring is deeply tied to Test-Driven Development (TDD) in XP:
[Link] a failing test (Red).
[Link] just enough code to pass the test (Green).
[Link] the code (Refactor).
The tests act as safety nets, ensuring that changes don’t break functionality.

Example:
Before refactoring:
if (status == 1) sendEmail("Active");
if (status == 2) sendEmail("Inactive");
if (status == 3) sendEmail("Pending");

After refactoring:
sendEmail(getStatusMessage(status));
private String getStatusMessage(int status) {
switch(status) {
case 1: return "Active";
case 2: return "Inactive";
case 3: return "Pending"; The code is now clear, concise, and reusable.
default: return "Unknown";
}}
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
3. Collective Code Ownership
Concept
In XP, Collective Code Ownership means that any developer can modify any part of the codebase at any time.
There are no “my code” or “your code” zones — the entire team owns the system collectively.

Key Principles
•Everyone can refactor, fix, or improve any part of the code.
•Encourages shared responsibility and team accountability.
•Reduces knowledge silos — no single point of failure.
•Promotes code consistency — everyone follows shared standards.

Benefits
Benefit Description
Everyone understands the full system, reducing
Shared Knowledge
dependencies on individuals.
Improved Code Quality More eyes mean more feedback and fewer defects.
Continuous Improvement Anyone can fix issues as soon as they find them.
Team Collaboration Encourages open communication and mentorship.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Practices Supporting Collective Ownership
•Pair Programming: Naturally shares knowledge.
•Coding Standards: Ensure everyone writes in a consistent style.
•Continuous Integration: Allows frequent integration of everyone’s work safely.

Example:
A developer notices a performance issue in another module. Instead of waiting for its “owner,” they fix and commit it — maintaining
high team velocity.

4. Relationship Between These Three Practices

Practice Purpose How It Supports XP Values

Simple Design Build only what’s needed now. Simplicity, Feedback
Continuously improve internal
Refactoring Courage, Excellence
design.
Collective Ownership Anyone can change any code. Respect, Communication

Together, they create a continuous improvement loop:

•Simple designs evolve through refactoring.
•Changes are freely made due to collective ownership.
•This keeps the system clean, adaptable, and team-driven.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Example – XP Design & Refactoring in Action

Scenario: Developing a digital wallet system.

[Link] start with a simple class structure for transactions (Simple Design).
[Link] new features (recharge, transfer, refund) are added, they refactor the Transaction class to separate responsibilities (Refactoring).
[Link] members freely improve and enhance the shared codebase (Collective Ownership).

Outcome:
•Minimal technical debt.
•Flexible system ready for new requirements. 7. Key Takeaways
•High morale and shared responsibility. •Simple Design → Solve today’s problem, not tomorrow’s.
•Refactoring → Keep the code clean, flexible, and alive.
•Collective Ownership → The whole team owns quality and design.

6. Summary Table
Aspect Description T1 – Uncle Bob T2 – Mike Cohn
Keep design minimal and Avoid unnecessary
Simple Design Enables adaptability
expressive complexity
Improve internal design Clean code requires constant Sustains agility and reduces
Refactoring
without changing behavior refinement cost of change
Professional responsibility Encourages self-organization
Collective Ownership Team jointly owns all code
shared by all and collaboration

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

XP: Core Practices – Integration and Releases
Extreme Programming (XP) promotes rapid feedback, adaptability, and technical excellence through continuous integration, small
releases, and close customer collaboration.
These practices ensure that teams deliver value continuously, maintain high-quality code, and respond quickly to changing business
needs — the true spirit of Agile.

1. Continuous Integration (CI)

Concept
Continuous Integration (CI) means that developers integrate their code changes into a shared repository multiple times a day,
ensuring that software always works as a whole.
Each integration triggers automated builds and tests, immediately detecting conflicts or errors.

Core Principles of CI

[Link] early and often: Merge changes several times per day.
[Link] builds and tests: Run unit and acceptance tests automatically.
[Link] the build fast and visible: The team should immediately see if something breaks.
[Link] broken builds immediately: A broken build halts progress — repair it before proceeding.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Benefits
Benefit Description
Early Defect Detection Integration issues found within minutes, not weeks.
Constant feedback from automated tests maintains
Improved Code Quality
system integrity.
Reduced Integration Risk Small, frequent merges minimize conflict and rework.
Team Collaboration Everyone works from a stable, shared codebase.

Example

A team uses Jenkins (CI tool):

•Developers commit code several times a day.
•Each commit triggers automated unit and integration tests.
•If a test fails, the system alerts the team instantly.
This ensures that the main branch is always deployable.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

2. Small Releases
Concept
Small Releases mean delivering working software frequently — ideally every one or two weeks.
Each release provides a complete, usable increment that delivers value to customers.
Why Small Releases Matter
•Encourage early customer feedback.
•Reduce risk of large-batch failures.
•Build customer confidence through visible progress.
•Allow rapid adaptation based on new insights.
Release Cycle in XP
Step Description
Iteration Development Implement a small set of user stories.
Automated Testing & CI Ensure all features pass tests.
Internal Release Team tests integrated functionality.
Customer Release Working product delivered for user validation.
Example
A fintech team building a digital payment app:
•Release 1: Add beneficiary & basic transfer.
•Release 2: Transaction history & notifications.
•Release 3: Bill payment feature.
Each release adds value and gathers customer feedback to refine the next iteration.
PRESIDENCY UNIVERISTY, BENGALURU, School of CSE
3. On-Site Customer
Concept
The On-Site Customer is a central XP practice where a real customer representative works directly with the development team every
day.
They clarify requirements, prioritize stories, and test features continuously.

Roles and Responsibilities

Responsibility Explanation
Define Requirements Writes and prioritizes user stories.
Clarify Details Answers questions instantly to prevent assumptions.
Validate Deliverables Tests completed stories and gives feedback.
Decides which features deliver the most business
Set Priorities
value.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

Benefits
Benefit Outcome
Fewer Misunderstandings Direct communication eliminates guesswork.
Faster Decision-Making Immediate clarifications keep development flowing.
Customer Alignment Team delivers exactly what users expect.
Continuous Feedback Early detection of issues reduces rework.

Example
In an insurance project, a claims officer (on-site customer) works daily with developers.
When a new “Claim Approval” feature behaves unexpectedly, she immediately provides the correct rule — saving time
and avoiding rework.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

4. How These Practices Work Together

XP Practice Purpose How It Supports Agility

Keep code working and integrated Enables fast feedback and stable
Continuous Integration
at all times builds
Encourages feedback and
Small Releases Deliver customer value frequently
adaptation
Reduces waste and
On-Site Customer Ensure constant collaboration
misunderstanding

These practices create a feedback-driven development loop:

[Link] customer defines a small, high-value story.
[Link] implement and integrate it using CI.
[Link] working increment is released quickly.
[Link] customer tests it and provides feedback for improvement.
This cycle repeats — enabling evolutionary delivery, technical quality, and customer satisfaction.

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE

5. Example – XP in Action

Scenario: Developing an e-commerce website.

•On-Site Customer: A sales manager works with the team daily.
•Continuous Integration: Developers integrate all changes into the main branch multiple times daily, with automated unit tests.
•Small Releases: Every two weeks, the team releases a new increment (e.g., product catalog → checkout → payment gateway).
Outcome:
•Stable builds, no integration delays.
•Rapid user feedback after each release.
•Features evolve naturally based on customer behavior and feedback.

6. Summary Table

Aspect Description T1 – Uncle Bob T2 – Mike Cohn

Frequent code integration Discipline and craftsmanship Enables short feedback loops
Continuous Integration
and testing in maintaining clean builds and team confidence
Deliver working software Working software is the only Builds customer trust and
Small Releases
frequently true progress supports iterative learning
Customer works daily with Collaboration replaces Real-time feedback and
On-Site Customer
the team documentation business alignment

PRESIDENCY UNIVERISTY, BENGALURU, School of CSE