AGILE SOFTWARE DEVELOPMENT

Unit-I

Introduction to Agile

Agile is a group of software development methodologies based on iterative development, where requirements and
solutions evolve through collaboration between self-organizing cross-functional teams.

Key Features:

 Incremental delivery

 Emphasis on individuals and interactions

 Customer collaboration

 Responding to change

The Agile Manifesto (2001)

Four Core Values:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Twelve Principles include:

 Satisfy customer through early & continuous delivery

 Welcome changing requirements

 Deliver working software frequently

 Business & developers work together daily

 Build projects around motivated individuals

 Face-to-face conversation is best

 Working software is the primary measure of progress

 Agile processes promote sustainable development

 Continuous attention to technical excellence

 Simplicity—the art of maximizing the amount of work not done—is essential

 Self-organizing teams produce best architectures & designs

 Reflect regularly to become more effective

Agile Methods (Frameworks)

Agile is an umbrella term for various methodologies:

1. Extreme Programming (XP)

 Focuses on technical excellence

 Practices:

o Test-Driven Development (TDD)

o Pair Programming
 o Continuous Integration

o Refactoring

o Small Releases

o On-site customer

2. SCRUM

 Framework for managing work

 Roles: Product Owner, Scrum Master, Development Team

 Artifacts: Product Backlog, Sprint Backlog, Increment

 Events:

o Sprint (2–4 weeks)

o Sprint Planning

o Daily Stand-up

o Sprint Review

o Sprint Retrospective

3. DSDM (Dynamic Systems Development Method)

 Foundation of iterative and incremental development

 Principles:

o Active user involvement

o Frequent delivery

o Integrated testing

o Reversible changes

o Collaboration

o Business needs first

4. Feature-Driven Development (FDD)

 Focus on building & designing features

 Steps:

1. Develop overall model

2. Build feature list

3. Plan by feature

4. Design by feature

5. Build by feature

Agile Modelling (AM)

What is Agile Modelling?

Agile Modelling is a practice-based methodology for effective modelling and documentation of software systems in an
Agile environment.
Core Principles:

 Model with a purpose

 Use multiple models

 Travel light (just enough documentation)

 Embrace change

 Enabling communication

 Content is more important than format

Practices:

 Create simple content

 Model storming (short modelling sessions)

 Apply modelling standards

 Prioritized requirements modelling

Modelling Misconceptions

1. Modelling is documentation – Not necessarily. Modelling is to understand and design systems.

2. You must use one tool – Agile modelling is tool-independent.

3. Model everything before coding – Agile modelling is iterative; models evolve.

4. No models in Agile – Agile promotes lightweight, useful modelling.

Tools of Agile Modelling

Agile modelling tools are often lightweight and promote collaboration.

Examples:

 Whiteboards & Sticky Notes – for quick model storming

 UML Diagrams – use-case, class, sequence diagrams

 Agile project boards – Jira, Trello

 Lightweight CASE tools – Lucid chart, Draw.io, Visual Paradigm

🔄 Updating Agile Models

Agile models are not static; they are revised regularly to reflect:

 New insights from team discussions

 Feedback from customer or stakeholders

 Design improvements or refactoring

 Changes in business requirements

Best Practices:

 Keep models simple and understandable

 Update as late as possible, but as early as necessary

 Use models as communication tools, not just as specs

 Collaborate when updating models

✅ Summary

Topic Summary

Agile Iterative, people-focused development methodology

Manifesto 4 values and 12 principles guiding Agile development

XP Emphasizes code quality and technical practices

Scrum Project management framework for Agile teams

DSDM Business-focused Agile approach

FDD Feature-centric modelling and development

Agile Modelling Lightweight modelling to support Agile projects

Misconceptions Agile does not mean "no modelling"

Tools Whiteboards, UML, digital boards, diagramming tools

Updating Models Continuous, collaborative, and adaptive

 UNIT-II

Extreme Programming (XP), covering all requested topics: Introduction, Core XP Values, The Twelve XP Practices,
Planning, Test-First Coding, and Pair Programming.

🔰 1. Introduction to Extreme Programming

Extreme Programming (XP) is an Agile software development methodology aimed at improving software quality and
responsiveness to changing customer requirements through frequent releases in short development cycles.

