Having done multiple projects with dependencies on a system provided by the client or third party, we have gained some valuable insights on how to collaborate in the most efficient way possible, while keeping a healthy relationship between all parties.
A single place of truth
What we mean by a single place of truth is a document that describes the service that everybody has access to and is always up to date. It should be easy to interpret, while not leaving out any important information. Nothing is worse then knowing a piece of documentation exists, but not finding it.
This single source of truth should at least describe the following topics so all teams can stay aligned: The current state of the API, and the state of the API after the changes. The tool we like to use for this is called Swagger; it allows us to create a visual representation of an API.
For less technical people, it gives you a quick overview of what does and doesn't exists (yet). Developers can dive into the details of each endpoint and analyse what parameters to provide to receive the expected data from the back end. Thanks to this hub, there is much less back and forth between teams, giving us a net gain in overall productivity.
Weekly refinements
When working on a project, we like to organize weekly refinement meetings. These are meetings where the engineers from both teams can put their heads together and decide on how certain things will or should work on a higher level.
When somebody finds an issue or has a question that's not bottlenecking anyone during the week, they can add this to the to-do list that's to be addressed during these meetings. This together with what's next on the planning is usually the agenda of this meeting.
Pretty often these meetings are pretty short and more lightweight than you would expect. But keeping in touch with each other and thus preventing smaller issues from accumulating, helps both teams. Also tackling items a couple days before somebody has to implement it, can reveal issues before somebody inevitably gets stuck on it.
Mocking data
A mock API is a type of back end endpoint that mimics the real endpoint. I returns data that looks identical to what the real endpoint will return. The only difference is that this mock API always returns the same response and don't do any calculations. This makes them really easy and fast to set up.
This might look pretty useless at first but it has some advantages for both teams, as every team can work at a pace they're comfortable with.
Without this mock API, the back end team is under constant pressure of having to hit every deadline. If they were to miss one, it would negatively impact multiple teams. If there is a mock API in place however, this impact is not as detrimental and they still have the opportunity to gain back the time lost in the weeks to come.
For the front end team, having a mock API available means that there are less blocking dependencies to manage. This team can create a planning that's independent from the planning of the back end team.
Overall, a mock API improves productivity, flexibility and the peace of mind for everyone involved.
Shared demos
Front and back end teams might have different tasks and areas of focus during a sprint, but at the end of the day, everybody involved in the project should strive towards the same goal.
That's why, at the end of every sprint, we like to organize a demo session. Every team that's been working on the project shares their progress with the other teams and stakeholders.
Even though the goals themselves had been clearly defined at the start of the project, having these sessions with everyone involved really enforces this sentiment of working together towards the same goal.
Fast communication channels
Email has proven not to be the most efficient channel of communication. When we're working closely together with a client or third party, we like to set up a Teams or Slack channel.
The barrier to ask questions and reach out for help should be as low as possible and we feel that this threshold is pretty high with regular emails.
When something is not clear, it should be possible to have a quick ad hoc call to help each other out. Having to organize and plan a real meeting is often overkill. A quick call that lasts a couple of minutes often resolves issues that could otherwise cause serious headaches down the road.