Systems Analysis & Design: How to Choose JAD, RAD, Scrum, DSDM, or Kanban.
They’re All the Same… Until They Aren’t: Choosing a Design Process by “Where You Put the Weight”
Most teams don’t fail because they picked the “wrong” methodology. They fail because they picked a label—and never clarified what they needed the process to emphasize.
JAD, RAD, Agile, Scrum, Kanban, DSDM, Disciplined Agile… big picture, they all aim at the same destination: deliver a solution that works, on a timeline that matters, with enough learning along the way to avoid expensive surprises. The differences show up in one practical question:
Where does this approach put its process weight—alignment, speed, learning, control, or flow?
Below is a simple way to make that visible so you can have better conversations with stakeholders before the project pressure hits.
The “emphasis map” that makes process debates productive
Instead of arguing which method is “best,” score each approach by what it emphasizes. Here’s the table we built (1 = low emphasis, 5 = high emphasis):
If the table does one thing, it’s this: it turns “methodology” into a set of trade-offs you can discuss.
Why the approaches feel similar (and why that’s not a bad sign)
Most modern approaches share core moves:
get stakeholder input
build something
learn from feedback
adjust
repeat
That’s why debates get stuck. Everyone can truthfully say: “We do that too.”
The difference is how strongly the process forces each behavior.
JAD forces alignment by concentrating stakeholder energy into structured sessions. It’s great when the risk is confusion, disagreement, or hidden requirements.
RAD forces speed and learning by timeboxing prototyping and pushing toward an end-to-end system quickly.
Agile/Scrum force learning and delivery by producing increments frequently, then using review/reflection to adapt.
Kanban forces flow and throughput by making work visible, limiting WIP, and improving the system continuously.
DSDM forces delivery discipline in timeboxes with explicit prioritization and governance.
Disciplined Agile forces fit-to-context thinking: tailor the way of working to the constraints you actually have (compliance, vendor realities, enterprise governance, multiple teams).
So if these methods feel similar, that often means your team is already operating in the “modern” zone of iterative delivery. The real question becomes: What do we need to emphasize next?
Use blended arcs to talk about the project reality
Most teams don’t run a single method from start to finish. They transition as the project shifts from discovery → build → operational support.
That’s what the blended arcs visualization captures: an intentional path over time.
Arc A: JAD → Scrum → Kanban (the “alignment → delivery → flow” path)
Start with JAD-style workshops to align stakeholders, clarify scope, define success, and surface risks.
Move into Scrum when you need timeboxed, high-visibility increments and frequent demos.
Finish with Kanban when the work becomes enhancements, bug fixes, and steady-state operational flow.
This arc is useful when stakeholder alignment is hard, delivery matters, and long-run sustainment is real.
Arc B: RAD spike → Scrum → Kanban (the “prototype first” path)
Use a RAD-style prototype spike to get fast clarity on user experience and workflow.
Convert learnings into a backlog and use Scrum for iterative build and hardening.
Shift to Kanban for sustainment.
This arc is useful when the solution is UI/process heavy and the fastest way to learn is to put something in front of users.
Arc C: DSDM → Kanban (the “fixed time, flex scope” path)
Use DSDM-style timeboxing and prioritization when deadlines and governance are non-negotiable.
Shift to Kanban once you’re in release/ops mode.
This arc is useful when you must hit dates, manage approvals, and still want adaptive delivery.
A simple way to choose: decide what you can’t afford to get wrong
Use this as a facilitation prompt with your team:
What is our biggest risk right now?
Misalignment on scope and requirements? → start with JAD
Needing rapid proof and UX validation? → RAD spike
Requirements changing as we learn? → Agile/Scrum
Too many simultaneous tasks and long cycle time? → Kanban
Fixed deadline, fixed governance, but flexible features? → DSDM
Complex enterprise constraints and multiple teams? → Disciplined Agile
What constraint is real and immovable?
date
budget
compliance/governance
staffing availability (especially users)
integration dependencies
What will “progress look like every two weeks?
If you can’t answer that, you’re not choosing a method—you’re choosing hope.
The discussion I actually want to have in meetings
If your goal is “timely delivery with learning and adaptation,” you’re already in Agile territory. The more important move is to stop treating “Agile” as a destination and start treating it as a delivery engine that you can precede and follow with other approaches.
So here’s the question that makes process conversations real:
Where are we in the arc—and what do we need the process to force right now?
If we’re early and confused: force alignment (JAD).
If we’re building: force incremental delivery and learning (Scrum/Agile).
If we’re sustaining and overloaded: force flow and limits (Kanban).
If governance is heavy: force timebox discipline and prioritization (DSDM/DA).
A short closing prompt you can reuse with any team
“Let’s pick our process the way we pick our tools: by the job we need it to do.
What do we need to emphasize this month—alignment, speed, learning, control, or flow?”
If you want, share your project scenario (type of system, stakeholders, constraints, timeline), and I’ll map it to a recommended blended arc and a set of meeting prompts you can use to guide the process conversation.
