Should we arrange multiple agile sub-teams along customer groups or along software components?

Question

The question's context is a company that creates a software product that consists of several functional components (you could also call them sub-products) and sells the product to a rather small number of customers (~10 core customers, <100 in total). Those customers pay a licence fee for new stuff and an annual fee for maintenance. There are around 20 developers, working with an agile process for several years. We consider moving from project teams to fixed teams. We are discussing two primary principles how to arrange the teams: (1) Each team is responsible for a set of functional components, or (2) each team is responsible for a group of customers.

Do you have positive or negative experiences with either option in a similar context? Which of the options is better for the given context?

Answer 1

Experiment.

No answer presented here will fit your specific product, team or customer. Agile promotes continuous improvement, so go for it.

With that in mind, we can review some key items to consider while experimenting:

• Why changing? Have clear the problems the team is intended to address by applying these changes. Changing for the sake of change "to become more agile" is not a real purpose. Your real purpose is to deliver value more often and with predictability. Agile is a tool that can help you on it.

• Teams should be able to deliver a complete product. If you organize teams by functional components, you'll have more expertise on this specific component, but you may end up with a great team in UI delivering a lot of changes that cannot be activated because the backend team is not as experienced.

• Understand your current knowledge background. If you have a single person doing UI and this is key for all deliveries, having different teams depending on this single person will eventually create a bottleneck.

The knowledge background is one of the most complex changes for fully functional agile teams. If your team relies on specific people's knowledge, before changing the team structure I'd suggest to:

1. review the current knowledge background the team members have
2. where are the gaps or potential bottlenecks if someone gets sick and then
3. discuss with the team who'd like to expand their knowledge background on these areas

Remember, one doesn't need to be expert on all and every area (I still consider a "full stack developer" a fallacy in most cases). Instead, one should have a T-shaped skillset enable every subteam to be able to delivery with minimal dependency of other teams.

Answer 2

This is a tough question to answer because it depends on your company. The general guideline is to optimize the team toward value creation. Usually, a question like this is posed as: should we organize teams around system components and functional areas. The answer in that question is easier because with system components, no one team can deliver a valuable feature to users on their own. However, in your case, it sounds like both potentially can deliver a full valuable feature on their own, so the question may be, which can better or more often deliver a valuable feature on their own?

One other model to consider with such a small number of developers is completely interchangable teams. If all teams can do all work, then you'll always get to your most important features fastest.

Answer 3

It seems to me that doing it around software components is wiser because It looks like the teams will be able to control decisions better since they will receive the input from multiple clients into a single feature.

If you do the other way around: having multiple teams working on the same component with different client inputs, it seems like there might be a chance of stepping on each other's toes.

You need to take into account the following:

• How are you measuring success? What do you think that it will happen after the change?
• Could you do gradual "pilots" and see if they actually have a benefit? (example: start moving a team working on a single software component and see if it improves performance in any way)