How to keep high standards of communication in remote cooperation with a software house?

When you start cooperating with a remote team, you may feel many nibbling doubts. Will they understand my motives? Will they be frank? How swift will our communication be? But it’s natural that you’re asking yourself these questions, especially if you haven’t worked with an outsourced team before.

At Merixstudio, we’re lucky to have worked as a remote development team for more than 20 years. Throughout that time, we’ve successfully delivered projects with nine-hour time differences, held online kickoffs, and remote feedback sessions. A lot of these milestones took place without us even meeting the client in person.

So what makes our communication successful? After reading this article, you’ll know what to look for in an outsourced team in terms of team composition, project management, and tools that help foster open and efficient communication.

The right setup

There’s no way we could underestimate the value of preparation. For us, the project communication begins long before we write the first line of code. When dealing with a new project, we want to be sure of a couple of things that make communication a lot easier when the project starts:

1. On the client’s side, the person responsible for the project is also empowered to make decisions. This ensures that our communication lines are short and sweet.
2. On the team’s side, there’s one point of communication. In most cases, it’s an experienced project manager whose role is also to address risks and remove obstacles on the way to project completion. Needless to say, their command of English is at least upper-intermediate. Not that difficult to achieve in a country with one of the highest language scores in the world.

Source: English Proficiency Index Report 2019

3. Rules and responsibilities are clear for each person involved in the project. It’s crucial to agree on the definition of done, meaning the objective conditions that both a single feature and the entire system need to meet so we could accept them as delivered.
4. Tools we use befit both the client and our team. From the practical point of view, it doesn’t make that much of a difference whether we use Google Hangouts, Zoom, or any other tool. What matters is that the software is reliable and secure.
5. Flexible working hours so that even with a big timezone difference in question, we can still achieve a reasonable time lapse within which direct communication is possible.

That’s for a start but hang on, there’s more coming.

Process makes perfect

Communication is not a single event but rather a series of events or even a continuous process. So is software development. We rarely start with the full knowledge about the business domain, not because we didn’t take enough time to learn about it but because software solutions are often pioneering projects. That’s why we are dealing with a fair dose of uncertainty.

That’s where agile comes to the rescue. Agile approach fosters transparency and information sharing. This way, if executed wholeheartedly, it creates an atmosphere of mutual trust and teamwork between the client and the development team.

Scrum gives a ready-to-use approach to the software development process. If you haven’t worked with Scrum before, you might think there is too much overhead and too many meetings. However, most of them are regular and short updates that are ought to keep everyone up to date. Let’s take a look at Scrum events that build a communication frame for our software projects.

Status meeting

A short daily gathering, important especially for the development team. The goal is to catch up as well as to inform the team members of what is planned for the day and of any obstacles or potential risks that might delay the delivery. The time of the daily meeting should be convenient for the development team and allow all team members to actively participate in the meeting.  

Planning

Scrum is organized in cycles called sprints. Each cycle starts with a planning session during which we set and prioritise the tasks for the sprint as well as discuss how to approach the challenges. Planning is also the right time to align our work with the product vision, to discuss different approaches to solving problems, and to make project decisions.

In order to avoid blockers at planning sessions, we often hold the so-called backlog refinement meetings in the middle of a cycle. It’s an additional time that allows us to go into details of more complex tasks and estimate them. Thanks to backlog refinements, planning sessions flow quicker as we’re able to focus on what to include in the sprint and how to approach challenges ahead of us.

Review

It’s a demo meeting at the end of each sprint when the development team showcases what they’ve accomplished so far. You can think of it as a big update and the opportunity to compare the result with the expectations. Now that we’re working 100% remotely, the entire development team meets with the client on a meeting platform. Then, we use screen sharing to go through the application and present the recent increment.

A review is an extremely important time for our team. Not only can we collect client’s feedback, but we see how they react to our work and we discuss high-level plans for further sprints.

Retrospective

Probably the most feedback-driven component of the Scrum process. Retro sessions allow the team to improve their processes and communication – and, as a result, deliver future iterations in an even more organized manner.

Communication products that make things work

As the project communication keeps flowing, there are certain types of documents you should expect to come across. A transparent team does a lot more than just chit-chatting while your project is ongoing.

Meeting notes

