Organizing teams

Dear Monica

Do I understand you correctly, you are talking about building new Scrum Teams?
This is a rather broad question.

Main points are:
Since we believe in self-organization we know that Scrum Teams best organize themselves (or future team members best build Scrum Teams themselves) while they need to understand, that they should be cross-functional and ready to deliver done increments in the end.

Hope this helps
Sebastian

I guess your question is about the team structure of the Scaled Scrum, Nexus.

Collectively, there are 2 type of team structure including feature team and layer team.

A feature team is a cross-functional development team.
A layer team, or component team, is responsible for a specified layer, such as UI team, DB team, function team, etc.

Organizing the Scrum Teams to features teams can minimize or eliminate the dependencies. That is very important for Scaled Scrum.
Feature teams have less overhead of communication.
Feature teams are easy to involve business people to collaborate or help.

You can get the input for the business people to help you turning the PBIs to the Increment that should meet their requirement.
You are not possible to ask business people how to design a database if you are a member of DB team.

Layer team is easy to organize. Each team has specified competencies and skills. Layer teams are not encouraged in Scrum.

Of course, for a large product with cross-cutting design, a hybrid structure may be introduced.
That means the Scaled Scrum consists of both feature teams and component team.

Thanks for your answers Ching-Pei and Sebastian.

When reading it, i wonder how to best organize them if the organization is having complex architectures and multiple application layers. From Ching-Peis answer i can tell it would be best to use the Feature team? But then I wonder if the competence will be to cross-functional to effectively solve PBI's?

According to Sebastians answer, I just put all developers in same meeting and let them self-organize and the outcome will be neither feature or layer?

Teams should be organized by feature rather than by layer or component. Each team should be in a position to complete the user stories in its Sprint Backlog, and to integrate them with other teams' work in a potentially releasable Increment.

Where there are cross-cutting dependencies across teams, then those teams should self-organize to ensure that the dependencies are resolved. This might be done through a Scrum of Scrums which co-ordinates work on shared components, for example.

Hi Monica, don't worry too much about the thery. Try to minimize dependencies between teams and pay attention to skills in the teams and just get started. use the scrum theory principles tranparancy, inspect and adapt to learn from experience. Later you always can change the focus of teams. We are using scrum now for 8 months and many teams have changed their organization or even made a restart. It is a very good idea to put the team members in the lead to organize how they want to work, but take care to adhere to to the scrum principles and disallow waterscrum solutions.

Stability in teams has its value, but you have to learn.

Dear Monica,


Sorry it has been a while!

According to Sebastians answer, I just put all developers in same meeting and let them self-organize and the outcome will be neither feature or layer?

We try to believe in our team members. And trust them to self-organize properly.
And as I wrote:

... while they need to understand, that they should be cross-functional and ready to deliver done increments in the end.

So we DO need to make them understand the idea of Scrum and that THEY will be responsible to deliver working software.
That’s why also THEY are responsible to create the teams and not some manager. Because it is them who know their work best and it is them who know best with whom they can work together efficiently.

...this should lead to self-organized, cross-functional, motivated and efficient teams.

That’s why also THEY are responsible to create the teams and not some manager. Because it is them who know their work best and it is them who know best with whom they can work together efficiently.

Hello Sebastian,

The Scrum Guide doesn't advise nor place responsibility on *teams* in regards to who will be assuming what role (PO, SM, Development Team) and how individuals will be distributed among teams (in a multi-team environment).

The fact that Scrum Teams are self-organizing doesn't mean they can pick and choose the roles and teams they want to be in.

There is a great article by Mike Cohn explaining the role of leaders and managers in an environment with self-organizing teams.

https://www.mountaingoatsoftware.com/blog/the-role-of-leaders-on-a-self…

"Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing."