Software development methodologies: which one fits your project

Software development methodologies are different answers to one question: how should a team handle change? Waterfall plans the whole project up front and moves through fixed phases. The agile family, including Scrum, Kanban and adaptive software development, expects change and absorbs it in short cycles that each end in working software. DevOps extends those cycles into deployment and operations. This guide explains how each works, where each fits, and what we use on client projects; for the services themselves, see custom software development services.

1Waterfall

How it works. Requirements, design, build, test and deploy, one after another. Each phase is finished and signed off before the next starts.

Where it fits. Projects whose requirements are stable and well understood, where changes are expensive or regulated, and where a fixed price for a fixed scope is the goal.

Where it fails. When the requirements were wrong or incomplete. The mistake surfaces in testing, at the end, when it is most expensive to fix.

2The agile family

In 2001, seventeen practitioners published the Manifesto for Agile Software Development. It values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan, while noting that the items on the right still have value. Several methodologies put those values into practice.

Scrum

Work happens in sprints of a fixed length, usually one to four weeks. The Scrum Guide defines three accountabilities (a Product Owner who orders the backlog, Developers who build, and a Scrum Master who helps the team work well) and a set of events: sprint planning, a daily scrum, a sprint review and a retrospective. Each sprint should produce a usable increment.

Fits: product development with a dedicated team and an engaged product owner.

Kanban

Work items flow across a board (for example, to do, in progress, review, done), with limits on how many can be in progress at once. There are no sprints; items are pulled when there is capacity.

Fits: support, maintenance and operations work, where requests arrive continuously and vary in size.

Adaptive software development

Adaptive software development is associated with Jim Highsmith, one of the manifesto's authors. It replaces a fixed plan with a repeating cycle of speculate (plan, accepting that the plan will change), collaborate (build together, across roles) and learn (review results with the customer and adjust). It is built for projects where uncertainty is high and learning is the point.

Fits: new products and complex systems where requirements will only become clear as users try early versions.

Extreme Programming (XP)

XP focuses on engineering practices: pair programming, test-first development, continuous integration and small releases.

Fits: teams that want to raise code quality and release safely and often.

3DevOps

DevOps joins development and operations: automated builds, tests and deployments, infrastructure described as code, and monitoring that feeds back into development. DORA's research on software delivery measures the results with a small set of numbers, such as how often a team deploys, how long a change takes to reach production, how often changes fail, and how quickly service is restored.

4Agile vs waterfall: a comparison

5How to choose

1. How stable are the requirements? Stable and well understood: plan-driven is fine. Uncertain: agile.
2. How is the work contracted? A fixed price needs a fixed scope; a dedicated team suits Scrum or Kanban. Our guide to the dedicated development team model explains the contract side.
3. Who can decide? Agile needs a product owner who is available every week. Without one, agile turns into drift.
4. Is the work a project or a flow? Projects suit sprints; continuous support suits Kanban.

6What we use, and why

On client projects we use a hybrid that combines the strengths of both:

• Up front, like waterfall: a written scope with what is in and what is out, the data model, the integrations and a price. Clients need a number, and the written scope prevents most disputes.
• During the build, like Scrum: one- or two-week cycles, each ending with working software on a staging site the client can log in to.
• After launch, like Kanban: support and small changes flow through a board with agreed response times.
• Throughout, like DevOps: automated tests and deployments, so every cycle can ship.

It is the same approach we use to build our own products, such as MatrixHR and RE-ERP.

7Methodologies and contracts

How a project is contracted shapes how it can be run:

• Fixed price, fixed scope needs a detailed specification up front, which pulls towards waterfall. You can still deliver in short cycles; the change process is what differs.
• Time and materials suits agile methods: you pay for the work done, and priorities can change each cycle.
• A dedicated team is time and materials at a monthly rate, and works best with Scrum or Kanban and a strong product owner.

Mixing the wrong contract with the wrong method causes friction: a fixed price with constantly changing priorities, or a time-and-materials contract with nobody setting priorities. Our guide to the dedicated development team model covers the contract side in more detail.

8Methodology and team size

• One or two developers: Kanban, with a weekly check-in, is usually enough. Heavy ceremony wastes a small team's time.
• A team of three to nine: Scrum fits well, with a product owner and regular reviews.
• Several teams: coordination becomes the main problem. Shared planning, clear interfaces between teams and a common definition of done matter more than the framework each team uses.

9How to tell if a methodology is working

Whatever you choose, judge it by results, not by how faithfully the rituals are followed:

1. Working software is delivered frequently, and the customer can use it.
2. Problems are found early, not in a final testing phase.
3. Priorities are clear, and the team knows what matters most this week.
4. Estimates improve over time.
5. The team can release without fear.

If these are true, the methodology is working, whatever it is called.

10A short glossary

• Backlog: the ordered list of work still to do.
• Sprint: a fixed period, usually one to four weeks, in which a Scrum team delivers a usable increment.
• Increment: working software added in a sprint.
• Work-in-progress limit: in Kanban, the maximum number of items allowed in a column at once.
• Definition of done: the shared checklist an item must meet before it counts as finished, such as tested, reviewed and deployed.
• Retrospective: a regular meeting where the team reviews how it works and agrees one or two improvements.
• Continuous integration: merging and testing code changes automatically, many times a day.

11The bottom line

No methodology rescues a project without clear priorities and a person who can decide. Choose the lightest process that keeps working software arriving every week or two, write the scope down, and adjust the process when the results tell you to.

12Common mistakes

• Agile in name only: sprints without working software at the end.
• Waterfall without sign-off: a plan nobody really agreed to.
• No product owner, so the backlog is a wish list.
• Ceremony over delivery: hours in meetings, little in production.

If your project shows these signs, our guide to technical challenges in software development covers the fixes, and software design consulting can review a project in trouble.