📌 Key Features:

 Customer-centric

 Frequent iterations (1–2 weeks)

 Continuous feedback

 Strong focus on programming discipline

 High team involvement and communication

💡 2. Core XP Values

XP is built upon 5 core values that guide its practices and culture:

1. Communication

o Encourage team discussions

o Promote shared understanding

2. Simplicity

o Do the simplest thing that works

o Avoid overengineering

3. Feedback

o Rapid feedback from tests and customers

o Use to improve design and direction

4. Courage

o Willingness to refactor, discard, or rework code

o Address problems without delay

5. Respect

o Mutual respect among team members

o Team collaboration and shared responsibility

🧱 3. The Twelve XP Practices

XP integrates 12 interdependent practices that work together to ensure agility and quality.

Practice Description

1. The Planning Game Quick planning based on business priorities and technical estimates.

2. Small Releases Frequent releases in short cycles to gain feedback.

3. Metaphor Shared story or vision that guides development.

Practice Description

4. Simple Design The system should be as simple as possible at every point.

5. Testing Write automated unit tests before coding (Test-Driven Development).

6. Refactoring Improve the structure of existing code without changing its behavior.

7. Pair Programming Two developers write code together at one workstation.

8. Collective Code Ownership Anyone can change any part of the code at any time.

9. Continuous Integration Integrate and test code frequently, ideally multiple times a day.

10. 40-Hour Week Maintain sustainable pace, avoiding burnout.

11. On-Site Customer Customer should be available full-time to answer questions.

12. Coding Standards Code should follow consistent style for readability and maintainability.

📊 4. About Extreme Programming

 Created by Kent Beck in the late 1990s.

 Emphasizes rapid feedback, incremental planning, and continuous improvement.

 Best suited for projects with frequently changing requirements and high technical risk.

 Encourages high involvement from both developers and customers.

📅 5. Planning XP Projects (The Planning Game)

Planning in XP is done collaboratively between the development team and the customer.

Components:

 User Stories: Short descriptions of desired functionality from the user's perspective.

 Estimation: Developers provide time or effort estimates for user stories.

 Prioritization: Customers rank stories based on business value.

Phases:

1. Release Planning – Determine which features to include in the upcoming release.

2. Iteration Planning – Choose stories to implement in the current iteration (typically 1–2 weeks).

3. Daily Standups – Brief meetings to check progress, blockers, and coordination.

✅ 6. Test-First Coding (Test-Driven Development - TDD)

Test-First Coding is a key XP practice where tests are written before the code itself.

Steps in TDD:

1. Write a test that defines a function or improvement.

2. Run the test and see it fail (red).

3. Write the code to pass the test.

4. Run the test again (green).

5. Refactor the code while keeping the test green.

Benefits:

 Ensures code correctness

 Drives design (code is written only to pass tests)

 Facilitates change and refactoring

 Builds a suite of automated regression tests

7. Making Pair Programming Work

Pair Programming = Two developers work together at one machine:

 Driver: Writes the code.

 Observer/Navigator: Reviews the code and suggests improvements.

Tips for Effective Pair Programming:

 Rotate pairs frequently

 Match complementary skill levels (experienced with beginner)

 Use it for complex or critical tasks

 Respect each other’s ideas and feedback

 Take breaks to avoid fatigue

Advantages:

 Improved code quality

 Knowledge sharing and reduced "knowledge silos"

 Faster problem solving

 Continuous code review

Challenges:

 Requires good interpersonal skills

 May feel slower initially

 Needs open communication to resolve conflicts

🧾 Summary Table

Topic Key Points

XP Introduction Agile method focused on coding practices, customer collaboration, and adaptability

Core Values Communication, Simplicity, Feedback, Courage, Respect

12 Practices Planning Game, Small Releases, TDD, Pair Programming, etc.

Planning XP Based on user stories, customer priorities, and developer estimates

Test-First Coding Write tests before writing code (TDD)

Pair Programming Two people write code together, improving quality and collaboration
 Unit-III

Agile Modeling and Extreme Programming (XP), covering: Introduction, The Fit, Common Practices, Modeling-Specific
Practices, XP Objections to Agile Modeling, Agile Modeling and Planning XP Projects, XP Implementation Phase.

1. Agile Modeling (AM): Introduction

 Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software
