You don't tell anything about your projects, their technology, and why they are late and defective. It's important, there might be all kinds of concrete problem

You don't tell anything about your projects, their technology, and why they are late and defective. It's important, there might be all kinds of concrete problems with concrete solutions: technical shortcomings (e.g. any small change requires a long build-deploy-test cycle that could be shortened with improved architectures and tools); opportunities for training and preparation that you should plan proactively (nobody wants to admit incompetence and/or make an "investment" of time with a pending deadline); misunderstandings that can be prevented with better communication protocols (final acceptance tests should confirm that there are no showstopper bugs, not decide the fate of a blind development effort); random accidents. What I read between the lines is the evergreen management pattern in which someone decides objectives and everybody else is held accountable for meeting them, at two levels: you with your team, and your users and bosses with you. "I manage a team of 3 developers": you aren't a developer. What are you doing in the team? "Deliver the work we commit to": you commit, they deliver. "Deliver work that ultimately fails the QA process": you are unable to test what you are writing before losing face with your internal customers, whom I mostly imagine as assholes who are much more eager to judge your work than to assist you. "Half the team is quite junior": unlikely to be able to say no. Thinking of it, the more senior developer is likely to be more aware of likely problems but more expert at manipulating you. "This is their first job": but you expect them to provide good estimates. "Everyone is smart and capable of writing logical, working, and tested code": you cannot be sure, particularly if failures and difficulties are a weakness that should not be admitted. If you are threatening underperformers with consequences, they'll spend their time and energy to avoid appearing to be underperformers, not necessarily to perform better. "Reducing the scope of the sprint to something that should be very easy to deliver": increasing micromanagement, but not productivity. "Daily 1:1 10 minute meetings with each seemed to be a burden on a everyone and didn't lead to productive conversations": How would admitting that a task is above the developer's skill level, that delivery will be late, that work has been grossly underestimated, etc. be a good move for the developer? You need to reward openness, but you are clearly rewarding reports that everything is fine. "Creating a rigid structure for the daily standup": you mean a more judgmental structure. "People seem to indicate everything is fine until 3-4 days before the end of the sprint": because near deadlines lying too much is worse than admitting defeat. How far from the deadline sincerity begins is an objective measurement of your attitude. "I'm struggling to understand if it's an issue of motivation, organization, team, or there are just some fundamental things that need to be fixed": what else do you consider fundamental for your team besides motivation and organization? "Everyone likes working with each other": you cannot be sure, if discussing a problem with a colleague marks people as a snitch, a loner, a bullying target, etc. Hopefully you, your team and your company are not as bad as your post might suggest, and you can simply improve productivity by improving processes. I'd try to analyze how your developers wasted time and find ways to prevent or mitigate the issues in the future, demanding justifications for being late and analyzing them in depth, which would prevent bullshit excuses that can't withstand scrutiny, encourage attention to wasted time, and demonstrate that you care about the problems of the team.