Feature teams specialization

Last post 04:25 pm September 16, 2019
by Timothy Baffa
10 replies
Author
Messages
07:21 pm September 11, 2019

Hello,

At my company I have following teams:

  • Mobile team
  • Backend team
  • Frontend team (Admin portal)
  • Customer portal team.

Mobile team (4 developers): Currently 90% of the time they are working on app redesign. This should occupy them for ~3 months. This is pure mobile work and does not require backend. 10% of the time they are working on "cross-team" features. Some of this 10% require work from Mobile, Backend, and Frontend teams. Sometimes they just ask Backend team to do a quick fix of something so they can proceed.

Front end team (2 developers) works on admin portal features that does not require backend around 80% of the time (they can produce their features end-to-end). Occasionally they work on a features together with backend team members. Sometimes (rarely) with Mobile team.

Backend team (4 developers) spends 50% of the time on helping other teams with their features (like create/update API) and 50% of the time on improving infrastructure (they don't need help from other teams for that)

Customer portal team is 1 developer. 90% of the time she can build a feature from beginning to the end. 10% of the time her feature requires some backend work, so she needs someone from backend team to help. (Usually this backend assistance require like 2-4hours)

QA guys are shared.

Could you help with ideas organizing feature teams out of those?

My thoughts: If I have a feature team of like 2 Mobile devs + 1BE guy + 1 FE guy they may work together on 1 small feature and get it done in 2 days, but they won't have any other common features in this sprint, so for example 2 Mobile devs will have to switch to app redesign, and BE guy to infrastructure work.

I also don't see any common areas where they can work together from month to month. For example if I have a feature team working on "Orders and payments" they may finish all high-priority features in couple sprints, and will have to work on something less-priority unless I move them into another area where important features are.

 

Thank you!

 

 

 

07:35 pm September 11, 2019

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. 

 

07:41 pm September 11, 2019

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. 

07:55 pm September 11, 2019

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?  

08:44 am September 12, 2019

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.  

09:39 am September 12, 2019

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

12:53 pm September 12, 2019

@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. 

01:32 pm September 12, 2019

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?
05:02 pm September 12, 2019

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? 

06:52 pm September 14, 2019

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

04:25 pm September 16, 2019

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