📘 Agile Development

3.1 Agile Development – What is Agility?

Definition of Agility
 Agility in software development means the ability to respond quickly and
effectively to change.
 It emphasizes:
o Rapid delivery of working software.
o Flexibility in accommodating evolving requirements.
o Continuous communication with stakeholders.
Key Idea: Agility is not just about speed; it’s about adapting while maintaining quality.

Characteristics of Agile Teams / Processes

Agile teams follow certain characteristics that make them different from traditional teams:
1. Incremental Delivery
o Deliver software in small increments, each providing some usable functionality.
2. Embrace Change
o Instead of resisting requirement changes, teams welcome change and adjust
their plans.
3. Simplicity
o Focus on doing only what is necessary.
o Avoid over-engineering or creating excessive documentation.
4. Collaboration and Communication
o Heavy reliance on face-to-face communication (team members and
stakeholders).
o Customers and developers work closely throughout the project.
5. Focus on People, Not Processes
o The skill, creativity, and teamwork of people are more valuable than rigid
processes.
6. Working Software as the Primary Measure of Progress
o Progress is judged not by documents produced but by actual working features
delivered.

Key Points of Agility in Practice

Agility in practice means:
  Adaptability: When requirements shift, the team adjusts quickly.
 Customer Value: Focus on delivering features that give immediate business value.
 Iterative Development: Frequent short iterations instead of one long cycle.
 Close Collaboration: Developers and customers make decisions together.
 Sustainable Pace: Teams avoid burnout by working at a steady rhythm.
Example: In a banking software project, if the client changes the interest calculation
method mid-project, an agile team can reprioritize and deliver that feature in the next short
iteration instead of waiting until the end.

Agility vs. Conventional (Prescriptive) Methods

Aspect Conventional (Waterfall, etc.) Agile Approach

Change Handling Change is seen as a problem Change is welcomed and expected

Delivered in small, frequent

Delivery Delivered at the end of project
increments

Customer Limited after requirements Continuous, throughout the

Involvement phase project

Process, documents, strict People, collaboration, working

Focus
phases software

Low – fixed plan and design up High – plans evolve as project

Flexibility
front evolves

Principle of “Welcoming Change”

 Traditional methods try to freeze requirements early.
 Agile methods assume that requirements will evolve.
 Agility accepts that the business environment changes quickly:
o Competitors introduce new features.
o Customer priorities shift.
o Technology evolves.
Agility = Turning change into a competitive advantage.

Example: An e-commerce site may need to quickly add support for a new payment
gateway (like UPI) because customers demand it. An agile process can deliver this in a short
sprint.
Summary
 Agility = ability to adapt quickly to change while delivering quality software.
 Agile processes are incremental, collaborative, simple, and customer-focused.
 Agile teams welcome requirement changes and treat them as opportunities to add
value.
 Main difference: Conventional models resist change; Agile embraces it.
3.2 Agility and the Cost of Change

Traditional View of Cost of Change

 In prescriptive (traditional) process models like Waterfall, the cost of change grows
dramatically as the project progresses.
 This is often shown as a curve rising steeply:
o Small at the beginning (requirements).
o Larger during design.
o Very high during coding, testing, or after deployment.
Why?
 Because requirements are assumed to be “frozen” early.
 A change later often requires redoing requirements, redesigning, recoding, and
retesting.
 Example: Discovering a missing requirement during testing can mean rewriting major
portions of code → very costly.

The Agile View of Cost of Change

 Agile methods challenge this traditional curve.
 Agile processes are designed so that the cost of change remains relatively flat
throughout the project.
 Key reason: Agile delivers software in increments and encourages continuous
feedback.
This means that:
 Even if requirements change late, it’s still manageable.
 Small iterations and refactoring reduce rework.
 Automated tests and continuous integration catch problems early.

Why the Cost Remains Flat in Agile

Agility uses practices that control the rising cost of change:
1. Incremental Development
o Small releases delivered frequently.
o Change affects only the current or next increment, not the entire system.
2. Refactoring
o Ongoing restructuring of code to improve design without changing behavior.
o Keeps the system flexible and easier to modify.
3. Continuous Customer Feedback
o Stakeholders review increments regularly.
o Changes are spotted early, not at the end.
4. Automated Testing
o Regression tests ensure that new changes don’t break existing features.
o Reduces risk of costly late defects.
5. Collaborative Approach
o Developers, testers, and customers work together to anticipate and integrate
changes.

Diagram (Conceptual)
In the book, Pressman shows a comparison diagram:
 Prescriptive Process → Cost of change curve rises steeply.
 Agile Process → Curve is flatter, meaning cost is more stable even later in the project.

Key Takeaways
 Traditional methods: Late changes = very expensive.
  Agile methods: Late changes = manageable, because of incremental development,
refactoring, and feedback.
 Agility makes it possible to welcome requirement changes, even in late project
stages, without losing control over cost and schedule.

Summary Table

Aspect Prescriptive Process Agile Process

Cost of change curve Rises steeply over time Flatter, relatively stable

When changes are

Low-cost only in early stages Low-cost throughout project
possible

Rigid phases; rework affects Incremental, feedback-driven,

Reason for rising cost
whole system refactoring

