Which development methodology fits your project
Every comparison of software development methodologies lists the same approaches and concludes that it depends. The useful version states what each one quietly requires from your organisation, because that is the part that decides whether it works.
Waterfall#
Sequential phases move requirements, design, build, test, deploy in order. Each phase completes substantially before the next begins.
Waterfall optimises for predictability. A fixed scope produces a defensible date and cost, which is why it persists in regulated and contractual environments where the plan is itself a deliverable.
It quietly requires that requirements are genuinely knowable in advance and will not change materially. That condition is rarer than it appears. The honest test is whether the business has actually settled the decision or has merely written it down.
Its failure mode is validation at the end. An assumption wrong in month one stays wrong until testing, which is the most expensive moment to discover it.
Agile#
Agile is an umbrella term for software development approaches that deliver working software in short cycles and adapt as understanding improves. The Agile Manifesto's four value statements are preferences, not a process.
Agile optimises for adaptability and early discovery of wrong assumptions.
It quietly requires a customer or product owner who is genuinely available and empowered to decide. An Agile process with an absent decision-maker degrades into short iterations that cannot close. The ceremony survives while the benefit does not.
Its failure mode is scope with no anchor. Without a clear outcome, iteration becomes indefinite refinement.
Scrum#
Scrum is a specific Agile framework: fixed-length sprints, defined roles, and a set of recurring events.
Scrum optimises for rhythm and visibility. The cadence creates predictable checkpoints without a fixed long-term plan.
It quietly requires a backlog kept in usable order and protection of the sprint from mid-sprint change. Organisations that cannot stop injecting urgent work get the overhead of Scrum without its benefit.
Kanban#
Kanban is continuous flow with explicit work-in-progress limits and no fixed iterations.
Kanban optimises for throughput and responsiveness, especially where work arrives unpredictably. It suits support, maintenance and platform teams better than Scrum does.
It quietly requires genuine enforcement of WIP limits. A board with unlimited columns and unlimited cards is a to-do list, not Kanban.
Hybrid approaches#
In practice most delivery is hybrid: a fixed discovery and architecture phase followed by iterative build, or Scrum for product work alongside Kanban for support. This is usually pragmatism rather than compromise. Stating it plainly is more honest than claiming methodological purity nobody practises.
Comparison table#
| Dimension | Waterfall | Scrum | Kanban |
|---|---|---|---|
| Optimises for | WaterfallPredictability | ScrumRhythm and visibility | KanbanFlow and responsiveness |
| Scope | WaterfallFixed up front | ScrumFixed per sprint | KanbanContinuous |
| Requires | WaterfallStable requirements | ScrumAvailable product owner, ordered backlog | KanbanEnforced WIP limits |
| Fits best | WaterfallRegulated, contractual, well-understood work | ScrumProduct development with evolving scope | KanbanSupport, maintenance, unpredictable arrival |
| Fails when | WaterfallRequirements change | ScrumDecision-maker unavailable | KanbanLimits are not enforced |
Three questions that decide it#
Rather than asking which methodology is best, ask three things about the work in front of you.
- Are the requirements genuinely settled, or merely written down. Settled favours sequential; unsettled favours iterative.
- Is there a decision-maker available weekly, with authority. If not, iterative approaches will stall regardless of how well they are run.
- Does work arrive predictably, or continuously and unplanned. Continuous arrival favours flow over iterations.
Where the answers conflict, the constraint should win. A project with unsettled requirements and no available decision-maker is not a methodology problem. It is a project that is not ready to start, and choosing a framework will not change that.
Assessment before development#
A project that needs this assessment before development begins can benefit from a scoping engagement to clarify requirements, constraints, and the appropriate delivery approach.
Understanding your requirements matters before choosing a path. Product discovery surfaces the decisions you need to make and the conditions each methodology depends on.
The key is naming what each methodology needs before you start, not discovering it in month three. Decision availability is the most common missing prerequisite, and it is worth stating before a project slips.
How this works at Atyantik#
We run iterative delivery with a fixed discovery and architecture phase at the front, which is a hybrid approach to custom software development rather than textbook Scrum. Scoping and integration assessment need to be substantially complete before an estimate is worth anything.
Our approach makes each increment demonstrable, so assumptions are tested early rather than at the end. Where a methodology's prerequisite is missing, we say so at scoping rather than discovering it months in.