# Software Development Methodologies

A software development methodology defines the *process, structure, and principles*
used to plan, manage, and execute software projects.

## Why It Matters

  - Ensures predictability and consistency across teams
  - Reduces risk of project failure
  - Aligns stakeholders and developers on expectations
  - Provides tools for handling change and uncertainty

-----

# 1\. Waterfall

## Overview

A **linear, sequential** model where each phase must be completed before the next begins.

## Phases

1.  Requirements
2.  System Design
3.  Implementation
4.  Testing
5.  Deployment
6.  Maintenance

## Example

``` example
A government agency contracts a firm to build a tax portal.
Requirements are frozen at sign-off; code is written six months
later; testing follows; the portal launches two years in.
```

## Pros & Cons

| Pros                        | Cons                                |
| --------------------------- | ----------------------------------- |
| Clear structure and phases  | Very rigid; change is costly        |
| Easy to manage milestones   | Late discovery of defects           |
| Good for fixed requirements | Customer sees nothing until the end |

## Best For

  - Projects with well-defined, stable requirements
  - Regulatory/compliance-heavy environments (aerospace, medical devices)

-----

# 2\. Agile

## Overview

An **iterative, incremental** philosophy that values:

> Individuals and interactions over processes and tools.
> Working software over comprehensive documentation.
> Customer collaboration over contract negotiation.
> Responding to change over following a plan.
> — The Agile Manifesto (2001)

## Core Concepts

  - **Iterations (sprints)**: Short delivery cycles (1–4 weeks)
  - **Incremental delivery**: Working software shipped frequently
  - **Feedback loops**: Customers review and redirect regularly
  - **Cross-functional teams**: Dev, QA, design collaborate continuously

## Example

``` example
A startup builds a mobile app in 2-week sprints.
Sprint 1 → user login
Sprint 2 → profile page
Sprint 3 → search feature
After each sprint, real users test and give feedback,
shaping what gets built next.
```

## Agile Values vs Waterfall

| Dimension     | Waterfall      | Agile                |
| ------------- | -------------- | -------------------- |
| Planning      | Upfront, fixed | Continuous, adaptive |
| Delivery      | End of project | Every sprint         |
| Change        | Discouraged    | Embraced             |
| Customer role | Sign-off only  | Active partner       |
| Risk exposure | High (late)    | Low (early)          |

## Best For

  - Products with evolving requirements
  - Startups, SaaS, consumer apps

-----

# 3\. Scrum

## Overview

Scrum is the most popular **Agile framework**. It imposes a specific
structure of roles, events, and artefacts on top of Agile principles.

## Roles

| Role              | Responsibility                              |
| ----------------- | ------------------------------------------- |
| **Product Owner** | Owns the backlog; prioritises what to build |
| **Scrum Master**  | Removes blockers; facilitates ceremonies    |
| **Dev Team**      | Self-organising; delivers the increment     |

## Artefacts

  - **Product Backlog** — ordered list of all desired features/fixes
  - **Sprint Backlog** — subset of items pulled into the current sprint
  - **Increment** — shippable product at end of each sprint

## Ceremonies (Events)

``` example
[Sprint Planning] → [Daily Standup × N] → [Sprint Review] → [Retrospective]
     ↑_____________________________ repeat (1–4 weeks) ___________________|
```

| Event           | Duration | Purpose                            |
| --------------- | -------- | ---------------------------------- |
| Sprint Planning | ≤ 8 hrs  | Decide what goes into the sprint   |
| Daily Standup   | 15 min   | Sync on progress, surface blockers |
| Sprint Review   | ≤ 4 hrs  | Demo increment to stakeholders     |
| Retrospective   | ≤ 3 hrs  | Reflect and improve the process    |

## Example: Daily Standup Format

``` example
Each team member answers three questions:
  1. What did I complete yesterday?
  2. What will I work on today?
  3. Is anything blocking me?
```

## Best For

  - Teams of 3–9 people
  - Products with frequent reprioritisation

-----

# 4\. Kanban

## Overview

A **flow-based** method focused on visualising work and limiting
work-in-progress (WIP) to maximise throughput. No fixed sprints.

## Core Principles

1.  Visualise the workflow (the Kanban board)
2.  Limit WIP per column
3.  Manage and improve flow
4.  Make policies explicit

## Example Board

``` example
| Backlog | In Progress (WIP:2) | Review (WIP:1) | Done |
|---------|---------------------|----------------|------|
| Task D  | Task B              | Task A         | Task X|
| Task E  | Task C              |                | Task Y|
```

WIP limits prevent bottlenecks — new work cannot start until a slot opens.

## Scrum vs Kanban

| Dimension | Scrum               | Kanban                 |
| --------- | ------------------- | ---------------------- |
| Cadence   | Fixed sprints       | Continuous flow        |
| Roles     | PO, SM, Dev Team    | No prescribed roles    |
| Change    | After sprint        | Anytime                |
| Metrics   | Velocity            | Cycle time, throughput |
| Best for  | Feature development | Operations, support    |

