Press enter or click to view image in full size

Laravel

PHP

Software Development

Software Planning

Architectural Design

Software Development Methodologies: When Should You Choose Agile, Waterfall, Spiral or Other Approaches?

Jalismahamud

10 min read

·

Oct 1, 2026

--

Listen

Share

One of the first questions we should ask before starting a software project is not:

“Which programming language should we use?”

A better question is:

“How are we going to develop this software?”

A project can have an excellent team and good developers, but if the development process doesn’t match the project’s requirements, the project can still become difficult to manage.

Some projects have fixed requirements.

Some projects change every week.

Some projects involve serious technical or security risks.

Some projects require a working prototype before the final requirements are even understood.

That’s why there is no single software development approach that is perfect for every project.

In this article, we’ll look at common software development approaches and, more importantly, when each approach makes sense.

1. First: Methodology, Model and Framework Are Not Exactly the Same

Developers often use terms like Agile, Scrum, Waterfall, and Spiral as if they are all the same type of thing.

They aren’t.

For example:

Waterfall → Development model
Spiral    → Development model
V-Model   → Development model

Agile     → Development philosophy / approachScrum     → Agile framework
Kanban    → Workflow management method

This distinction is useful because a team can use Agile principles while using Scrum or Kanban to organize the actual work.

Similarly, a team may use a hybrid approach instead of following one model strictly.

The goal is not to choose a fashionable methodology.

The goal is to choose a process that fits the project.

2. Waterfall

Waterfall is one of the most traditional software development models.

The basic idea is that development moves through relatively defined stages.

Requirements
      ↓
Design
      ↓
Development
      ↓
Testing
      ↓
Deployment
      ↓
Maintenance

The team generally tries to understand and document requirements before moving deeply into implementation.

When does Waterfall make sense?

Waterfall can be appropriate when:

• Requirements are well understood
• Requirements are unlikely to change significantly
• Documentation is important
• The project has formal approval processes
• There are contractual requirements
• Each phase needs formal sign-off

For example, imagine a project where a client has already defined:

100+ pages of requirements
Fixed database specification
Fixed approval workflow
Fixed delivery requirements
Fixed contract scope

A structured sequential approach may make sense.

The problem with Waterfall

The biggest challenge is change.

Imagine spending six months building a system and then hearing:

“The business process has changed. We need to redesign this part.”

If the architecture and implementation were heavily based on the original requirements, making large changes can become expensive.

3. Agile

Agile takes a different approach.

Instead of trying to define everything perfectly at the beginning, the team develops the product incrementally and uses feedback throughout the process.

A simplified cycle looks like:

Plan
  ↓
Develop
  ↓
Test
  ↓
Release
  ↓
Feedback
  ↓
Improve
  ↓
Repeat

Instead of waiting six months to show the complete application, the team can deliver useful functionality earlier.

For example:

Sprint 1
Authentication

Sprint 2
User ManagementSprint 3
Product ManagementSprint 4
Order ManagementSprint 5
Payment

The exact structure can vary.

The important idea is continuous feedback and adaptation.

4. When Should You Choose Agile?

Agile is especially useful when:

• Requirements are expected to change
• Customer feedback is important
• The product is evolving
• The project is complex
• Features can be delivered incrementally
• The team needs frequent releases

For example, imagine building a SaaS product.

At the beginning, the team may think:

Users need Feature A
Users need Feature B
Users need Feature C

After releasing the first version, users may say:

“Feature B isn’t actually useful. We need Feature D instead.”

An iterative approach makes this kind of change easier to handle.

5. Scrum

Scrum is commonly used with Agile development.

It organizes work into time-boxed iterations called Sprints.

A typical sprint might look like:

Sprint Planning
      ↓
Development
      ↓
Daily Scrum
      ↓
Testing
      ↓
Sprint Review
      ↓
Retrospective
      ↓
Next Sprint

A team might work in:

1-week Sprint
2-week Sprint
3-week Sprint

Two-week sprints are common, but there is no universal requirement that every Scrum team must use exactly two weeks.

Scrum is useful when the team needs:

• Regular planning
• A predictable review cycle
• Prioritized work
• Frequent feedback
• A structured team process

6. Kanban

Kanban is different from Scrum.

Instead of focusing primarily on fixed-length sprints, Kanban focuses on managing the flow of work.

A simple board might look like:

Backlog
   ↓
To Do
   ↓
In Progress
   ↓
Code Review
   ↓
Testing
   ↓
Done

A team can also limit how many tasks are allowed in:

In Progress

This is called a Work In Progress (WIP) limit.

For example:

In Progress: Maximum 3 tasks

If three tasks are already being developed, the team should finish or move one before starting another.

7. When Is Kanban Useful?

Kanban can work well for:

• Maintenance teams
• Support teams
• Bug fixing
• DevOps work
• Continuous delivery
• Projects with constantly changing priorities

