Structure of a Development Team
Hi, I found a sentence in the Scrum Guide that really confused me. Page 7, 2nd paragraph: "Development Teams are structured and empowered by the organization to organize and manage their own work."
What means in this context, that the organization structures a Development Team? I thought, that even forming the team is a part of self-organization. Should the organization really put together (is that the same as "structure") a Development Team or define its structure? For me the only criterion with regard to a Development Team is, that it needs to be able to deliver increments.
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.