Which Is Better: Agile, Predictive, or Hybrid?

This question comes up so often it feels like it’s pulled from a standard list of audience questions. It shows up in every course, webinar, workshop, and conference I take part in. There’s always this evident need to figure out whether being agile, predictive, or hybrid is the solution to every management challenge.

Behind the question lies a legitimate concern every director shares. How should I manage my team, project, or organization? Is agility the future, coming to replace the traditional management model? Is agility the only valid management model in our time? Here I lay out, in detail, the different management paradigms, where they come from, and the advantages and disadvantages of each.

Why look for the “best” project management methodology? Agile, predictive, or hybrid

Although this article talks about paradigms, the truth is that methodologies and frameworks assume a context of application — what we formally call a paradigm. These contexts can be classified in many ways, but in this article I’ll present the most popular classification model.

Our brains aren’t wired to make objective value judgments. We’re always tempted by the power of comparison, and comparison is something we humans are exceptionally good at. That simple urge to find the best, the prettiest — or the most attractive, the cheapest, the fastest, and of course the most effective of the methodological approaches — is in our DNA. We struggle to quantify the intrinsic value of things, so we always end up comparing X against Y along some given quality.

I can’t say I’m a “pure” or “radical” agilist, and I’ve never been an exemplary traditional project director who leans on documents, minutes, and every kind of written evidence either. That’s exactly why, in this article, I invite you to drop the search for the best or most efficient way to manage a project, and instead reflect on the meaning and implications of each paradigm — the value and benefits of the practices and procedures we use in each one.

The project director’s toolbox: the utility belt

I’m a fan of examples and analogies. This is one of my favorites. Everyone who’s ever followed Batman — the fictional character created by Bob Kane in the late 1930s — knows about the utility belt . That belt, nothing more than the careful selection of tools and gadgets for a superhero with no powers beyond his own conviction, is a great example of a toolbox.

A good project director is like Batman: no superpowers, but the conviction and drive to complete a project successfully. The best project directors I’ve had the luck to work alongside have an enviable toolbox at their disposal. And these directors don’t waste time picking one tool or methodology over another. They don’t jump on the newest, shiniest tool — they’re simply pragmatic about choosing tools within a given context.

What are the best tools for managing a project, whether agile, predictive, or hybrid?

I need to say upfront that any director who assumes one practice replaces another simply because it’s new or “trendy” just doesn’t understand the value each tool offers. Every practice, tool, or technique was designed for a specific problem, challenge, or opportunity, within a particular context or paradigm.

What we know today as good practices is the result of years of work and experience from one or several project directors. So here are 5 tips for building out the best tools for your own toolbox:

1. Don’t discard a practice without understanding the paradigm it applies to, whether that’s agile, predictive, or even hybrid.
2. There’s no use having the best screwdriver — or “desarmador,” as we call it in my country — if you can’t identify a screw. Even for practices you don’t personally like, build the judgment to know where and when to use them.
3. It’s worth checking what reference institutions in project management propose — the Project Management Institute (PMI ), the International Project Management Association (IPMA ), Scaled Agile (with its SAFe framework), and Advanced Development Methods, Inc. (the company behind Scrum.ORG ). One last reference worth mentioning is Management 3.0 , which, even though it’s been around for a while now, is still an excellent point of reference.
4. A good director knows their strengths and feels comfortable in certain contexts. Identify which projects or challenges you enjoy managing, under what conditions, and in what role (director, manager, facilitator, or coach). Identify the good practices for that context. Specialization can be a differentiating factor in your career.
5. Stay current, always. Practices evolve, across every paradigm — agile, predictive, or hybrid. Join professional associations, interest groups, and forums. This isn’t just useful for how you perform your profession — it’s key to staying relevant and employable.

The Stacey Matrix and decision-making

I’ve talked about the importance of context — the paradigm — where a project’s decisions are planned or happen. This is key to answering the question correctly: agile, predictive, or hybrid? So let’s get into it.

Ralph D. Stacey , who was a professor at Hertfordshire Business School, spent years studying human organizations and their management models. Among his most “popular” work we find the Stacey Matrix — I’ll be upfront that I haven’t read the entirety of Stacey’s work, so I’m going off the most popular of his publications, according to Google.

The Stacey Matrix is a graphical representation — derived from his work — that has been adapted over the years to represent the different paradigms tied to strategic decision-making, including, for example, deciding how to plan and manage projects. This “matrix” establishes two dimensions to consider: the first, “agreement,” refers to “how much agreement or clarity we have about what we want to achieve or decide,” and the second, “certainty,” represents the level of “confidence” we have about how the outcome will unfold or be achieved.

Consensus and Certainty

Stacey might have a heart attack reading how I’ve oversimplified years of work and how I’m applying it to the agile, predictive, or hybrid paradigm, but what matters for this article is identifying the impact these two dimensions have on our decision-making: Consensus and Certainty.

• Consensus: What do we want to achieve?
• Certainty: How are we going to achieve it, and what can we expect from that process?

