Your goal of encouraging self-managing collective ownership of the product development process is the right one for encouraging team agility. However, the team as whole appears to lack sufficient experience (and possibly the teaming skills) required to fully embrace agility.
The solution is essential to find the X in the implicit X/Y problem. That means identifying the roles and skills missing from the team, and addressing the gaps at a more fundamental level. It seems highly likely that the dysfunction is organizational, and probably can't be improved without active leadership from the top.
Analysis and Recommendations
First of all, it's worth noting that you aren't doing formal Scrum, as evidenced by the fact that you have no Scrum Master. Based on your description of the project structure, it seems more likely that you're doing some variation of Kanban or Scrumbut. The lack of a coaching role or process referee is at least part of the problem, so I'd strongly encourage you to add a Scrum Master, Kanban expert, or agile coach to the team.
Next, acknowledge that you don't actually have a team. Instead, you appear to have a group of individual members who are neither self-managing nor collectively invested in delivering a coherent product. This is part of what Scrum was designed to address through its core accountabilities. While other frameworks certainly allow for agile teams that are real teams, not just a collection of individual contributors, Scrum is the most widely accepted template for encouraging that. You might want to reconsider whether your Kanban or Scrumbut process is sufficient scaffolding for building the type of team you say you want.
Beyond that, you might need to work with line management or senior leadership to determine whether the organization is hiring the right sorts of T-shaped people who are capable of being self-managing, want to be collectively responsible for measurable outcomes, and have the skills to collaborate and swarm rather than act solely as individual contributors. Agile frameworks don't magically make mediocre collections of individuals a cohesive team; they simply provide scaffolding that enables self-actualizing people to come together and collaborate more effectively within the limits of their individual skills and abilities.
High power-distance cultures and organizations often struggle with agile implementations. Companies that hire for narrow technical capabilities and willingness to respect authority frequently run into problems when switching to agile development models that require a different skill set that focuses on:
- independent- and critical-thinking skills,
- a strong drive for collaboration, and
- honest and courageous interpersonal communications.
If the problem is systemic, the problems will need to be addressed top-down from the senior leadership level to gain any real traction. Be honest with yourself, the team, and senior management about the expectations of the team and the skills/experience gaps the team has. It's up to the organization to decide how to fix the expectations they have of the team, and to populate the team with the right people and skills required to make the project successful. Any other approach is simply stepping around the problem without addressing it head-on.