✥ ✥ ✥
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 must 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 still the “best” as time goes on and as 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 someone else controls their work, they miss valuable opportunities for efficiency, effectiveness, and for quality results. For example, a factory worker may improve the efficiency or safety of one of their tasks at their own initiative. This improvement might never come to be were we to wait for it to come from a manager who is too out of touch with the situation to appreciate the need for a solution, let alone to be able to conceive the solution.
Development Team members often have specialized skills, and it is beneficial to take advantage of their differences to work efficiently. But if everyone only works only within their own expertise, they may delay work that they would otherwise complete if they were to spread the work more evenly.
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 can contribute. This will help to set up 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 the business allows Development Teams to self-organize, they gain both 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 become more proud both of themselves and of 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)