How to work with a remote software development team?

Since you are here chances are you are in search of a remote software development team who could help you out with application development.

Since you will be working with a remote engineering team, you might run into some issues initially. However, the best part is that, once you overcome these issues, the remote unit can become a strategic asset.

BeautifulCode has more than six years of experience in working with clients from various industries/countries, and in this article, we summarize our learnings.

These recommendations are for relatively large projects that span over six months to several years.

Summary

• Work with a fully managed remote engineering team instead of several individuals. Select your team after doing a small project with multiple teams.
• Onboard by providing the business context.
• Do the necessary training and more importantly set the right expectations from day one.
• It is recommended to have a "product sprint" along with the "development sprint" especially given the distributed nature of teams.
• Do at least two meetings every week. One of them can be sprint planning/sprint retrospective. Use the other meeting to discuss open questions or launch plans.
• Plan for a couple of hours of overlap in work timings if the remote team works in a different time zone.
• Last but not least, meet the team in person. A personal touch can work wonders.

The long version

Please keep it simple. Work with a fully managed team.

The team structure and composition is one of the most crucial decisions that you'll take as the business stakeholders or the product manager.

You have two options to structure your remote engineering team.

Option 1 – Handpick your team members.

In this option, you typically research on freelancers and contractors and assemble your team. The following are some of the pros and cons of this approach.

Pros

• You can handpick talent from wherever you want. Theoretically, you get the best people for your job.

Cons

• The onus is on you to manage the team and set them up for success. Working across multiple time zones can be quite challenging.
• You'll spend a disproportionate amount of time and energy in finding the team members and building a cohesive unit.
• Managing several people is not easy. You will have to double as a project manager as well. You'll end up spending less time on what you should be doing – thinking about the product roadmap and product features.
• Risk: If you are working with 3-4 individuals from 3-4 countries, there is always a possibility that one of them would want to leave your project. Now all of a sudden you have lost your designer or the only frontend developer. You must hire someone ASAP so that the team continues to make progress.

Option 2 – Work with fully managed remote teams.

You can work with a fully managed remote team by contracting your projects to established companies that specialize in niche technical areas.

Large companies set up "captive centers," that are fully controlled subsidiaries that take advantage of low-cost locations.

Pros

• Managing technical talent is handled by the vendor, and you can focus on business and strategic initiatives. Typically there is one point of contact, often an engineering manager, who is responsible for the delivery of the user stories or planned milestones.
• The entire team of designers and developers is under one roof. The decision making/knowledge sharing is seamless, and you can target more aggressive project timelines.
• There is minimal risk of individuals leaving the team. Since the team is "fully managed," you need not worry about finding a replacement. The engineering manager will find a replacement and work with her.

Cons

• Selecting the right team: There are chances that the group as a whole might not meet your expectations. You should choose your remote engineering team carefully. Always start small (try out a less critical project) and try out a couple of different organizations. Once you have chosen the team, increase the scale of engagement over a period of 6 months to 1 year.

Given the above two options and their pros and cons, it is easy to see why you should work with a fully managed remote engineering team.

Onboard the team

After you have selected the team, onboarding the team sets up the expectations and acclimatizes the remote unit to your working style and culture. Onboarding would typically involve:

• Agreement and NDAs: Make sure that you have the right contract/NDAs in place before you start any major work. Once you have NDAs in place, you'll be comfortable in sharing the context of the problems that you are trying to solve. This context will help the team empathize with the user and design better solutions.
• Explain the context: Your remote team may or may not have built solutions for the problems you are trying to solve. Before they start building the application, explain the industry and the business. Explain what your company is trying to accomplish with the team. This context will help the remote team appreciate the product and the features they are trying to build.
• Set expectations: Talk about the best-case scenario of the engagement. Talk about delivery expectations. Be clear about who is responsible for what. Ex: Deliver the MVP (minimum viable product) in 8 weeks. Fix P1s within 24 hours.
• Training: Most likely, your remote will be good at agile practices. It will be familiar with standard tools like Trello, GitHub, google docs, and wireframing tools. However, you should invest some time to help the team understand the specific tools/processes that your company employs.

The delivery process

After onboarding the team, you should figure out a delivery process- a way to shipping user stories as features.

At BeautifulCode most of our successful projects have followed the below version of the Scrum with a 2-week sprint cycle.

The critical insight from our experience is that by making progress in product definition(via product sprints) and product implementation(via development sprints), the delivery process becomes hyper-productive.

Product sprints (aka backlog grooming) – Building a lot of new features and throwing them at users is not smart. Ensuring that the newly added features will deliver value to its users is the key.

In the product sprint, the product team evaluates which ones among the fifty different features add the most value to the users. The feature set is typically decided based on the expected impact on the unit economics of the business, feasibility of implementing a feature, RICE framework, etc.

Usually, the product owner, the designer, and the engineering lead are active in the product sprint cycles. The goal of these parallel sprint cycles is to ensure that the high priority product backlog items are well defined. That way, they are ready to be discussed in the sprint(development sprint) planning meetings. At BeautifulCode, we try to accomplish the following in the product sprint.

