I am struggling to reconcile some good recommendations, relating to the microservice architecture and Agile and DevOps, that are mutually exclusive in my mind.
On one side we have the recommendation that each microservice should have a small, two-pizza team that owns it (e.g. see "Service per team"). This is the model that the company I work for has adopted. There are several benefits to this approach:
Cognitive load is kept low. (A huge "pro".)
Teams take pride in maintaining the quality of the services they own.
Teams are able to enforce that new code complies with their coding standards and design principles.
Teams know they are unambiguously responsible for the performance of their services in production.
These benefits are evident when you compare the state of our microservices to the sorry state of our monolith, which is owned collectively and therefore by no one. However, there are also a number of challenges and I do not see how to reconcile them within this framework. Namely:
Complex coordination for any medium-to-large projects. Simple stories can be implemented by one team on their own, but any more complex undertaking ends up spanning multiple services owned by different teams. Teams end up waiting on other teams to finish their bit.
High WIP. Work must be allocated in order to keep every team busy at any time. Once a team did their part for a larger project, they look for other things to do. They are effectively banned from helping other teams finish the rest of the project, so they take on a new one.
Narrow value streams. In the idealised implementation of this "service per team" pattern, teams are decoupled and do not require input from other teams for any of their work. Even if this could be realistically executed, you'd end up having as many projects in flight as many teams you have. The WIP across the organisation remains high. Each team is a value stream, and no value stream may be served more than one 9-or-so engineers.
Suboptimal prioritisation. Team availability becomes a key factor for prioritising incoming projects. As a result, projects bringing relatively little benefit to the organisation may be prioritised ahead of projects with a greater potential return.
It does not scale. Not easily: in order to add a team, you may need to first re-architect an existing service and break it up in two. Even if a team already owns multiple services, and so ownership of some may simply be reassigned to the newly formed team, you still end up increasing handoffs and all the complexity listed in previous points.
Q: Is exclusive ownership of microservices by specific teams a goal worth pursuing at all, in your opinion? How do other organisations manage it? Would that be better for services to be owned collectively by all teams within the same value stream? How do you limit cognitive load experienced by engineers without overly restricting the organisation's ability to assign resources to highest priority projects?
P.S. I realise that above I assumed that the owners of a service would be the only team doing work on it. This may not necessarily be the case: ownership is also intact if other teams submit pull requests for the owners' review. However, review, and potentially testing, is still work that needs to be carried out by the owners. On the other side, teams tend to be reluctant to take on work related to services they have little experience working with.