Development Methodologies

A development methodology is a shared agreement about how a team turns an idea into working software: what happens first, how work is split up, and when the team stops to check it is building the right thing. Without one, every developer follows their own instincts, and the project pays for the disagreements.

What a methodology actually decides

Every software project has the same raw activities: working out what to build, designing it, writing the code, testing it and releasing it. A methodology does not add new activities. It decides how they are arranged.

The main questions it answers are:

• How big is each step? One large plan for the whole product, or a small slice at a time?
• When does feedback arrive? At the end of the project, or every week or two?
• Who decides what comes next? A plan written up front, a product owner, or whatever the board says is ready?
• How is progress made visible? A schedule, a sprint goal, or cards moving across a board?

The four approaches below give different answers to those questions.

Waterfall: one phase at a time

Waterfall runs the project as a sequence of phases: requirements, design, build, test, deploy. Each phase finishes and is signed off before the next begins, so work flows downwards like water over a series of steps.

Why teams use it

The strength of Waterfall is predictability. Because the requirements are fixed early, the team can estimate cost and time, write a contract around them and plan who is needed when. That matters when:

• the requirements are genuinely stable and well understood;
• mistakes are expensive to undo, such as software tied to hardware or regulated systems that need formal approval at each stage;
• a customer needs a fixed price and a fixed scope agreed in advance.

What it costs

The weakness is that feedback comes late. Nobody uses the software until the build and test phases are over, which might be months after the requirements were written. If the requirements were wrong, or the world changed in the meantime, the team finds out at the most expensive point to fix it.

Agile: small pieces, shipped often

Agile is less a single method than a set of values. The Manifesto for Agile Software Development, written in 2001, prefers individuals and interactions, working software, customer collaboration and responding to change, over processes and tools, comprehensive documentation, contract negotiation and following a plan. It does not say the second list is worthless, only that the first matters more.

In practice, Agile teams build in short cycles. Each cycle delivers a small, working, tested piece of the product. Users or stakeholders see it, the team learns something, and the next cycle is planned with that knowledge. Instead of one big bet, the project becomes many small ones.

Why it works

Short cycles shrink the cost of being wrong. A feature nobody wants is discovered after two weeks, not after a year. The product is usable early, so value arrives sooner, and priorities can change without tearing up a master plan. Shipping often also shapes how a team uses Git: frequent releases tend to go with short-lived branches, as covered in Branching Strategies.

Where it goes wrong

Agile is easy to claim and harder to practise. Common failures include treating 'we don't plan' as permission for chaos, skipping tests because the cycle is short, and shipping small pieces that never add up to a coherent product. Agile still needs a direction; it just revisits that direction often.

Scrum: Agile with a timetable

Scrum is the most widely used framework for putting Agile into practice. It gives the short cycle a fixed shape, called a sprint, of one month or less, and often two weeks.

Scrum defines three roles:

• Product Owner: decides what is most valuable to build next and keeps the product backlog, the ordered list of work, in shape.
• Scrum Master: helps the team follow Scrum and removes obstacles in its way.
• Developers: the people who build the increment, whatever their speciality.

It also defines a set of events, which is where the reputation for meetings comes from:

• Sprint Planning picks the sprint goal and the work for it.
• The Daily Scrum is a 15-minute check on progress towards that goal.
• The Sprint Review shows what was built to stakeholders.
• The Sprint Retrospective looks at how the team worked and what to change.

Each event has a time limit, and each exists to create a feedback point. When the meetings feel pointless, it is usually because they have lost that purpose: a Daily Scrum that turns into a long status report, or a retrospective whose actions never happen.

Scrum suits a team building a product with a clear owner and a steady stream of features. It is a poorer fit for work that arrives unpredictably, such as support tickets or operations, where committing to a fixed batch for two weeks does not match reality.

Kanban: make the work visible

Kanban comes from manufacturing, where cards were used to signal when more work was needed. In software it starts with a board. Each task is a card, and the columns show its state, at minimum 'To Do', 'Doing' and 'Done'.

The board makes the work visible, but the real power of Kanban comes from two further ideas:

• Work-in-progress (WIP) limits. Each column has a maximum number of cards. If 'Doing' is full, nobody starts anything new; they help finish what is already there. This stops the common pattern of ten things half done and nothing shipped.
• Pull, not push. People take the next card when they have capacity, instead of having work assigned to them regardless of load.

Kanban has no sprints and no required roles, so work flows continuously. That makes it a good fit for support, operations and maintenance teams, and for small teams that find Scrum's structure heavy. Its risk is the opposite of Scrum's: with no fixed rhythm, a team can go a long time without stepping back to review its priorities unless it builds that habit deliberately.

Practices sit inside methodologies

Writing tests before code, known as test-driven development (TDD), is usually described as a practice rather than a whole methodology. It came out of Extreme Programming, one of the early Agile methods, alongside ideas such as pair programming and continuous integration.

The distinction matters. A methodology decides how the project is organised; a practice decides how the code is written. A Scrum team can use TDD, and so can a Kanban team. Choosing one does not rule out the other.

A worked example

Picture a four-person team building an app for booking pet sitters.

With Waterfall, the team spends the first weeks writing a full specification: search, booking, payments, reviews, messaging. Design follows, then several months of building, then testing. On launch, users say the thing they wanted most was to see the sitter's availability at a glance, which nobody wrote down. Changing the booking flow now touches code that was finished months ago.

With Scrum, the first two-week sprint aims for something small but usable: a list of sitters and a basic booking request. At the Sprint Review, a handful of pet owners try it and ask about availability. The Product Owner moves an availability calendar to the top of the backlog, and it is built in the next sprint.

With Kanban, the same backlog is a column of cards. The team has a WIP limit of three in 'Doing'. When a developer finishes the booking form, they pull the next most important card. Bug reports from early users join the board and are handled in the same flow, without waiting for a sprint boundary.

None of these is automatically right. If the app had to pass a payments audit before any user could touch it, some up-front planning around that part would be sensible even inside an Agile process.

Choosing one

Most real teams blend these approaches, and that is fine as long as the blend is deliberate. Some useful questions:

Big, risky projects benefit from more planning. Fast-moving products benefit from more flexibility. The mistake is picking a methodology because it is fashionable, then following its rituals without understanding what each one is for.

Common mistakes

• Cargo-cult process. Holding every Scrum event or keeping a Kanban board without using them to change anything.
• Calling chaos Agile. Short cycles still need a goal, tests and a backlog in order of value.
• Never revisiting the choice. A method that suited a two-person prototype may not suit a twenty-person product.
• Treating the method as the goal. The goal is working software that people want; the method is only a tool for getting there.

Key takeaways

• A development methodology is how a team organises planning, building, testing and releasing.
• Waterfall runs one phase at a time and is predictable, but feedback comes late.
• Agile builds in small, working pieces so the team can learn and adjust often.
• Scrum adds fixed-length sprints, three roles and timeboxed events; Kanban adds a visible board, WIP limits and continuous flow.
• No methodology is magic: match it to the project's risk and pace, and keep what gives you useful feedback.