0

We are a team of around 60 software engineers divided into almost 6 teams. We are working on an ecommerce project and following microservice architecture. Each team is responsible for their own service.

As team size is growing and we are moving towards bigger and complex features, inter team dependencies and communication are also growing. Let's say one team is looking into the seller app and the other team is responsible for the buyer app. Now these 2 teams always have to work closely because whatever seller will list will be visible on the buyer app. Now the problem is, both teams are tightly coupled with each other. If one team misses the deadline, the second team suffers as well. Also if we under communication, it also impacts our deadlines.

We have explored spotify squad/tribe based team structure. Which makes sense to us. I just want to ask if this is a good solution or if there is something else which we can do to minimise inter team dependencies to smooth the delivery pipeline and to make loosely coupled teams.

1 Answer 1

2

The teams are coupled together because the applications/microservices that they are working on are coupled together. There are several techniques you can use to decouple the services such as:

Version the public API's

In this case I am using "public" to mean the API that is exposed to other services/teams (rather than the internet as a whole). If you establish a principle that multiple versions of your services are available it will mean that one team can release a new version without having to sync up with other teams.

You will need to establish a process for shutting down old versions, specifically you need to put pressure on "slower" teams to upgrade their code so that "faster" teams are not stuck with maintaining a large number of versions of their services.

Communication between Services is a Contract

Making a breaking change to one service may result in another service having to be updated to handle that change. As such there should be communication between the authors and users of a given service whenever changes are made - theoretically you only need to communicate breaking changes, but its good practice to discuss all changes to the API.

This will allow other teams to incorporate the change into their schedule. Additionally it should be possible to mock out all public API's so clients can be tested concurrently with the service implementation changes - the clients don't have to wait for the implementation to be complete before they can start their work.

Feature Flagging / Canary Traffic

Having the ability to turn on/off features and/or switch the version of a remote service - particularly if you can do it for a specific set of users or specific tests allows you to build confidence in a new release of a service before it is activated for the majority of your traffic.

Summary

If a feature requires changes to 3 services to implement it you will still be tied to all the services being ready before you can launch the feature - but by breaking the dependencies between teams you should be able to allow the faster teams to move on / ship other features instead of being tied to the release cycle of the slower teams.

Supporting multiple versions of a the same service can be tedious and can slow the teams velocity - you will have to figure out if the trade off is worth it for your teams.

Finally if you find that the same teams are always depending upon each other it may be worth taking a look at your code perhaps the code bases can be merged and/or split in a different way, such that one team is responsible for similar areas - even if they are split across multiple deployment units.

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.