Lesson 4 - Development Methodologies

Welcome to Development Methodologies#

Meet Ledgerly. It is an invoicing and subscription-billing web app, built by a three-person team, aimed at freelancers and small businesses. The team needs to send invoices, track payments, and handle recurring subscriptions, and they need to ship features without breaking what already works. Before they write a line of code, they must answer a quieter question: how will the team actually organize its work? That question is what a development methodology answers. A methodology is the set of rules a team follows for planning, building, and releasing software. Different methodologies suit different situations, and the Ledgerly team will end up using more than one.

This lesson walks through the major methodologies in use today, always through Ledgerly’s eyes. You will see why they run two-week Scrum sprints for their main product, why their support-ticket queue uses a Kanban board instead, and why a stricter Waterfall-style process might make sense for one compliance feature.

By the end of this lesson, you will be able to:

• Explain the Waterfall methodology and identify projects where its upfront planning fits well
• State the four values behind Agile and explain why they favor adaptation over fixed plans
• Describe Scrum’s three roles, its sprint cycle, and its four ceremonies
• Describe Kanban’s continuous flow, work-in-progress limits, and pull-based scheduling
• Choose an appropriate methodology, or a hybrid of methodologies, for a given team and project

Waterfall: Plan Now, Build Later#

Waterfall is a methodology where a team completes one phase fully before starting the next. The phases usually run in this order: gather requirements, design the system, build it, test it, then release it. Each phase produces a document or a deliverable that the next phase depends on. Nobody starts building until the design is signed off, and nobody tests until the building is finished. The name comes from the image of water falling downward through a fixed set of stages, never flowing back uphill.

Waterfall works best when requirements are stable and unlikely to change during the project. It also suits projects that need heavy documentation, such as those under legal or regulatory review. Suppose Ledgerly signs a customer in a regulated industry that requires an audit-trail feature: every invoice edit must be logged, timestamped, and tied to a named user, with a paper trail an external auditor can check. The rules for what counts as an acceptable audit log rarely change once a regulator has approved them. The team can write the full specification up front, get it approved by the customer’s compliance officer, then build and test it as one block of work. Changing course midway would mean re-approval, which costs more than getting it right the first time.

Waterfall has a real cost, though: nobody sees working software until testing begins. If the compliance officer misunderstood the specification in month one, the team will not find out until month five. That risk is acceptable only when requirements truly will not change and stakeholders can commit time to a thorough, upfront review.

Agile: Adapting as You Learn#

Agile is not a single process. It is a set of shared values that favor adapting to change over locking in a fixed plan. Four statements capture the idea: value people and their interactions over rigid processes and tools; value working software over exhaustive documentation; value collaborating with the customer over negotiating a fixed contract; and value responding to change over following a plan drawn up months earlier. None of these throw away planning, documentation, or contracts. They say which one wins when the two conflict.

For most of Ledgerly’s product, requirements are genuinely uncertain. The team does not know yet whether freelancers want automatic late-payment reminders or a simpler one-click reminder button, and only real usage will tell them. An agile approach lets them build a small piece, show it to a handful of pilot customers, and adjust the next piece based on what those customers actually do. Waterfall would force the team to guess the whole feature set up front and live with a wrong guess for months.

Agile is a philosophy, not a checklist of ceremonies. Scrum and Kanban, covered next, are two concrete frameworks that put agile values into practice, each in a different way.

Scrum: Agile in Two-Week Sprints#

Scrum is the most widely used agile framework, and it is the one Ledgerly’s three-person team chooses for building the core invoicing product. Scrum organizes work into fixed-length iterations called sprints, and Ledgerly runs theirs at two weeks each. At the end of every sprint, the team delivers a working, demonstrable slice of the product, rather than a partially finished pile of code.

Scrum defines three roles. The Product Owner decides what gets built and in what order, keeping a prioritized list of work called the backlog. On Ledgerly, one founder plays this role, prioritizing features like “add PayPal as a payment option” above “redesign the invoice PDF template.” The Scrum Master protects the team’s ability to focus, removing anything that blocks progress and keeping meetings short and useful. The remaining Development Team members do the actual design, coding, and testing, and they decide together how much work fits in a sprint.

