To directly address the branching question: Keep the number minimal. One master/trunk/main that is the production code base, and one development/edge that is used by all developers with Continuous Integration and Continuous Deployment (CI/CD) may be enough. Mo' branches, mo' problems; reduce the number of branches, reduce the merge maintenance.
As a framework, Scrum is not prescriptive about the details for creating the product. Due to contextual differences, each Scrum Team and Development Team have to find the techniques and practices that help them to be effective and efficient in serving the customer with a highly valuable product of great quality. As Daniel discussed, making the transition can be challenging. He also mentioned several common practices, many from eXtreme Programming (XP), that have been successful for many over the years.
Collaboration is key. The first value and several principles of the Manifesto for Agile Software Development highlight that aspect. Quality is also a high priority. Silos and walls between development, quality assurance, design, infrastructure, etc. are great impediments. A test-first mentality can be helpful in making that transition. By working together from the onset, quality will improve and cycle times will be reduced. As you have noticed, the ScrumWaterFail that you are currently executing is not working; it is a common pattern for groups new to the agile philosophy.
Product Backlog Refinement (~8 hours throughout the Sprint as needed) is not an official Scrum event. However it is a foundation for each Sprint's effort. The various skills that each member brings to the team are invaluable for examining the top Product Backlog Items from different perspectives in order to create a holistic understanding. The result is less noise and confusion which reduces the need for hashing out basics during the Sprint when bringing the forecast PBIs to 'Done' is the Focus. This is a great opportunity for applying vertical slicing techniques. How do you eat an elephant? One bite at a time.
Sprint Planning (~4 hours to begin the Sprint) utilizes the shared understanding of the top Product Backlog Items achieved during refinement when the Development Team forecasts what they believe they can accomplish. Collaboratively a sketch is created for how the effort will be approached. The first items to be addressed should be planned with greater detail with the quality strategy as a priority. This is a good time to outline test scenarios.
During the Sprint, two or more individuals with mixed skills should work together collaboratively on completing a PBI using pair and mob programming reducing the need for code reviews.1 The number of PBIs being worked on concurrently should be kept to a minimum: A Development Team is 3-9 people, so only 1 or 2 (maybe 3) in progress items. New tests for the item should be developed locally, executed often, then added to the shared suite. Code should be committed frequently to avoid merge hell; merges don't create conflicts, they reveal them. Ideally tests should be executed by automation in the Continuous Integration and Deployment pipeline. Issues will be discovered sooner and should be addressed quickly. There are no hand offs between people or groups.
As collaboration increases, the Daily Scrum ( < 15 minutes daily) will become less about sharing progress of work, because people are having discussions throughout the day's activities, and will become more about validating the forecast from Planning. Because
Quality goals do not decrease it should be more acceptable to reduce scope over cramming to complete all items. The only failed Sprint is one that doesn't produce a 'Done' Increment.
Demonstrating that Increment is only part of the Sprint Review (~2 hours near the end of the Sprint) which also provides feedback on quality and value. This is a great opportunity to connect with users and stakeholders. This is not a Pass/Fail phase gate. As a an important aspect of quality, the Product Owner should be available to answer questions and review 'Done' work throughout the Sprint.
Sprint Retrospective (~2 hours to close the Sprint) will provide an opportunity to inspect and adapt the collaborative effort of the Scrum Team. It is also the event where the Definition of 'Done', usually the expression of quality, is improved for future Sprints. It is important to
Inspect how the last Sprint went with regards to people, relationships, process, and tools because each is a factor in providing quality, and working effectively and efficiently. Create a safe environment for candid discussion throughout the Sprint, and especially during the Retrospective.
All times based on the stated two-week Sprint time-box. Feel free to chat. HTH