systems.

 It promotes lightweight, flexible, and collaborative modeling.

 Supports Agile methodologies like XP, Scrum, etc., by guiding how to model and document software.

Core Principles:

1. Model with a purpose: Every model must fulfill a specific goal.

2. Travel light: Keep models simple and minimal.

3. Multiple models: Use different types of models (UML, CRC cards, sketches, etc.).

4. Rapid feedback: Get feedback early through reviews or working software.

5. Embrace change: Be ready to revise models.

2. XP (Extreme Programming): Introduction

 XP is an Agile software development methodology focusing on high-quality software and responsiveness to

changing requirements.

 Introduced by Kent Beck, XP emphasizes technical excellence, simplicity, and frequent releases.

Core XP Values:

 Communication

 Simplicity

 Feedback

 Courage

 Respect

3. The Fit: How Agile Modeling Fits with XP

 XP promotes code-focused development, but modeling still has a role.

 Agile Modeling enhances XP by:

o Adding lightweight modeling practices.

o Supporting early requirement analysis and design thinking.

o Enabling better team collaboration through visual artifacts.

Complementarity:

XP Focus Agile Modeling Support

Working code Models for understanding

Refactoring Model-based exploration

Pair programming Collaborative modeling

Test-driven development Modeling test cases

4. Common Agile Modeling Practices

Agile Modeling includes general modeling practices used across all Agile methods:

Core Practices:

 Iterate incrementally: Build models step-by-step.

 Model storming: Short, impromptu modeling sessions.

 Just barely good enough (JBGE): Do only as much modeling as necessary.

 Active stakeholder participation: Engage users/customers in modeling.

 Collective ownership: Any developer can improve any model.

5. Modeling-Specific Practices

These focus directly on modeling aspects within Agile Modeling:

 Use simple tools: Whiteboards, paper, and sticky notes preferred over complex CASE tools.

 Apply modeling standards: Use common notations like UML for consistency.

 Create several models in parallel: Combine UI models, data models, and process models.

 Model in small increments: Avoid upfront exhaustive modeling.

 Prove it with code: Validate models by converting them into working code quickly.

6. XP Objections to Agile Modeling

XP traditionally resists upfront modeling. Reasons include:

Objection Agile Modeling's Response

Modeling delays coding AM promotes model storming—short and fast sessions

Documentation is wasteful AM supports minimal, purposeful documentation

Code is the best documentation AM accepts this but adds supportive visuals

YAGNI (You Aren’t Gonna Need It) AM encourages just enough modeling

Fear of "big design up front" (BDUF) AM focuses on incremental modeling

7. Agile Modeling and Planning XP Projects

Agile Modeling helps XP with project planning:

 Release Planning:

o Use high-level models to identify features and dependencies.

o Models help estimate effort and understand user stories.

 Iteration Planning:

o Use modeling to break stories into technical tasks.

o Support estimation and task decomposition.

 Risk Management:

o Models clarify unknowns and reduce technical risks.

 Architecture:

o Lightweight architecture modeling provides direction.

 o Avoids rework by spotting issues early.

8. XP Implementation Phase and Agile Modeling

During XP's coding-focused implementation phase, Agile Modeling contributes by:

Integration Points:

 Model Before Coding:

o Quick sketches before writing logic.

o Model class interactions, workflows.

 Support Test-First Design:

o Model inputs, outputs, and edge cases before writing tests.

 Refactoring Support:

o Update models after code changes for team clarity.

 Pair Programming:

o Collaborative modeling done on-the-fly during code sessions.

 Continuous Integration:

o Models used to coordinate integration points and interfaces.

Conclusion

Agile Modeling and XP work best in synergy:

 XP ensures high-quality working software.

 Agile Modeling ensures the right software is being built with clarity, collaboration, and minimal overhead.

 Together, they balance thinking before coding and delivering value quickly.

Unit-IV

Feature-Driven Development (FDD), covering: Introduction, Incremental Software Development, Regaining Control: The
Motivation behind FDD, Planning an Iterative Project, Architecture Centric, FDD and XP

1. Feature-Driven Development (FDD): Introduction

 Feature-Driven Development (FDD) is a model-driven, short-iteration process for software development.

 Developed by Jeff De Luca with influence from Peter Coad in the late 1990s.
  FDD is client-centric, architecture-driven, and emphasizes design before implementation.

 It is suitable for large-scale and complex projects with many developers.

