The traditional descriptions of the scrum team say: it is dedicated to a product, crossfunctional, and has three scrum roles: product owner, scrum master, and team members. Scrum introduces the timed team interaction structure: sprints, sprint meetings, and standups.
The core of good planning is product backlog refinement, user story analysis, definitions of 'done', stakeholder involvement, continuous improvement through reflection and retrospects, etc. Beyond that, scrum does not quite tell you what to do. It says the teams are 'self-organizing' without being specific on what it means: scrum is agnostic to any actual process, design, or development methods, which are outside of scrum and left to the self-organizing team or the parts of the organization outside of the team to choose and manage.
The good read, Dave Nicolette, Limits of a self-organizing team, 2018, demonstrates how vague the meaning of "self-organizing" is and gives an overview of what is and what is not up to the team itself. The combination of vague term and belief that imposing scrum onto a team would work on its own. Then, in large organizations, the team self-organization often quickly becomes the thinly veiled old relationships, and in small young startups, the original chaotic lack of structure prevails.
The Myth of scrum team: if an organization adopts scrum, the effective product team will emerge, given proper coaching and organizational support.
Clearly, scrum does not cover all the software process: design methods, continuous integration, etc, let alone specific software skills. Scrum's purpose is timing, planning, and minimalistic structured team interaction. However, it is a mystery how the ongoing communication inside of the classical scrum team of up to a dozen of people is vaguely described as "self-organization". Even a couple of software engineers notoriously and quickly go out of sync with each other, often in the matter of hours.
Therefore, what does scrum team self-organization means at all? One could say: self-organization is what is up to you (with the understanding what is not). That's the angle from which Dave Nicolette's article mostly treats the subject.
Let's step back a bit in establishing what self-organization means in the scrum context. In software (or maybe even generally in commercial enterprise), self-organization is not a goal in itself. Unless it serves a purpose, why bother. Thus, the meaning of self-organization in the scrum context is established through its use.
Both theory and practice of scrum show that in principle, if you have up to a dozen of diligent engineers, with a hyper-active product owner and scrum master, you totally can run very well-planned, flexible, satisfying, and successful projects. The problem is that, depending on the team size, the product owner and scrum master would need to spend half or most of their time to make sure the process is followed, definitions of 'done' are satisfied, backlog refined, etc.In the team of 3-4 people with a good project owner and scrum master, one could afford to worry very little about the team self-organization, but in the teams closer to a dozen, the time and context switching of the owner anb master become a productivity bottlenecks, a blockage in the lean value flow.
Team self-organization (apart from the lateral benefits) is meant to unblock it. That's the usage and meaning of it in the scrum context. It all is about the mechanisms of team interaction, of which, apart from the scrum rituals, scrum seems to be silent.
This silence creates an impression that scrum is agnostic about self-organization: it is up to the team, as long as the team has the capability to tell what is and what is not up to them.
However, I do not think scrum is silent on the matter. Instead, it stays lean, permissive, and minimalistic. Additionally to looking for the answer outside of scrum and adding other methodologies (e.g. kanban, or XP) into the mix, the question is whether more specific team interaction structures could be deduced from the scrum process itself.
User story combined with its definition of done is the value-producing dimension of scrum (and arguably of any agile or lean approach) along which informs all of its other practices. User story expresses a deliverable in user's vocabulary, while the definition of done is the companion "implementation story": what is it that needs to be done so that the user would be able to say "as ... I want to ... so that I can do ..." (see Modeling bias for more). User story + implementation story represent deliverable artefact.
A common distortion of scrum is activity bias: the definition of done replaced with action items, e.g. "unit test" as a functional part of deliverable replaced with "test such and such", seemingly the same statement, which nevertheless subtly shifts the ownership from owning the unit test to owning the action of writing the unit test, which loses the view of user-owner relationship: The user story has nothing to do with the action ("write unit test"), unlike the unit test itself, which represents a kind of "standard" user story: "As a pilot of the plane, I want to be able to meaningfully report software malfunctioning, so that its cause is quickly identified and fixed." (Sometimes, it is reasonable to cut corners there: "As a player of this cool online game, I give no damn if it malfunctions, as long as reload button in my browser fixes it.")
Artefact needs a user (or, much better, two users; see The rule of second use case) and the owner: the person or a group who satisfy the definition of done. This is essential microstructure defined in scrum, and my point is that exactly this microstructure informs scrum team self-organization, as much as scrum is concerned. This user-owner relationship at the level of each artefact on the backlog does not necessarily emerge on its own.
It is necessary, but not enough correctly identify the users and owners. The usage of the artefact throghout its life cycle is in continuous negotiation between its users and the owner, which involves (and really is the purpose of) all scrum ceremonies as well as design sessions, code reviews, demos, etc. For example, I always design a product, or a tool, or a utility through its usage, both with the clients and other engineers. When I have a design session with a colleague, we sketch the artefact usage, e.g. --help for a command line utility with usage pattern, not just an "interface"; one of us in fact plays the user role and the other the owner's.
Nurturing and maintaining this relationship for each backlog item may be the most important skill and duty of the scrum coaches, product owners, and scrum masters. The more continuous, fluid, casual, and distributed in the team the user-owner relationships, the more self-organized the team is in scrum sense.
Users of artefacts always are stakeholders, but not the other way around. They also are not the ones who tell user story (which may come from marketing or a business analyst - although eventually, direct connection between the actual engineers and actual users is the best. Users are those about whom the user story speaks: "as a plane pilot, I want to ..., so that I am able to ...".
The status of the user and the owner of an artefact creates familiar situations with which the product owner and team leads or scrum masters need to deal to distribute the user-owner relationships in the team:
Although Scrum does not formally define self-organizing team, it is not agnostic about the meaning and structures of the team self-organization. Scrum is minimalistic and silent on the matter, but its value flow (through user stories) and bottlenecks (product owner's and scrum master's overhead) imply that, as Scrum is concerned, the team self-organization means delegating user story treatment to all team members. The form of this delegation is user/owner relationship explicitly articulated and continuously maintained for each user story.
This micro-structure replicates Scrum roles in miniature and permeates team work. The product owner and scrum master (as well as senior - in terms of experience and initiative - team members) is to continuously build such user/owner relationships as well as watch and repair them, if they start disintegrating, often due to the enthropy inside or outside of the team, by means of daily standups, reviews, demos, facilitating peer-to-peer relationships, etc.
The user/owner relationship around the user story and asking the question "having such and such technical capabilities, what is it that we should do for the user to be able to realize his story?" maps into or rather stems from semiotic structures reflected for example in the notion of semantic-pragmatic meaning-use relationship introduced by Robert Brandom; see more on it in: Architectureless design