The History of Hybrid Project Management

By Victor Hoang · Updated Oct 21, 2026

Builders have always mixed a fixed plan with on-site adjustment. Nobody called it a method. The documented story of a named choice between the two starts in the 1950s. It starts in the offices of the people building the first very large software systems and test aircraft.

Hybrid project management did not start with a product launch or a single inventor. It grew in the gap between two ideas that software and project people argued about for half a century. Plan the whole job first, or learn as you build? The earliest written case for mixing them is Winston Royce's 1970 paper. The first formal model of the blend is Barry Boehm's 1988 spiral. The word "hybrid" went mainstream after Forrester's 2011 "Water-Scrum-Fall" report and PMI's 2017-2021 standards.

The throughline is branching and reconvergence. Two schools split, each one proved right for some kinds of work, and then the profession stopped asking which school to join and started asking which mix fits this project. This page follows that arc. For the concept itself, start with what hybrid project management is; this article tells where it came from.

Timeline at a Glance

The Two Instincts (1950s-1970)

Sequence and iteration both appear, long before anyone blends them

Picture the 1950s, when programs for national defense networks had to work the first time they were switched on. Boehm's 1988 paper says that by 1956, experience on large systems such as the Semi-Automated Ground Environment (SAGE) had produced a stagewise model, a set of successive stages from operational plan through coding, testing and evaluation. That is the sequential instinct: decide, then build, then check.

The adaptive instinct is just as old. Craig Larman and Victor Basili's 2003 history says iterative and incremental development dates as far back as the mid-1950s, and that the 1950s X-15 hypersonic jet program applied it. The same article quotes Gerald Weinberg, who worked on early NASA software: "We were doing incremental development as early as 1957". He recalls a team reassembled in Washington in 1958 for Project Mercury that built its system in steps. Larman and Basili add that Mercury ran with very short, time-boxed iterations.

Then, in August 1970, Winston Royce wrote the paper both schools later claimed. It was reprinted from the IEEE WESCON proceedings, and it opens with his personal views on managing large software developments, drawn from work on spacecraft mission planning and analysis software. He draws the sequential flow, then says he believes in the concept but that the implementation is "risky and invites failure". The reason is timing: testing comes at the end, so the first real surprises arrive when change is most expensive. He then adds five features to fix it, including a step to design the program first, a step to do the job twice so the first version acts as an early simulation, and a step to involve the customer formally at earlier points.

Read that carefully and you find the first documented blend: a sequential skeleton with iteration and feedback built in. Keep precursor and concept apart, though. Royce did not call it hybrid, and later readers kept the first diagram and dropped the five fixes. Larman and Basili note that many people incorrectly view the paper as the paragon of single-pass waterfall.

What this means for teams today: If someone says "we're a waterfall shop," ask which of Royce's five fixes you actually do. Most teams that stay sequential still prototype, review early and involve the customer, which is the blend in miniature. Our guide to waterfall methodology covers where the sequential core still fits.

The Spiral Years (1970-1988)

Boehm turns the choice into a question about risk

By the 1980s the waterfall had become the default of government software buying, and the complaints were loud. Boehm's 1988 paper opens with a few lines that capture the mood, including "The waterfall model is dead" answered by "No, it isn't, but it should be." He writes that a 1987 Defense Science Board report had raised the concern that traditional process models discouraged prototyping and reuse. The paper itself calls the waterfall a highly influential 1970 refinement of the stagewise model, one that added feedback loops between stages and an early form of prototyping.

Boehm, writing from TRW's Defense Systems Group, offered the spiral model as one candidate fix, published in Computer in May 1988. Its distinguishing feature, in his words, is a risk-driven approach in place of a primarily document-driven or code-driven process. Each loop of the spiral repeats the same sequence of steps, for each part of the product and each level of detail. The point for this history is a claim buried in the evaluation: the spiral can accommodate most previous models as special cases and gives guidance on which combination of them best fits a given situation.