Core Idea:

 Build software by developing small, client-valued features in quick iterations.

FDD Lifecycle Consists of 5 Main Activities:

1. Develop Overall Model

2. Build Feature List

3. Plan by Feature

4. Design by Feature

5. Build by Feature

2. Incremental Software Development in FDD

 FDD promotes incremental and iterative development by focusing on individual features.

 A feature is a small, client-valued function expressed in a short phrase (e.g., “Calculate total invoice”).

 Each feature typically takes less than 2 weeks to complete.

Advantages:

 Constant progress tracking.

 Easier bug isolation.

 Rapid feedback from stakeholders.

 Continuous integration and delivery.

3. Regaining Control: The Motivation Behind FDD

FDD was created to address challenges in large software teams, such as:

Problems in Traditional Approaches:

 Poor communication among large teams.

 Lack of visible progress.

 Poor code ownership and accountability.

 Delayed delivery and unpredictability.

How FDD Regains Control:

 Breaks down system into manageable features.

 Assigns chief programmers for ownership.

 Tracks progress at a granular feature level.

 Promotes early modeling and architectural decisions.

4. Planning an Iterative Project with FDD

FDD encourages careful planning before coding begins, but keeps the process Agile.

Key Planning Steps:

1. Developing the Overall Model:

 o Build a domain object model (often in UML).

o Involve domain and development experts.

2. Feature List Creation:

o Identify and group features by subject areas.

o Features are derived from the object model.

3. Planning by Feature:

o Assign features to developers.

o Estimate and prioritize feature delivery.

o Create milestones (design, code, test).

Progress Tracking:

 Percentage of features completed.

 Features checked in and verified.

5. Architecture-Centric Approach in FDD

 FDD is architecture-first: it starts with a domain model that guides all development.

 This model helps ensure:

o Consistency across the system.

o Reusability of components.

o Clear understanding of system structure.

Benefits:

 Reduces rework during development.

 Aligns all features to a shared architectural vision.

 Facilitates better communication in large teams.

6. FDD and XP: Comparison and Integration

Though both are Agile methods, FDD and XP differ in focus and application:

Criteria Feature-Driven Development (FDD) Extreme Programming (XP)

Focus Modelling, features, planning Code quality, feedback, testing

Architecture Strong emphasis on upfront Modelling Minimal upfront design

Team Size Designed for large teams Best suited for small teams

Iterations Feature-based, guided by model Time-boxed iterations

Ownership Chief programmer owns code segments Collective code ownership

Practices Design by feature, build by feature Test-first, pair programming, refactoring

Can They Work Together?

Yes — FDD and XP can complement each other:

 Use FDD's modelling and planning discipline with XP's technical practices like:

o Test-driven development (TDD)

o Refactoring

o Continuous Integration

Feature-Driven Development (FDD) provides a structured, feature-centric approach to Agile development. It brings:

 Discipline through upfront modeling,

 Control through detailed planning,

 And flexibility by focusing on small deliverable features.

While it contrasts with XP’s code-centric view, both can be combined to create a robust, scalable, and Agile development
process, especially for large or distributed teams.

Unit-V

Agile Methods with RUP and PRINCE2, Tools, and Obstacles, covering: Agile Modeling and RUP, FDD and RUP, Agile
Methods and PRINCE2, Tools to Help with Agile Development, Eclipse: An Agile IDE

1. Agile Modelling and RUP (Rational Unified Process)

What is RUP?

 A software development framework developed by IBM Rational.

 Based on best practices and phased development: Inception, Elaboration, Construction, Transition.

 It’s use-case driven, architecture-centric, and iterative.

Integration with Agile Modelling (AM):

  Although RUP is often seen as heavy, it can be adapted using Agile Modeling principles.

 Agile Modelling brings lightweight, flexible, and collaborative practices to RUP’s formality.

How Agile Modelling Supports RUP:

RUP Element Agile Modelling Addition

Elaboration Phase Use lightweight modelling (UML, CRC) to define architecture

Use Case Modelling Model just enough; avoid excessive documentation

Iteration Planning Collaborate with stakeholders to define priorities

