vault/Career/Software Development Methodologies.md

note type, date, done

note type	date	done
theory	2026-06-03	true

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

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

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)

[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

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

| 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

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

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

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

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