For example, a maintenance team might receive:

Bug #101
Bug #102
Client Request
Server Issue
Small Feature
Security Fix

New work can arrive continuously.

A strict sprint structure may not always be the most convenient way to manage that workflow.

Kanban can provide a clearer flow.

8. Spiral Model

The Spiral model focuses heavily on risk analysis.

A simplified cycle looks like:

Planning
   ↓
Risk Analysis
   ↓
Engineering
   ↓
Evaluation
   ↓
Next Spiral

The project goes through multiple cycles.

Each cycle identifies risks, develops or validates part of the solution, and uses the result to plan the next cycle.

When is Spiral useful?

It can be useful when:

• The project is large
• Technical risks are high
• Requirements are uncertain
• Failure would be expensive
• Prototypes or experiments are valuable
• Risk assessment needs to be explicit

For example, imagine developing a highly complex system involving:

New technology
Complex integrations
Security requirements
Large-scale infrastructure
Uncertain technical feasibility

It may be better to investigate the highest risks early instead of discovering them after most of the system has already been built.

9. Prototype Model

Sometimes the biggest problem is not:

“How do we build this?”

The problem is:

“What exactly should we build?”

In that situation, prototyping can help.

For example:

Requirement
    ↓
Prototype
    ↓
User Feedback
    ↓
Requirement Refinement
    ↓
Final Development

A prototype could be:

• UI mockup
• Clickable Figma design
• Proof of concept
• Technical prototype
• Small working implementation

The goal is to reduce uncertainty before investing heavily in the final implementation.

10. When Should You Use Prototyping?

Prototyping is particularly useful when:

Requirements are unclear
        +
Users don't know exactly what they want
        +
The UI/UX is important
        +
Technical feasibility is uncertain

For example, a client may say:

“I want a dashboard where employees can manage everything.”

That’s not enough information to start building a large system.

Instead, we can create:

Dashboard Prototype
       ↓
Client Review
       ↓
Changes
       ↓
Approved Design
       ↓
Development

This can prevent expensive misunderstandings.

11. Incremental Development

In incremental development, the system is built and delivered in smaller functional pieces.

For example:

Version 1
Login + User Management

Version 2
ProductsVersion 3
OrdersVersion 4
PaymentsVersion 5
Reports

Each increment adds more functionality.

The important idea is that the system grows over time.

This can be useful when the business wants to start using part of the system before the entire project is finished.

12. V-Model

The V-Model puts strong emphasis on verification and validation.

A simplified representation is:

Requirements       → Acceptance Testing
     ↓
System Design      → System Testing
     ↓
Architecture       → Integration Testing
     ↓
Module Design      → Unit Testing
     ↓
      Coding

The idea is that testing activities are planned alongside corresponding development activities.

This approach can be useful where:

• Testing requirements are strict
• Traceability is important
• Verification is critical
• Requirements are relatively stable
• The cost of failure is high

In highly regulated or safety-sensitive environments, strong verification processes can be especially important.

13. Agile vs Waterfall

The common question is:

“Which one is better?”

That’s usually the wrong question.

A better question is:

“Which one fits this project?”

Consider the differences:

FactorWaterfallAgileRequirementsUsually stableCan evolveChangesMore difficult laterExpectedFeedbackOften laterFrequentDeliveryOften later in the projectIncrementalPlanningMore upfrontContinuousCustomer involvementOften concentrated at milestonesFrequentUncertaintyLower requirement uncertainty preferredBetter suited to changing requirements

Neither approach automatically guarantees project success.

Execution, communication, technical quality, and team discipline still matter.

14. Agile vs Spiral

These approaches solve different problems.

Agile focuses heavily on:

Iteration
Feedback
Adaptation
Incremental delivery

Spiral places stronger emphasis on:

Risk identification
Risk analysis
Prototyping
Iterative development

A highly uncertain project may benefit from explicitly identifying its biggest technical and business risks before committing heavily to implementation.

15. Scrum vs Kanban

These are often compared because both can be used in Agile environments.

Scrum

Works around:

Sprints
Sprint Planning
Sprint Review
Retrospective
Product Backlog

Kanban

Works around:

Continuous Flow
Work In Progress Limits
Visual Workflow
Cycle Time

If your team works with predictable development cycles and wants a structured iteration process, Scrum may fit.

If work arrives continuously and priorities change frequently, Kanban may fit better.

Again, the project context matters more than the name of the framework.

16. Hybrid Approach

Real-world software development doesn’t always follow one textbook model.

A company might use:

Initial Planning
      ↓
Prototype
      ↓
Agile Development
      ↓
Kanban for Maintenance
      ↓
Formal Release Process

This is a hybrid approach.

For example, a large ERP project could use:

Architecture Planning
        ↓
Prototype
        ↓
Agile Feature Development
        ↓
Formal QA
        ↓
