Waterfall, Agile, and Scrum: Choosing How to Work

The first three lessons covered the substance of project management, the role, planning, and execution. This lesson covers how that work is organized, because the same project can be run with very different rhythms, and the choice matters.

Methodologies fall into two broad philosophies:

• Plan-driven (predictive), the waterfall approach. Plan the whole project in detail up front, then execute the plan in sequence. Best when the requirements are well understood and stable.
• Adaptive (iterative), the agile approach. Work in short cycles, delivering a little at a time and adjusting continuously based on feedback. Best when requirements are uncertain or likely to change.

Neither is universally "better", they suit different situations, and much modern work blends them. But they represent genuinely different mindsets about planning and change, and a project manager needs to understand both. Job listings routinely ask for agile or Scrum experience, so for a career switcher this vocabulary is not optional.

This lesson explains waterfall and agile, then goes deeper on Scrum, the most common agile framework, because knowing how a Scrum team actually runs is one of the most practically useful things an aspiring PM can learn. It closes with how to choose a methodology and how to break into the field, certifications, first roles, and showing your skills.

The waterfall methodology is the traditional, plan-driven approach, and it works exactly like the planning in Lesson 2 taken to completion. The project flows through sequential phases, each finished before the next begins, like water flowing down steps:

Requirements -> Design -> Build -> Test -> Deploy

You gather all requirements, then design the whole solution, then build it, then test it, then release. Each phase has defined deliverables and sign-off before moving on.

Strengths:

• Predictability. With everything planned up front, you have a clear scope, timeline, and budget from the start, good for fixed-price contracts and stakeholders who need firm commitments.
• Clarity and documentation. Well-defined stages and thorough documentation make it easy to follow and hand off.
• Fit for stable, well-understood work. When you truly know what is needed and it will not change (construction, regulated hardware, some infrastructure), planning it all once is efficient.

Weaknesses:

• Inflexible to change. Its great assumption, that requirements are known and stable, often fails, and changing course late is costly because everything was planned around the original.
• Late feedback. You do not see a working result until near the end, so if the plan was wrong, you find out expensively and late.

Waterfall is not obsolete, it is the right tool for stable, well-defined projects. But its rigidity in the face of change is exactly what motivated the agile alternative.

Agile emerged, formalized in the 2001 Agile Manifesto written by a group of software developers, as a response to waterfall's struggles with change. Its core idea: instead of planning everything up front and resisting change, work in short iterations, deliver working results frequently, and adapt continuously based on feedback.

The Agile Manifesto expresses four value preferences (it values the second item too, but favors the first):

• Individuals and interactions over processes and tools.
• Working software (a working product) over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

In practice, agile means:

• Iterative delivery. Build the product in small increments over short cycles, producing something usable each cycle rather than one big release at the end.
• Embracing change. Requirements are expected to evolve; feedback from each increment shapes the next, so change is welcomed, not fought.
• Continuous feedback. Frequent delivery to users and stakeholders means you learn early and often whether you are building the right thing.

The trade-off mirrors waterfall's in reverse: agile handles uncertainty and change far better, but offers less up-front predictability about the exact final scope and date, because those emerge as you go. Agile is a philosophy, not a single procedure; the most popular concrete framework for practicing it is Scrum.

Scrum is the most widely used agile framework, a specific set of roles, events, and artifacts for running iterative work. Its heartbeat is the sprint: a short, fixed cycle (commonly two weeks) in which the team delivers a usable increment of the product.

Three roles:

• Product owner: owns and prioritizes the backlog, deciding what the team builds next and why (the value-focused role).
• Scrum master: a servant-leader who facilitates the process, removes blockers, and coaches the team, often the closest Scrum equivalent of a project manager.
• Development team: the people who build the increment, self-organizing about how.

Key artifacts:

• Product backlog: the prioritized master list of everything the product might need.
• Sprint backlog: the slice of items the team commits to for the current sprint.

The events (ceremonies):

• Sprint planning: the team selects and commits to what it will deliver this sprint.
• Daily stand-up: a short daily sync, what I did, what I will do, what is blocking me.
• Sprint review: at the end, demo the working increment to stakeholders for feedback.
• Sprint retrospective: the team reflects on how to work better next sprint.

The cycle repeats every sprint: plan, build with daily syncs, review, reflect, then start the next sprint with what was learned. This rhythm delivers working value continuously and builds in inspection and adaptation, the agile ideal made concrete. Notice this changes the PM's flavor: much traditional PM coordination is spread across the product owner and scrum master roles, which is why understanding Scrum is essential vocabulary in modern project work.

So which methodology should a project use? The honest answer is it depends on the project, and the deciding factor is mostly how stable and well-understood the requirements are.

A few guiding questions: Are the requirements likely to change? (Change favors agile.) Do you need firm up-front cost and date commitments? (That favors waterfall.) Can you deliver value in small pieces, or only as one finished whole? (Incremental value favors agile.)

Crucially, most real organizations run a hybrid: some up-front planning for structure and predictability, combined with iterative delivery and adaptation for the uncertain parts. PMI's own guidance and job market both increasingly favor people who can work across both worlds. So the goal for a switcher is not to become dogmatic about one camp, but to understand both philosophies and apply the right blend to the situation, which is exactly what a thoughtful project manager does.

You now have the core discipline: the role, planning, execution, and methodologies. Here is how a career switcher turns that into a job.

Recognize and reframe your experience. You have almost certainly run projects already, an event, a move, a work initiative, a volunteer program. Reframe that as project management: you defined scope, scheduled, coordinated people, managed risks, and delivered. This is real, describable experience.

Consider a certification. Credentials carry real weight in this field:

• CAPM (Certified Associate in Project Management, from PMI): entry-level, aimed at those without extensive experience, a strong signal for a switcher.
• PMP (Project Management Professional, from PMI): the gold standard, but it requires documented project experience, so it is a target for after you have some.
• Certified ScrumMaster (CSM) or similar agile credentials: valuable given how much work is agile, and often accessible early.

Build and show the skills:

• Start where you are. Volunteer to coordinate a project at your current job, an on-ramp that builds real, citable experience.
• Learn the tools. Familiarity with common project and agile tools (task boards, Gantt and backlog tools) is practical and expected.
• Speak the language. In applications and interviews, use the vocabulary correctly, scope, iron triangle, critical path, risk management, stakeholders, sprints, and tell concrete stories of delivering something.

Project management rewards organization, communication, calm problem-solving, and ownership, transferable strengths you can build deliberately, backed by an accessible certification path. Demand is high and broad across industries. The role is learnable, the path is well-marked, and you now have the map.

Step back and see the entire cursus as one connected craft.

The thread through all of it: a project manager takes a temporary, unique effort and drives it to a successful delivery, defining the work, planning it, steering it through reality, and organizing it in the rhythm that fits, all while leading people through communication rather than authority. Whether run as waterfall or Scrum, the underlying job is the same: get a defined piece of work done well, on scope, on time, on budget, with a team.

For a career switcher, the encouraging summary is that this is a learnable, high-demand discipline built on transferable human skills. You do not need a specific degree; you need organization, communication, judgment about trade-offs, and the willingness to own an outcome, plus the concrete practices this cursus laid out and, over time, a certification to prove it.

The best next step is to practice: take something real you need to accomplish, and run it deliberately as a project, define the scope, plan it, execute and control it, choose a fitting approach. Do that once, consciously, and you have not just learned project management, you have started doing it.

Waterfall runs sequential phases to one big release, best for stable requirements; agile runs repeating short sprints delivering increments with continuous feedback, best for changing requirements; most real projects blend the two.