Aug 25, 2019
Thoughts on software teams cooperation and alignment
Let’s face it, moving multiple software development teams as a one unit within the same organization: is hard!
In this article we reflect about technical cooperation and alignment between different software development teams.
Fact is, independent teams in agile software development work isolated and at their own cadence, expertise and technical capabilities. Dream is to have multiple teams aligned and working as an organism, but teams will always tend to work as isolated units.
To my experience, some of the issues that can affect cooperation between different software teams are:
- Teams pick different development methodologies, X-Agile, SCRUM, “NONE” deriving on unaligned sprint cadences (even lack of those), different productivity levels, etc...
- Lack of global overview or technical miss-understanding of other teams roadmap usually ends on a puzzle with missing cards.
- Very common, teams will be very busy on their own specific roadmap and deliverables.
- Poor clarity in regard of cross-teams business and technical domains.
- Teams will inevitably choose different software architectures, programming languages, frameworks, communication protocols…. But, how will solutions integrate at the end?
There are multiple reasons for this, mainly because the technical spectrum is too broad. Also, teams prefer to have the freedom of working with the technologies their team members feel more comfortable with.
How can we make cooperation easier?
Although there are no ABC rules to resolve the issues mentioned above. We want to highlight a couple of routines and premises that will improve team’s communication and cooperation.
- Make clear, all teams feel equally important for the organization. As we all contribute to the same mission.
- Technical leads should be aware and well educated in other team’s technical milestones.
- Software stacks will be inevitable different per team, but we need to make usability and integration as friendly as we can. Internal usage of sophisticated architectures and communication protocols should not affect how simple and universals the public communication interfaces have to be. This becomes even more critical on solutions with several dependents.
Before assuming anything, ensure all technical leads are involved and agreed in those technical decisions. - Teams should have a clear separation between domain responsibilities, so there are no surprises while they are in the middle of a custom feature implementation. In general, cross-team dependencies should have been assessed in the early stages.
- Always involve the “product” board on decisions that can affect other teams roadmap and milestones. “That guy” will give you an impartial point of view where the business goals tend to be prioritized. IMHO, goals are most certain way to go.
And the most important advice would be again:
Talk and agree before acting. Surprises are never pleasant, especially when the labor of others is involved.
Are there technical “silver bullets” when it comes to simpler solutions integrations?
As I have mentioned before, each team development ecosystem will be different and there is no way to force it otherwise.
What makes a communication protocol better than others? Is REST better than Event Sourcing? Or RabbitMQ better than Kafka?
The solution is never black and white, the most successful communication interface will be the one the most team members are familiar with. Respect that rule, it is like democracy ;)
When testing and pushing modern software development practices, make sure all dependents are onboard and agreed on the efforts and support that is required to make it successful.
So with no order, I want to list technologies and practices that are proven to be successful when used in large enterprise solutions:
- HTTP and REST remain as the most adopted communication way of doing remote procedure call.
Although gRPC is emerging as a very exciting trend. - Use effortless and cross-platform serialization formats like JSON, Avro, Protobuf,…
- Event based communication is proven to be great for synchronizing states across different solutions:
Kafka, RabbitMQ, AWS SNS/SQS, etc.. are your new best friends! - The “mysteries“ of a super sophisticated solution architecture should not be exposed to dependents, use an API Gateway so you can be friendly with third-party consumers.
- GraphQL is the toy frontend/consumer teams love the most.
- And finally but not less important, documentation is gold.
The more documented is your solution, the simplest it will be for others to use it. Here we can mention Swagger/OpenAPI as a successful tool for REST based APIs, but there can be others for event-based protocols.
What else did we missed?