1. Get clarity on product backlog items. Ideally, there should be zero questions on the feature requirement in the development sprint planning meeting.
2. Prepare interactive prototypes (ex: Invision prototypes in case of a web or mobile application) and get sign-off post user research.
3. Identify dependencies (ex: an external data dependency) and notify external teams to reserve their bandwidth.
4. Do one-pager documentation on the proposed architecture for medium (ex: development of a new microservice) to large-sized user stories.
5. Build a healthy backlog of prioritized and detailed user stories that need to get delivered in the next two quarters.

Development sprints – This is "the sprint" in the traditional sense of Scrum. Thanks to product sprints, at the time of the sprint planning meeting, the team has clarity on the top backlog items. All dependencies such as high fidelity mock and data dependencies would have already been addressed/defined.

The goal of this sprint is to complete the development of the chosen user stories and be ready with a potentially shippable product. At BeautifulCode, we do the following in a typical development sprint.

1. Breakdown the user story into smaller subtasks and have them assigned to the developers during the sprint planning meeting.
2. Develop the user stories, which include implementation and test code.
3. Code review.
4. Demo the new features in a for product sign off.

Sprint Gotchas

Some things to keep in mind to get the maximum value out of your sprint process.

1. Sync twice a week: In the real world, developers will have questions in the development sprint. Sync 2 times a week for 30 minutes or so to go over the outstanding blockers. You can also use this time to do backlog grooming.
2. Manage time-zone difference: If you end up working with a team that is halfway around the world, there are a couple of things you could do to manage the time-zone difference.

1. Be responsive to emails/slack messages: Prioritize responding to messages from your remote team. This way the remote engineers do not get blocked and lose a day
2. Try to have at least two working hours overlap every day. Use this time to address any blockers or high priority questions quickly.

3. Proactive demos: A 2-week sprint does not mean that the team comes up with shippable features right at the end of 2 weeks. Taking a leaf from the Kanban approach, you can ask the development team to demo completed features. Do not wait till the end of the sprint for the "big demo" of all the features.
4. Retrospection: While Scrum is an excellent generic framework to execute complex projects, every team can benefit from tweaking it for their particular context. The processes we set up should be serving us and not the other way around.

Communication is the key.

One of the common fundamental reasons for project failures is the failure to communicate. Understand how communication is happening in your technical teams and plan for the right amount of interaction. Here are some of the processes and tools that focus on getting it right.

• Scrum standups – The daily standups within the remote team, helps quickly check on the status of the sprint and calls for attention on any problem areas.
• Interactive user validated screens/mocks – Interactive mocks help envision the future very quickly and get everyone on the same page quickly. One pitfall we have observed with some product managers is that they skip the step of user validation of the mocks. Communication is not just about transferring information between you and your team. Involve the end-user as well early on. You may start slow, but you will be walking in the right direction.
• Intra team communication tools – Tools such as Slack, Hipchat help teams broadcast updates in realtime for effective collaboration.
• Architecture documentation – The system architecture documentation helps the engineering team consider multiple options to solve the problem at hand and avoid rushed implementation. Iterating on the systems and UML diagrams helps build confidence between the architect, engineering lead, and the developers.

Understand and play to the strengths of a remote team setup.

Remote teams have their unique strengths, and playing to them will result in excellent collaboration experience.

• Autonomy – Enabling the remote team to be autonomous has multiple advantages.

• Get the communication aspect right and set a clear agenda for the team. Let the team focus on getting to the finish line in its way. You can disconnect from managing the team and focus on other priorities.
• The remote team feels that it is responsible and will proactively reach out to you for progress updates, demos, or escalating issues. Autonomy gives the remote team ample opportunities to lead, which in itself is challenging and satisfying in addition to the technical work they accomplish.
• By forcing to be autonomous, you will be evaluating a long term relationship with the remote team. Ideally, you want partners, not short-term contractors.

• A reduced non-productive activity like commuting – This has become a massive benefit for the modern workforce that values flexibility and work-life balance over everyday commutes and constant interruptions in a centralized workplace. We are seeing "digital nomads" who take this aspect to an extreme where they are always on the move and using their lifestyle to inspire themselves at being their best.
• Forced to get communication right – This point is worth repeating in the article. A weak communication setup will demotivate the remote team and lead to confusing outcomes. The onus is on both the parties to communicate very effectively during the syncing sessions and set the right expectations. Communication is a classic example of a constraint turning into a strength.

Don't forget the human touch!

Share both positive and negative feedback from the end-users – Your team is just not a black box that spits out feature implementations. They are also emotionally invested in the success of the project and take pride in the outputs.

 Negative feedback will help the team empathize more with the end-users and create better workflow and designs.

On the other hand, nothing motivates the team more than a customer who says, "I love the feature. Thank you!" Forward such emails to your remote team!

Meet the remote team in person – This is especially true if you are about to start a big project. Meet at least once a quarter. You fly out or have them fly in.

In-person meetings go a long way in building trust and motivating the team.

Once the trust level goes up between the parties, they will graduate from the "remote engineering team" to "co-creators."

When you co-create, the possibilities are endless.

---