Practical implication Fear of late changes Welcoming late changes

3.3 What is an Agile Process?

An agile process is a software development approach that is guided by a set of core
assumptions about how software should be built. These assumptions differentiate agile from
conventional, prescriptive processes.

Four Key Assumptions of an Agile Process

It is difficult to predict requirements and design in advance

 In most software projects, especially in today’s dynamic business environment,
requirements change rapidly.
 Users may not know exactly what they want until they see a working system.
 Technology also evolves quickly.
 Therefore, trying to define all requirements and design details upfront (as in Waterfall)
is unrealistic.
Example: In an e-commerce system, the client may later want to add new payment
methods (like UPI or digital wallets) after the project has already begun.

A process that is plan-driven is risky and inflexible

 Traditional models (like Waterfall) rely on a detailed upfront plan.
 When changes occur, the plan quickly becomes outdated.
  Agile assumes that the process must be adaptive, not predictive.
 Planning is still important, but it is incremental and flexible, not rigid.
Example: Instead of planning 12 months of development in detail, an agile project might
plan for 2–4 weeks (a sprint), deliver results, and then re-plan.

Working software is the primary measure of progress

 Documents, charts, and reports do not guarantee real value.
 What matters most is delivering working software that provides functionality to the
customer.
 Agile focuses on short iterations that produce usable features.
Example: A demo of a working login system after 2 weeks is more valuable than a 50-page
design document.

Agile processes must be designed to accommodate change

 Change is not an exception; it is the norm.
 Requirements will evolve, priorities will shift, and customer needs will change.
 Agile processes build in mechanisms to handle and welcome change at any stage.
Example: In agile, if a customer wants to change the user interface layout in the middle of
the project, the team can adjust it in the next iteration without derailing the whole project.

Summary Table – Key Assumptions

Assumption Agile Belief Contrast with Traditional

Requirements & design cannot be fully Everything can be defined

Predictability
predicted upfront

Rigid upfront plan guides

Planning Plans must be adaptive & flexible
everything

Measured by documents &

Progress Measured by working software
milestones

Change Change is inevitable & welcome Change is disruptive & costly

So, an agile process is essentially adaptive, iterative, and customer-focused, built on

these four assumptions.
 3.3.1 Agility Principles
Agile development is guided by the Agile Manifesto, which defines 12 principles that every
agile team follows. These principles provide the philosophy and mindset of agility.

The 12 Principles of Agile Development

Satisfy the customer through early and continuous delivery

 The highest priority is to deliver valuable software frequently.
 Customers see progress early and give feedback.
Example: Delivering a working login feature in week 2 instead of waiting months.

Welcome changing requirements, even late in development

 Agile teams expect requirements to change.
 Change is viewed as an opportunity to improve the product.
Example: Adding a new reporting feature in the last month of development is still
accepted.

Deliver working software frequently

 Deliver in short time frames (usually 2–4 weeks).
 Each increment provides usable functionality.
Example: Sprint 1 delivers user login, Sprint 2 delivers profile update.

Business people and developers must work together daily

 Agile stresses close collaboration.
 Frequent interaction reduces misunderstandings and ensures alignment.
Example: A product owner sits with developers every day to clarify requirements.

Build projects around motivated individuals

 Trust the team to do the job well.
 Provide them with the right environment and support.
Example: An empowered agile team makes decisions without waiting for long approval
chains.

Face-to-face conversation is the best form of communication

 Written documents are useful, but face-to-face discussions are faster and clearer.
  Agile encourages co-located teams or frequent video calls.
Example: Instead of emailing long requirement lists, have a 15-minute stand-up meeting.

Working software is the primary measure of progress

 Progress = Features delivered that the customer can use.
 Not just documents, charts, or reports.
Example: A functional shopping cart is proof of progress, not a requirement spec.

Agile processes promote sustainable development

 Teams should work at a steady, consistent pace, not long overtime hours.
 Sustainable pace avoids burnout and maintains quality.
Example: Regular 40-hour weeks instead of exhausting “crunch time.”

Continuous attention to technical excellence and good design

 Quality code and solid design make it easier to adapt to change.
 Avoid “quick fixes” that cause problems later.
Example: Regular refactoring keeps code clean and flexible.

Simplicity – maximize the amount of work not done

 Do only what is essential.
 Avoid unnecessary complexity and features.
Example: Deliver only features that add customer value, not “nice-to-have” extras.

The best architectures, requirements, and designs emerge from self-organizing

teams
 Agile teams are self-directed and make their own technical decisions.
 Leadership is distributed, not top-down.
Example: Developers decide how to implement a feature, rather than waiting for a
manager.

At regular intervals, the team reflects on how to become more effective

 Agile teams hold retrospectives to discuss what worked and what didn’t.
 They then adapt their processes for improvement.
 Example: At the end of each sprint, the team identifies problems (e.g., poor
communication) and fixes them in the next sprint.

Summary Table of Agile Principles

# Principle Meaning

1 Customer satisfaction Deliver early & continuous value

2 Welcome change Accept and embrace evolving requirements

3 Frequent delivery Deliver increments regularly

4 Collaboration Business + developers work together daily

