Feature teams specialization

What would happen if the Customer Portal Team (since it's 1 person) left the company one day? 

Because the teams are so small and specialized there seems to be a high potential for negative impact to the application(s) should someone choose to leave the company. 

Other than that, are there current challenges that the teams are facing with the way they're currently organized? 

While I'm an advocate for feature teams that can produce a vertical slice of working functionality; I also feel it's important for the individuals to understand the problem it might solve and how it can benefit them and the company long term. 

Hi Tony - guys from Front end team can back her up if needed.

Challenges are:

1. These cross-team feature are getting longer to release and there is no real ownership on them. Also I have to gather separate meetings with members of different teams to discuss them.

2. Sometimes we have huge features that may require work of several teams. Like soon we will start working on a feature that will occupy 2BE guys for 1 month and 1 Frontend guy for 1 month. Current team decomposition will not support this feature very well. 

Were you thinking 2 feature teams working from 1 Product Backlog? Some benefits I'm seeing to what you proposed above is that the team can knock out a common feature quickly (it could also address the ownership and communication challenges you mentioned.) 

Perhaps when the team is not working on a common feature they could focus on cross training each other for goals related to infrastructure, front end work, etc. 

Here's a question I've seen teams struggle to find an answer to:

How might the proposed feature team create shared goals and work as an actual team (not a collection of individuals) in the absence of common features?  

Could you elaborate on your first question?

You are not saying that it worth to gather a new feature team for each big feature right? 

Regarding your last question - If there're no common features I don't see any other value of all of them working together.  

The Scrum Guide says that a team should have all the skills to produce a Done increment. So, because of dependencies / needs you describe, feature teams is a logical choice. If you separate them into "technologies", you create hard dependencies between teams and limit their way of providing Done increments as a team by themselves.

Epics or themes can be put into one team, to be handled end-to-end cross-tech.

The trick might be in designing your PBIs and themes in such a way, that they will fit this structure

@Pavel, 

Given the amount of developers/ QA, it sounds like you'd have enough cross functional skills to have 2 feature teams that can produce a done increment. What I'm not sure of is how many products the teams currently support. 

It sounds like the biggest opportunities could be decreasing dependencies between teams, cross training developers to be able to support the whole product, and less time coordinating between teams and filling in any communication gaps that come with that. 

1. These cross-team feature are getting longer to release and there is no real ownership on them. Also I have to gather separate meetings with members of different teams to discuss them.

2. Sometimes we have huge features that may require work of several teams. Like soon we will start working on a feature that will occupy 2BE guys for 1 month and 1 Frontend guy for 1 month. Current team decomposition will not support this feature very well. 

Before we consider team structure:

• Is there one Product, with one Product Backlog, and one Product Owner?
• Does the Product Owner value incremental delivery of that Product?
• Is there an authoritative Definition of Done with which product increments must conform?

I'm going to start with this quote from the Scrum Guide.

Scrum is a framework for developing, delivering, and sustaining complex products. 

From your comments it seems to me like the work being done isn't very complex since all but one of the current teams can do 80% or more of their work without needing any interaction from other teams and the one team can still do 50% of their work alone. You have never mentioned anything about a Product Owner, Product Backlog, Sprints, or any other Scrum artifact.  The only problems you specifically mentioned are not really adding to complexity of the product.  

I'm going to suggest that you might be trying to force something in place that isn't necessarily the right solution. Both of the challenges you provided could be addressed in a number of ways and some of them are waterfall practices.  Is there a compelling reason for the solution choice you are considering?  Will it provide better solutions for all current and future work? 

Before we consider team structure:

• Is there one Product, with one Product Backlog, and one Product Owner?
• Does the Product Owner value incremental delivery of that Product?
• Is there an authoritative Definition of Done with which product increments must conform?

1. The whole solution consists of 3 products: 1) Mobile application 2) Admin Portal 3) Customer Portal. We have one product owner and one product backlog. On the Sprint planning meeting we take PBIs one by one, split them to subtasks and those go to each team's sprint backlog

2. Yes. At the moment we release the whole products once a month, but would like to make releases more frequent.

3. Yes, and it's pretty simple at the moment: No Critical and Major bugs. 

 Is there a compelling reason for the solution choice you are considering?  Will it provide better solutions for all current and future work? 

I want to:

1) Decrease amount of dependencies between teams

2) Make each team able to release their features independently

I want to:

1) Decrease amount of dependencies between teams

2) Make each team able to release their features independently

I do not intend to come off as oversimplifying this, but:

• Feature teams decrease/eliminate dependencies 
• Feature teams support the independent release of features
  
   
• Component-based teams / individuals (front-end, back-end) increase dependencies between teams
• Component-based teams / individuals make it more difficult to release