Work and pressure is a spectrum
If you do something like Waterfall it doesn't mean that you work at full capacity, and if you do something like Scrum it doesn't mean the team can slack off. If you do Waterfall it doesn't mean you are under pressure to do the work, but if you do Scrum you can just relax and do things when you eventually feel like it. These things have nothing to do with Waterfall or Scrum, they are related to how things work in a particular team, project, department, organization, domain, etc.
These things are a spectrum: from subjecting your people to a death march with unreasonable deadlines and larger than capacity amounts of work, to people just chilling in the office while watching movies online. Again, these have nothing to do with Scrum or whatever methodology you use. It depends on the project, company, management, clients, etc.
Throughout history, in various context, people have figured out that you can't put infinite pressure on teams to make them do what you want in the shortest amount of time, because people burn out, start making mistakes, introduce defects into what they are doing, etc. Agile simply recognizes this and brings more attention to it than more traditional project management approaches that don't shy away from starting death marches. It's referred to as sustainable pace, a work pace that the team should be able to sustain indefinitely. To give you an example, if you want to run a long distance, what approach do you think will work best? Start running as fast as you can, using all your strength and energy, or running "at a slower pace" trying to conserve your energy and strength?
Commitment vs forecast
The 2011 version of the Scrum Guide saw a change in the terms used for the work to be delivered in the sprint: Commitment vs. Forecast: A Subtle But Important Change to Scrum. Why? Because upper management were putting pressure on teams to finish everything in the sprint, something that, sometimes, can't be possible for reasons independent of the team. To put it bluntly, some were transforming sprints into mini death marches. From the same source:
In Scrum, the Development Team is now asked to forecast the specific work that can be done in a Sprint, rather than “commit” to it. This allows teams to focus on the things that matter in professional software development like quality, value, and continuous improvement, rather than satisfying an arbitrary obligation.
Business-facing people (Product Owner, stakeholders, customer…) must recognize the inherent uncertainty in building software of any real value and complexity. Their responsibility is to create an environment where Development Teams can succeed, and trust in those teams’ professionalism to do all they can to deliver things of value.
Inspect and adapt
But how do you know if the team's pace is a decent one, too fast, or too slow? Inspect and adapt. Are people interacting and collaborating in the office or are they sitting in isolation? You can watch videos on youtube in isolation, but team members can't work in isolation. Are there many bugs? Maybe the team is going too fast. Basic features take a long time to be built and you project isn't where you would expect it to be and progress seems slow? Maybe the team isn't going fast enough.
You inspect to see what's going on then turn some nubs to fix it. This can mean a lot of things, not just putting some more pressure on the team, or taking some pressure off.
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.
Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.
In simple words, you need the right people. No lazy developers slacking their butts off, and no crazy managers trying to impose death marches. Everyone needs to act professional and when they do, and collaborate to reach the same goals, the right balance of work and pressure will be reached. Of course, it goes without saying that there is a disclaimer: you can have dysfunctional organizations, dysfunctional projects, dysfunctional managers, and dysfunctional Scrum teams, to throw that balance out of whack in one direction or the other.