5 Motivated teams Build around trusted individuals

6 Face-to-face Best communication is direct

7 Working software Main measure of progress

8 Sustainable pace Maintain steady development speed

9 Technical excellence Focus on quality and design

10 Simplicity Do only what’s necessary

11 Self-organizing teams Teams decide their own methods

12 Reflection & adaptation Regularly improve processes

3.3.2 The Politics of Agile Development

Agile is not just a technical shift — it also introduces organizational and cultural change.
Moving from traditional methods to agile often faces political resistance inside companies.

Why Politics Comes into Play

1. Agile challenges traditional authority structures
o In prescriptive models, project managers and processes dominate.
o Agile shifts power to self-organizing teams, which may reduce managerial
control.
2. Documentation and control are reduced
o Traditional stakeholders (e.g., quality assurance, compliance, management) rely
heavily on documents and rigid plans.
o Agile values working software and collaboration more than paperwork.
o This may be seen as a loss of control by some groups.
3. Cultural shift
o Agile emphasizes trust, empowerment, and collaboration.
o In some organizations, culture may still favor command-and-control.
o This clash creates political tension.

Common Political Challenges

1. Management Resistance
o Managers may fear losing control when teams become self-organized.
o They may be uncomfortable with less documentation.
2. Stakeholder Misunderstanding
o Business stakeholders may think “agile” means “no discipline” or “no planning.”
3. Team Resistance
o Developers used to rigid structures may struggle with the freedom and
responsibility agile demands.
4. Compliance and Oversight
o In industries like banking, healthcare, or aerospace, strict compliance rules
require documentation, which may appear to conflict with agile values.

How to Manage the Politics of Agile

1. Educate Stakeholders
o Explain that agile is still disciplined — just different.
o Documentation exists, but it is lightweight and purposeful.
2. Demonstrate Early Wins
o Delivering working increments quickly helps prove agile’s value.
o Success stories reduce resistance.
3. Blend Agile with Existing Practices
o Some traditional practices (like compliance documentation) can coexist with
agile.
o Balance agility with organizational needs.
4. Promote Collaboration Across Levels
o Encourage managers, customers, and teams to work together.
o Build trust gradually.

Summary Table – Politics of Agile

Aspect Traditional View Agile View Political Issue

Centralized (managers Distributed (self- Managers feel loss of

Authority
control) organizing teams) power

Documentation Heavy, mandatory Lightweight, just enough QA/compliance worried

Culture Command-and-control Trust and collaboration Cultural resistance

Stakeholder Minimal after

Continuous involvement Misunderstandings
role requirements

Key Idea:
The politics of agile development revolve around organizational resistance to change. Agile
disrupts existing power structures, reduces reliance on documentation, and demands trust in
self-organizing teams.

3.3.3 Human Factors

Agile methods emphasize that people are more important than processes or tools.
The success of an agile project depends heavily on the human factors — the traits and
behaviors of the people involved.

Key Human Traits in Agile Development

Pressman highlights seven essential traits that agile teams and individuals must have:

Competence
 Team members must have the necessary technical and domain skills.
 Without competence, even the best agile practices will fail.
 Agile teams are usually cross-functional, so each member brings expertise.
Example: A team building an e-commerce app includes skilled backend developers,
frontend designers, testers, and business analysts.

Common Focus
 All team members must share the same goal: delivering valuable software.
 Personal preferences or hidden agendas must not override the project vision.
 Agile fosters alignment through daily meetings and shared backlogs.
 Example: Everyone in the team works toward finishing the “shopping cart feature,” not
just their isolated tasks.

Collaboration
 Agile thrives on teamwork and face-to-face communication.
 Collaboration happens not just within the development team but also with customers
and stakeholders.
 Team members support one another rather than working in isolation.
Example: A tester and developer pair up to resolve a defect immediately, instead of
blaming each other.

Decision-Making Ability
 Agile teams are self-organizing, meaning they must take responsibility for decisions.
 Delaying decisions or pushing them to management reduces agility.
 Teams must learn to make timely decisions with available information.
Example: The team decides during a sprint planning meeting how many features they
can commit to, without waiting for management approval.

Fuzzy Problem-Solving Ability

 Agile projects face uncertain and incomplete requirements.
 Teams must be comfortable working with ambiguity and refining solutions iteratively.
 They solve problems step by step, learning as they go.
Example: A client wants a “recommendation system” but is unclear on details. The team
starts with a simple version, then improves it over sprints.

Mutual Trust and Respect

 Agile teams cannot function without trust.
 Members must respect each other’s expertise and contributions.
 Trust also extends to customers, who must believe the team will deliver.
Example: Developers trust testers to ensure quality, and testers trust developers to fix
defects responsibly.

Self-Organization
 Agile teams are expected to organize their own work.
  There is no heavy top-down management.
 Teams distribute tasks, plan sprints, and resolve issues themselves.
Example: In Scrum, the team decides who takes which task from the sprint backlog
without the project manager assigning work.

Summary Table – Human Factors in Agile

Trait Meaning

Competence Team members must have necessary skills

Common Focus Everyone works toward the same project goal

Collaboration Team + customer work closely together

Decision Making Teams make timely decisions themselves

