Structure of a Development Team

Management creates the Scrum Team by hiring and assigning the right resources to the team. Ideally, the leadership of the organization would then give the Team a sense for the high-level vision, and let the Team decide how to create value. That may happen in small start-ups, but it doesn't normally happen in large organizations.

Isn't self-organization a kind of structure ?

What will happen if the organization is averse toward self-organization (because it will obviously be crappy if there isn't a manager... )

Here in the forum you can find various articles about forming a team. When talking about "the real world" many of them state that management may simply assign them. However, when we go back to "scrum by the book" or "scrum by the Scum guide" or "scrum as it was meant by its creators" it's quit different. Then self organization seems to be an important factor. 

Here is an interesting article from Ken Schwaber on how to compose a team: https://kenschwaber.wordpress.com/2012/07/25/self-organization-and-our-belief-that-we-are-in-charge/

For me it is pretty obvious that the opinion expressed in this article cannot be aligned with the statement that the organization structures the scrum team.

In my experience, organizations have to do an awful lot of restructuring before their teams become empowered.

York, you ask a very interesting question, and there isn't just a single correct answer to it.

I like how the late Dr. Hackman explains self-organization. If you look at his authority matrix, you'll see that self-organization is an umbrella term spanning across self-managing teams that work within a structure given by someone outside that team to self-governing teams that design their structure. How and to what extend self-organization is enabled and lived depends on the maturity of the people - managers and team members - involved.

Based on that, where do you see Ken Schwaber's perspective? And how might different interpretations of self-organization influence people?

Johannes, thanks for your reply. I find it to be an interesting idea that self-organization can have different levels of advancement. However, given the fact that the organization sets up the team and gives it a certain structure and the team self-organizes within these boundaries would mean that the Scrum Guide only describes teams of relative low "maturity". 

Honestly, none of the explanations really convinces me. Maybe that frase should be removed or changed in a new version of the scrum guide because it is confusing.

It depends on the management to decide the team.

Well, the development team can be formed in different ways, according to the structure of the company/institution that needs that sort of team, to their size, goals...

For example, a small company that employs less than 10 people will more or less organise itself into a development team (or at least, a part of that company), while a bigger company could tell several of its employees to create a team. Or they could specifically hire people to create it. Or they could mandate a private R&D company to work for them.

There are as many structures of development teams as there are development teams, I'd say...

Structuring a Development Team might be nothing more than having a budget and defining accountability (or an expected return on investment) for that team.

Developers may then self-organize into that space and create the Development Team around the defined structure.

Not to mention that the very structure of the team may change over time. For example, if you're working on a program, you'll need a graphic designer to make that program look good only relatively late in the development process, as all of the groundwork has to be done before aesthetics become something worth worrying about. 

We developed applications for this situation. I already know that expertise and quality software are really important to build a technical team on the same subject. But it is very difficult to find a successful team and to consult. The best way to ensure that software development team structures is the main programming languages is straightforward. I hope that it will make progress and prosperity possible.

It's 2024 and the confusion in this thread is still relevant. The key question is: Does the 2020 Scrum Guide require Scrum teams to always be self-organised? 

And the answer is a definite no. With the 2020 version, the guideline has deliberately become less prescriptive towards the organisation. Quote: Rather
than provide people with detailed instructions, the rules of Scrum guide their relationships and
interactions." 

This purpose of the scrum guide also applies to this question of who has the mandate to form teams.       I myself am a clear advocate of agile teams and self-organisation, but by definition it is not an absolute requirement or value conformity to scrum if teams are appointed or structured by organisations if they are empowered by the organisation to work self-managed according to scrum. Quote: "They are structured and empowered by the organisation to manage their own work." 

With all due respect to self-organisation-advocates, it is not an exclusion criterion to work according to scrum. Why should scrum prescribe this, if it does not violate the values of scrum or the pillars of empiricism. It is consistent with scrum theory and absolutely compatible with the agile core values. Neither the agile manifesto nor the 12 basic principles or the 7 principles of continuous innovation are negatively influenced or curtailed by this. 

As the learing-series regards ScrumTeams state out: "It's true that the managers are not required to constitute a Scrum Team, but that doesn't mean that no managers are required in the organisation." It is not a requirement that the organisation appoints or organises Scrum Teams, but it is an adaptation variant within the Scrum Guide 2020. I totally understand if someone has done Scrum certification in 2013 or 2017 and cannot reconcile this with their values. However, i advocate a magnanimous living out of the Scrum values and the principle of continuous improvement and let Scrum be Scrum.