Skip to main content

Please suggest how to divide teams

Last post 07:32 pm February 13, 2023 by Maksym Odanets
4 replies
08:41 am February 10, 2023

Hey colleagues,

Could you please help with the decision of how to split/divide teams to increase productivity?

Our story:

We are building microservice architecture. From the very beginning, we set up a couple of Backend (BE) teams and a couple of Frontend (FE) teams. Teams worked independently on one feature which cased situations, when one team blocked another (BE could finish their part first with no way how to test on FE or vice versa). However, such setup has Pros as well - each team is a service owner, they have their internal culture, they can suggest improvements.

In order to speed up delivery, we are considering changing a team structure and have several options:

  • Create a "Feature Team" around one (or a couple of) service(s). Each team will consist of Frontend & Backend developers. Each team will be service owners and have everything they need to finish the task; However, for some situations cross-team collaboration will be still needed;
  • Create a couple of independent "Pod Teams" which will be focused on a feature and will be able to go to any service and do their changes if needed: like Internal Open-source; In this case we will be able to focus on features however will lose service ownership which can affect on some Quality Attributes;

What could you suggest, which option will work better? Or maybe we are missing something and there are other solutions?

Other info, right now:

  •  each team works by scrum
  •  we have about 20 BE microservices and 5 large FE applications; 5 BE teams & 2 FE teams


07:51 pm February 10, 2023

You make no mention of Scrum or Products.  Do you have identified Products?  Is there a Product Owner that can maintain a backlog of items that represent changes that need to be made for those Products? Have you asked the Developers if they have a better solution to the issues you are seeing? 

If you want my Scrum specific answer, here it is. 

Scrum is focused on having a team of individuals that fulfill specific responsibilities to create, maintain and manage a specific Product.  The team is made up of cross functional members that have all the skills necessary to accomplish the mission of achieving the Product Goal. In your current situation, you have multiple teams focused on a small portion of a product that will, as you have experienced, dependencies.  If one team had all the skills needed to make changes to code base to introduce new functionality, it would be easier to mitigate those dependencies to allow for faster delivery.  But it would require your organization to change the way that it thinks about software delivery. 

My not Scrum specific answer is pretty much the same so I won't go to the effort of typing it out. 

11:18 pm February 10, 2023

Ideally, any decisions on how to organize the people and teams would come from the teams themselves.

That said, the teams may want to investigate LeSS and Nexus for scaling Scrum and Team Topologies for structuring the teams around the value streams and products. Assuming that the teams are already practicing Scrum, LeSS and Nexus are two good structures for coodinating between three or more Scrum Teams working on a single product, while Team Topologies can give you some structures for thinking about how to think about the work taken on by each team within the context of the product. It could also be interesting for the teams to look at FAST Agile as an alternative approach for self-organizing.

If the teams have recognized that there is a problem and are struggling to think through ideas, these are a few things to bring to the team for their consideration. However, if the teams haven't yet realized the concerns, starting with the perceived problems would be a good start and then seeing if the teams have any thoughts for how to solve them, perhaps bringing in some of these solutions to have more concrete conversations.

08:56 am February 11, 2023

Could you please help with the decision of how to split/divide teams to increase productivity?

First have a grip on how productivity is being measured. What are the clear value streams which are worth owning and maximizing? For each of these products, how is quality going to be accounted for so each increment is genuinely Done?

Quality is not a matter of "service ownership" to be handled as a separate concern. It's an accountability and a commitment made by Developers, irrespective of whether they have self-organized into feature teams or something else.

02:14 pm February 13, 2023


Thanks for your suggestions. Really helpful.

Now we have lots of things to discover.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.