Skip to main content

Dividing big Dev team into small Dev teams

Last post 03:40 pm January 16, 2020 by Aditya Vaze
10 replies
11:41 am January 14, 2020

My situation is:

  • Working on a mobile banking app
  • We have 3 backends, 3 frontends, 3 iOs, 3 android developers and 4 business analysts

The Dev team must be divided into Dev small teams, as SM my offer is building 3 Dev teams which each consists of 1 back, front, iOs, android developers and an analyst. It will reduce complexity, but the PO thinks in a different way. His offer is building feature-based Dev teams and a dedicated support team which I am against because it will lead to non-cross-functional teams. In my opinion, there should not be a dedicated support team, all teams have to take into account that there will be some support work to do so they can make proper planning.

The question is which approach is better? Having equally divided Dev teams? Or feature-based Dev teams and a dedicated support team?

02:37 pm January 14, 2020

In my opinion, I'd say, Feature-based team. As long as the Support team has Experienced Tech's at that point all you need is the appropriate  Knowledgebase, proper documentation skills, and the right Support Manager. You can create a cross-functional support team.

A feature team is a cross-component, cross-functional, and a long-lived team that picks end-to-end customer features one by one from the product backlog and completes them. These teams play a crucial role in scaling up Agile development. An organization without a feature team structure is expected to create plenty of problems that lead to a sequential development cycle like Waterfall. This team structure fixes all these problems and also introduces some changes and challenges.

03:29 pm January 14, 2020

Why don't you let the developers decide? Raise the team size as an impediment and let them decide.

04:27 pm January 14, 2020

One approach at a former company of mine was the creation of cross-functional feature teams, but rotating one of those teams into a support role for a couple sprints.

The rotating support team would take a reduced amount of feature work due to their reduced capacity, and being in that support role provided every team member with a crash course in the applications they worked with and associated issues.

Each Development Team and individual Team member came out of the support experience much healthier and more knowledgeable.


06:16 pm January 14, 2020

Which approach would reduce the dependencies each team would then have to manage?

What do the team members think? They are the ones who’ll do the work.

08:54 pm January 14, 2020

The Dev team must be divided into Dev small teams,

When I read that I immediately asked "Why?".  What problem is being solved by doing so? And feels the change is needed?

After I read both of your suggestions I still have no clear picture of what you are trying to address or who feels there is a problem. Both options you have are viable but under different conditions. If you can clearly elaborate the problems with the current organization, then you can start to address them. However, I am going to side with @Aditya Vaze and @Ian Mitchell by saying that after you identify the problem, let the people doing the work decide how they feel they can best organize to address it. 


12:17 am January 15, 2020

I like the idea to ask the developers themselves. It will give you and your PO other insights.

07:57 am January 15, 2020

We have already asked the team how they want to do this, but there are different visions. I would like to know which approach is better. 

12:15 pm January 15, 2020

The only advice that I can give you is to NEVER create a DEDICATED support team WITH permanent members.

The developers that get stuck in that team will get/have the feeling that they aren't developing and will quit fast by asking their transfer to another department or just plain quitting the company.

I'm going the side of Timothy Baffa, you could suggest this approach to the Team and see what they think.

04:24 pm January 15, 2020

I agree with @René Gysenbergs and @Timothy Baffa.  The permanent support team is usually the team with the highest turnover rates. Avoid it if you must have a support team of some kind.

We have already asked the team how they want to do this, but there are different visions. I would like to know which approach is better. 

I think what you are missing is that none of us can tell you which is better because every organization, every team, every situation is different.  You have to help the organization for which you work to determine what is best for them.  If you are getting different visions, what would be the harm in letting the team pick one to try with the understanding that if it isn't accomplishing what is needed to solve the problem you are addressing, additional changes will investigated and try.  Approach this problem just as you would a new feature in your products. 

  1. Pick something to do
  2. Do it
  3. Get feedback
  4. Inspect
  5. Adapt
  6. Go to step 1

03:40 pm January 16, 2020

You may want to try a few "One-Day Sprints" (within the sprint)  for development teams to grasp their own inclinations, cohesions, and frictions. You can design it around a feature and support roles and align with your organization's vision. But still, I will insist that it would be better that they themselves decide how to organize. It will also provide all of you an ample opportunity to find a viable solution that fits your organization's needs.     

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.