It's important to recognize that Scrum does not say that a team must be between 3 and 9 individuals. The Scrum Guide says that Scrum is most effective with a Development Team size of between 3 and 9 people. A Scrum Team (including the Product Owner and Scrum Master) would have an ideal size of 4-11. Development Teams that are smaller than 3 people or larger than 9 people may experience some issues with the rules that Scrum has laid out - for smaller teams, it may add unnecessary overhead in the way the events and artifacts are managed; for larger teams, you may not have sufficient time within the timeboxes and the additional communication channels may slow the team down.
But that doesn't address the issue - you have a team of 12, which is larger than what Scrum suggests.
Ideally, you would split the team. Because Scrum teams are self-organizing, the team would determine how to best split the team.
There are two guides that take Scrum and scale it - Nexus (from Ken Schwaber and Scrum.org) and Scrum@Scale (from Jeff Sutherland and Scrum, Inc.). There are also a number of other scaled agile frameworks, but those may be a bit heavyweight at this point in time. Even Nexus and Scrum@Scale are designed for cases of 3 or more teams, but some of the concepts are still relevant.
At this point in time, you really only need to split the Development Team. The common guidance is that you have one Product Owner for each Product Backlog and there is only one Product Backlog for a particular product. Since you only have one Product, you only need one Product Backlog and therefore one Product Owner. The Scrum Master can, in theory, also facilitate both teams but that would almost certainly make the Scrum Master a full-time role.
How you split the team is up to the team, although the business should probably have input. Scrum does have some rules about the makeup of the team, primarily that each Development Team needs to have all of the skills necessary to create a Product Increment. That is, a team should be able to take a Product Backlog Item and get it to Done without needing to go outside of the team.
After you split the team, the result of each Sprint should be a fully integrated and Done Increment.
But let's say that you can't split the team. There are still some other things that you can do.
First, try to better enforce the timeboxes of events. A Daily Scrum is not a status meeting - people don't need to get into the details of their work. Focus on things of interest to the group (for example, finishing something that was impeding someone else) or on current impediments that will prevent the team from achieving the goal. The same holds true for the other events - focus on their intents and be disciplined about getting to the purpose.
Second, work on dependency management when ordering the Product Backlog and in Sprint Planning. Try to keep everyone active and engaged. Don't have individuals begin work that is blocked because other people are working on other things. This is wasteful (in the Lean sense of the word). At the same time, keep trying to deliver visible value to the stakeholders at the end of every Sprint.
Third, reduce the size of the people involved in the different Scrum Events. For example, limit the attendees of the Daily Scrum to the Development Team only. If there are people in supporting roles, you can invite them as silent observers (and enforce the silent observer rules) and ask them to leave if they interfere with the event. For events like Sprint Planning and Backlog Grooming, invite only the people who are required. Some good examples would be that roles like UX Designer and Business Analyst would be supporting the Product Owner - only the Product Owner would need to attend the events with the team (and can delegate if unavailable for any reason). This may help reduce the number of people and make meetings and events flow more smoothly.
Finally, begin to cross-train. If your organization continues to grow, you will almost certainly have to either change your process as Scrum will be unsuitable for such a large team or split your team. If you go down the path of splitting the team, you're going to want to make sure that teams have the right skills on that future. Also consider this if you hire new people into the organization.