Ex.

no 3 Study the Agile Process Examples

Date: a) SCRUM
b) FDD
c) Lean software development
d) XP

Aim:

To study and understand the working of different Agile Process models:

a) SCRUM
b) Feature Driven Development (FDD)
c) Lean Software Development
d) Extreme Programming (XP)

Objectives:

1. Understand key principles and practices of each Agile process.

2. Compare workflows and artifacts produced by different methods.
3. Perform simulation or modeling of Agile iterations.
4. Identify use cases or suitable projects for each methodology.

Tools/Software Required:

 Whiteboard / Sticky Notes / Kanban Board (physical or digital)

 JIRA / Trello / Asana (for SCRUM board simulation)
 IDE (e.g., Visual Studio Code, Eclipse)
 Git/GitHub (for XP practices like CI)
 Browser / PPT tools (for presenting FDD models)

a) SCRUM
What is SCRUM?

SCRUM is an Agile framework used for managing product development and software
projects. It divides work into small, manageable chunks called sprints, enabling teams to
deliver working software iteratively and incrementally.

Key elements include sprint planning, daily scrums, sprint reviews, and sprint retrospectives.

Core Components of SCRUM

SCRUM Roles:

1. Product Owner (PO)

o Represents the customer and stakeholders
o Creates and manages the Product Backlog
o Prioritizes user stories based on business value
2. Scrum Master (SM)
o Facilitates the SCRUM process
o Ensures team follows Agile practices
 oRemoves blockers and shields the team from distractions
3. Development Team
o Cross-functional team (developers, testers, designers)
o Responsible for delivering increments of working software
o Self-organizing and accountable
4. SCRUM Events:

Event Purpose
Sprint 1–4 week iteration to deliver a working product increment
Sprint Planning Define what can be delivered in the Sprint and how it will be done
Daily Scrum 15-minute daily stand-up for progress tracking and obstacle removal
Sprint Review Demo the product increment to stakeholders and gather feedback
Sprint Retrospective Discuss what went well, what didn’t, and how to improve in the next Sprint

SCRUM Artifacts:

Artifact Description
Product Backlog A prioritized list of features, enhancements, and bug fixes (user stories)
Sprint Backlog Selected user stories/tasks for a sprint
Increment The working software delivered at the end of a sprint
Definition of Done Criteria to determine if a user story is complete

Example: E-Commerce Shopping Cart

Let’s walk through an example of using SCRUM to develop a shopping cart module in an e-
commerce app.

Step 1: Product Backlog Creation

The Product Owner gathers user stories such as:

ID User Story Priority

US01 As a user, I want to add items to a shopping cart. High

US02 As a user, I want to view items in my cart. High

US03 As a user, I want to remove items from the cart. Medium

US04 As a user, I want to update item quantities. Medium

US05 As a user, I want to checkout securely using a payment gateway. High

✅ Step 2: Sprint Planning (Sprint 1 – 2 Weeks)

The team selects 3 user stories for Sprint 1:

  US01: Add items to cart
 US02: View cart
 US03: Remove items from cart

Sprint Goal: “Develop basic shopping cart functionality.”

✅ Step 3: Daily Scrums

Each day, the team answers:

1. What did I do yesterday?

2. What will I do today?
3. Any blockers?

✅ Step 4: Development

The development team builds the features using test-driven development (TDD):

 Write test cases before coding

 Implement feature
 Refactor as needed

✅ Step 5: Sprint Review

At the end of Sprint 1, the team demonstrates:

 Adding items to cart

 Viewing cart items
 Removing items

Stakeholders provide feedback, e.g., "Allow adding multiple quantities."

✅ Step 6: Sprint Retrospective

The team reflects:

 👍 What went well: Clear backlog, good teamwork

 👎 What didn’t: API integration delays
 🔄 Action: Start backend stubs earlier in Sprint 2

Benefits of SCRUM in This Example

Benefit How It Helped

Early feedback Stakeholders saw a demo after 2 weeks

Focused team efforts Sprint goal kept tasks aligned

Flexibility New requirements like “multiple quantities” were easily added

Transparency Daily stand-ups ensured visibility

 B) Feature-Driven Development
Feature-Driven Development (FDD) is a model-driven, short-iteration Agile methodology
focused on designing and building features. It emphasizes planning, design, and code
ownership, making it ideal for large-scale software systems.
Key Concepts in FDD
Element Description

Focus Delivering tangible, working software features frequently

Iteration Unit Features (not time-boxed like SCRUM sprints)

Feature A small, client-valued function deliverable in 2–10 days

Architecture First High-level modeling and domain design done before implementation

