It’s okay to feel a little reluctant when you first begin a collaboration with a remote software development team. Managing a team located thousands of kilometers away can make you feel a little insecure, and that’s alright.
But you need to build your product on time, on budget and to top code quality standards and hiring an internal development team doesn’t always make financial sense.
This is where outsourced teams come in. Leaving aside that you’ll be working with someone in a different country and, most probably, time zone, there are ways to make you feel like they’re sitting at the end of the hallway. In this article, our main focus will be the do’s and don’t of working with a remote development team. We’ll share some insights as well as some of our own best practices to help you get started.
Communicate - choose communication channels wisely
Developing a great product requires a deep understanding of the needs, wants, and expectations of your client so it is important to choose communication channels wisely, especially when managing your team remotely.
Prior to moving on to the actual development of your product, selecting between the pool of communication tools available is vital. Skype, Slack, Zoom, Discord and email have proven to work beautifully for us even before the pandemic.
However, let’s not forget that every team should also have a product manager or product owner. The product owner has a lot on its plate. This role isn’t only responsible for conveying which activities will generate the most business value but it also bridges communication between the development team and the stakeholders.
Having a calendar in place for daily/weekly/monthly calls with the team goes hand in hand with your chosen communication channel because the development team has a myriad of recurring meetings:
- Daily stand-up meetings where they coordinate with each other to share status on tasks and lift any blockers they might encounter;
- Sprint planning where the tasks for a future sprint get prioritised;
- Backlog refinement meetings to make sure we have a common understanding of the stories and acceptance criteria, to make estimations and identify unclarities;
- Retrospectives - to understand what worked and what didn’t and give the team the chance to continuously improve their approach;
- Sprint review at the end of each sprint - it’s when the team showcases their progress to the client to get their feedback.
We mainly use Zoom for video conferencing for both internal meetings and the ones where the client joins. Nonverbal communication - both tone of voice and body language - are key components of good communication, so seeing the people you work with matters a lot when working with a remote team. It helps connect faces to the names of the people you talk to, it builds trust and it encourages active participation in the discussions.
Slack, on the other hand, is better suited for group communication, as well as one-on-one chatting. Product teams usually have a dedicated channel that includes both team members and members on the client’s side.
Our approach: we believe good communication goes beyond gathering skilled communicators and choosing a tool to facilitate a conversation. Logistics is just as critical. Although the pandemic forced us to make do with what equipment each had on hand, while we’re in our office, it’s equally important for us to have a high-end audio-video system in place for everyone to be heard and seen.
The success of working with a remote development team is directly proportional to how dedicated all the parties involved are to communicating regularly and building healthy rapport.
Pro tip: treat your outsourced team like a partner and they will become one.
Build a relationship based on trust
Contrary to popular belief, long-distance relationships do exist in the software development realm. To make it work, people must commit to nurturing that relationship; a relationship will only work if it is based on trust.
Following your decision to work with an external development team to build your next million-dollar product, the next step should be to settle on a strategy that’s beneficial for all parties involved. For example, start with scheduling daily calls in the incipient phase of product development to get to know the people working with you. As the team gets a good understanding of your needs and wants, it’s common practice to switch to weekly calls. This will enable the team to focus on what needs to be done and spend less time in meetings.
Trust has to be earned and, although there’s no way of knowing you’ve made the right choice, it pays to give people the benefit of the doubt; especially if they have a good reputation of working remotely. Don’t hesitate to ask about past projects completed, deadlines, and challenges faced and overcome.
Our approach: one of our favourite ways of building trust is based on quarterly face-to-face visits to the client and vice-versa. It is an opportunity for us to get out of our comfort zones as well as a unique chance to demonstrate that we rock software development in person, too. Although they don’t happen as often during this pandemic, face-to-face meetings allow us to build a closer connection with the client; and by getting to know the client and all stakeholders in person, we can develop a better perspective of the product under development as well. Read more about our Canopy case study where we went the extra mile for a product we believe in.
Pro tip: dig deeper into your outsourced team's company culture. If the company culture allows for remote work, it means their own company trusts them. Why shouldn’t you?
Refine product backlog - leverage the power of sprint
Agile, productive teams are essential to client satisfaction, regardless of location. Working with a remote team of developers can be done successfully when quality is delivered on budget and on time. This is where sprints and product backlog refinement enter the scene. Both communication and collaboration lie at the heart of an offshore agile team. Regular meetings to clarify requirements, refine the backlog, and reevaluate estimates are essential because they allow team members to keep track of the work done and have a clear picture of what matters the most to the client.
Also known as product backlog “grooming”, the method is a basic Scrum process where team sprints are followed by reviews. The review sessions are critical, and you should definitely join in because it is an opportunity to watch your team present their progress and talk about the next steps. One very important aspect of the process is feedback. Your team will want to know if the work done so far lives up to your expectations. During sprint reviews you’ll have the chance to speak your mind.
Our approach: we believe in agile-driven software development done SMART: specific to the needs and requirements of the client, but also measurable, achievable, realistic, and timely. Careful planning and sprints of one or two weeks enable us to constantly review and assess what we’re building. Here’s how Scrum product “grooming” happens at Thinslices: the team, including the product owner, meets for a weekly/bi-weekly session of product backlog grooming, where we remove irrelevant stories, create new stories, reassess priorities, assign and correct estimates.
Pro tip: try not to confuse the power of sprints with micromanagement. It’s one thing to participate in spring reviews and provide feedback, but it’s a totally different thing to be present at all times and make your team feel uncomfortable with unrealistic demands.
Working with a remote team of developers - or any other remote team in any other industry - may not be for you if you feel more secure and confident if you’re the one managing people directly. In this scenario, hiring freelancers might work better. From the very beginning, an outsourced team already has a manager - also known as the product owner, PM or team lead.
As a client - and not an employer - you are more than welcome to work closely with the product owner to make sure your project is being developed according to the development roadmap. During sprint reviews, everyone gets involved to share the progress, receive feedback from your side on project demos, and plan for the future. However, micromanagement has no place in agile software development.
Don't treat experienced outsourced teams as merely executants
Believe it or not, your vision for a perfect product may not be realistic. That’s why agile matters so much. Experienced and committed development teams strive to add extra value with new features, relevant solutions and tweaks you never thought were possible in the first place. A good team might have surprising insights if they’re not seen as executants. As trusted consultants, you can put their collective experience to good use.
Stop believing in telepathy. It doesn’t work
Communication and collaboration are fundamental in any relationship. Great products can only be masterfully crafted when the client actually verbalises his or her ideas and concerns. Whatever you’re thinking, just say it. Not only does telepathy not work, but in the world of software development, it can have costly repercussions. If you don’t share expectations, thoughts, ideas, and demands your team won’t be able to develop accordingly. Therefore, having a detailed project plan in place is critical. Sticking to that plan, discussing progress on a regular basis, talking about challenges while fixing them along the way, matter just as much.
Working with a remote development team is totally doable but finding your dream team is easier said than done. We, at Thinslices, have a handbook that helps us paint a clearer picture of our company culture from a people-centric perspective. Working remotely has proven to work and we’ve tested and refined our methodology over and over again.
The true test came with the pandemic which forced us to leave our beautiful office and work from home. Still, for our clients not much has changed - except for the walls they see behind us during video calls.
On a final note, there are ways to test-run the collaboration with a remote software development team. A “dating before marriage” type-of approach. For us it’s pretty common practice to start with a smaller project - a product design phase or a small MVP. This way the clients get to know the team and see if a longer-term collaboration would make sense for their particular context.
[This article was initially published in Jan 2020 on Digital Knights’ blog.]
YOU MIGHT ALSO BE INTERESTED IN
Kicking off new projects
The ABC of starting a new software project, complete with best practices, how-tos, and other resources.