
A software development methodology decides three things you will feel as the person paying for a custom build: how often you see working software, who can change the plan, and how the contract prices the work. The name of the method matters much less than those three answers.
Most of the methods in older comparisons, such as Rapid Application Development, DSDM or the Spiral model, still exist mainly as ideas inside newer ones. The ones you are most likely to hear from a vendor in 2026 are Scrum, Kanban, Waterfall, Shape Up or a hybrid, with DevOps practices underneath. Here is how they compare.
The methodologies compared
| Method | How work is planned | When you see working software | Who can change the plan | Fits |
|---|---|---|---|---|
| Scrum | Fixed Sprints of one month or less | Every Sprint Review | The Product Owner, between Sprints | A product whose backlog will change for months |
| Kanban | Continuous flow with limits on work in progress | Whenever an item is finished | Anyone, through the board’s policies | Support, maintenance, a steady stream of small requests |
| Waterfall | Phases run once, in order | Near the end | A formal change request | Fixed scope set from outside: a regulation, hardware, a contract |
| Shape Up | Six-week cycles with a two-week cool-down | End of each cycle | Stakeholders, at the betting table between cycles | Product teams that fix the time and let the scope flex |
| Hybrid | A fixed plan for some parts, Sprints for the rest | Depends on the part | Split by part | Regulated or integration-heavy products |
Agile and Scrum
Agile is the umbrella: a set of values and principles, not a process. Its principles ask teams to deliver working software “from a couple of weeks to a couple of months, with a preference to the shorter timescale” and treat working software as “the primary measure of progress.”
Scrum turns those principles into a fixed routine. The Scrum Guide defines a small team, typically 10 or fewer people, working in Sprints of one month or less, with a Product Owner who orders the backlog. You see working software at every Sprint Review and can change priorities before the next Sprint. Our Scrum fundamentals guide for founders covers what you do in each event.
Kanban
The Kanban Guide, updated in May 2025, defines Kanban as “a strategy for optimizing the flow of value through a process.” It has three practices: defining and visualizing a workflow, actively managing items in it, and improving it. Teams limit how many items are in progress and forecast from how long items take to flow through, instead of planning Sprints. Kanban fits work that arrives as a stream, such as bug fixes and small requests after launch. It gives you less of a natural checkpoint than a Sprint Review, so agree on a regular demo anyway.
Waterfall
Waterfall runs requirements, design, build, verification and maintenance once each, in order. It works when the scope can’t change: a fixed government tender, firmware tied to a hardware release, a migration with a hard cut-over date. The risk is that you see working software late, when changes cost the most.
Shape Up
Shape Up, written by Ryan Singer at Basecamp, works in six-week cycles followed by a two-week cool-down for bug fixes and planning. Instead of estimating, the team sets an appetite: “the amount of time we want to spend on a project, as opposed to an estimate.” Stakeholders decide which shaped ideas to fund at a betting table during the cool-down. It suits a product team that wants a fixed rhythm without daily ceremonies.
Extreme Programming and Lean Startup
These two are less about planning and more about how to build and what to build. Extreme Programming brings engineering practices such as pair programming, test-first development and continuous integration. Lean Startup brings the minimum viable product and the loop of building, measuring and learning. Our MVP work combines the short cycles of Extreme Programming, Scrum, Customer Development and Lean Startup.
DevOps
DevOps isn’t a planning method. It is a set of practices that join development and operations: automated builds, tests and deployments, monitoring and fast recovery. Any method above works better with it. DORA’s AI Capabilities Model from September 2025 names working in small batches and a user-centric focus among seven capabilities that amplify the benefits of AI. Without a user-centric focus, DORA found, AI adoption can have a negative impact on team performance.
On Koncierge, a payment platform for Japan, the client asked for daily deployments and we shipped every day. Shipping daily inside a one-month build window only works with automated builds and deployments underneath.
What happened to RAD, DSDM, FDD, Spiral and the rest
| Method | Core idea | Where you see it today |
|---|---|---|
| Rapid Application Development (RAD) | Prototype fast with users involved | Clickable prototypes before the build, low-code tools |
| DSDM | Fixed time and budget, flexible scope | Fixed-price MVPs with a ranked feature list; Shape Up’s appetite |
| Feature-Driven Development (FDD) | Deliver client-valued features every two weeks | Two-week Sprints built around user stories |
| Spiral | Tackle the biggest risk first in each loop | A test build of the riskiest part before the full build |
| Prototype model | Show a working model before building | Discovery with a clickable Figma prototype |
| Joint Application Development (JAD) | Workshops with all stakeholders | Discovery workshops and story mapping |
| Big Bang | Little planning, build and see | Hackathons and throwaway experiments |
Method and contract go together
The method you choose and the way you pay have to match, or one of them breaks. A fixed price needs a fixed scope. Time and materials, or a dedicated team, fits a backlog that keeps changing.
The market shows the split. Of the 41 agencies in the Rocketech MVP Price Index 2026 that state their own MVP price, 20 sell at a fixed price. Those fixed-price agencies start at $8,200, with a midpoint of $13,125 and timelines of up to 8 weeks. Those are published prices, not what agencies charge after scoping.
We say it plainly on our own pages: a fixed price while your requirements change every week doesn’t work, because each change reopens scope and price. Our engagement models page compares a fixed-price project, time and materials, a dedicated team, staff augmentation and a co-founder partnership.
How to choose a methodology for your project
| Your situation | Method to start with |
|---|---|
| First version, scope will change after users try it | Scrum with 1-2 week Sprints, or a fixed-price MVP for a narrow first scope |
| Live product with a steady stream of fixes and small features | Kanban |
| Fixed scope from a contract, a regulation or a hardware date | Waterfall for the fixed part, Sprints for the rest |
| Product team that wants a calm, fixed rhythm | Shape Up |
| Several teams and a budget board | Scrum teams plus a project or programme plan above them |
The PMBOK Guide, Eighth Edition, published by PMI in November 2025, treats this mixing as normal: it is written for “a range of approaches and environments” and asks you to tailor practices to your team and context.
How we would estimate a custom build before choosing the method
The method decides how you manage the work. You still need to know how much work there is. Our project estimate turns your brief into user stories, and you confirm what is in scope. Every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour.
The result tells you which contract fits. A small, clear set of stories can go to a fixed price. A long list with open questions is a sign to start with Sprints and time and materials. It’s a planning range, not a fixed quote. You can run your idea through our project estimate in about four minutes. Once a team is in place, it can size the same backlog quickly with swimlane sizing.
What we would do
- Decide whether your scope is fixed by something outside your control. If not, don’t buy a waterfall plan.
- For a first version, keep the scope narrow and use either a fixed-price MVP or Sprints of one to two weeks.
- After launch, move maintenance and small requests to a Kanban flow, and keep larger features in Sprints or cycles.
- Whatever the method, ask for working software on a fixed rhythm and automated tests and deployments underneath.
- Match the contract to the method before you sign. Our custom software development work starts with your process, then the method and the contract. For the phases every method goes through, see agile lifecycle phases explained.
FAQ
What is a software development methodology?
A set of rules for planning, building and delivering software: how work is broken up, how often working software is shown, who can change the plan and how progress is measured. Scrum, Kanban, Waterfall and Shape Up are common examples.
Which methodology is best for custom software development?
For a product whose requirements will change as users try it, Scrum with short Sprints or a narrow fixed-price first version usually fits. Waterfall fits only when the scope is fixed from outside. After launch, routine work fits a Kanban flow.
What is the difference between Scrum and Kanban?
Scrum plans work in fixed Sprints of one month or less and reviews working software at the end of each. Kanban has no Sprints: work flows continuously, the team limits work in progress and forecasts from how long items take to finish.
Can a fixed-price contract use agile?
Yes, if the scope of each fixed-price piece is narrow and written down. A fixed price with requirements that change every week doesn’t work, because each change reopens scope and price.
Are RAD, DSDM and the Spiral model still used?
Rarely by name. Their ideas live on: RAD in clickable prototypes, DSDM in fixed-time and flexible-scope deals, the Spiral model in testing the riskiest part before the full build.