So here’s my personal version of the matrix — call it a derivative work.

In short, we can see:

1. Simple Domain: when we’re clear on the objective and have high certainty about the results our actions will produce (in pursuit of that objective), we’re in the domain of the simple.
2. Complicated Territory: when certainty decreases, or consensus about what we expect to achieve does — or both, to some degree — we enter the domain of complicated decisions.
3. Complex Territory: when one or both variables move far outside what I’d call “the zone of apparent control,” we enter the domain of complex decisions.
4. Chaos: if we drift too far, we lose the very sense of the work.

For each of these regions or domains, a paradigm for decision-making emerges. These decisions are:

1. Rational, where there’s agreement on what we want to achieve and certainty about how to achieve it.
2. Negotiated, where, with certainty about the ways to reach the objectives, the debate requires negotiation and agreement between parties.
3. Evidence-based, where, more than agreement, we need to discover or create the ways to solve problems or reach goals. This context requires experimentation and, as a result, relies on data and evidence to make judgment calls.
4. Complex, where we apply both learning and creativity to decision-making — essentially a combination that requires adaptation.

Although project management isn’t directly part of Stacey’s work, it’s possible to extrapolate these concepts to decision-making within a project, and in particular, to the decisions tied to project planning.

Adaptive, predictive, or hybrid planning

For each of the paradigms or decision-making frameworks Ralph Stacey proposed, it’s possible to suggest a “best” way to conduct the management of that process. In the context of projects, we talk about the “project management paradigm.”

For each paradigm there’s a recommendation for governing the planning and management processes during execution. I want to be clear that I’m talking about management, not execution — because execution, academically speaking, can only happen if there’s a plan. So the decisions get made while planning the work or managing it (through corrective and preventive actions), not in the act of executing tasks itself — as if we were automatons.

That’s how the so-called management paradigms (agile, predictive, or hybrid) come about in projects. These paradigms are:

1. Predictive planning — where, based on experience and knowledge, we make rational decisions and can define a plan ahead of time. This management model is sometimes known as “traditional.”
2. Increment-based management assumes defining stages or “checkpoints” where we validate the outcome against stakeholder expectations and interests. These checkpoints should be verifiable results, and they’re commonly called “increments.”
3. Decisions that require evidence use models oriented around experimentation. Each experiment needs controlled variables — since we can’t anticipate the outcome, we try to contain other dimensions instead, like the experiment’s duration or budget. These experimentation periods are known as iterations.
4. For complex decisions, we need a kind of combination between validating expectations and needs, and discovering the path to reach the expected result. This model is known as adaptive or agile (an association I’m not fully sold on), and it’s where complex adaptive systems enter the picture. This paradigm requires a balance between creativity and learning, with increments that let us validate the “what” and experiments that let us validate the “how.”

Example projects for the different project management paradigms

Over the next few paragraphs we might touch some nerves in the philosophical debates of project management, and probably a professional or two along the way. I ask for your understanding — the goal here is educational, which is why I’m simplifying concepts (sometimes to excess). Always remember the metaphor of the “perfectly spherical cow.”

Example of a predictive project: The bridge

Problems within the domain of the simple assume we can anticipate the results of our decisions and actions. That’s how predictive planning conceives of management.

A problem or challenge we can solve predictively is building a vehicle bridge. Suppose a regional governor wants to build a bridge between two cities separated by a river, and your company was selected for its experience and track record building similar bridges for other regions, even over the same river.

While building a bridge isn’t a simple task and requires structural calculations and quality construction — often carried out by dozens or hundreds of people who need tight coordination — we can say the problem to solve falls within the domain of predictable or simple problems and decisions. In other words, our knowledge and the technology we have let us anticipate the risks and difficulties we’ll face, as well as identify proven solutions.

You’re not going to start building a bridge by running experiments — you’re going to define a work plan and focus on completing it, a plan that represents thousands of years of human experience in civil works and construction. That’s why it’s called the predictive model or paradigm.

Example of an incremental project: The presidential campaign

The imaginary scenario for this example is that you’re part of the campaign team for a candidate running for president of your country. As a serious, responsible professional, you develop a campaign plan with the team around the thematic pillars that have historically proven key to shifting citizens’ voting intentions.

So far, this all looks like a predictive project, but as soon as the campaign starts, you’re up against your audience: the voters. They’re the ones who ultimately choose, often guided by the most unlikely situations, which topics they expect to hear from the candidates. They’re the ones who set the priorities for the campaign team’s work. One day it can be a predictable situation, and the next a video goes viral on social media revealing the deep disconnect between citizens and their electoral process , tipping the scales in unexpected ways just days before election day.

You know you can’t see the future. You have a plan, but you have to adapt it to your stakeholders’ needs and expectations. You have the tools, the technology, and you know how to respond. Success will come down to how sharp your increments are.

Example of an iterative project: The vaccine

Now, iterations might look like increments, but they’re not. Here’s why increments aren’t the same as iterations.