Design Activities Favor sketches and evolving models

Reviews Use quick peer reviews instead of formal inspections

Benefits of Integration:

 Reduces overhead and documentation bloat.

 Encourages communication and adaptability.

 Preserves RUP's strengths (structure, risk management) while becoming more Agile.

2. FDD and RUP Integration

Why Integrate FDD and RUP?

 Both are model-driven and iterative, making them compatible.

 RUP provides a strong framework; FDD offers practical methods to implement features quickly.

How They Align:

FDD Activity RUP Equivalent or Support

Develop Overall Model RUP’s Elaboration (Domain Modeling)

Build Feature List Use Case Analysis

Plan by Feature Iteration Planning

Design/Build by Feature Construction Phase with role-specific development

Advantages:

 RUP’s documentation and tools support large projects.

 FDD adds practicality, team focus, and client-valued delivery.

 Ideal for scaling Agile methods in enterprise environments.

3. Agile Methods and PRINCE2

What is PRINCE2?

 A project management methodology developed in the UK.

 Focuses on planning, control, accountability, and business justification.

 Often seen as heavyweight but is framework-based (can be tailored).

Integrating Agile with PRINCE2:

 Use Agile methods (like Scrum or XP) for product delivery, while PRINCE2 governs the project environment.
  PRINCE2 manages project-level activities: scope, budget, risk, reporting.

 Agile handles team-level development: iteration, feedback, continuous delivery.

Compatibility Points:

PRINCE2 Element Agile Method Equivalent/Support

Business Case Product Vision and Backlog

Product-Based Planning User Stories and Iteration Planning

Stage Boundaries Sprint Reviews and Retrospectives

Tolerance Management Timeboxing and Iterative Delivery

Benefits of Integration:

 Keeps management oversight while empowering teams.

 Helps regulated industries adopt Agile with control.

 Promotes transparency, risk control, and accountability.

4. Tools to Help with Agile Development

Agile development benefits greatly from tools that support collaboration, automation, and visibility.

Key Categories of Tools:

a) Project Management & Collaboration:

 Jira – User stories, sprints, tasks.

 Trello – Simple visual Kanban boards.

 Asana, Monday.com, ClickUp – Workflow planning.

b) Continuous Integration & Testing:

 Jenkins – Automates build and test cycles.

 GitLab CI/CD, CircleCI – Full pipelines.

 Selenium, JUnit, TestNG – Automated testing.

c) Version Control:

 Git (with GitHub, GitLab, Bitbucket) – Source code management and collaboration.

d) Agile Modeling Tools:

 PlantUML – Create diagrams using text syntax.

 Lucidchart, draw.io – Collaborative diagramming.

 Enterprise Architect – Advanced UML support.

e) Agile IDEs (see below for Eclipse)

5. Eclipse: An Agile IDE

Overview:

 Eclipse is an open-source, Java-based Integrated Development Environment (IDE).

 Highly extensible via plugins, making it suitable for Agile practices.

Agile Features in Eclipse:

a) Version Control Integration:

 Git support (EGit plugin).

 SVN, CVS support available via plugins.

b) Test-Driven Development (TDD):

 Integrated JUnit/TestNG support for unit testing.

 Refactoring tools support continuous improvement.

c) Pair Programming & Collaboration:

 Plugins like CodeTogether and Live Share (via VS Code extension bridge).

d) Continuous Integration Plugins:

 Integration with Maven, Gradle, Ant for build automation.

 Supports Jenkins integration for CI/CD workflows.

e) Modeling Support:

 Papyrus – UML modeling.

 EMF (Eclipse Modeling Framework) – Domain modeling for Agile Model-Driven Development.

Advantages of Eclipse for Agile Teams:

 Encourages modular development and frequent testing.

 Facilitates collaborative coding and refactoring.

 Open-source and community-supported.

Agile methods can be successfully integrated with traditional or structured approaches like RUP and PRINCE2:

 Agile Modeling lightens RUP’s process.

 FDD complements RUP with practical feature-based development.

 PRINCE2 provides project governance, while Agile ensures fast delivery and responsiveness.

With the right tools like Eclipse, Jira, and CI/CD pipelines, Agile teams can improve productivity, communication, and
software quality—while still aligning with organizational needs for control and reporting.