Four recurring ceremonies structure each sprint:

• Sprint Planning — the team picks backlog items for the upcoming two weeks and agrees on a plan to complete them.
• Daily Standup — a short, roughly fifteen-minute check-in where each person states what they did, what they will do next, and what is blocking them.
• Sprint Review — the team demonstrates finished work to stakeholders, including Ledgerly’s pilot customers, and collects feedback.
• Sprint Retrospective — the team reflects privately on how the sprint went and agrees on one or two process changes to try next time.

Teams often measure how much work they complete per sprint using story points, a relative unit of effort assigned to each backlog item. Tracking points completed per sprint gives a team its velocity, the average amount of work it finishes in a typical sprint, which helps forecast how many sprints a larger backlog will take.

sprint_points_completed = [18, 22, 20, 25, 23]


def average_velocity(points):
    return sum(points) / len(points)


def forecast_sprints(remaining_points, velocity):
    import math
    return math.ceil(remaining_points / velocity)


velocity = average_velocity(sprint_points_completed)
remaining_backlog = 130
sprints_needed = forecast_sprints(remaining_backlog, velocity)

print(f"Average velocity: {velocity:.1f} story points per sprint")
print(f"Sprints needed for {remaining_backlog} points of remaining backlog: {sprints_needed}")

Running this against Ledgerly’s last five sprints prints:

Average velocity: 21.6 story points per sprint
Sprints needed for 130 points of remaining backlog: 7

With an average velocity of 21.6 points per sprint, the team can tell their next pilot customer that the remaining 130-point backlog will likely take about seven more sprints, or roughly fourteen weeks. That estimate is not a promise, but it is far more grounded than a guess made before any sprint had run.

Kanban: Continuous Flow for Unpredictable Work#

Sprints work well when a team can predict, two weeks ahead, roughly what it will build. Ledgerly’s support-ticket queue does not behave that way. A customer’s payment webhook might fail at any time, an invoice PDF might render incorrectly for one browser, and these tickets cannot wait for the next sprint planning meeting. For this queue, the team uses Kanban instead.

Kanban tracks work on a board with columns representing stages, commonly something like Backlog, In Progress, Review, and Done. Each ticket moves across the board as it advances, and there is no fixed two-week boundary. Work simply flows continuously, and a ticket can start the moment someone has the capacity to take it.

The defining rule of Kanban is the work-in-progress limit, usually shortened to WIP limit: a cap on how many tickets can sit in a given column at once. If the “Review” column has a WIP limit of one, nobody is allowed to move a second ticket into Review until the first one moves out. This forces the team to finish work already in flight instead of starting new work and letting everything pile up half-done. New work only enters a column when there is open capacity, which is called a pull system, since work is pulled forward rather than pushed in by a plan.

The following script checks whether Ledgerly’s support board currently violates any of its WIP limits.

board = {
    "In Progress": ["Refund not processing", "Stripe webhook retry logic"],
    "Awaiting Customer Reply": ["Invoice PDF missing logo"],
    "Review": ["Login redirect loop", "Failed payment email wording"],
    "Done": ["Password reset email delay"],
}

wip_limits = {"In Progress": 2, "Awaiting Customer Reply": 3, "Review": 1}


def check_wip(board, limits):
    violations = []
    for column, limit in limits.items():
        count = len(board.get(column, []))
        if count > limit:
            violations.append((column, count, limit))
    return violations


violations = check_wip(board, wip_limits)
if violations:
    for column, count, limit in violations:
        print(f"WIP limit exceeded in '{column}': {count} tickets (limit {limit})")
else:
    print("All columns are within their WIP limits.")

Running this prints:

WIP limit exceeded in 'Review': 2 tickets (limit 1)

The “Review” column has two tickets against a limit of one, which tells the team to stop pulling new tickets into Review and instead help finish one of the two already there. This is exactly the discipline a WIP limit is meant to enforce: fewer things half-done, more things fully done.

Choosing a Methodology, or Blending a Few#

