1

So we work at a company following the microservices architecture where each microservice is developed by its own scrum team with its own Product Owner.

Every microservice is used by multiple different products and the microservices are considered products on their own.

We are looking at options to arrange the work between the different Scrum teams as there are complex team dependencies and we were looking at the standard scaled agile frameworks. One thing they all have in common is that they focus on multiple teams working for one product while we have multiple teams working for different products so we cannot apply them.

Is there any 'standard' or well know approach to handle a situation like ours which seems pretty normal based on today's companies organization?

Improve this question
6
  • Can you elaborate on “complex team dependencies”? As to understand your problems better.
    – Kris Van Bael
    Commented Jul 14, 2021 at 5:21
  • One example, to add a new feature to a product 9 teams need to collaborate adding functionalities to their microservices. These 9 teams need to coordinate between them to plan their work as there are multiple dependencies between them.
    – Ignacio Soler Garcia
    Commented Jul 15, 2021 at 6:51
  • Hmmm, if that is common, then your micro-service architecture might need a closer inspection than your organisation.
    – Kris Van Bael
    Commented Jul 16, 2021 at 5:29
  • Can you elaborate a bit more? What is what you consider needs to be improved?
    – Ignacio Soler Garcia
    Commented Jul 16, 2021 at 10:03
  • I would expect that your microservices would be loosely couples and to some extend organized per domain. So a typical new feature would need a few services updated at most.
    – Kris Van Bael
    Commented Jul 16, 2021 at 21:12

1 Answer 1

Reset to default
4

It's not surprising that you're struggling. Organizing teams around services is a form of having component teams.

Just because your organization considers each "microservice" to be a product doesn't mean that your customers see them that way. Your customers see the thing that they pay for and use as the product, and discuss changes (feature requests, bugs) in that context. However, in order to support those changes, you need to align multiple teams and dependencies.

Dependency management between teams is hard, which is why the preference tends to be on teams that are aligned with customer-facing products. For large and complex products, aligning the teams with streams may also be a viable solution, where each stream cuts across the entire product but serves a particular user base or high-level use case. The idea is to reduce the number of teams necessary to go from the initial request to deploying the necessary changes.

The common assumption in many of the scaled frameworks is that teams are feature teams because this greatly reduces the complexity. If you combine it with a robust automated test framework to capture the system behavior as an executable specification, you can reduce the complexity even more by ensuring that changes one team makes to a service don't negatively impact another team's changes. You may still have to deal with conflicts when integrating but at a much lower rate.

I believe the best suggestion would be to make fundamental changes to your organization. There may be some organizations who can manage with component teams, it's generally seen as less effective, especially when attempting to support agility.

Improve this answer
2
  • Well, as far as I know, the classical approach with microservices was to build them around a team that has the ownership of the service. And to give the microservice the full vertical slice of functionality so it can be fully independent, so with that approach, you would end up with an organization like ours. How would your approach fit with a microservices organization? Or is just that microservices organization is not a favoured trend anymore?
    – Ignacio Soler Garcia
    Commented Jul 13, 2021 at 6:41
  • 1
    @IgnacioSolerGarcia The approach I describe has nothing to do with the system architecture and applies equally to monoliths, microservices, and everything in between. For some organizations, a component-based approach may work well. I don't think that's the majority of organizations, though. Teams that own the whole system or an end-to-end slice (often organized by customer or user group) of the whole system, across components, have been found to be better at delivering faster and producing higher-quality work because they have reduced dependencies on other teams to deliver their changes.
    – Thomas Owens ♦
    Commented Jul 13, 2021 at 9:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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