Documentation Lightweight but present; model and feature lists are key

The 5 Core Processes of FDD

Step Description

1. Develop an Overall Analyze the domain and create a high-level object model using UML or class
Model diagrams.

Identify and group features based on the model. Each feature should be small and
2. Build a Feature List
deliverable quickly.

3. Plan by Feature Assign ownership and prioritize features based on business needs.

4. Design by Feature Design each feature before coding. Includes sequence diagrams and inspections.

Code, test, and integrate the feature into the build. Includes unit testing and code
5. Build by Feature inspections.

Roles in FDD
Role Responsibility

Project Manager Oversees delivery and timelines

Chief Architect Designs overall architecture

Development Manager Manages development team

Chief Programmer Coordinates feature design and implementation

 Role Responsibility

Class Owner Owns design/code of specific classes

Domain Expert Provides business logic and feature validation

FDD Artifacts
Artifact Description

High-level UML m
Overall Model
odel

Feature List Hierarchical list of features

Feature Plan Scheduling of feature development

Design Package Diagrams and documents per feature

Codebase Source code updated iteratively

Example – Online Library System

Step 1: Develop an Overall Model

 Domain modeling identifies entities: Book, User, Loan, Reservation

Step 2: Build a Feature List

Grouped into functional areas:

 User Management
o Register a new user
o Update user profile
 Book Management
o Add a new book to the catalog
o Search for books
 Loan Process
o Issue a book to a user
o Return a book

Step 3: Plan by Feature

 Assign Search for books to Dev A

 Assign Issue a book to Dev B
 Schedule based on dependencies and business priority

Step 4: Design by Feature

 For Issue a book:

 o Create sequence diagram showing interaction between User, Loan, and Book
classes

Step 5: Build by Feature

 Code feature → unit test → inspect → integrate into main codebase

Benefits of FDD
Benefit Description

Scalable Suitable for large teams and projects

Predictable Progress Measurable output per feature

Structured Yet Agile Combines modeling with iterative development

Code Ownership Improves accountability and quality

Limitations of FDD

 Not as adaptive to changing requirements as other Agile methods (e.g., SCRUM)

 Heavy reliance on initial modeling
 May be less suitable for small teams or startups
 Lacks built-in mechanisms for customer feedback loops

When to Use FDD?

FDD is ideal when:

 The project is large and complex

 Teams are distributed
 There is a need for strong upfront modeling and structure
 Stakeholders want predictable deliveries and clear ownership

C) Lean Software Development Agile Process

Lean Software Development (LSD) is an Agile methodology derived from Lean

manufacturing principles developed by Toyota. It emphasizes eliminating waste,
improving efficiency, and delivering maximum customer value in the shortest possible
time.

7 Lean Principles
 Principle Meaning
1. Eliminate Waste Remove anything that does not add customer value (e.g., unused features, delays)
2. Build Quality In Prevent defects through automation, TDD, and peer reviews
3. Create Knowledge Promote learning and knowledge sharing through documentation, retrospectives

4. Defer Commitment Delay irreversible decisions until they are necessary (last responsible moment)
5. Deliver Fast Shorten cycle times, use small batches, reduce wait times
6. Respect People Trust and empower the development team
7. Optimize the Whole Improve the entire value stream, not just individual processes
Lean Software Development Practices
Practice Description

Value Stream Mapping Identifies steps that add or reduce value

Kanban Board Visualizes work in progress and limits task overload

Continuous Delivery Enables faster releases with minimal effort

Refactoring & Automation Keeps the system clean and maintainable

Customer Feedback Loops Regular updates to validate assumptions and reduce risk

Cross-functional Teams Encourages collaboration and knowledge sharing across roles

Waste in Software Development (The 7 Wastes)

Waste Type Example

Partially Done Work Unfinished features, unused code

Extra Features Gold-plating, unnecessary functions

Relearning Poor knowledge sharing, lack of documentation

Handoffs Too many steps or approvals between team members

Delays Waiting for approval, dependencies

Task Switching Constant context switching reduces efficiency

 Waste Type Example

Defects Bugs and rework due to poor quality or misunderstood requirements

Example: Lean in a Food Delivery App

Goal: Build a basic food ordering feature in 2 weeks.

Stage Lean Approach

Feature Selection Only core features: search, menu, add-to-cart, checkout

Development Small batches, Kanban board to track tasks

Testing Automated tests + early user feedback to “build quality in”

Deployment Continuous integration for fast, safe releases

Feedback Customer testing at end of 1st week to reduce risk

Decision-making Payment gateway choice delayed until needed (defer commitment)