Good old meeting notes, they hold all contributions, promises, and action points. Sounds a bit corporate? Maybe. But if you imagine a project that lasts for a couple of months, requires making a lot of decisions and one or two pivots, is there any other way to remember everything? A meeting note is a record and a reference point for any future actions and planned improvements. Thus, you should expect to receive it after each planning session, demo meeting, and retro.

Product backlog

One of the most obvious traces of managing a software project is the project backlog, meaning a list of features and tasks that, one by one, add up to the complete product. The backlog contains the features we plan to deliver in the nearest iteration as well as those whose priorities will be set.  

Burn-down charts

The burn-down chart gives us information on whether the velocity of our development is higher or lower than expected. It shows whether the team estimates tasks with acceptable accuracy or constantly under- or overrates them. As a part of a bigger picture, the chart helps the team anticipate potential difficulties in delivering the project on time.

Risk assessments

The steady flow of information would probably include some risk assessments. No need to run from it. In fact, the bigger the project and the more innovative the solution, the bigger the room for improvement.

Risk assessment is like a health checkup. When you do it regularly,  you’re able to predict risks and their consequences. What’s more, you can take precautions to prevent yourself from getting sick or to stop the progression of a disease. The same refers to software development. A responsible software development team would keep your project healthy by making the risk assessment an inseparable part of regular project reports.

Software tools that foster regular communication

A well-organized work process allows teams to focus on delivering value, instead of running in circles. When you have your development team in the same office, meetings are not as easy as it might seem – in many cases, you’re lucky if you manage to book the conference room. Ironically, when your team is in another city or even on the other side of the ocean, meeting with them can be a lot easier.

At Merixstudio, for example, we use a proven set of communication tools such as chats (our beloved Slack) for making quick arrangements, online meetings (Zoom, Hangouts or Skype) for holding video calls, and project management software (Jira) for progress tracking, time tracking, backlog management and, of course generating reports. Of course, the sole fact of installing all these programs doesn’t automatically make us great communicators. But our standards do.

Now let us unveil the mystery about some unwritten rules we follow when using popular communication tools.

Chat

By using Slack or other communicators, we create a dedicated space for project discussion. Every project has its own Slack channel that’s accessible only by project members. We’re able to discuss current matters, ask questions that have not been asked in the planning session, or simply schedule additional meetings and exchange links.

Online meetings

There’s not much of a difference between a meeting face-to-face and online. With today’s technology, we’re able to meet any time yet give one another a virtual handshake. We like to use Google Hangouts for online meetings (single or recurrent), but there are numerous tools that work just as well. Zoom, Microsoft Teams, or Skype are just a few recognizable examples of conference video software meant for online collaboration.

Project management tool

Hard to imagine a software project without proper management software. Tools such as Jira, Pivotal Tracker, or Asana help teams plan, track, and release software on a regular basis. On top of that, they’re equipped with a rich set of predefined reports that help assess risk, control costs, and optimize team performance.

Reality check: what clients think about communication with us

It all looks very well on paper but the ultimate proof of the software houses keeping high standards of communication can be found only in their clients’ testimonials. That being said, here’s how our communication practices are perceived by those who cooperated with us recently:

Daily communication was done through Slack with video calls on Microsoft Teams. We did not face any issues with the time difference or notice any language barriers. - CPO, Burrow

Their (Merixstudio) team uses a range of different systems such as Slack, which we use for ongoing and daily communications. (...) We had sprint review calls every two weeks, so communication was good. - Founder & Managing Director, AUTIUM

We used various tools. We communicated through Slack and held sprint reviews every two weeks. We maintained daily communication with everyone on the team. - CEO, Unibo

Sounds too good to be true? Well, these are only three out of sixty positive reviews on Clutch which prove that putting all the above-mentioned communication rules to practice results in customer satisfaction.

Final thoughts on taking the time to set up client communication

Working with a new team, especially a remote one, can be a challenge. A lot depends on the ability to build trust through frequent and transparent communication. Luckily, with just a handful of solid applications, communicating across the globe, managing time differences, and setting up meetings between a team of ten or twelve people can be a piece of cake (or at least a fluffy bun).

Looking for a trusted partner who understands the gravity of communication in remote cooperation? See why you should consider Merixstudio.

‍