Fuzzy Problem Solving Comfortable with uncertainty and iteration

Trust & Respect Mutual trust among team members and stakeholders

Self-Organization Teams manage and organize their own work

Key Idea:
Agile development succeeds because of people, not just methods. A team with these seven
traits can adapt, collaborate, and deliver effectively in a constantly changing environment.

3.4 Extreme Programming (XP)

Extreme Programming (XP) is one of the most widely used agile methods.
It was introduced by Kent Beck in the late 1990s and is known for its emphasis on
communication, simplicity, feedback, courage, and respect.
XP pushes certain good practices in software development to the “extreme”, hence the
name.
For example:
 Code reviews → In XP, code is reviewed all the time (via pair programming).
 Testing → In XP, testing is done continuously.
 Integration → In XP, code is integrated several times a day.

3.4.1 XP Values
Extreme Programming is based on five fundamental values that guide how teams work:
1. Communication
 o Constant, open communication between team members and with the
customer.
o Pair programming and on-site customer presence strengthen this value.
2. Simplicity
o Always implement the simplest solution that works.
o Avoid unnecessary complexity or over-engineering.
3. Feedback
o Continuous feedback from:
 The system (through tests),
 The customer (through reviews),
 The team (through collaboration).
o Feedback loops drive improvement.
4. Courage
o Courage to make necessary changes, even if it means reworking code.
o Courage to discard poor solutions, embrace refactoring, and adapt to evolving
requirements.
5. Respect
o Team members respect each other’s skills, contributions, and responsibilities.
o Builds trust and healthy collaboration within the team.

3.4.2 The XP Process

Extreme Programming is not just values; it defines a development process that guides how
work is done. The XP process emphasizes short iterations, close customer collaboration,
and disciplined practices.
 Key Elements of the XP Process
1. Planning
o Uses the Planning Game where customers define user stories (features) and
the development team estimates effort.
o The result is a prioritized set of stories for the next short release.
2. Design
o Design is kept as simple as possible.
o A system metaphor may be used to provide a shared story that guides the
architecture.
o CRC cards and informal modeling help in communicating design ideas.
3. Coding
o Pair programming is the central practice.
o Collective code ownership ensures anyone can improve any part of the system.
o Coding standards are followed consistently.
4. Testing
o Tests are written before the code (Test-Driven Development).
o Automated unit tests verify functionality continuously.
o Customers provide acceptance tests to validate user stories.
5. Small Releases
o Software is delivered in frequent, small increments, each adding useful
functionality.
o This ensures the customer always has a working system.
6. Continuous Integration
o Code is integrated and built multiple times a day.
o Prevents integration surprises and ensures stability.
7. Sustainable Pace (40-Hour Week)
o Workload is kept at a consistent, healthy pace.
o Overtime is discouraged to maintain quality and morale.

Summary – XP Process

Phase/Activity Key Practice

Planning Planning Game, user stories, prioritization

Design Simple design, metaphor, CRC cards

Phase/Activity Key Practice

Coding Pair programming, coding standards, collective ownership

Testing Test-driven development, unit & acceptance tests

Release Small, frequent releases

Integration Continuous integration

Workload Sustainable pace

3.4.4 The XP Debate

Extreme Programming (XP) has gained wide popularity, but it also sparked debates in the
software engineering community.
Some see XP as revolutionary and highly effective, while others criticize it as risky or
incomplete.

The XP Debate – Criticisms

Critics of XP argue that:
1. Requirements Volatility
o Since XP encourages embracing change, it may lead to unstable
requirements that keep shifting.
o This makes it hard to maintain control over the project scope.
2. Conflicting Customer Needs
o Having a single on-site customer representative cannot always capture the
needs of multiple stakeholders.
o This may result in conflicting or incomplete requirements.
3. Requirements Are Expressed Informally
o XP relies on user stories, which are informal.
o Critics argue that without formal requirements, misunderstandings and gaps
may occur.
4. Lack of Formal Design
o XP promotes simple design and refactoring instead of heavy upfront design.
o Critics believe this can cause architectural weaknesses in larger or long-term
projects.

3.5 Other Agile Process Models

1. 3.5.1 Scrum
 2. 3.5.2 Dynamic Systems Development Method (DSDM)
3. 3.5.3 Adaptive Software Development (ASD)
4. 3.5.4 Crystal
5. 3.5.5 Feature-Driven Development (FDD)
6. 3.5.6 Agile Modeling (AM)
7. 3.5.7 Agile Unified Process (AUP)
8. 3.5.8 Other Agile Methods

3.5.1 Adaptive Software Development (ASD)

Adaptive Software Development (ASD), introduced by Jim Highsmith, is an agile process
model that emphasizes adaptation over prediction.
It recognizes that software projects operate in environments of uncertainty and change, so
the process must be flexible and learning-oriented.

Key Philosophy of ASD

 Traditional processes (like Waterfall) assume requirements can be predicted early.
 ASD rejects this assumption and instead focuses on continuous adaptation.
 It replaces the idea of a rigid plan with a dynamic cycle of learning and
collaboration.

The ASD Development Cycle

