SDLC Models & Agile Practices
SDLC Models & Agile Practices
The Software Development Life Cycle (SDLC) defines how software goes from idea to production. Different models make different tradeoffs between predictability, flexibility, feedback frequency, and overhead.
Waterfall
The original linear model: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Each phase is fully complete before the next begins.
When it works: highly stable requirements (building a bridge, launching a satellite), regulatory environments requiring documentation gates, and projects where rework is prohibitively expensive.
Why it fails for most software: requirements are not fully knowable upfront. Users don't know what they want until they see something working. Technology changes during long projects. The first working version isn't delivered until testing is complete — often 18+ months after requirements.
The iron triangle of project management (scope, time, cost — pick two) shows the fundamental tension: Waterfall fixes scope and time but overruns cost; Agile fixes time and cost but adjusts scope.
Scrum
Scrum is the most widely adopted Agile framework. Core elements:
Sprints: fixed 1-4 week iterations producing a potentially shippable increment. "Potentially shippable" means it meets the Definition of Done — it could be deployed, even if the business chooses not to.
Roles:
- Product Owner: owns the product backlog, sets priorities, represents business value
- Scrum Master: coaches the team on Scrum, removes impediments, facilitates ceremonies
- Development Team: self-organizing group that commits to and delivers sprint work
Ceremonies:
- Sprint Planning: select backlog items and create a sprint goal; team commits to what they can deliver
- Daily Standup: 15 minutes; what did I do, what will I do, what's blocking me
- Sprint Review: demonstrate what was built; stakeholders give feedback
- Sprint Retrospective: inspect and adapt the process
Scrum anti-patterns:
- Treating velocity as a target to game (adding story points to look productive)
- Skipping retrospectives when "too busy"
- Product Owner unavailable during sprint (backlogs go stale)
- Sprints never delivering shippable increments (the DoD is aspirational, not enforced)
- Estimates used as performance benchmarks
Kanban
Kanban is a flow-based method with no fixed iterations. Work items flow through stages (To Do → In Progress → Review → Done) with WIP limits.
Work In Progress (WIP) limits: limit how many items can be in each stage simultaneously. If a stage is at capacity, upstream work stops — forcing focus on completing work rather than starting more. This surfaces bottlenecks: if Review is always full, the bottleneck is review capacity, not development.
Kanban metrics:
- Cycle time: time from start to done
- Throughput: items completed per week
- WIP: current items in flight
When Kanban fits better than Scrum: operations and support work (unpredictable inflow), mature teams with continuous deployment, and contexts where fixed-length sprints create artificial batching.
Extreme Programming (XP)
XP is an Agile method focused on technical practices:
- Test-Driven Development: write tests first
- Pair Programming: two engineers at one workstation
- Continuous Integration: merge and build multiple times per day
- Small Releases: deploy frequently
- Refactoring: continuous design improvement
- Collective Code Ownership: any engineer can change any code
XP's value is its emphasis on technical discipline. Scrum often gets adopted without XP practices — teams sprint but don't do TDD or CI, which leads to technical debt accumulating under Agile timelines.
Choosing a Model
New product with unclear requirements: Scrum — short sprints force early feedback, allowing pivots before significant investment is sunk.
Support/operations team with continuous inflow: Kanban — no artificial sprint cycles; work flows as it arrives.
Regulated or safety-critical systems: structured V-Model or hybrid — rigorous documentation gates matter when rework is dangerous.
Small team, trusted stakeholders, continuous deployment: Kanban or "shape up" — minimal ceremony, maximize flow.
Startup finding product-market fit: Kanban with weekly goals — avoid sprint overhead before the product direction is stable.
The Backlog and User Stories
A product backlog is an ordered list of everything that might be done. Items at the top are detailed and ready; items at the bottom are vague and distant.
User stories: "As a [user type], I want [capability], so that [benefit]." This format forces thinking about who uses the feature and why, rather than technical solutions.
Acceptance criteria: the specific conditions under which a story is done. Without them, "done" is ambiguous. With them, testing is clear.
Story splitting: large stories (epics) must be split before they enter a sprint. Techniques: by workflow step, by user type, by data variation, by interface simplification.
Estimation
Story points are relative estimates of complexity and uncertainty, not time. A 3-point story is roughly 3x the effort of a 1-point story; absolute hours are not meaningful.
Planning poker: team members simultaneously reveal their estimates; discuss discrepancies; re-estimate. This surfaces different understandings of scope early.
The key insight: estimation is about reducing uncertainty and surfacing unknowns, not predicting time precisely. If the team disagrees on an estimate, there is a misunderstanding to resolve.