Scheduled Production Release
        ↓
Kanban Maintenance

This can be more practical than forcing the entire organization into one methodology.

17. How to Choose the Right Approach

Before selecting a development approach, ask these questions.

1. Are the requirements stable?

Yes → Sequential approaches may fit
No  → Iterative approaches may fit

2. How frequently will requirements change?

Rarely → Waterfall / structured approach may work
Frequently → Agile / iterative approach may work

3. How high are the technical risks?

Low → Standard iterative development may be enough
High → Risk-driven / prototyping approaches may help

4. Does the customer need frequent feedback?

Yes → Agile / iterative approach
No  → More sequential planning may be practical

5. Is the work continuous?

Yes → Kanban can be useful
No → Sprint-based planning may be useful

6. Are testing and traceability extremely important?

Yes → Strong verification-oriented processes may be appropriate

7. Is the product idea itself uncertain?

Yes → Prototype first

18. Example: Choosing an Approach for Different Projects

Let’s look at a few examples.

Project A — Government Data System

Suppose the requirements are:

Clearly documented
Contractually defined
Strict approval process
Formal documentation

A more structured, sequential process may be appropriate.

Project B — Startup SaaS Product

Suppose:

Requirements change frequently
Customer feedback is essential
Features are released continuously
Product-market fit is still evolving

An iterative Agile approach may be useful.

Project C — Large Technical Research Project

Suppose:

Technical feasibility is uncertain
There are major risks
New technology is involved
Failure could be expensive

A risk-driven approach such as Spiral, combined with prototypes or proof-of-concepts, may be appropriate.

Project D — Production Support Team

Suppose the team receives:

Bug
Bug
Client Request
Security Issue
Small Feature
Bug
Server Problem

Work arrives continuously.

Kanban can be a practical fit for managing this flow.

Project E — Complex UX Product

Suppose nobody is completely sure about the final interface.

Starting development immediately may be expensive.

Instead:

Research
   ↓
Prototype
   ↓
User Feedback
   ↓
UI Refinement
   ↓
Development

can reduce uncertainty.

19. Don’t Choose a Methodology Because It Is Popular

One of the biggest mistakes is saying:

“Every modern company uses Agile, so our project must use Agile.”

That’s not good engineering.

Likewise:

“Waterfall is old, so it must be bad.”

That’s also an oversimplification.

The development approach should be selected based on:

Requirements
Risk
Team
Customer
Timeline
Regulatory Constraints
Project Complexity
Feedback Frequency
Release Strategy

Not popularity.

20. Methodology Can Change During the Project

Another important point:

Your initial process does not have to remain unchanged forever.

A project might start with:

Prototype

Then move into:

Scrum

And after launch:

Kanban

For example:

Product Discovery
       ↓
Prototype
       ↓
Agile Development
       ↓
Production
       ↓
Continuous Maintenance

The project’s needs change over time.

The development process can change with them.

21. A Practical Decision Framework

Before choosing a methodology, I like to think about five dimensions:

Requirements
     +
Risk
     +
Feedback
     +
Delivery
     +
Team Workflow

Then ask:

Are requirements stable?
        ↓
How much uncertainty exists?
        ↓
How expensive are failures?
        ↓
How frequently is feedback required?
        ↓
How frequently will software be released?
        ↓
How does the team receive and manage work?

The answers should guide the development approach.

22. The Real Goal of a Methodology

The purpose of a development methodology is not to create more meetings, documents, or ceremonies.

Its purpose is to help the team:

Understand the problem
        ↓
Plan the work
        ↓
Manage uncertainty
        ↓
Build the software
        ↓
Validate the result
        ↓
Deliver value
        ↓
Improve continuously

A methodology is a tool.

It should serve the project — not the other way around.

Final Thoughts

There is no universal software development methodology.

Different projects have different characteristics.

A simple way to think about it is:

Stable Requirements
        ↓
Structured / Sequential ApproachChanging Requirements
        ↓
Agile / Iterative Approach

Continuous Incoming Work
        ↓
Kanban

Structured Iterations
        ↓
Scrum

High Technical Risk
        ↓
Risk-Driven / Spiral Approach

Unclear Product or UX
        ↓
Prototype First

Strict Verification Requirements
        ↓
V-Model / Formal Testing Approach

Complex Real-World Project
        ↓
Hybrid Approach

The important skill isn’t memorizing the names of methodologies.

The important skill is understanding why a particular approach fits a particular situation.

Before starting a project, don’t ask:

“Which methodology is the best?”

Ask:

“What is uncertain?”

“How stable are the requirements?”

“How expensive is failure?”

“How often will we need feedback?”

“How frequently do we need to release?”

“How does our team actually work?”

Once those questions are answered, choosing a development approach becomes much easier.

Good software engineering is not about blindly following a methodology.

It’s about choosing the right process for the problem you’re trying to solve.