June 13, 2017


When commissioning software, such as a new customer website or a mobile application, the trend in recent years has been to decouple the front end client from back end services, thanks in part to the advances in API integration and cloud services.


This change has enabled companies to empower technology specialists to help in areas of expertise where they may have weak or limited domain knowledge (for more on this, take a look over our getting started blog). This could be analytics, Single Page app development, or in the case of Chelsea Apps, experience of delivering mobile applications with strengths in usability and design. But simply deciding on a technology stack is just one part of the puzzle. Actually developing it is another.


Complex development projects can pose many problems, but for enterprise development the complexity of multi-team environments working in harmony can be the difference between success and failure. So it’s easy to see why large organisations are investing time and money in frameworks such as SAFE and DAD.


Many internal development projects are governed and controlled by a PMO or Programme board, but how do you ensure effective coordination between companies in a supplier/customer relationship and more importantly, what measures can you put in place to set this up for success?


While it would take more than a few paragraphs to explain how to do this, here are a few tips that have helped us.


Whatever tools the two development teams use – whether it be Jira or VSTS – one must be a master and the other a slave. There can only be one source of the truth, and while a story may be broken down into smaller ones for feature development, the sum total, once developed, must match the original PBI.


Each team’s Product Owner must have access to the other’s backlog – so that they can monitor and make sure that the stories being delivered are identical. The teams don’t have to develop each backlog item at the same time but to protect against technical debt the features need to be linked together in some form.


This is a collaborative process and can only be achieved if the product owners meet regularly to review and prioritise the items. Joining team grooming sessions on epics or parent stories is a great way to get the teams working in a collaborative manner.


It’s not uncommon for parent stories to be broken down into smaller ones for a feature. If this does happen at the team level, the Product Owner needs to have confidence that – as long as the rules have been adhered to – once the stories are developed to make the feature, it will match the acceptance criteria of the parent.


Creating an API blueprint/contract at the start of the project which both teams agree to adhere to is really important, as it could be the difference between a project delivered on time or a project that over runs. It’s as simple as that.


Technical debt is the biggest killer of any project. If changes need to be made because the front end client and the back end service don’t match, it will affect everything from the source code and BDD scenarios to future stories that are directly linked.


While stubs and mock back ends are useful to get a product/app up and running they should always be defined based on how the actual API will work. That way, if the API is not available at the time of development, the team can begin the work, confident that they will not have to go back and correct it at a later date.


Risks can take many forms in a project. Identifying and tackling them first is always advisable. But what may seem risky for one team may not hold the same concerns for another.


In a consumer facing app where customer data is stored, the authentication and security could be seen as the highest risk and implementing the correct solution will have a direct impact on the tech stack and the IA.


However a UI Pin-entry screen on the front end may not hold the same complexity as the work required by the back end service to process the call. So who decides what gets developed first?


Having both teams complete a technical complexity review on each feature and assigning their own story point estimation will help, as both teams will have a clear understanding of the challenges the other faces.


This can then feed into the initial backlog grooming and should inform the decision of what features are developed first, minimising any technical debt. Changing code at the end is only going to delay your project but can also highlight issues that you may not have accounted for at the beginning.


As strange as it sounds, uncertainty and change should be something that is embraced.


With multi-teams you will get conflict and change as the project begins to become a living, breathing entity and it would be unrealistic to believe this will not happen. But if you are working with an Agile mindset then open your hearts and minds.


That doesn’t mean you should do everything with a “just in time” mentality.


Get ahead of the curve with stories, designs and backlog grooming, so when that curve ball is dropped that a feature is more complicated than first thought, or the back end team are not ready, you can remove or change it at the drop of a hat.


Also try not to be negative about the other team. Sure, their decision to make a change has had a direct impact on yours but the tables will be turned and if you are not flexible enough to bend you will ultimately snap.


Time is of the essence, especially when a project has to be delivered to a deadline. But if the team is going too fast, quality will surely start to suffer. If this is the case it may be best to reduce what the team take into a sprint to improve the quality that comes out at the end.


Bugs are as much about writing code as the language it is written in, but be careful your bug count doesn’t go too high. There is no point rushing to the end if you then have to spend two more sprints stabilising. If you have two teams working on separate parts of a feature the last thing you want to do is hold up the other while you fix the bugs on your code.


Quality is king and it’s better to enforce it at the beginning of the project than trying to rectify it at the end.


During the inception phase of a project the only communication that takes place is between the product owners or the technical architects. But what happens when the teams start the work and they have problems or require further information?


You could ask the product owner or project manager to request the information from the other team – or you can get everyone talking.


Set up a team chat channel such as Slack or Skype and don’t be afraid to let the teams talk. Communication is the key to success in any project and the more conversation flows the greater the multi-team collaboration will be.


At review time, try and demo your new features as one team. If the front end team have developed a new feature such as a pin entry, it is always helpful to have the back end team there to explain how that call will be handled. This way, your stakeholders feel confident that the project is in safe hands.


While no two projects are the same, by following a few simple rules you can make the difference between a project succeeding and a project failing.


It sounds like a cliche but there is no “I” in team. This is never more so than when working in multi-team development. Embrace your brothers in arms and if you work with them, not against them, you can never go wrong.