Iterations vs. Increments

We can “plan” increments — we know what actions to take to develop one outcome or another. What we can’t anticipate is whether our assumptions about the value of the product or service we’re developing are correct, or whether, on the contrary, our stakeholders will change their minds once they see it.

For iterations, we can’t anticipate the outcome at all — we don’t know if we’ll succeed in building something, and we might still be unsure whether what we’re proposing even makes technical sense. That’s why we decide to adjust other variables instead, like the iteration’s duration and the resources assigned to it.

So here’s our example: developing a vaccine for a disease that has the world in the grip of a pandemic. Who can predict when the vaccine will be developed? Who can predict whether we’ll succeed on the first attempt, or whether it’ll take 5, 10, 20, or 1,000? The answer is nobody can.

Remember that movie where the main character was “the last human survivor of a pandemic in New York City” and ran experiments on test subjects again and again, waiting for a result. This kind of complex-natured project can’t be anticipated — it only allows for an indefinite series of attempts in search of a solution to a problem.

To keep this kind of project from bleeding organizations or nations dry, we cap the resources invested (time and money in particular) and manage in cycles — what we call iterations, or what’s known in Scrum as Sprints — where we evaluate results and adjust our plans.

To bring this example closer to the corporate world, imagine you’re the director of an innovation department. I can guarantee you more than one director would love to promise the development of 3, 5, or 10 new, sales-successful products by year end, but the reality is that’s impossible. So instead we set aside a specific budget for innovation and manage it to optimize that investment and its impact — even if it means just one truly successful product.

Example of adaptive or agile management: Software product development

Well, this is probably the model you’ve heard about the most in recent years, and even though it’s been around for more than three decades, it’s still new territory for many organizations only now evaluating specific methods for their own use.

Adaptive or agile management requires a delicate combination of increments and iterations. Several models have emerged around this effort — very close to the software industry. The reason, I’d bet, is the unique combination that exists between developing intangible products — like software code — and the accelerated evolution of the technologies we develop those software products for.

Natural to software development and technological evolution, we see an explosion of new opportunities, which turns the process itself into a continuous search — between the product and its perfect features (or the most timely and effective ones for the context) and the best way to use the resources available: new programming languages, new frameworks, new architecture models (serverless, to name one example).

Adaptation comes almost naturally to intangible products, to their abstract nature that depends somewhat on the judgment of the builder or “producer” of the result. Though it’s not exclusive to this kind of product. A book, a document or contract drafted by lawyers, an application’s source code — in general, results that emerge from very personal processes and are later confronted by other people’s perspectives — will always be subject to questions of form and substance.

So, in the end, agile, predictive, or hybrid?

Well, I think you can already guess the answer: “it depends.” Let me close this article with a reflection and a tool for defining the management framework or context for a project, whether agile, predictive, or hybrid.

When should you reach for advance planning and the predictive management model?

Whenever you can. Without a doubt, predictive planning is the best way to anticipate an outcome. If you and your team agree that it’s possible to anticipate the result of your actions, and that neither external nor internal factors will alter the substance of the product or service in development, then you’re looking at a predictive project.

What are the advantages of advance planning?

• It brings clarity to the team and stakeholders by reducing speculation.
• It allows for more detailed, and in many cases more precise, estimates.
• Greater control over execution and progress measurement — based on indicators.
• It reduces risk — in theory — for fixed-cost, fixed-duration projects.

When should you reach for adaptive planning and the agile management model?

Apply an agile model whenever you can. That said, adaptive planning has a different goal: maximizing benefit. Predictive planning is about compliance with the plan; adaptive planning is about effectiveness. If your project needs to adjust over time in order to maximize benefit, then adaptation is the way to go.

What are the advantages of adaptive planning?

• Greater maneuvering room to adjust the plan.
• It promotes innovation, in products as well as processes and practices.
• It maximizes return and reduces the risk of early cancellation.
• Greater visibility into overall progress — based on evidence.

What is a hybrid management model?

In my opinion, the term “hybrid” is valid during this deep transformation project management is going through as a profession. That’s happening because “traditional” management had a deep focus on processes, their inputs and outputs, and had shifted the director’s focus into something closer to a process auditor. Today, the profession talks about values, principles, and, in general, a paradigm oriented around results and generated value. In this context, the hybrid concept assumes a particular mix in certain projects, where different components or stages call for different approaches.

Example of a hybrid management model: Designing and building your dream house

Well, this one’s easy — we know the construction process for a house is almost always predictive. Not so the design. The design process is more incremental, and if the design is extreme, even experimental.

So, within the same project, we can have incremental or adaptive phases (like designing the property) alongside predictive ones (like the actual construction).

Conclusion: agile, predictive, or hybrid

It’s not an either/or, it’s a both/and. A true toolbox includes every kind of practice, applicable to one or several contexts, whether agile, predictive, or adaptive.

It’s not about filtering — it’s about adding and building judgment. Our toolbox carries no weight, only value to contribute.