Unit-VI

Obstacles to Agile Software Development, covering: Management Intransigence, The Failed Project Syndrome,
Contractual Difficulties, Familiarity with Agility

Obstacles to Agile Software Development

Although Agile methods offer speed, flexibility, and collaboration, several challenges and obstacles can prevent their
effective adoption, especially in traditional or rigid organizations.

1. Management Intransigence

Definition:

 Intransigence means unwillingness to change or compromise.

 Refers to resistance from management to adopt or support Agile practices.

Reasons for Resistance:

  Fear of losing control or authority.

 Preference for command-and-control hierarchies.

 Concern over lack of detailed documentation and upfront planning.

 Misunderstanding Agile as “unstructured” or “undisciplined.”

Impact:

 Undermines Agile team autonomy.

 Delays decision-making.

 Causes friction between management and developers.

 May lead to partial or fake Agile implementations (also called Agile in name only).

Overcoming It:

 Educate management on Agile values and ROI.

 Use pilot projects to demonstrate Agile’s effectiveness.

 Promote transparency and continuous feedback.

 Encourage management to participate in Agile ceremonies (reviews, planning).

2. The Failed Project Syndrome

Definition:

 Occurs when past project failures lead to a culture of fear, blame, and skepticism.

 Teams and organizations become risk-averse and hesitant to try new approaches like Agile.

Symptoms:

 Developers don’t trust new methods.

 Managers demand heavy documentation and sign-offs.

 Focus shifts to avoiding failure rather than delivering value.

 Preference for waterfall-style control to “prevent chaos.”

Root Causes:

 Repeated over-budget or delayed deliveries.

 Blame culture and punitive management styles.

 No clear postmortems or learning from failure.

Consequences:

 Agile adoption is met with cynicism and resistance.

 Innovation is stifled.

 Teams prefer to follow processes blindly rather than adapt.

Solution:

 Promote a blame-free culture of learning.

 Use retrospectives to understand and improve.

 Share small successes with Agile to rebuild confidence.

  Implement Agile gradually with coaching and mentoring.

3. Contractual Difficulties

Definition:

 Many organizations work under fixed-scope, fixed-cost contracts, which conflict with Agile’s iterative and adaptive
nature.

Problems Faced:

 Agile embraces changing requirements; fixed contracts resist them.

 Clients demand detailed specs upfront, limiting flexibility.

 Legal teams often write contracts based on waterfall assumptions.

 Vendors struggle to get paid for iterative delivery or change requests.

Why This Is an Obstacle:

 Agile thrives on customer collaboration over contract negotiation (Agile Manifesto principle).

 Fixed contracts force rigid planning, defeating Agile adaptability.

Solutions:

 Use Agile-friendly contract types, like:

o Time and materials contracts with change budgets.

o Incremental delivery contracts based on user stories/features.

o Rolling-wave planning with scope flexibility.

 Involve legal and procurement teams in Agile education.

4. Familiarity with Agility

Definition:

 Lack of understanding, experience, or training in Agile methods among team members and stakeholders.

Common Issues:

 Teams misunderstand Agile as "no planning" or "no documentation".

 Poor implementation of Agile ceremonies like daily stand-ups or retrospectives.

 Stakeholders expect waterfall-like predictability in an Agile environment.

 Inconsistent terminology and practices across teams.

Consequences:

 Agile becomes misapplied or superficial.

 Team morale and productivity drop due to confusion.

 Projects drift from Agile principles, causing hybrid messes.

How to Improve Familiarity:

 Conduct formal Agile training for all roles (Scrum Master, Product Owner, Dev team).

 Hire or assign Agile coaches or mentors.

 Practice continuous learning through workshops and Agile meetups.

 Share success stories from Agile teams within the organization.

Agile Transformation Faces Real-World Challenges:

Obstacle Root Problem Remedy

Management Intransigence Fear of losing control Agile awareness, involvement, coaching

Failed Project Syndrome Fear and cynicism from past failures Culture shift, small wins, retrospectives

Contractual Difficulties Legal/financial rigidity Use Agile contracts, educate legal teams

Familiarity with Agility Lack of knowledge or poor implementation Training, coaching, iterative improvements

Successful Agile adoption is not just about changing processes — it's about changing mindsets across all levels of the
organization.