ASD is structured around a three-phase cycle:
1. Speculate
o Instead of fixed planning, ASD encourages speculation.
o Teams create a mission statement and define project goals.
o Plans are made at a high level but treated as tentative and adjustable.
o The focus is on exploration and embracing uncertainty.
2. Collaborate
o Collaboration among developers, customers, and stakeholders is central.
o Since requirements are uncertain, collaboration ensures continuous
alignment.
o Team members work closely together, sharing responsibility for success.
3. Learn
o ASD emphasizes learning through iteration.
o After each cycle, the team reflects on results, gathers feedback, and adjusts.
o Failures are treated as learning opportunities.
 Practices of ASD
 Iterative Development: Short cycles of delivery and review.
 Risk-Driven Approach: High-risk features are addressed early.
 Change-Tolerant: Assumes that requirements will evolve.
 Timeboxing: Work is constrained within fixed short time periods.
 Focus on Mission, Not Tasks: Encourages teams to focus on business objectives, not
just completing task lists.

Example
Imagine building a mobile banking app:
 In the Speculate phase, the team outlines goals like “Enable customers to view
account balances.”
 In the Collaborate phase, developers, testers, and banking staff work together to
refine the idea.
 In the Learn phase, feedback from an early prototype leads to adding fingerprint login
for security.

Summary

Phase Meaning

Speculate Create high-level mission and goals; flexible plans

Collaborate Work closely with team & stakeholders

Learn Reflect, adapt, and improve through iteration

 Key Idea:
ASD focuses on adaptation, collaboration, and continuous learning instead of rigid plans. It
is well-suited for environments with high uncertainty and rapid change.

3.5.2 Scrum
Scrum is one of the most widely used agile process models.
It emphasizes iterative development, self-organizing teams, and frequent delivery of
working software.
The name “Scrum” is borrowed from rugby, where teamwork and quick adaptation are key.

Core Principles of Scrum

1. Development is done in small increments called Sprints.
2. Teams are self-organizing and responsible for their own work.
3. Customer collaboration is continuous, with regular feedback.
4. Transparency and inspection allow for quick identification of problems.

Scrum Framework
Scrum defines a framework of roles, activities, and artifacts.
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?

1. Scrum Roles
 Product Owner
o Represents the customer.
o Defines and prioritizes features in the Product Backlog.
 Scrum Master
o Facilitator and coach.
o Ensures Scrum practices are followed, removes obstacles.
 Scrum Team
o Cross-functional group of developers, testers, designers.
o Self-organizing, typically 5–9 members.
2. Scrum Activities (Ceremonies)
 Sprint Planning
o At the start of each sprint, the team selects items from the backlog to
implement.
 Daily Scrum (Stand-up meeting)
o Short (15-minute) daily meeting to synchronize progress and identify issues.
 Sprint Review
o Held at the end of a sprint. The team demonstrates completed work to
stakeholders.
 Sprint Retrospective
o Team reflects on what went well, what can be improved, and adjusts
accordingly.

3. Scrum Artifacts
 Product Backlog
o Ordered list of all desired features, requirements, and fixes.
o Continuously updated by the Product Owner.
 Sprint Backlog
o Subset of the Product Backlog items selected for the current sprint.
 Increment
o The working, tested software delivered at the end of each sprint.

Scrum Cycle Diagram

 Example
Suppose a team is developing an e-learning platform:
 Product Owner lists features: login, quizzes, progress tracking.
 In Sprint 1, the team commits to “Login + Profile setup.”
 They hold daily scrums, track progress, and deliver a working login system at the end.
 Stakeholders review, give feedback, and features are reprioritized for the next sprint.

Summary

Aspect Scrum Approach

Work Unit Sprint (2–4 weeks)

Roles Product Owner, Scrum Master, Scrum Team

Artifacts Product Backlog, Sprint Backlog, Increment

Meetings Planning, Daily Scrum, Review, Retrospective

Focus Iteration, collaboration, self-organization

Key Idea:
Scrum enables frequent delivery, adaptability, and continuous improvement. It works well
in dynamic environments with changing requirements.

3.5.3 Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM) is an agile process framework that
originated in the 1990s in the UK.
It was developed as a formalized, structured approach to rapid application development
(RAD).
The goal of DSDM is to deliver business solutions quickly and efficiently while maintaining
quality.

Key Principles of DSDM

DSDM is based on eight guiding principles:
1. Active User Involvement – Users must be engaged throughout the project.
2. Empowered Teams – Teams must be given the authority to make decisions.
3. Frequent Delivery – Deliver working increments regularly.
 4. Fitness for Business Purpose – Deliver what is needed, not necessarily everything
possible.
5. Iterative and Incremental Development – Develop in cycles, building up solutions
gradually.
6. Reversible Changes – Changes should be reversible if they don’t work out.
7. Integrated Testing – Testing is built into the development lifecycle.
8. Collaboration and Cooperation – Encourage communication between stakeholders.

DSDM Process
DSDM organizes development into phases:
1. Feasibility Study – Quick analysis of business case and whether DSDM is suitable.
2. Business Study – Understanding business context and objectives.
3. Functional Model Iteration – Build prototypes and refine functions.
4. Design and Build Iteration – Develop the actual system with continuous testing.
5. Implementation – Deploy and deliver the solution to the users.

