Water Scrum Fall

The Scrum Guide says:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Considering the above, and bearing in mind that complex work is uncertain and emergent:

• How likely do you think it is that requirements can be defined up front?
• How likely do you think it is that design and testing during a Sprint would be ignored by a Scrum Team?
• How likely do you think it is that, in Scrum, you would find separate Development and UX/UI teams?

A scrum team must be self-organized, and self-managing. Meaning that it controls the entire process from start to finish.

If you have a very common Water - Scrum - Fall scenario... You have a business that communicates with a customer or stakeholder without looping in the team, until the work itself is ready to begin, which has usually already been solutioned.

Often this work is represented by Epic's and then Features that hang off of that. Teams are then organized by the work that they do, so you'll get say a database engineer, then a cloud engineer, then perhaps a monitoring specialist, then a tester etc etc. Because the business identified a problem or a need, devised a solution based on what the company should be able to do.

So, now you have this assembled team who are not volunteers, they're told to join this team and then they're told the type of work they need to complete, but they're told to do it in 2 weeks sprints and attend meetings, managed usually by a PM they call a scrum master.

The operational work that supports this solution is done by a separate team, the resources themselves are probably somewhat shared or at least still have other work they're required to work on at the same time, and most importantly, they're not able to release until after a UAT or some other process has been completed.

Feedback is usually not even getting to the team, so they have no idea how the customer is responding, although management usually just wants more more more.

As you can see there is a sea of bottlenecks and process break downs all along the way. This team is not only not self-organizing, they're not self-managing, they're essentially being dictated to and required to just push work out like an assembly line.

In Scrum, the requirements from the customer / stakeholder are created in collaboration with the team, who then decides their priority. The architecture is designed by the team, the operational aspects are designed by the team, and the team itself forms voluntarily. No one outside of the team is telling them how to complete the work, even if they do present the problem to the team. Plus, the team is fully dedicated to this specific task, they're not a shared resource.

In this environment there's no need to wait for other teams to complete work, because all of the work needed to be done is handled by this team. There's no further testing required, because the definition of done provides the quality. Quality increases over time as the definition of done becomes more articulated through continuous introspection and improvement. 

Customer relationships are very close to the team, allowing for constant feedback and course correction.

Even if you have a situation of multiple teams working on the same solution, you have them all using the same definition of done, marching to the same vision, and the feedback / improvement is done across all of the teams. There are no outside dependencies, when they're all working together in sync. 

what about in a situation where there are several development teams and only one UX/UI team? 

This is easily addressed by removing a UX/UI team, and allowing them to be recruited into scrum teams just like database engineers, or cloud engineers etc. Then, when a UX/UI piece is needed, the team already has the skills needed to address that part of their solution.

I haven't ready "Mastering Professional Scrum", so I don't know if there's more context, but the quoted paragraph is a bit of an oversimplification.

Up-front requirements aren't a problem. Big, detailed, and so-called complete requirements specifications up-front are a problem. Naturally, you will spend some time early on defining what the stakeholders need and what you are going to build. The problem becomes when this effort drags on for an extended period of time, rather than getting enough of an understanding to start iterating on ideas and getting something into stakeholders' hands to get feedback.

Similarly, performing up-front design isn't a problem, but creating big, detailed design documents that lock a team into choices early is the problem. You need to do some design early. Unless some decisions are made, the ability to make other decisions is blocked. However, trying to design the whole product and expecting that design to remain relatively static as you implement the product doesn't work.

Performing testing late really is a problem. There may be some testing that needs to be performed later because the existence of more of the product enables that testing. However, testing needs to be a continuous activity. This helps to support the feedback loops. The stakeholders want to be sure that what they are getting works. Plus, the tests can help the developers make sure that future changes don't unintentionally break something that must work.

We can take a more specific look at this with a Scrum lens.

Scrum vaguely acknowledges some up-front requirements. There needs to be enough of a Product Backlog for teams to work on. Editions of the Scrum Guide before the 2020 revision referred to the Product Backlog as the single source of requirements for changes to the product, but this language was changed to be a list of "what is needed to improve the product". However, the team would only need a Sprint's (maybe a little more) worth of refined work in the Product Backlog before the team starts the first Sprint. More requirements will emerge, but there will be some level of requirements development before the Sprint in which they are designed and implemented. The level of detail in the requirements will depend on the team's tolerance for risk.

Product Backlog Refinement is, to some degree, starting the effort of designing a solution. As Product Backlog Items are broken down into more precise items, the team may decide what work to do and what work not to do. Ordering and sizing the work may also require some design decisions to be made. This design could be user experience design, architectural design, or even some more detailed design. The vast majority of design, however, happens within a Sprint. Like with requirements, the amount of design to do as part of refinement activities depends on the team's tolerance for risk. Also, refining work too far ahead can result in rework, so there's a balance to be achieved.

Once Sprinting has begun, both requirements and design activities happen within the context of a Sprint. The Product Owner is always ensuring the state of the Product Backlog, with input and perhaps support from various stakeholders. Refinement is also an ongoing activity that happens within each Sprint timebox. There are no requirements or design sprints in Scrum - every Sprint results in value-adding, deliverable product Increments.

Testing is something that should be fully contained within the Sprint. The team's Definition of Done guides the quality of completing Product Backlog Items and maintaining a fully working, potentially releasable product Increment. Having a testing Sprint would be a Scrum anti-pattern since testing is almost certainly a requirement to release a product Increment.