That sentence is the intellectual seed of hybrid project management. The answer to "which model?" stopped being a school and became a function of risk. Where the risks are about requirements, build a prototype first. Where they are about integration, plan the integration carefully. The cost was complexity: the spiral asked managers to judge risk well, and the paper itself admits it was at an incomplete level of elaboration.

What this means for teams today: Choose the amount of up-front planning by naming your biggest risk. If the risk is "we may be building the wrong thing," shorten the loop. If it is "this has to connect to the regulator's system on a fixed date," plan that part firmly.

After Snowbird (2001-2010)

Agile gets a name, the schools harden, and Boehm argues for balance

On 11 to 13 February 2001, seventeen people met at The Lodge at Snowbird in Utah. They represented Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming, among others. Alistair Cockburn objected to being called a "lightweight," and Martin Fowler's only worry about the new name Agile was that most Americans did not know how to pronounce it. The manifesto they signed says that in four pairs of values, the items on the left matter more, including responding to change over following a plan. The same sentence says there is value in the items on the right. In our reading, many people heard only the first half, and the movement and the plan-driven world hardened into rival camps with their own vocabularies. Our article on the Agile Manifesto covers the text, and what agile methodology is covers the practice.

Boehm answered the split with a book. Barry Boehm and Richard Turner's Balancing Agility and Discipline, published 11 August 2003 by Addison-Wesley, argues that agile and disciplined methods are often presented as exclusive but "lie on a continuum". It compares the two approaches, names the kinds of projects where each has been most successful (their "home grounds"), and describes a risk-based method for balancing them within a project. Notice the line back to 1988. The risk-driven spiral had become a risk-based way to blend two named schools.

The rest of the decade is quiet in this history. Teams adopted agile practices project by project, and the standard word for the blend arrived only when an analyst described what organizations were actually doing.

What this means for teams today: Boehm and Turner's "home ground" idea is still the most practical test. Ask where your project sits on the continuum before you ask which framework to buy. Our comparison of agile versus waterfall lays out the two ends.

The Water-Scrum-Fall Years (2011-2016)

An analyst names the blend most organizations were already running

On 26 July 2011, Forrester published a trend report by Dave West titled "Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today". Its subtitle told readers to manage the water-Scrum and Scrum-fall boundaries to increase agility. The summary says actual practice had drifted from the manifesto and that the model is not inherently bad, but that teams must decide deliberately where its boundaries fall.

West explained the idea in a webcast covered by ADTmag in June 2011. Development teams were using Scrum practices, he said, but under constraints: the requirements and planning had been done up front, took about three months and were well documented, and software was not released very often. His objection was practical. Feedback from each sprint helps little if the original requirements cannot change.

Source: ADTmag's report of West's webcast, summarized.

This was a turning point because it described the blend as something that had happened by accident, practitioner by practitioner, not by design. In 2012 Scott Ambler and Mark Lines co-created Disciplined Agile with the goal of a flexible approach that recognizes every organization and team works differently, letting people tailor their "way of working." West's warning and their toolkit address the same problem from opposite ends: accidental hybrids need deliberate boundaries.

What this means for teams today: If your agile teams sit between a long approval phase and a quarterly release, map the three zones on one page. The fix is rarely to abolish the first and last zones. It is to make them smaller and let sprint feedback change something upstream. Our article on Disciplined Agile covers the toolkit.

PMI Builds the Bridge (2017-2021)

The standards body adds agile to its own standard

For decades the Project Management Institute stood on the plan-driven side of the split, so its moves in this era are the clearest sign of reconvergence. In 2017 PMI began selling the PMBOK Guide Sixth Edition with a new Agile Practice Guide as one package. PMI's shop page says the Sixth Edition now contains detailed information about agile, while the Agile Practice Guide, created in partnership with Agile Alliance, serves as a bridge to connect waterfall and agile. Our overview of the PMBOK Guide covers the standard itself.

In August 2019, PMI announced its acquisition of Disciplined Agile, the toolkit Ambler and Lines had built. Ambler's own blog post on the news is dated 10 August 2019. The deal put a "choose your way of working" body of knowledge inside the institution that once defined the plan-driven camp.

