Learn the basics of Agile, predictive, and hybrid project management in plain English—see how they differ and when to use each approach.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Key terms
Agile project management: A flexible approach to managing projects that delivers work in small, usable pieces, involves stakeholders throughout, and adapts quickly to change.
Predictive project management: A structured, plan-first approach where the project’s scope, timeline, and resources are defined upfront and followed through in a set sequence.
Hybrid project management: A mix of Agile and predictive methods, tailored to suit the specific needs, risks, and environment of a project.
Waterfall project management: A term used to criticize poor practice where each project phase is done strictly as planned, without room for feedback or revision. Often misused today as a general label for all predictive methods, though modern predictive approaches allow for iteration and change.
Iterative development: A way of working where tasks are repeated in short cycles, with each version improving on the last based on feedback and learning.
Cost of change: The expenses incurred when making modifications or corrections to a project’s plan. This cost typically increases as the project progresses.
Project management: The art of getting things done.
8.1.1: Don’t go chasing waterfalls…
Up to this point, we’ve explored the initiation and planning stages of project management using a style best described as predictive.
That means working through a clear, structured process to define what the project will deliver, how it will be delivered, and what people, time, and money will be needed to get the job done.
Predictive approaches aim to map out the delivery process with as much accuracy as possible before the real work begins.
Frameworks like PMBOK, PRINCE2, and ISO 21500 are good examples of this. They’re especially useful in projects where the deliverables are well understood from the outset, and where change needs to be carefully managed, not welcomed midstream.
But as we know, sometimes strict methodology can get in the way of a successful project.
The term “waterfall” was first used by Dr. Winston Royce in a 1970 presentation at a tech conference in Los Angeles to describe a particular type of project methodology—and the term wasn’t meant kindly.
In the model he described, the stages of a project—initiation, planning, delivery, and close—happen one after the other, in a single, downward flow. You don’t move to the next stage until the current one is done.
The problem? Water doesn’t flow uphill.
Royce’s point was that once a project was set in motion under a waterfall approach, there was no easy way to go back. If something changed, or if the customer realized late in the process that their needs had shifted, tough luck. Going back meant rework, delays, and extra cost.
Royce wasn’t against structure, but he was challenging the kind of rigid thinking that valued process over outcomes. His paper criticized the way project managers could become so locked into their plan that they lost sight of what actually mattered: delivering a working product that met stakeholder needs.
This issue was especially common in engineering-led environments, where technical specialists were great at solving problems, but not always great at talking to the people they were solving them for. Royce was saying: maybe it’s time we change that.
8.1.2: Enter the Agile
So where does Agile come in?
Agile emerged as a response to the limitations of traditional project management practices that became known as waterfall. It offered an alternative—a way to stay flexible, keep users involved, and adapt to change as the project unfolded.
You’ve probably heard the term “agile” thrown around in a few different contexts. These days, agility is often used as a buzzword—something that implies speed, adaptability, responsiveness, and the ability to change course when needed.
And while some of the branding can be a bit over-the-top, the core ideas are practical and grounded in real project experience.
Agile isn’t just about going faster. It’s about delivering value sooner, learning from feedback, and adjusting your direction based on what you discover along the way.
One of the most important shifts Agile introduced was a focus on the people using the product, not just those building it. In an Agile project, users and stakeholders are involved throughout, helping to shape what gets delivered. They’re not just invited in at the end to evaluate what’s already built.
This represented a major shift in thinking. Rather than locking down a plan at the start and sticking to it no matter what, Agile welcomes change. It assumes you probably don’t know everything upfront, and that the smartest thing you can do is learn as you go.
And Agile doesn’t just shift what we do—it shifts how we think. It values collaboration over control, learning over certainty, and conversation over documentation. It’s not anti-process, but it is pro-people.
Agile teams ask not just “How do we stick to the plan?” but “How do we make sure we’re solving the right problem for the people who matter most?”
8.1.3: So what changed, and why did it stick?
The early signs of this shift in thinking can actually be found in Royce’s original paper. Interestingly, seven of the nine pages he wrote focused on how the basic waterfall model could be improved. He talked about iterative development, early testing, and continuous customer involvement—ideas that form the backbone of Agile today.
What became the agile community simply took those ideas and ran with them.
What really made Agile stick, though, was that it solved real problems project teams were facing every day, such as:
- Endless planning that didn’t reflect reality
- Expensive rework caused by late feedback
- Projects that looked good on paper but missed the mark in practice
- Teams delivering what worked for them, but not what was actually needed
Agile gave teams a way to work in smaller pieces, get feedback earlier, and adjust based on what they learned without having to throw out everything and start again. It made change less scary because it was baked into the process from the start.
It also gave users a voice throughout the process, not just at the end. That shift alone has helped countless projects deliver more relevant, more usable outcomes.
And it’s not just a software thing. While Agile was born in software development, its principles apply anywhere you need to stay flexible, test ideas, and deliver in fast-moving environments. These days, Agile is used in marketing, education, service design, health, finance, and more.
Agile didn’t gain popularity because it was trendy—it stuck because it works in real life, especially when uncertainty is high and the stakes are real.
8.1.4: Predictive vs Agile (and the space in between)
Before we go further, let’s clear up a common point of confusion.
The terms “predictive” and “waterfall” are sometimes used interchangeably, but they’re not quite the same. Modern predictive methods do allow for iteration, particularly between planning and delivery stages.
If you’ll recall our lifecycle infographic, you’ll know that predictive planning isn’t completely locked down—it evolves as more information becomes available.
So it’s not about choosing between being flexible or being structured. It’s about understanding what kind of flexibility is needed and where it fits best.
Agile doesn’t replace predictive methods. It simply offers a different structure. Instead of moving through the entire project lifecycle once, once the project is initiated, Agile teams repeat the cycle multiple times in short, focused bursts. Each cycle delivers something usable, gathers feedback, and sets up the next round of work.
This approach is particularly powerful in projects where:
- The end result isn’t fully known upfront
- Stakeholder needs might change during delivery
- New ideas or technologies are likely to emerge
- Speed to value is more important than sticking rigidly to a plan
And no, Agile isn’t ideal for every situation. You probably don’t want to build a bridge or a power plant using Agile. But you might use Agile to design a digital component of the project, create training resources, or develop a customer engagement platform.
Agile and predictive aren’t opposites—they’re complementary. The most effective project managers understand both approaches and use them interchangeably or together, depending on the job at hand.
We’ll dig into this further as the course continues. For now, the key takeaway is this:
Agile didn’t appear out of nowhere. It was built to address very real project challenges. And when used well, it can make your work more responsive, more collaborative, and more focused on delivering real value—early and often.
8.1.5: Our old friend, the cost of change
We first introduced the idea of the cost of change back in earlier units, and now it’s time to take another look. This principle plays a huge role in helping us decide whether to manage a project using a predictive, Agile, or hybrid approach.
In simple terms, the cost of change means that the further into a project you go, the harder and more expensive it is to change your mind.
Early in the project, making a change might involve editing a document or having a quick chat. Later on, it might mean redoing weeks of work—or worse, fixing the damage caused by delivering the wrong thing.
The more uncertainty you’re facing, the more likely it is you’ll need to make changes, and the more important it becomes to manage those changes carefully.
Predictive project management works best in situations where we can reasonably forecast what’s going to happen. Because we expect things to go mostly according to plan, we put significant time and effort into defining the scope clearly, engaging stakeholders early, confirming requirements, and building a solid plan up front.
Why so much prep? Because in predictive projects, the cost of change increases steeply once delivery starts. So it’s worth doing the hard thinking early to avoid problems later.
Imagine, for example, a government agency rolling out a new compliance requirement across all registered providers. The legislation is set, the outcomes are fixed, and consultation has already taken place.
In this scenario, a predictive approach makes sense. Making changes mid-rollout would require renegotiation, retraining, and potentially even legal amendments, so it’s better to plan carefully and get it right the first time.
Agile, on the other hand, assumes that some things just can’t be known upfront—and that’s OK.
Instead of trying to plan everything in one go, Agile works in short cycles, each one delivering a small, usable outcome. Feedback happens early and often, and learning is built into the process.
This reduces the cost of change by making adjustments while things are still flexible, before major effort has been sunk into the wrong solution.
For example, a charity staffed entirely by well-meaning people over 40 is developing a campaign to raise awareness about healthy eating among teenagers.
The message, format, and delivery method are all open questions, mainly because none of the team is quite sure what TikTok is, or whether emojis still count as “cool.”
Rather than locking everything in from the start, they test a few different messages on a range of platforms and gather real feedback from actual teenagers (who, let’s be honest, are the experts here).
Based on what gets the most engagement—or at least isn’t completely ignored—they tweak the messaging and roll it out more widely.
This Agile-style approach keeps costs down and helps ensure the final campaign is actually effective.
Most projects fall somewhere in the middle. That’s where hybrid project management comes in.
Think of it like a sliding scale: more uncertainty, lean more toward Agile. More stability, lean more toward predictive.
Take the example of a multi-use sports stadium. In the early stages, the project team might start with Agile-style planning to explore what the stadium should include, who it needs to serve, and how it can meet a wide range of community expectations. That might involve multiple rounds of consultation, design feedback, and iteration, especially when there are competing priorities or diverse user groups involved.
Once there’s final agreement on the stadium’s design, purpose, and outcomes, the project can shift into a more predictive mode. With scope and budget locked in, the team can now focus on delivering the build through a structured, step-by-step process, using predictive methods to manage time, cost, risk, and compliance.
This kind of hybrid approach is common in large, complex projects where the early stages are full of uncertainty, but the later stages require precision and control.
It’s not about being purist—it’s about being practical.
Therefore, the more unpredictable your project is, the more it makes sense to work in smaller cycles, test early, and adapt quickly. That’s what Agile is built for.
On the other hand, when the path is clear and the stakes are high, predictive methods help you avoid costly mistakes by investing more time and effort into initiation and planning upfront. And when your project has a bit of both? That’s where hybrid shines.
Your job is to understand the level of uncertainty, weigh up the cost of getting it wrong, and choose the right mix of tools to deliver the best result.
The rest of this unit focuses on Agile as a standalone methodology—how it works, how teams use it, and what makes it tick.
But whether or not you’re running a fully Agile project, there’s something here for everyone.
The principles behind Agile—learning early, engaging people often, and designing for change—can strengthen almost any project, in any environment.
So even if you don’t manage projects in sprints, there are lessons here you can apply straight away.