Practices in DSDM
 Timeboxing – Each iteration is carried out within a fixed time.
 Prioritization (MoSCoW rules):
o Must have
o Should have
o Could have
o Won’t have this time
 Prototyping – Building quick models for feedback.
 Continuous User Involvement – Ensures system meets business needs.

Example
Suppose a company wants a customer support portal:
 In the feasibility study, the team decides DSDM is appropriate.
 In the business study, they identify goals: ticketing, FAQs, live chat.
 Through functional model iterations, prototypes for ticketing are created.
 With design and build iterations, the live system is developed and tested.
 Finally, in implementation, the portal goes live for customers.

Summary
Aspect DSDM Approach

Philosophy Rapid, business-focused solution delivery

Principles 8 guiding principles (active users, frequent delivery, reversible changes, etc.)

Feasibility → Business Study → Functional Model Iteration → Design/Build

Phases
Iteration → Implementation

Practices Timeboxing, Prototyping, MoSCoW prioritization

Focus Delivering business value quickly

Key Idea:
DSDM provides a disciplined agile framework with strong user involvement, timeboxing,
and prioritization to ensure business-focused outcomes.

3.5.4 Crystal
Crystal is a family of agile methodologies created by Alistair Cockburn.
It is based on the idea that different projects require different strategies, depending on
factors like team size and system criticality.
Unlike rigid process models, Crystal emphasizes people, interaction, and communication
over tools and processes.

Key Characteristics of Crystal

1. Family of Methods
o Crystal isn’t a single method; it includes variations like Crystal Clear, Crystal
Orange, Crystal Red, etc.
o Each variation is suited to projects of different sizes and criticality levels.
2. People-Centric
o The most important property of a Crystal methodology is people and
communication.
o “People trump processes” — effective teamwork is prioritized.
3. Adaptive
o Crystal encourages teams to adapt methods to their context instead of
following rigid rules.
4. Simplicity
o The processes are intentionally lightweight, focusing only on what adds value.
 Crystal Method Variants
Crystal defines methods by colors, which indicate project size and system criticality:
 Crystal Clear → For very small teams (up to 6 members).
 Crystal Yellow, Orange, Red → For progressively larger teams (20, 50, 100+).
 Criticality Levels →
o Comfort (C) – Loss is only inconvenience.
o Discretionary Money (D) – Loss involves some financial impact.
o Essential Money (E) – Large financial impact.
o Life (L) – Safety-critical, life-threatening if failed.

Practices in Crystal
 Frequent Delivery – Deliver usable increments frequently.
 Reflective Improvement – Teams hold regular reflection workshops.
 Close Communication – Face-to-face communication preferred.
 Personal Safety – Team members must feel safe to raise issues.
 Focus on Quality – Developers are encouraged to keep quality visible and high.

Example
Suppose a startup is developing a chat application with a 5-member team.
 They use Crystal Clear since the team is small.
 They emphasize frequent delivery (every 2 weeks).
 Daily face-to-face communication ensures alignment.
 After each iteration, they hold a reflection meeting to improve teamwork.

Summary

Aspect Crystal Approach

Philosophy People and communication are more important than process

Variants Crystal Clear (small teams), Crystal Orange/Red (larger)

Criticality Comfort, Money, Essential Money, Life

Practices Frequent delivery, reflective improvement, communication

Focus Adapt methods to project context

 Key Idea:
Crystal is a flexible family of agile methods that tailors practices based on project size and
criticality. Its main belief: effective people and communication matter more than rigid
processes.

3.5.5 Feature-Driven Development (FDD)

Feature-Driven Development (FDD) is an agile process model that focuses on designing
and building features that are valuable to the client.
It was introduced by Peter Coad and Jeff De Luca in the late 1990s.
The central idea: "Build software by implementing features that are meaningful to the
customer."

Key Characteristics of FDD

1. Feature-Centric
o Development is organized around “features” (client-valued functions).
o Example: “Calculate the monthly interest for a savings account.”
2. Model-Driven
o FDD begins with domain object modeling before coding starts.
3. Short Iterations
o Each feature is small enough to be developed in 2 days – 2 weeks.
4. Team-Oriented
o Work is done in feature teams (small, cross-functional groups).

The Five FDD Process Steps

FDD defines five main activities:
1. Develop an Overall Model
o High-level domain object model of the system is created.
o Helps teams understand the business context.
2. Build a Features List
o Break system functionality into a hierarchical list of features.
o Features are small, client-valued functions.
3. Plan by Feature
o Prioritize and assign features to developers/teams.
4. Design by Feature
o Detailed design is created for each feature (class diagrams, sequence
diagrams).
5. Build by Feature
o Code, test, and integrate the feature into the system.

Example
Suppose we are developing an online shopping website:
 Overall Model: Define domain objects (Customer, Product, Cart, Order).
 Features List: “Add product to cart,” “Calculate total price,” “Process payment.”
 Plan by Feature: Assign “Process payment” to one feature team, “Add product to cart”
to another.
 Design by Feature: Create class and sequence diagrams for payment processing.
 Build by Feature: Implement, test, and integrate payment feature into the system.

Summary

Step Description