The 2021 Seventh Edition of the PMBOK Guide then changed the standard's shape. PMI later describes the Eighth Edition as retaining the principles and performance domains foundation of the Seventh Edition, so the Seventh is where the standard's current shape begins. PMI community records show the edition cleared its ANSI approval step in early 2021, with PMI saying only that a 2021 release was planned.

What this means for teams today: The standards themselves now say tailor. If your organization still treats a methodology as a policy, point to the standard and ask for a fit-for-purpose policy instead.

The Fit-for-Purpose Era (2022-present)

Hybrid becomes a counted, named, mainstream choice

By 2024 the blend had numbers. In February 2024, PMI's Edivandro Conforto reported from the 15th Annual Pulse of the Profession survey that hybrid adoption rose from 20% in 2020 to 31.5% in 2023, an increase of 57.5%. The same post reports comparable project performance regardless of whether the approach was predictive, agile or hybrid, and says the shift reflects organizations prioritizing a fit-for-purpose approach over a single framework.

Institutions then closed the old gap. PMI says it signed an agreement on 31 December 2024 under which Agile Alliance joins PMI. Agile Alliance was founded in 2001 by some of the original manifesto authors. The release says the future of project management "cannot rely on rigid distinctions between delivery approaches", and it describes mastery of multiple approaches that can be combined according to context. Eleven months later, in November 2025, the PMBOK Guide Eighth Edition appeared with six core principles and seven performance domains, and a section on tailoring for your context.

Two cautions belong in the record. First, a count of how many projects call themselves hybrid depends on how respondents define the word, and a rising share can mean growing practice or growing vocabulary. Second, the blend inherits the problem Forrester named: a hybrid with undecided boundaries is just a confusing waterfall. Frameworks that mix Scrum and Kanban, such as Scrumban, show how small teams make the same choice at the board level.

What this means for teams today: Treat "hybrid" as a decision you make per project and write down: what is planned firmly, what is discovered as you go, and who can change each.

Key People

Key Facts

Key Facts: Hybrid Project Management History

• Royce's 1970 paper said the plain sequential implementation was "risky and invites failure", and added five features to fix it.
• Boehm's 1988 spiral paper says the spiral can accommodate most earlier process models as special cases.
• Forrester's Water-Scrum-Fall report was published on 26 July 2011.
• PMI reports hybrid use rose from 20% in 2020 to 31.5% in 2023, with comparable project performance across approaches.
• PMI announced its acquisition of Disciplined Agile in August 2019.
• Agile Alliance joined PMI under an agreement signed on 31 December 2024.

The Pattern Behind the History

We call this the Split and Settle pattern. It is our reading of the timeline, not a research result.

1. Both instincts exist first. Sequence and iteration appear side by side in the 1950s, before either has a school.
2. A diagram outlives its caveats. Royce's warning was lost when the first figure spread, and the split began there.
3. Risk becomes the arbiter. Boehm's spiral and the Boehm and Turner book replace "which school" with "which risk".
4. Practice runs ahead of vocabulary. Teams blended for years before Forrester gave the blend a name.
5. Institutions follow practice. PMI added agile, bought Disciplined Agile and absorbed Agile Alliance only after the blend was common.

What It Teaches Teams Today

• Name your biggest risk before you pick a method. That is Boehm's contribution, and it still works.
• Decide the boundaries on purpose. Forrester's warning applies to any team that mixes up-front planning with sprints.
• Keep what the old plan-driven world got right: early design, formal customer commitments and planned testing, all in Royce's fixes.
• Keep what the agile world got right: short feedback loops and the freedom to change requirements.
• Write the blend down. A hybrid that lives only in people's heads becomes Water-Scrum-Fall by default.

For the wider story, read the history of project management, the evolution of project management methodologies and the project management timeline.

Hybrid project management is what happens when a profession stops treating a method as an identity. The teams that do it well still ask the 1988 question: what is the biggest risk on this project, and which mix of planning and learning answers it?