✥ ✥ ✥
There is no one way to structure a team or work that is correct for all situations and all work.
For any multi-person work you have to organize tasks and people to work together in a coherent, coordinated manner. Otherwise, you risk falling into chaos. But this organization can be complex.
To reduce complexity organizations will standardize structures and processes. This may be through adoption of “world’s best practice” or through historical development of the organization’s culture. Best practices develop in a specific context to achieve specific objectives and these may not suit a given organization.  An organization may develop its own “best practice” structures and processes at a certain time, for the situation at that time. They become established practices. However, while they work for a while, they no longer remain to be the “best” as time goes on and the situation changes.
People can be comfortable when someone else leads and tells them what to do. This direction and control has some consequences. Motivation and workplace factors such as turnover intention and job satisfaction can suffer when people are working for controlling managers.  Moreover, the people doing the work are the ones who understand how to do their jobs the best, and when their work is controlled by someone else, valuable information about how they do their job is lost. For example, a factory worker may improve the efficiency or safety of some task at their own initiative, and this improvement might never be implemented if it should come only from a manager who is not enough in touch with the situation to appreciate the need for a solution, let alone the solution itself.
Development Team members have specialized skills, and it is beneficial to take advantage of their differences to work efficiently. But if everyone only works within their own expertise some work may not get completed and the team might not finish anything at all.
The Development Team controls all aspects of its day-to-day work. For example, they run the Daily Scrum meetings, and decide who works on what. They decide the order of work, and decide how to organize Swarming. The team decides how to take advantage of Developers’ special skills and areas of expertise. It may include deciding who pairs with whom, and so forth.
✥ ✥ ✥
Note that self-organization requires maturity and discipline. Some people are uncomfortable with self-organization. Stakeholders such as the Product Owner may be tempted to jump in to help, or the ScrumMaster might think they know the who should work on what (at no time does the ScrumMaster assign people to work on tasks or tell Developers how to work). But people outside of the Development Team need to let the team learn through self-organization, even if it is initially difficult. A Scrum Coach can help.
One danger in removing an explicit supervisory role is that another individual (on the team) may fill that same role, forcing their will on the team through charisma, bullying, or dominating the conversation. This leaves the team with exactly the same dynamics as it had previously. The ScrumMaster needs to understand that this may happen and prepare the team by modeling behaviors that ensure everyone on the Development Team has the opportunity to contribute. This will help to establish norms for the team. If this type of behavior does appear (or anything else that inhibits self-organization) it is the responsibility of the ScrumMaster to resolve the impediment.
This pattern is one of the practices at the heart of Scrum. It allows the work in a Sprint to move forward in the most efficient manner. It improves the morale of the Development Team (and there is evidence of improved performance ). It allows the Development Team to examine itself and improve (See Sprint Retrospective, Scrumming the Scrum, and Happiness Metric, for example.) With it, the Development Team becomes self-healing — it can see its faults and has the power to fix them. This is one of the most important patterns for a Scrum organization to master.
When a Development Team is allowed to self-organize, they are given freedom and commensurate responsibility: it is the gate to a Community of Trust. A team that has their own say over how they build their product is likely to increase their pride both in themselves and in their product; see Team Pride and Product Pride, respectively.
 Don Reinertsen. Managing the Design Factory: a product developer’s toolkit. New York: The Free Press, 1997, p. 184.
 Stefan T. Güntert. “The impact of work design, autonomy support, and strategy on employee outcomes: A differentiated perspective on self-determination at work.” In Motivation and Emotion 39, 2015, pp. 74—87.
 Marie-Ève Jobidon, Isabelle Turcotte, Caroline Aubé, Alexandre Labrecque, Shelley Kelsey, and Sébastien Tremblay. “Role Variability in Self-Organizing Teams Working in Crisis Management.” In Small Group Research 48(1), 2016, pp. 62-92.
Picture from: Juan Eduardo De Cristofaro / Licencia Básica, image-id: F100005244, freejpg.com. (no copyright)