Benefits of Lean Software Development

Benefit How it Helps

Faster Delivery Reduces delays and unnecessary steps

Higher Quality Continuous testing and defect prevention

Lower Cost Efficient use of resources

Better Customer Satisfaction Delivers what users need, not what developers assume

Team Empowerment Respects expertise, boosts morale and collaboration

Challenges of Lean
Challenge Description

Less prescriptive than SCRUM; may overwhelm inexperienced

Lack of Structure
teams

Requires Culture Change Strong emphasis on trust, feedback, and cross-functionality

Needs Strong Discipline Hard to balance "just enough" without under-documenting

Difficult to Scale Without Tools Requires tools like Kanban, CI/CD pipelines
D) Extreme Programming (XP)

Extreme Programming (XP) is an Agile software development methodology aimed at

improving software quality and responsiveness to changing requirements. It emphasizes
frequent releases, automated testing, continuous communication, and simplicity in
design.

XP is best suited for:

 Projects with changing customer needs

 Small to medium-sized teams
 Teams focused on technical excellence

Core Values of XP

1. Communication – Constant collaboration between team members and with

customers
2. Simplicity – Do the simplest thing that works
3. Feedback – From automated tests and frequent deliveries
4. Courage – To refactor code and accept change
5. Respect – Among all team members

XP Key Practices (Grouped by Category)

Category Practices

Development - Test-Driven Development (TDD): Write tests before code

markdown
CopyEdit
- **Simple Design**: No unnecessary complexity
- **Refactoring**: Improve internal structure without changing behavior |

| Teamwork | - Pair Programming: Two developers share one workstation

- Collective Code Ownership: Anyone can change any part of the code
- Coding Standards: Team-wide consistent coding style |
| Process | - Small Releases: Frequent and incremental delivery
- Continuous Integration: Merge and test code frequently
- Sustainable Pace: Avoid burnout by keeping a 40-hour work week |
| Planning | - User Stories: Short descriptions of a feature from user’s perspective
- Planning Game: Collaborative planning with developers and customers
- On-site Customer: Customer representative always available for feedback |

🔁 XP Lifecycle (Simplified)
csharp
CopyEdit
[Customer Writes User Stories]
↓
[Planning Game]
 ↓
[Small Iterations (1-2 weeks)]
↓
[TDD → Code → Refactor → Test]
↓
[Daily Integration + Pair Programming]
↓
[Release Working Product]

Example – XP in a “To-Do List App” Project

Goal: Implement a basic to-do list app with add/edit/delete functionality in 2 weeks.

Step 1: Planning Game

Customer writes stories like:

 “As a user, I want to add a task to my list.”

 “As a user, I want to delete a completed task.”

Team estimates and selects a set of stories for Iteration 1.

Step 2: Test-Driven Development

Before coding “add task” feature:

 Write test: testAddTask()

 Write minimum code to pass the test
 Refactor code to improve readability

Step 3: Pair Programming

Developer A and B work together:

 One writes tests

 One writes code

Step 4: Continuous Integration

Code is pushed and tested in CI server after every commit.

Step 5: Release

At the end of the week, a working “add + delete task” feature is demoed to the customer.

Benefits of XP
Benefit Description

High Code Quality Through TDD, refactoring, and pair programming

 Benefit Description

Frequent Feedback Due to small releases and on-site customer involvement

Adaptability Easily adapts to changing requirements

Developer Satisfaction Emphasis on sustainable pace and collaboration

Challenges in XP
Challenge Description

Needs High Discipline TDD, Pair Programming, and CI require consistency

On-site Customer Requirement Not always feasible in all organizations

Less Emphasis on Documentation May not suit teams needing formal processes

May Not Scale Easily XP is better for small to medium projects

When to Use XP?

 Rapidly changing requirements

 Projects with uncertain scope
 Teams seeking high-quality code and frequent delivery
 Startups or internal tools needing fast iterations

Comparison Table:

Planning
Method Key Focus Best For Artifacts
Style
Complex, dynamic Sprint Backlog, Burn-
SCRUM Iterative Delivery Sprint-based
projects down chart
Feature List, Design
FDD Feature Delivery Feature-wise Larger, stable projects
Documents
Value
Lean Flow-based Process improvement VSM, Kanban
Optimization
Small teams, high-
XP Code Quality Code-centric Unit Tests, CI logs
collab
Outcome:

Result:

The working of four Agile processes—SCRUM, FDD, Lean Software Development, and XP
—were studied, simulated, and compared. Their roles, practices, workflows, and artifacts
were analyzed in different software project contexts.