Cost reduction, access to diverse talent, improved quality and productivity, flexibility, and opportunities to avoid stringent regulations are typical reasons driving businesses to offshore and onshore outsourcing. Many software companies also follow the trend, although managing a remote software development team comes with certain communication difficulties.
The context of building and maintaining SaaS systems, where software engineers may not always have a direct grasp on the consumers’ issues and requests, amplifies the complexity of offshore team communication.
Simultaneously, many organizations shift away from the approach centered around a static hierarchy of elements and processes to Agile methodologies. This progressive approach is focused on daily tasks, rapid continuous delivery, and instantaneous feedback. Stakeholders and Agile team members need to collaborate daily on improving the product. The pursuit of dynamism and constant acceleration of the processes also bring about communication challenges.
How do offshore teams communicate with product managers, CTOs, and other stakeholders located in different time zones? How to make cooperation with remote developers successful? This article will offer answers, as well as some tips on such communication as part of an Agile approach.
Face-to-face conversations are essential to Agile communication, but this precept seems to be immediately violated by remote teams. Luckily, modern communication tools like Zoom are here to help, but the language and cultural differences still pose challenges to international team communication. The simplest examples of misunderstandings that can occur due to cultural differences are different word orders or using the DD/MM/YYYY date format instead of MM/DD/YYYY. Some people may not be ready to ask again or argue their point; they may be politely saying ‘yes’ to everything, but it doesn’t necessarily mean they understand or agree with you.
For Agile methods to work best, each member of a self-organizing team needs to have a clear picture of what the team is doing. They should thoroughly understand the project goals, business context, product requirements and updates to them, existing issues, their colleagues’ responsibilities, etc. The dispersed teams also need to consistently synchronize their effort and avoid cases when several people are doing the same job independently. However, the more people an Agile project involves, the more difficult it becomes to coordinate, share information, and talk through issues with all of them. Every new communication channel adds to the complexity.
Agile generally downplays ‘following a plan,’ including full-fledged discovery and design phases. Agile teams that take this approach too far risk missing the project objectives. The lack of clearly defined deliverables, deadlines, metrics, and quickly accessible project specification or another single source of truth makes it difficult to organize the work and track the project team’s progress. Without a common product vision, geographically dispersed teams may end up working chaotically while the product manager, CTO, and project managers (PMs) are talking through things with each other and every team member.
An Agile project should be flexible and dynamic: throughout the implementation, changes may occur, and the requirements may be updated. However, if this happens too often and too fast, it becomes increasingly difficult for the international project team members to stay organized, focused, motivated, and on the same page.
These factors may pose significant challenges to the outsourced software development process, but many companies and agencies have learned to overcome them. Let us share some insights into Agile communication with and within offshore development teams.
The smoothest communication can be expected when you are working with offshore teams best positioned in terms of time zones, preferred language, and similar legislation, business rules, and work culture. This enables frequent in-person meetings, ensures mutual understanding, and minimizes risks. Unfortunately, this may not always be the case, and the following best practices become as relevant as ever.
Just like when you are hiring in-house personnel, you can review the CVs and interview in-person or online every offshore developer recommended for your project or dedicated team. This helps build trust and lets you evaluate their English and communication skills, among other things.
When working with offshore teams, try to treat their members as coworkers: try some occasional chitchat, learn more about them, respect them as professionals, and work every day to improve the relationships within the team, albeit virtual.
At the beginning of each project phase, Onix’s PMs have a virtual kick-off meeting with the whole team. The bigger your plans, the more important these kick-offs become.
The remote team members, wherever they are based, need to be on the same page with the in-house team regarding the product vision and roadmap. The people who define it need to be open, consistent, and concise in what they communicate to the entire project team. A perfect understanding of the product direction empowers remote developers to make the right daily decisions, minimize technical debt, maximize code maintainability, and anticipate future steps.
The product team should involve remote developers and other specialists at the initial stages of defining the project scope. For example, during a brainstorm, they can help create user stories based on their experience or suggest ideas on simpler solutions and more suitable technologies. This also promotes an early understanding of product goals, structure, complexity, and challenges.
To help prevent different stakeholders from giving contradicting information to the developers, set up relevant policies and responsibilities early on. They need to participate in kick-off meetings and be notified of essential changes. The meetings should be planned well to inform everyone on the work scope and how they will achieve the goals.
It’s equally important to share your business goals, challenges, risks, and other relevant project information. Brainstorming together builds a sense of partnership among your offshore team members. At Onix, trust is promoted with NDAs and agreements with each client that regulate confidentiality and intellectual property matters.
Product requirements should be defined as clearly as possible while avoiding assumptions. An established validation method will promote equal understanding among the team and stakeholders, preventing confusion. For example, at Onix, PMs conduct the requirements review and approval process. If needed, they act as interpreters between the client and their foreign team members both in the direct meaning and when it comes to the engineers’ lingo.
Make sure you have an accessible reliable source of truth for the product requirements that can be edited by all authorized team members. This promotes transparency and prevents many communication issues. It can be a prototype, project specification, list of approved user stories, an issue description, a confluence page, or even a whiteboard drawing, but the developers should have no doubt about a feature’s look and function.
Easily accessible technical documentation, issue logs, and similar sources facilitate the sharing of project knowledge. It’s useful to create and maintain a project glossary. The names of variables, classes, and APIs may be next to impossible to change later. For example, we start each confluence page with a glossary of important terms related to the new feature.
Another example is a style guide, a compilation of the product design principles and nuances. When the developers need to implement a new feature quickly, e.g., a dark mode, they can do it without a designer’s participation, using only the style guide. This saves the client time and money.
It’s also useful to provide your company’s internal processes and culture to the offshore team. By providing them with technical and soft skills training, you can dramatically improve communication on your outsourced Agile project. Leave space for learning curves so that the team members can get fully acquainted with the project, corporate culture, and technical requirements.
Try to encourage and support the culture of knowledge sharing in formal and informal ways. Regular Q&A sessions, live training, online courses, retrospective meetings, and similar activities will help share the team members’ working experience and insider learning. For example, at Onix, subject matter experts conduct weekly half-hour tech talks.
Both parties need to agree on the optimal format, communication channel, schedule, and rules from the very beginning. For example, video calls are the second-best way to meet your team, especially during the hard coronavirus times. Zoom and Google Meet will facilitate these virtual meetings. For prompt clarifications or updates, messengers like Slack or Skype may be useful. Sharing screenshots and visual presentations will facilitate understanding. Emails, the most organized and formal way of corporate communication, are suitable for communicating schedules, commitments, meeting notes, project reporting, and sharing project documentation.
Your communications plan should consider any time zone differences, days-offs, and national holidays on both sides. If your team members are located in different time zones, identify the time that falls into both parties’ workdays and working hours. If your remote team is really motivated, they would probably provide some flexibility regarding working hours and critical real-time communication. It’s also helpful to hire companies with representatives located in your time zone.
Still, a big difference between time zones may become an advantage. For example, the time difference between Ukraine and Onix’s American clients is 7-10 hours. A couple of hours are available for live chat or video calls with PMs every day. It is sufficient for updates, coordination, and discussions about work to be done while the client sleeps. Pushes to production and deployments that need to happen at night or during the weekend can be done by offshore team members during their normal working hours. Thus, software can be built and monitored in a harmonious, continuous cycle.
Communication is a two-way process. While you expect your offshore team members to share reports consistently, they will expect regular constructive feedback from you. All participants should do their best to adhere to the schedule of meetings, calls, reporting, and other communications. Their chat windows should be open as long as possible for quick clarifications and sync-ups. However, it’s not reasonable to expect all remote coworkers to be ready to respond to your requests 24/7.
The lack of direct communication between in-house and offshore development teams can sometimes be mistaken for indifference. By contrast, frequent cross-team communication, even via voice or video calls, builds understanding and helps align efforts. It’s wise to schedule regular structured meetings to enable everyone to express their ideas and concerns.
An Agile communication plan typically includes daily get-togethers and weekly meetings. A daily 15-minute online stand-up is feasible, even across different time zones, and helps everyone remain synced and maintain a stable information flow. For example, one of Onix’s practices is detail-oriented communication twice a day. In the morning, Scrum masters conduct a brief stand-up with the team over Skype or Zoom. In the evening, they update the clients on the day’s results and work planned for the next day by email or during video calls.
Real-life conversations are still the best form of communication. Try to visit your remote team when possible.
To minimize the communication gap while managing offshore teams, you need to empower your remote team members and help raise their morale. Instead of micromanaging them, rely on the self-organizing and self-managing abilities of modern Agile teams.
Offshore development teams usually have a wealth of diverse experience to share with all types of projects. Regular communication between the in-house and external team members will enrich both teams and facilitate creativity and exchange of ideas.
PMs should promote a feedback-oriented culture, encourage healthy and productive discussions, and create a respectful and non-threatening environment where all opinions are welcome and valued. International team members need to communicate in a way that enables them to share their points of view freely and help promote self-improvement.
While adhering to the overall business goals, the team needs to remain flexible, open-minded, honest, and respectful. It’s recommended to minimize using the word “you.” Instead, “us” and “we” will help reinforce the notion of collective development and ownership.
Conflicts that may arise between team members can be a problem for them and for the whole project team. To help prevent and address disputes, PMs should have a conflict management system in place. In case of a conflict, they need to examine the cause, make the team aware of it, talk it through, help work out a solution that everyone is comfortable with, and make the solution a standard going forward.
Modern project management tools, including collaboration, issue, bug tracking, and automated testing systems, facilitate Agile communication between clients and their offshore developers. Instruments like JIRA, specifically designed for Agile projects, Asana, or Trello, help manage and prioritize tasks, track progress, and generate reports and analytics.
A common Slack chat, Google Hangouts room, or a corporate Trello account helps nurture a collaborative spirit within a geographically dispersed project team. Shared calendars with deadlines, schedules, and team availability tracking facilitate communication as well.
Tools like GitHub allow for easy sharing of components between your domestic and offshore development teams, collaboration on changes, and consistent synchronization.
If your in-house and remote developers have different coding practices, miscommunication is more likely to occur. Clarify the preferred data structure, advise on code reviews and commenting practices, and other code-related aspects from the very beginning.
For example, we use the following procedure: the developer who wrote the code cannot merge it into the develop branch without another developer’s approval and until Jenkins puts together the builds and runs the tests. In each new build, we will also add a changelog.
We try to keep pull requests as small as possible and push often. It’s best to review smaller pieces of code sooner than later. If a reviewer leaves 50 comments in one go, it may be pretty difficult, tiresome, and discouraging to discuss changes and fix them.
For every programmer’s comment or every time they have a different opinion, it’s desirable to allow room for doubt and give their fellow team members a chance to express their point of view. Simply put, reviewers can formulate a comment either as a command or as a question. Using the latter style, they can ask for clarifications and offer a solution without dismissing alternative arguments.
Agility in software development helps to cope with the almost inevitable changing requirements. Still, even on Agile projects, good PMs try to keep every change as small and simple as possible. Together with developers, they break down a large feature into manageable chunks with a clearly defined scope and bring them as fast as possible into production. Unfinished changes can be hidden behind feature flags.
Product managers should help the developers understand what parts are not yet fully defined or may change. For example, in the documents, you could mark uncertain parts in red. Regular meetings also re-sync the team about what changes are needed and why. Developers need to know the answer to questions such as:
Agile teams are a balanced combination of juniors, team leads in different specialties, and skillful project management. It’s recommended to avoid adding new team members unless there is no other option. Even senior members will take some time to become self-sufficient, while the product manager and PM will need to meet them online and offline, define the role and duties, give permits, educate, introduce to team meetings, and so forth.
The perks of outsourced software development in terms of cost, scalability, and global talent can be realized only when you are managing remote operations effectively. Their success directly depends on how you build communication between the product and offshore development teams.
As a product manager or CTO, you are striving to deliver the best solutions to your customers. Optimized communication with your domestic and remote team members will ensure you are moving in the same coordinated direction. A healthy cooperative environment fosters high productivity and quality of the product.
At Onix, we are constantly working on perfecting our software development models and communication between the development and product teams. Our clients can order the building of a software product from the ground up, hire a dedicated team of professionals, or augment their Agile project team with a couple of remote developers. The finest seasoned software developers, designers, and project managers can be hired affordably and quickly, and we follow the best practices for managing offshore resources for our clients.