-----

# 5\. Extreme Programming (XP)

## Overview

An Agile methodology with an extreme focus on **engineering practices**
and code quality.

## Key Practices

  - **Test-Driven Development (TDD)**: Write the test before the code
  - **Pair Programming**: Two developers work at one machine
  - **Continuous Integration (CI)**: Merge and test code multiple times a day
  - **Refactoring**: Continuously improve code structure
  - **Small Releases**: Deploy frequently, in small increments
  - **Collective Code Ownership**: Anyone can change any code at any time

## Example: TDD Cycle

``` example
Red   → Write a failing test
Green → Write the minimum code to pass it
Refactor → Clean up without breaking the test
Repeat.
```

## Best For

  - Teams prioritising code quality and technical excellence
  - Projects with rapidly changing requirements

-----

# 6\. SAFe (Scaled Agile Framework)

## Overview

SAFe scales Agile practices across **large enterprises** with multiple
teams working on the same product.

## Key Concepts

  - **Agile Release Train (ART)**: A long-lived team of 50–125 people
  - **Program Increment (PI)**: A 8–12 week planning cycle (like a "super sprint")
  - **PI Planning**: All teams plan together face-to-face every PI

## Levels

``` example
Essential SAFe:  Team + Program levels
Large Solution:  + Solution Train (multiple ARTs)
Portfolio SAFe:  + Portfolio strategy & funding
```

## Best For

  - Enterprises with 100+ engineers
  - Organisations migrating from Waterfall to Agile at scale

-----

# 7\. DevOps (Methodology + Culture)

## Overview

DevOps bridges **development and operations** to enable faster, more
reliable software delivery through automation and collaboration.

## Core Pillars

| Pillar                     | Description                                  |
| -------------------------- | -------------------------------------------- |
| **CI/CD**                  | Automate build, test, and deploy pipelines   |
| **Infrastructure as Code** | Manage servers via code (Terraform, Ansible) |
| **Monitoring**             | Observe systems in production continuously   |
| **Blameless Culture**      | Learn from failures without finger-pointing  |

## Example: CI/CD Pipeline

``` example
Code Push → Build → Unit Tests → Integration Tests → Deploy to Staging
         → Manual Approval → Deploy to Production → Monitor
```

## Best For

  - Any team wanting faster, safer releases
  - Organisations running cloud-native infrastructure

-----

# Comparison Summary

| Methodology | Structure  | Delivery Cadence | Flexibility | Team Size | Best Fit                |
| ----------- | ---------- | ---------------- | ----------- | --------- | ----------------------- |
| Waterfall   | Sequential | End of project   | Low         | Any       | Fixed scope, compliance |
| Agile       | Iterative  | Every sprint     | High        | Small–Med | Evolving requirements   |
| Scrum       | Iterative  | Every 1–4 weeks  | High        | 3–9       | Feature development     |
| Kanban      | Flow-based | Continuous       | Very High   | Any       | Ops, support, flow work |
| XP          | Iterative  | Weekly           | High        | Small     | Quality-critical code   |
| SAFe        | Iterative  | Every 8–12 weeks | Medium      | 50–125+   | Enterprise Agile        |
| DevOps      | Continuous | On every commit  | High        | Any       | Fast, reliable delivery |

-----

# Choosing the Right Methodology

Ask these questions:

1.  **How stable are the requirements?**
      - Stable → Waterfall / SAFe
      - Changing → Agile / Scrum / Kanban
2.  **How large is the team?**
      - 3–9 → Scrum
      - 50+ → SAFe
      - Any size ops team → Kanban
3.  **How important is engineering quality?**
      - Very high → XP (TDD, pair programming)
4.  **How often do you need to ship?**
      - Daily → DevOps + CI/CD
      - Weekly → Scrum / XP
      - Continuously → Kanban
5.  **What is the regulatory environment?**
      - High compliance → Waterfall or hybrid

<!-- end list -->

``` example
Most modern teams use a HYBRID approach:
  Scrum (planning cadence)
  + Kanban board (visual workflow)
  + XP practices (TDD, CI)
  + DevOps (automated pipelines)
```

-----

# Key Terminology Glossary

| Term               | Definition                                                   |
| ------------------ | ------------------------------------------------------------ |
| Sprint             | A fixed time-box (1–4 wks) in Scrum for delivering work      |
| Backlog            | Prioritised list of work items                               |
| Velocity           | Amount of work a team completes per sprint                   |
| WIP Limit          | Maximum items allowed in a workflow stage simultaneously     |
| CI/CD              | Continuous Integration / Continuous Delivery (or Deployment) |
| TDD                | Test-Driven Development                                      |
| Retrospective      | Meeting to inspect and improve team process                  |
| Definition of Done | Agreed criteria for when a task is truly "complete"          |
| Epic               | Large body of work broken into smaller user stories          |
| User Story         | Feature described from end-user perspective                  |