:PROPERTIES:
:ID:       67ad330b-cc11-4e8e-b054-12b9da45ea60
:END:
#+title: Software Development Methodologies
#+filetags: :notes:career:technical:


* 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
#+BEGIN_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.
#+END_EXAMPLE

** 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:
#+BEGIN_QUOTE
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)
#+END_QUOTE

** 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
#+BEGIN_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.
#+END_EXAMPLE

** 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)
#+BEGIN_EXAMPLE
[Sprint Planning] → [Daily Standup × N] → [Sprint Review] → [Retrospective]
     ↑_____________________________ repeat (1–4 weeks) ___________________|
#+END_EXAMPLE

| 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
#+BEGIN_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?
#+END_EXAMPLE

** 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
#+BEGIN_EXAMPLE
| Backlog | In Progress (WIP:2) | Review (WIP:1) | Done |
|---------|---------------------|----------------|------|
| Task D  | Task B              | Task A         | Task X|
| Task E  | Task C              |                | Task Y|
#+END_EXAMPLE

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
#+BEGIN_EXAMPLE
Red   → Write a failing test
Green → Write the minimum code to pass it
Refactor → Clean up without breaking the test
Repeat.
#+END_EXAMPLE

** 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
#+BEGIN_EXAMPLE
Essential SAFe:  Team + Program levels
Large Solution:  + Solution Train (multiple ARTs)
Portfolio SAFe:  + Portfolio strategy & funding
#+END_EXAMPLE

** 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
#+BEGIN_EXAMPLE
Code Push → Build → Unit Tests → Integration Tests → Deploy to Staging
         → Manual Approval → Deploy to Production → Monitor
#+END_EXAMPLE

** 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

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

-----

* 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                  |