No single methodology is correct for every situation, and Ledgerly’s own setup proves it: the same three people run Scrum for their product roadmap, Kanban for support, and would lean toward Waterfall for a compliance feature with fixed, externally reviewed requirements. Three questions help decide which approach fits a given piece of work.

First, how stable are the requirements? If they are fixed and well understood, as with a regulatory audit log, Waterfall’s upfront planning avoids wasted rework. If they will keep changing as the team learns, Scrum or Kanban fit better. Second, does the work arrive in predictable batches or unpredictably? Product features that a team plans ahead of time suit Scrum’s fixed sprints. Support tickets and production incidents arrive whenever they arrive, which suits Kanban’s continuous flow. Third, how much documentation and formal sign-off does the work require? Regulated or safety-critical work often needs Waterfall’s phase-gated paper trail; a small team’s everyday feature work usually does not.

Many real teams do not pick one methodology and use it everywhere. A hybrid approach, sometimes described as “Waterfall at the edges, Agile in the middle,” keeps a Waterfall-style requirements sign-off for a specific regulated feature while running Scrum for the rest of the product. Ledgerly’s structure already works this way, without anyone needing to declare a single company-wide methodology.

Practice Exercises#

Exercise 1: Match the methodology to the project#

Ledgerly is asked to add a new feature: a government tax authority requires a specific, fixed export format for invoice records, with a full audit before release. Which methodology fits this feature best, and why?

Exercise 2: Diagnose a broken Kanban board#

Ledgerly’s support board has a WIP limit of 2 for “In Progress,” but the team keeps starting new tickets while old ones sit unfinished, and the column often holds 5 tickets. What is going wrong, and what should the team do differently?

Exercise 3: Compute a velocity forecast#

Ledgerly’s team completes 15, 19, 17, and 21 story points over four sprints. Using the average_velocity function shown in this lesson, compute their average velocity, and estimate how many more sprints a 100-point backlog will take.

Summary#

A development methodology is the set of rules a team uses to plan, build, and release software, and no single methodology fits every project. Waterfall completes one phase fully before the next begins, and it suits stable, well-documented requirements like a regulatory audit feature. Agile is a set of values favoring adaptation over a fixed plan, and it underlies both frameworks Ledgerly actually uses day to day. Scrum organizes work into fixed-length sprints with three roles and four ceremonies, and it fits Ledgerly’s product roadmap, where a velocity of 21.6 points per sprint let the team forecast seven more sprints of work. Kanban tracks continuous flow through columns bounded by work-in-progress limits, and it fits Ledgerly’s unpredictable support queue, where a single WIP-limit check caught two tickets stuck in “Review.” Real teams often blend methodologies rather than picking one for the whole company.

Key Concepts#

• Development methodology — the rules a team follows for planning, building, and releasing software.
• Waterfall — a sequential methodology that completes each phase fully before the next begins.
• Agile — a set of values favoring adaptation and working software over rigid, upfront plans.
• Scrum — an agile framework of fixed-length sprints, three roles, and four recurring ceremonies.
• Velocity — the average amount of work, in story points, a team completes per sprint.
• Kanban — a continuous-flow methodology that limits work in progress instead of using fixed iterations.
• WIP limit — a cap on how many items can sit in one board column at the same time.
• Hybrid approach — combining methodologies, such as Waterfall for one feature and Scrum for the rest.

Why This Matters#

Choosing a methodology is not a formality before “real” engineering work begins; it decides how fast a team learns it was wrong and how cheaply it can correct course. Ledgerly’s three-person team could have picked one methodology and forced every kind of work through it, but that would have meant either burying support tickets in sprint planning or forcing a regulator’s fixed requirements through endless rounds of agile change. Matching the methodology to the actual shape of the work, stable versus uncertain, scheduled versus unpredictable, is what lets a small team move quickly without missing what matters. The next lesson turns this plan into a concrete project outline for Ledgerly itself.

Next Steps#

Continue Building Your Skills#

You now know how Waterfall, Scrum, and Kanban each organize work, and you have seen why Ledgerly’s small team uses more than one of them at once. Next, you will put this thinking into practice by planning Ledgerly’s own methodology mix as a guided project.