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?