1. Develop Overall Model Build domain object model

2. Build Features List Break into small, client-valued features

3. Plan by Feature Assign features to teams

4. Design by Feature Create class/sequence diagrams for each feature

5. Build by Feature Code, test, and integrate feature

 Key Idea:
FDD combines modeling and iterative development, ensuring that each increment delivers
real customer value in the form of features.

3.5.6 Lean Software Development (LSD)

Lean Software Development (LSD) adapts the principles of lean manufacturing (Toyota
Production System) to software engineering.
It emphasizes efficiency, elimination of waste, and delivering value quickly.

Core Principles of LSD

The method is guided by seven principles:
1. Eliminate Waste
o Waste = anything that does not add value to the customer.
o Examples: partially done work, unnecessary features, waiting time, hand-offs.
2. Build Quality In
o Quality is not tested in later, it is built into the process from the start.
o Practices like automated testing, continuous integration, and refactoring
ensure quality.
3. Create Knowledge
o Development is a process of learning.
o Feedback loops (short iterations, retrospectives) spread knowledge across the
team.
4. Defer Commitment
o Delay irreversible decisions until they are absolutely necessary.
o Allows for flexibility as requirements evolve.
5. Deliver Fast
o Deliver value quickly through short cycles and frequent releases.
o Increases customer satisfaction and reduces risks.
6. Respect People
o Teams must be empowered and trusted.
o Collaboration and responsibility are shared.
7. Optimize the Whole
o Focus on improving the entire value stream (end-to-end flow), not just
individual tasks.
 LSD Practices
 Small batch sizes → Work is divided into smaller, manageable parts.
 Kanban boards → Visualize workflow and identify bottlenecks.
 Continuous improvement (Kaizen) → Teams regularly reflect and improve processes.
 Set-based development → Consider multiple design alternatives before finalizing.

Example
Suppose a company is building a ride-hailing app:
 They eliminate waste by avoiding unnecessary features (e.g., custom skins for cars).
 Build quality in with automated testing of ride-matching algorithms.
 Deliver fast by releasing a basic version with booking and payment within weeks.
 Respect people by empowering developers to make design choices.
 Optimize the whole by looking at the full user journey (from booking → ride →
payment → rating).

Summary

Principle Meaning

Eliminate Waste Remove non-value-adding work

Build Quality In Ensure quality from the beginning

Create Knowledge Learn through feedback loops

Defer Commitment Delay irreversible decisions until necessary

Deliver Fast Release working software quickly

Respect People Empower teams, encourage collaboration

Optimize the Whole Improve the entire value stream, not isolated steps

Key Idea:
Lean Software Development focuses on efficiency, fast delivery, and continuous learning,
ensuring maximum customer value with minimum waste.

3.5.7 Agile Modeling (AM)

Agile Modeling (AM) is a methodology introduced by Scott Ambler that focuses on effective
modeling practices within an agile development process.
It provides guidance on how to model software systems in a lightweight, flexible, and
collaborative way.

Philosophy of Agile Modeling

 Traditional software engineering often emphasizes heavy, detailed documentation.
 AM takes the opposite view: “Model only what is necessary, when it is necessary.”
 The purpose of modeling is to understand, communicate, and explore ideas, not to
create large documents.

Core Principles of Agile Modeling

1. Model with a Purpose
o Every model must have a clear reason (e.g., to explore, communicate, or
document).
o Avoid modeling for the sake of paperwork.
2. Use Multiple Models
o No single model is sufficient.
o Use different models (use case diagrams, class diagrams, activity diagrams)
depending on need.
3. Travel Light
o Keep models as simple and lightweight as possible.
o Only document what is truly valuable.
4. Content Is More Important than Representation
o The ideas in the model matter more than the form or notation.
o A whiteboard sketch may be just as useful as a detailed UML diagram.
5. Know the Models and Tools You Use
o Teams should be skilled in the notations and tools they choose.
6. Adapt Locally
o Practices must be tailored to the local project environment.

Practices in Agile Modeling

 Collaborative Modeling → Stakeholders and developers work together.
 Just-in-Time Modeling → Create models only when they’re needed.
 Incremental Modeling → Start small and evolve models as the project progresses.
 Executable Models → Where possible, models are tied to working code (e.g., UML +
code generation).
 Example
Suppose a team is designing a healthcare appointment booking system:
 Instead of producing a 200-page requirement specification, they quickly draw a use
case diagram showing “Book Appointment,” “Cancel Appointment,” “View Records.”
 For database design, they sketch an entity-relationship model on a whiteboard.
 Later, as implementation progresses, they refine only the parts that are unclear.

Summary

Aspect Agile Modeling Approach

Philosophy Lightweight, flexible modeling

Key Principles Model with purpose, multiple models, travel light

Focus Understanding & communication, not paperwork

Practices Collaborative, just-in-time, incremental modeling

Output Diagrams/sketches that directly support development

Key Idea:
Agile Modeling encourages simple, purposeful, and collaborative modeling — models are
tools for thinking and communicating, not heavy documentation.

3.5.8 Agile Unified Process (AUP)

