How to form scrum teams

Question

I work as a scrum master in a place where we have two distinct products. And these products have submodules:

Product A: (The bigger product)
  Submodule A.1
  Submodule A.2
  Submodule A.3
  etc.

Product B: (The smaller product)
  Submodule B.1
  Submodule B.2
  Submodule B.3
  etc.

Right now we have two teams. Product A team (Consisting of 12 developers) And Product B team (Consisting of 3 developers)

And also we have two testers who are not actually part of these teams and have a diffrent backlog.

In our teams we have code reviewing process which is done before an issue is resolved. So a code which is unreviewed by a peer cannot be marked as done.

I know 12 developers is much for a scrum team and 3 developers is a small number for a scrum team. Because of this and for some other reasons we are facing some problems.

1) Product B team is moving at a slow pace and losing too much time on issues. The code reviews are not done throughly and buggy codes are being marked as done. The B team is actually not much like a team, everyone having their own goals. That is because one developer is always working on the core features and on an operating system level. The other developer is always working on the User Interface side (actually he is not a UI designer, but a backend developer) and the other developer has joined the team recently and working on ways and making research on how to make the product run with more performance.

So the developer working on the operating system level is reviewing the UI codes. The UI developer is reviewing the OS level codes. They actually do not have the expertise to review each others code and doesn't really know or isn't really interested on what another is doing.

2) Product A team is a big team and the product is a huge product. It consists of several (like 10) submodules. All submodules are distinct modules on the server side (sometimes they use common libraries and common conf files, modules etc. but generally distinct) but they all share the same GUI (A java swing application is used to manage all these modules) So 2 developers are always working on the GUI, some developers work on most of the modules on backend side. And some developers are always working on the same submodule (For ex: Submodule A.1 and Submodule A.2) So those guys have much expertise on that module, but doesn't know much about the rest of the product. Whereas the other developers know much of the product except from those submodules (Submodule A.1 and Submodule A.2)

Actually all of our developers are good developers who can handle whatever you throw at them. But of course some of them are better on the UI side whereas some of them are better on the backend side. Some have gained much expertise on a specific module, so a job on that specific module is always done by that specific person. This leads to one man shows, the failure and success becomes his not the teams.

So my main question is how should we form teams and backlogs? Right now we have to teams (product A and product B team) and two backlogs (Product A and Product B backlog). Should we keep this?

We are planning to create teams like OS Team, Platform Team, Frontend team, Architecture team, Implementation Team, Test team, Security team, Documentation team. Actually I don't even know how this will happen, we don't even have that much developer. Maybe one person will be in multiple teams, I don't know. And if we create teams like this how should we form the backlogs?

But I think this kind of team structure is against scrum, because scrum teams should be cross functional. All kinds of expertise should be in teams.

Or should we create new teams at the beginning of each sprint according to the sprint's needs. But how will this be (Who will attend which sprint planning meeting?)

P.S: Product A and Product B developers are skilled enough to work on the other product.

And according to the team structure you will recommend how many scrum masters should we have. Is one scrum master is enough or should each team have their own scrum masters?

Answer 1

Your asking many questions here:

• component teams (platform, front end ... ): You are correct, that goes against Scrum. If you want to lose time with handover then do this :-)

• shared team members Also goes against Scrum. Multitasking slows people down, makes them lose focus. Good for bad quality :-)

• How to deal with a really large and really small team? The obvious solution is to shift team members. Just make don't order it. Address the issue with the teams. Maybe some of large team would like to help out in the small team. This may be for a limited amount of sprints or permanent. It could be a kind of sabbatical.

• Some people work on the same all the time: Remember t-shaped worker? It is okay if some team members a really good at one thing and do this a lot. But if the do it exclusively you run into bottlenecks. Inspire the specialist to teach and share their know how. They will stay the specialist but others can and should help out.

• How many backlogs? Maximal one per product, independent of the number of teams.

• New Team structure every sprint: Been there done that, does not work. A team needs time to form. Building new teams every sprint makes really bad teams. An extra effect is that after a while everybody seen just a bit of everything but has no deeper understanding of anything.

• How many Scrum Masters: With that may issues a Scrum Master per team is necessary.

Answer 2

Very late answer. It won't help you, but maybe someone else.

Product A team (Consisting of 12 developers) And Product B team (Consisting of 3 developers)

Team A is too large for effective communication. Team B could work in theory but it's very small.

because one developer is always working on the core features and on an operating system level

You shouldn't have a 'core feature'. Your features should deliver value for the end-user. Any 'core feature' that needs 'UI features' to be actually used, is not delivering value. It is a technical task, not a feature.

Ideally your developers would work together on the same feature, and usually from their own perspective (core. UI.) But with the same user-value in mind.

In your case I would mix the teams. First, the backlog must contain user-stories (deliver value to the user); not 'build this UI feature which still requires X-Y-Z to be built before it works'.

I would call them together (all 15); tell them the backlog; and ask them to organise around the work. * Form teams yourselves * No one left behind * No team smaller than 4 or larger than 7 * Each team must have the capabilities to do the work.

You'll end up with 3 teams and each may have a different focus area. Team 1 may focus on Product A, and teams 2&3 may work on product A + B both.

• I want to know how they plan to divide the work over the teams.