Agile vs Waterfall for UX Projects: What PMBOK Gets Right

Few debates in product organizations generate more heat and less light than agile versus waterfall, and UX sits awkwardly in the middle of it. The PMBOK Guide’s modern treatment of the question is more useful than either camp’s marketing: the approach should fit the work’s uncertainty, not the organization’s fashion.

What does waterfall get right for UX?

Sequence. Some design work genuinely cannot be parallelized: research must precede flows, flows must precede screens, and a design system must precede its components. Waterfall protects these dependencies. Discovery that ends with evidence is worth more than discovery timeboxed into oblivion. For fixed-scope projects with stable requirements, a marketing site with a hard launch date, waterfall’s predictability is real value.

What does agile get right for UX?

Change. Requirements evolve the moment users touch working software, and agile absorbs that reality instead of denying it. Iteration turns usability findings into next sprint’s fixes rather than next year’s roadmap item. For product work with living requirements, agile’s short feedback loops are how design stays honest.

Why is hybrid usually the answer?

Because UX projects contain both kinds of work. Discovery is uncertain in outcome but sequential in logic: research it properly, waterfall-style. Delivery is continuous: ship and iterate, agile-style. PMBOK’s framework gives teams permission to stop arguing ideology and start matching method to phase. Discovery to learn, sprints to ship.

Why does Tremoloo share this book?

Because we deliver design inside both kinds of organizations, and the teams that struggle are the ones forcing one methodology onto work that needs two. This standard’s pragmatism is a relief.

Need a design partner fluent in your delivery model? Our designers extension works the way your team works.