The Agile Unified Process (AUP) is a simplified, agile version of the Rational Unified
Process (RUP), introduced by Scott Ambler.
It retains the core structure of RUP but adapts it to align with agile principles such as
simplicity, adaptability, and iterative delivery.

Philosophy of AUP
 RUP is often criticized for being heavyweight and documentation-driven.
 AUP makes it lighter and more agile, while still providing discipline and structure.
 The focus is on:
o Simplicity → minimize bureaucracy.
o Agility → embrace change, deliver incrementally.
o Discipline → structured phases for large/complex systems.
 AUP Phases
AUP retains RUP’s four phases, but applies them in an agile way:
1. Inception
o Define business case, scope, and feasibility.
o Establish initial requirements and architecture vision.
2. Elaboration
o Refine requirements.
o Establish the baseline architecture.
o Address high-risk elements.
3. Construction
o Iteratively develop the software in small increments.
o Apply agile practices like test-driven development and continuous integration.
4. Transition
o Deliver the system to users.
o Perform training, deployment, and final validation.

Practices of AUP
 Modeling → Lightweight modeling where useful (use cases, class diagrams).
 Implementation → Agile coding and testing practices.
 Testing → Continuous testing across all iterations.
 Deployment → Frequent releases and incremental delivery.
 Configuration Management → Keep track of versions, changes, and artifacts.
 Project Management → Agile planning with flexibility for changes.
 Environment Management → Provide necessary tools and support for the team.

Example
Suppose a government agency wants a tax-filing system:
 In Inception, the team defines the system’s vision (online filing, payment gateway).
 In Elaboration, high-level risks (security, scalability) are resolved and baseline
architecture built.
 In Construction, features like form filling, submission, and payment are developed in
short iterations.
 In Transition, the system is deployed in phases (pilot launch, then nationwide rollout).
 Summary

Aspect AUP Approach

Philosophy Lightweight, agile adaptation of RUP

Phases Inception → Elaboration → Construction → Transition

Practices Agile coding, continuous testing, lightweight modeling

Focus Balance of agility and structure for complex projects

Key Idea:
The Agile Unified Process blends the discipline of RUP with the flexibility of agile, making it
suitable for organizations that want agility but also require structured phases.

3.6 A Tool Set for the Agile Process

Agile development is not just about practices — it also benefits greatly from a set of
supporting tools.
These tools help agile teams manage work, communicate effectively, and deliver software
efficiently.
Let’s identify a collection of tool categories that support agility:

Agile Tool Categories

1. Project Management Tools
o Support backlog management, sprint planning, task tracking, and burndown
charts.
o Example functions: create product backlogs, assign features to sprints,
visualize progress.
o Examples: Jira, Rally, VersionOne.
2. Configuration Management Tools
o Track different versions of code, manage changes, and coordinate team
contributions.
o Essential for agile teams working with continuous integration.
o Examples: Git, Subversion, Mercurial.
3. Design and Modeling Tools
o Enable lightweight modeling (UML diagrams, sketches, prototypes).
o Support collaboration and help communicate ideas visually.
o Examples: Enterprise Architect, Visual Paradigm, whiteboard-based modeling.
 4. Refactoring Tools
o Automate the process of restructuring code without changing its behavior.
o Maintain clean, simple, and efficient code — a key XP/Agile practice.
o Examples: IDE refactoring support (Eclipse, IntelliJ, Visual Studio).
5. Testing Tools
o Automated unit testing, regression testing, and test coverage analysis.
o Essential for test-driven development (TDD) and continuous feedback.
o Examples: JUnit, NUnit, Selenium, TestNG.
6. Metrics and Tracking Tools
o Collect data on velocity, code coverage, defect density, and team productivity.
o Provide real-time insights for retrospectives and process improvement.
o Examples: SonarQube, Burndown/Burnup charts, Agile dashboards.
7. Collaboration and Communication Tools
o Facilitate continuous interaction among distributed teams.
o Includes chat, video conferencing, wikis, and document-sharing platforms.
o Examples: Slack, Microsoft Teams, Confluence, Google Workspace.

Example of Agile Tool Integration

Imagine a team building an online food delivery system:
 Jira → manages product backlog and sprint planning.
 GitHub → source control with versioning.
 IntelliJ → refactoring support during coding.
 JUnit → automated unit testing.
 SonarQube → tracks code quality metrics.
 Slack → keeps developers, testers, and product owners in sync.

Summary

Tool Category Purpose in Agile Examples

Project Management Manage backlogs, sprints, tasks Jira, Rally, VersionOne

Configuration Version control and change

Git, SVN, Mercurial
Management management

Design & Modeling Lightweight UML, prototyping Visual Paradigm, EA

Tool Category Purpose in Agile Examples

Improve code structure without

Refactoring IntelliJ, Eclipse, VS
altering behavior

Testing Automated unit/regression tests JUnit, NUnit, Selenium

SonarQube,
Metrics & Tracking Track velocity, coverage, defects
dashboards

Collaboration & Enable team interaction and Slack, MS Teams,

Communication knowledge sharing Confluence

Key Idea:
Agile development benefits from a tool ecosystem that supports planning, coding, testing,
and collaboration. These tools enable teams to respond quickly to change, ensure quality,
and sustain continuous delivery.