Multisite software development, the good, the bad and the ugly
The increasing globalisation of the software industry has meant that multi-site software development is now widely practiced. With offices across the globe, organisations are trying to be more cost efficient, reduce overhead and maintain fees and margins charged to clients.
Software engineering is a task difficult enough when done locally—but it is even more difficult when cross-functional stakeholders specify requirements across cultural, language and time zone boundaries.
Multisite software development comes with many challenges.
Remote communication, knowledge management, cultural diversity and time differences are all factors that negatively impact engineering practices. Aspects such as lack of a common understanding of requirements and engineering practices, together with a reduced awareness of a working local context, a trust level and an ability to share work artefacts significantly challenge the effective collaboration of remote engineers that satisfies geographically distributed customers.
One of the main recommendations to improve and speed up software development would be to collocate individual and self-managing teams. A self-managing team is considered one that can deliver a piece of work from concept to production. If you have 1 team that is dispersed across different locations, even in the same country, it is recommended to reorganise teams in a way that they can physically be in one office should this be required. That is the definition of collocation.
If you are faced with a challenge of having to build software across multiple geographical locations, ensure that you also avoid the following common mistakes.
Treating sites as not equals
This is a difficult thing to manage because lots of organisations have one location that presents itself as ‘leader’, and it can be tempting to bow to the whim and needs of that branch of the business at the expense of everyone else, but you should be very careful about letting this happen. Not only does it breed resentment between sites, but you can’t hope to build a comprehensive and fully functional multisite software solution if you aren’t taking all sites equally into consideration.
The key here is to treat all sites as self-managing units rather than having a ‘leaders’ and ‘doers’ mentality.
Organising sites by system components
This might feel like a sensible thing to do initially, but this can cause real issues in the future. When sites are broken down by system components it means that one site can be responsible for the frontend build of your tech solution and another team is responsible for the backend and middle layer. This significantly increases the dependencies between multiple sites, slows down communication and therefore speed of development. With challenges in communication between sites which are reduced with collocated teams, the end product is skewed from what the customer initially requested. Streamlining the development of work is particularly difficult when teams are spread geographically and split by system components.
Dispersing the team across multiple locations
Dispersing one team across several locations might happen organically and accidentally, but it is vitally important you avoid this from happening. Team cohesion is much more difficult to achieve when we consider streamlining of work, communication and culture diversity if teams are dispersed and are not collocated.
Sometimes, team dispersal cannot be helped, but it should be avoided, and we should aim at keeping self-managing teams all physically collated.
Splitting development of a feature across multiple sites
We can speed up development by creating cross functional teams. Cross functional teams will improve decision making process, collaboration, and efficacy in a team.
We would hope that you have cross functional teams across all sites. If not, do that first. Once cross functionality has been implemented, ensure that all teams can work on a single feature in one location.
Splitting the development of a feature across multiple sites can overcomplicate things and slow down progression. It’s a much better idea to consolidate development of customer focussed features to one site and ensure cross functionality has been fully integrated.
Treating CI/CD as separate for each site
Just as you shouldn’t organise your sites by system components, nor should you treat CI/CD as separate for each site you operate from. Your software development team should automate continuous integration and delivery all the way through the CI/CD pipeline. The same continuous pipeline is for the whole organisation and should not split by separate sites.
Digital Dom is an agile programme delivery and software development practice. Our team can help you to organise multisite development to achieve speed, creativity, flexibility and growth for your organisation across business and it.
For more information about our work, visit our services team. To speak to a member of our team, please contact us.
Subscribe To Our Newsletter
Join our subscribers to Weekly Newsletters. Every week, you'll get 1 actionable tip on agility, business transformations and software delivery for your organisation today.
You may also like
E-commerce is entering a new phase in Southeast Asia. Are logistics players prepared?
Changing consumer and merchant habits are creating opportunities for logistics companies—if they can cater to new needs and meet more exacting standards. While growth of Southeast Asia’s e-commerce market has accelerated since the mid-2010s, ...
A technology survival guide for resilience
Resilience means understanding the criticality of a business process, the capability of the underlying technology, the business impact if the technology fails, and the organization’s risk tolerance. It’s no secret that in highly competitive ...