6

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?

Improve this question
4
  • A few questions; are you making use of microservices? Ideally you want to reduce the idea of duplicate work and dependencies.
    – Venture2099
    Jan 22, 2019 at 10:31
  • We do not use microservices, but our dependencies are pretty much under control (i.e., no package cycles and packages of decent size throughout the codebase; trying to have defined interfaces; healthy level of re-use). We use a single-repo with trunk-based development and homogenous development practices.
    – Tobias B.
    Jan 22, 2019 at 20:49
  • I think all the answers so far contain valuable input. We discussed the topic further, and it seems like we are going to try a mix: Each team is the primary contact for a set of customers and does as many stories as possible for these customers autonomously. The groups of customers also relate to certain feature groups, so that the team has specialists for these feature areas. If there is a more complex story for which the customer team is lacking the knowledge background, it delegates this story to the team with the respective specialists.
    – Tobias B.
    Jan 26, 2019 at 8:44
  • Also see this article about moving away from projects: martinfowler.com/articles/products-over-projects.html
    – ottodidakt
    Jan 29, 2019 at 4:21

3 Answers 3

Reset to default
3

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.

Improve this answer
1
  • 1
    Thanks for the reply. I agree that distribution of knowledge is probably one of the key questions we need to solve. And perhaps we should just try it out.
    – Tobias B.
    Jan 22, 2019 at 20:55
1

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.

Improve this answer
1
  • Thanks for the reply. I like the idea of thinking about which option leads to more valuable features. We discussed interchangable teams, but so far we dismissed the ideas because we want the teams to be more focused (assuming this will lead to more effectiveness).
    – Tobias B.
    Jan 22, 2019 at 20:51
1

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)
Improve this answer
1
  • Hi Roberto - our application was structured exactly like that, two years ago. We had part of the team delivering a lot of must + nice to have features that never went live because other component was barely delivering must have features. Been there, never back again.
    – Tiago Cardoso ♦
    Jan 23, 2019 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.