When is Waterfall better

First - what do you mean by waterfall? The traditional "waterfall" process - requirements, analysis, design, coding, testing, deployment - was never meant to exist. If you were to read Winston Royce's paper Managing the Development of Large Software Systems that sparked this idea, you would find that it was described as a process that "is risky and invites failure". The proposed processes for developing software systems involves feedback loops and learning. Maybe not as rapidly as we can do today with the technology and tools that we have, but you can see the start of concepts that we would find familiar in the various lean or agile methods, but perhaps a bit more documentation-centric rather than working software centric.

I think that this is one of the downsides to Scrum - it doesn't provide any detail into that very early work in a project. These inception level activities - identifying the relevant stakeholders, forming the development team, developing the initial vision or objective, defining the initial or baseline scope, identifying and establishing your infrastructure - aren't identified and there's no guidance on how to do this in a way that aligns with the agile principles and values. But doing these things up-front doesn't make your project a "waterfall project" or even a "Waterfall / Agile hybrid". They are simply essential things that must be done before work can commence. You should spend the time to define these things as much as makes sense for your product, but if you embrace the agile/lean values and principles, you'll recognize that these things aren't fixed. And the best way to adopt and respond to changes is to put working software in front of users (or at least user representatives) quickly and frequently to obtain feedback.

Even in an ongoing effort that is using Scrum, there's a lot that can happen before work can be taken into a Sprint. There's nothing that describes how the Product Owner goes about figuring out what should be expressed as Product Backlog Items or how to get to a Product Backlog Item from a concept that exists in a stakeholder's mind. There's also no definition for the level of understanding of a Product Backlog Item. In my experiences, a lot goes into working with different stakeholder groups to figure this out. It could be weeks (or even months) from the time a high level need is identified to the first Product Backlog Items are captured. Personally, I even put user experience design into the product side and not the development side of the equation - user interface designs are requirements and inputs into the Development Team. It takes a lot of time to build up a design system and do user experience testing on prototypes so that way the Development Team knows what to build into the system under design.

So my take - by all means, spend the right amount of time to do the right amount of this up-front work to make sure that you have a grasp on the risks and value of the work. However, once you have that initial Product Backlog and Scrum Team formed, bring in the Scrum principles and practices to manage the Development and the changes, especially since it sounds like you're already familiar with Scrum.

There will be a lot of design work before we even get to the point of producing a product that we can show stakeholders.

Is this a simple product with few unknowns? Will there be no need for empirical process control in order to validate an emergent design?

You might choose to use Scrum if the product is complex, feedback has value, the plan for proceeding can be inspected and adapted, or empirical forecasting of completion dates will influence decisions.

There will be a lot of design work before we even get to the point of producing a product that we can show stakeholders.

Why? Is it not possible to design a very small part of the product, and then develop and release it?

The ideal situation for many products like this would be to show this small part to real customers, but sharing with internal stakeholders will allow some feedback to be gathered. Even producing this releasable product demonstrates what can be Done, and allows the Development Team to learn what is involved in producing releasable increments.

There are some people who would like to use Agile for this project, eg completing the design in two weeks, but I’m more cautious here. What are people’s thoughts to using a Waterfall / Agile hybrid here?

By a hybrid, do you mean having a series of sprints to design, develop, test, release, etc.

This could be wasteful if there is such a lead time to having an increment you can gather feedback on.

Perhaps in the first sprint, the team could produce an increment that has some small output that can be inspected, while they also spend time refining the backlog for the upcoming sprint.

Maybe they can produce something adequate without an upfront design, and then tweak it later to meet emerging design standards.

Does anyone have examples of projects that haven't had a lot of unknowns and have been simple enough that Scrum isn't necessary? 

Also, has anyone come across projects where Scrum has been used to get the product to a state where it is no longer complex? Where additional work is better planned in a stage gated fashion?

In practice there are very few simple initiatives. Complexity and risk can be found across the dimensions of requirements, technology, and people.

Like-for-like migration projects can be ostensibly simple in so far as requirements are already understood, proven, and demonstrated in existing products or services. However, there can be technical uncertainty in terms of new implementation choices, and doubts about the ability of people to form teams which can demonstrably complete the work. Hence there would still be value in adopting an empirical approach to development.

I agree with you guys in theory.. But in practice if you don't work in a 100% agile company you'll struggle working without no previous preparations and design efforts... Here in my company we use method like Design Sprint and Lean Inception before we enter in te execution therms.. I recommend you to check those :) 

There are clear guidelines for when waterfall is a good approach: 1) The requirements are clear and we don't expect them to change much during the project. 2) The technology, with which we develop the new product or service is clear and does not pose great challenges. 3) If the product or service you are building cannot be spit into small increments that can be developed functionally in a few weeks than waterfall is the best approach. Examples are: Building a house or a bridge.

+1 Thomas

I would also add that the initial work (before the "real" developers join) should also be done in an agile way: discuss, prototype, gather feedback, repeat. And once the bare minimial vision is created/achived/shared, then the team may grow with more developers, that will actually start creating potentailly releasable product.