Module 02 · Process · All tracks
Software Methodology & Agile
Methodology questions aren't about reciting the Scrum guide — they're checking whether you've actually shipped on a team. This module gives you the working engineer's view, not the certification view.
By the end you'll be able to explain, with conviction:
- Why Agile displaced Waterfall — the actual problem it solved, not the manifesto.
- Scrum and Kanban as different answers to different kinds of work.
- How estimation, "done," and code review work in practice on a healthy team.
1The SDLC arc
Every methodology is a different way of moving through the same fundamental stages.
The Software Development Life Cycle is the arc every feature travels: requirements → design → implementation → testing → deployment → maintenance. No methodology skips these stages — they differ only in how often they cycle through them and how much they commit to up front.
That reframing is the key insight for interviews. Waterfall walks the arc once, end to end, betting it can get requirements right before writing code. Agile walks a tiny version of the whole arc every couple of weeks, betting that feedback beats foresight. Same stages, radically different rhythm — and the rhythm is the whole argument.
Why it matters
If you can frame methodologies as "different cadences over the same SDLC stages," you stop sounding like you memorised definitions and start sounding like someone who understands the tradeoff being made.
2Waterfall vs Agile — why Agile won
Waterfall is sequential: finish requirements, then design, then build, then test, then release. It assumes the requirements are knowable and stable up front. For genuinely fixed domains — a bridge, a regulated medical device — that discipline is a feature. For most software it's a liability, because the cost of a wrong assumption isn't discovered until the testing phase, months after it was made, when it's wildly expensive to fix.
Agile attacks exactly that feedback delay. Instead of one long bet, you ship small, working increments and let real usage correct your course. The 2001 Agile Manifesto put it as four preferences: individuals and interactions over processes, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan. None of those reject the right-hand items — they just say which wins when they conflict.
The honest version: Agile won because requirements are usually discovered, not given. Shortening the loop between building and learning is its entire advantage. Where requirements really are fixed and the cost of change is catastrophic, Waterfall still has a place — saying that out loud shows judgment rather than dogma.
Interview angle
"Agile won because in most software the requirements are discovered, not handed down. It shortens the loop between building something and learning whether it was right — Waterfall pays for a wrong assumption months later, Agile pays for it in a sprint."
3Scrum — roles & artifacts
Scrum is the most common implementation of Agile: fixed-length iterations called sprints (usually two weeks) that each produce a potentially shippable increment. It defines three roles and three artifacts, and knowing who owns what is the part interviewers probe.
The three roles
- Product Owner — owns the what and the why. Prioritises the backlog to maximise value. The single voice on priorities.
- Scrum Master — owns the process. A servant-leader who removes blockers and protects the team from mid-sprint scope changes; not a project manager assigning tasks.
- Developers — own the how. They self-organise to turn backlog items into working software and collectively commit to the sprint.
The three artifacts
- Product Backlog — the ordered master list of everything that might be built, owned by the PO.
- Sprint Backlog — the slice the team commits to this sprint, plus the plan to deliver it.
- Increment — the sum of completed work, meeting the Definition of Done, ideally releasable.
Common trap
Calling the Scrum Master "the boss" or having them assign tasks is the giveaway of someone who's read about Scrum but not lived it. The team self-organises; the Scrum Master clears the road.
4The sprint ceremonies
Four recurring events give a sprint its shape. Each exists to answer a specific question.
- Sprint Planning — "what can we commit to, and how?" The team pulls items from the backlog into the sprint.
- Daily Standup — "are we on track and is anyone blocked?" A ≤15-minute sync, not a status report to a manager.
- Sprint Review — "is this what you needed?" The team demos the increment to stakeholders and gathers feedback.
- Retrospective — "how do we work better next time?" The team inspects its own process and picks one or two concrete improvements.
Interview angle
"The retro is the one I'd protect most — it's the only ceremony aimed at improving how the team works rather than what it builds. A team that skips retros stops getting better."
5Estimation — story points & velocity
Teams estimate in story points rather than hours, and the reason is subtle but worth getting right: points measure relative effort and complexity, not time. A 3-point story is roughly three times the effort of a 1-pointer, regardless of who picks it up. This sidesteps the trap of "how many hours will this take you specifically," which is unanswerable and varies per person.
Teams often use a Fibonacci-ish scale (1, 2, 3, 5, 8, 13) because the widening gaps reflect growing uncertainty — you can't meaningfully distinguish a 21 from a 22. Velocity is the number of points a team actually completes per sprint, averaged over time. Its only legitimate use is forecasting and capacity planning for that team.
Common trap
Velocity is not a productivity metric and never compares across teams — points are relative to each team's own baseline. Using velocity as a target corrupts it instantly: estimates inflate, and the number stops meaning anything (Goodhart's law).
Interview angle
"Points estimate relative effort, not hours — that's what makes them stable across different people. Velocity is just a forecasting tool for one team; the moment it becomes a target, it stops being useful."
6Kanban vs Scrum
Both are Agile, but they suit different work. Scrum is iteration-based: fixed sprints, a committed scope, and change held until the next planning. It fits feature work that benefits from a planning rhythm. Kanban is flow-based: a continuous board with work-in-progress (WIP) limits, no sprints, and work pulled as capacity frees up. It fits unpredictable, interrupt-driven work like support, ops, or a maintenance team.
| Scrum | Kanban | |
|---|---|---|
| Cadence | Fixed sprints | Continuous flow |
| Commitment | Sprint scope locked | Pull as ready |
| Key lever | Velocity per sprint | WIP limits, cycle time |
| Best for | Planned feature work | Support / unpredictable flow |
The WIP limit is Kanban's secret weapon: by capping how many items are in progress at once, it forces the team to finish things before starting new ones, exposing bottlenecks instead of hiding them under a pile of half-done work.
Interview angle
"I reach for Scrum when work is plannable and benefits from a rhythm, and Kanban when work arrives unpredictably — its WIP limits stop the team from starting ten things and finishing none."
7Definition of Done / Ready
These two checklists prevent the most common failure modes at the edges of a sprint.
Definition of Ready guards the entrance: a story shouldn't enter a sprint until it's clear, estimated, and free of blocking unknowns — acceptance criteria written, dependencies understood. It stops the team committing to work that's secretly undefined.
Definition of Done guards the exit: a shared, explicit standard for what "complete" means — code reviewed, tested, documented, merged, deployable. Without it, "done" means "works on my machine" and quality quietly erodes. The power of both is that they make implicit expectations explicit and agreed, so nobody relitigates them mid-sprint.
Interview angle
"Definition of Ready stops us committing to vague work; Definition of Done stops 'done' from quietly meaning 'compiles on my laptop.' They turn assumptions into a shared, written contract."
8JIRA & Confluence in practice
You'll be expected to have lived in these tools, so speak about them like a practitioner. JIRA is where work is tracked: epics break into stories, stories into sub-tasks; boards visualise the sprint or flow; tickets move through workflow states (To Do → In Progress → In Review → Done). Confluence is the wiki alongside it — where design docs, runbooks, retro notes, and decisions live so knowledge outlives any one person.
The senior framing isn't "I used JIRA"; it's understanding why they matter: a single source of truth for what's being worked on and why, traceability from a requirement through to the commit that closed it, and durable team memory. Tools are interchangeable; that discipline isn't.
Common trap
Don't bad-mouth process tools as pure overhead — it reads as junior. The mature take is that lightweight, well-kept tracking buys traceability and shared context; the problem is only ever ceremony without value, not the tool itself.
9Code review & PR etiquette
Code review is where methodology meets daily craft, and how you talk about it reveals your seniority fast. Its real purpose is broader than catching bugs: it spreads knowledge across the team, enforces shared standards, and creates a second pair of eyes on risk. Bug-catching is almost a side effect.
As the author
- Keep PRs small and focused — a 50-line PR gets a real review; a 2,000-line one gets a rubber stamp.
- Write a description that explains the why and how to test, so the reviewer isn't reverse-engineering intent.
- Separate refactors from behaviour changes into different PRs.
As the reviewer
- Critique the code, not the person; ask questions rather than issue commands.
- Distinguish blocking issues from nits — label opinions as opinions.
- Approve when it's better than the status quo, not when it's perfect; perfect blocks the team.
Interview angle
"I treat code review as knowledge-sharing first and bug-catching second. As an author I keep PRs small with a clear why; as a reviewer I separate blocking concerns from nits and approve when it improves the codebase, not when it's flawless."
Recap — what you can now teach
- Every methodology is a different cadence over the same SDLC stages.
- Agile won because requirements are discovered, not given — it shortens the feedback loop.
- Scrum: PO owns what, Scrum Master owns process, Developers own how; four ceremonies, each answering one question.
- Points measure relative effort; velocity forecasts one team and dies the moment it's a target.
- Scrum for plannable work, Kanban for unpredictable flow with WIP limits.
- DoR and DoD turn implicit expectations into a written, shared contract.
- Code review is knowledge-sharing first; small PRs and kind, specific feedback.
Self-check
Say each answer out loud before revealing it.
In one sentence, why did Agile displace Waterfall for most software?
Because requirements are usually discovered rather than known up front, and Agile shortens the loop between building and learning whether it was right.
What do story points measure, and why not hours?
Relative effort and complexity — which stays stable across different people, unlike per-person hour estimates.
When would you choose Kanban over Scrum?
For unpredictable, interrupt-driven work (support, ops) where continuous flow with WIP limits beats a fixed sprint commitment.
What's the primary purpose of code review?
Sharing knowledge and enforcing shared standards across the team; catching bugs is almost a side effect.
Why is velocity dangerous as a target?
It's relative to one team's baseline; making it a target just inflates estimates so the number stops meaning anything.