Agile Communication in Distributed Teams (with no overlapping hours)

So as you know my speciality is distributed teams 🙂 This post is about what changes does the agile communication face (and scrum in particular), when it’s adjusted to the distributed teams. This is my experience, I don’t assume this is a silver bullet, but such approach works for me for the last 5 years and proved itself to be proficient.

Let’s divide communication by types:

  1. stragetic meetings (plannning, retrospective)
  2. daily huddles (e.g. daily standup in scrum)
  3. day-to-day clarifications.
2018-01-18 11.12.16
by Text I mean Instant Messaging

Let’s add another dimension: geographical distribution:

Collocated teams – everything’s perfectly fine for all three types of communication events. Teams, working in scrum, that are collocated face no issues with any of those.

Distributed teams with little difference in timezones, but still with overlapping hours. Great examples are US – Chile / Mexico. Netherlands / India.

  • Daily syncup can be handled with almost no pain, as well as planning and retrospective (if you incorporate scrum in your company).
  • Instantness of clarification on work tasks is lost (when overlapping hours end), however given that skype / hangouts / whatever you use is just a click away – no significant impediments are to be found.
  • No matter what you think about focused team, and that it processes everything faster due to unitedness, whenever team member is outside of her overlapping hours with the rest of the team – communication lag happens.


Distributed teams with no overlapping hours (8+ hours difference).

Approaches here are:

  • 3.1 Team liason. When someone from the team in one part of the world is having a meeting during his time off work, to sync up with other part of the team in different timezone. Usually, team liason is someone from product team, however there are different examples of who syncs up with dev team in the industry. It can be simply a representative from one part of the team that syncs up on the progress with the other part (just like in scrum of scrums)


  • 3.2 Timezone Compromise approach. Teams change their work schedule, to have a compromise in at least 1 overlapping hour, in order to sync properly. For example, start of working day for one part of the team in western hemisphere moved from 10am to 9am, and eastern hemisphere team changes their working day to start from 10am to 9am. Thus, you got at least 1-2 hours overlapping. Whoa, problem solved -> we can get back to bullet 2, on how teams with overlapping hours work together! But remember, everything depends on team configuration, whether the team is comfy with selected approach, and development tasks specifics.


  • 3.3 And finally, you can set up communication process in a way it’s comfortable for everyone in the distributed team. My personal beliefs is that redundant communication is always less efficient than on-demand-clear-bulleted-discussion, thus I’d prefer clear agenda and clarification when needed.

— 3.3.1 First of all, that means that people still are participating in retrospectives and planning sessions, cause those events happen once per 2-3 weeks (thus distraction or working off-time is tolerable). However, those meetings / scrum rituals are to be performed with clear goals, and well-prepared bullets. Try to not allow offtop conversations (when someone gets into topic not relevant to current discussion). Remember, team values personal time, and no team member should suffer from poorly planned meetings.

— 3.3.2 Second, it means that daily sync (or daily standup, if you follow scrum) can be done via text, at the end of team’s working day. In order to reach more visibility, developer can share a link to the branch, that he worked on. But main goal is to have an exceprt of what team member has done during the day, that is visible for everyone (e.g. special channel on updates in telegram). Some people also propose asynchronous video messages (Dave Snowden of cognitive edge shared this experience of his with me, referring to the times he worked at IBM) – you record video message for the team, and even share the screen, if you want some visual material on your work.

— 3.3.3 Third, clarificational communication (meaning day-to-day clarification communication type) is done on demand. Meeting for such batch of clarifications is done in a compromise time, so that noone’s felt left out). The good part of that is since you don’t have to get explanations on critical and extremely complex clarifications every day – you don’t need to torture your colleagues with evening / early morning calls each day. Usually, most of the impediments are resolved via instant messaging. Please keep in mind, that requirements standardisation is a key role in these clarifications, as properly structured requirements save a lot of time while developing a feature.

— 3.3.4 And fourth, but equally important, more standards and documenting. The more info necessary you prepare for your colleagues overseas, for the questions that may rise during your off-time, the less he will be stuck. Please use common sense in how much you need to prepare. When team gets to know each other, such planning becomes much easier. And finally, efficient process always means that person doesn’t get stuck 🙂

Finally, we’re getting to my favourite ever part!

Distributed teams with no overlapping hours + language barrier! I’ve been working with those for the last three year, and here are the additional steps to make it all work efficiently.

The three common baseline rules to follow are:

  1. Prepare meeting agenda prior to the meeting. I’m talking about writing down basic points, explanations, and maybe even branching when presenting solutions (depending on meeting complexity). It’s obvious, that people not fluent in english can’t properly communicate during the meeting – everything starts to require much more time, which isn’t efficient (and quite heavy, when it comes to hourly payrates 😉
  2. More documenting. You may say that Agile says “working software over comprehensive documentation”, however when dealing with distributed teams + no overlapping hours + language barrier, I can’t stress enough how much documentation means. There are key principles better to be described, as the team grows: communication standards (what type of communication is done via which tool, working time, speed of response), requirements acceptance, visual standards for documentation. All three principles affect how developer understands the task he’s supposed to work on. Requirements should have only one way of interpreting, should include clear pre-and-post-conditions; bugs are to be described in reproducible steps.
  3. And finally, it’s essential to have a bi-lingual person (team liason), who helps with english (he comes up with translation of complex bits, moderates the discussion). This person is better to be a developer or someone who gets the technical part well, as she often helps with syncing two development parts of the team. She may also add meeting notes on technical details agreed once meeting is over. That person most likely will sacrifice some of her time off, since hours don’t overlap.

At the end of the day, there are plenty examples across my experience, and blogs, how people manage to work with just on demand meetings, and create complex projects together. Those are git, atlassian and, among others – SkuVault.

Let me add an additional rule to common sense manifesto – process over redundancy. Greatly established process, understandable and rational for all parts of the team, makes it easy to track progress through transparency, keep team motivation high (for being productive) and time off undistracted.



Team Spirit + Exciting Project = Good Product (and vice versa)


Product is crafted by people. It is not a sum of collaborative work. It’s usually a combination of work, excitement, collaborative ideas, feedback loop inside the team throughout the whole project lifecycle.

Passion is right at the heart of every person, and if environment tends to motivate – a person will work hard to achieve a good result (appreciated by the team and himself). Moreover, working with passionate team amplifies the overall product, makes it bigger than sum of efforts.

I approach to motivation as to a three-factor equation.

  • Excitement about the project (and willingness to work on it)
  • Ability to apply your skills (and improve them)
  • Compensational part

Let’s leave out compensational part. Let’s also make a note, that such approach doesn’t work on lousy boring projects.

The rest two points are extremely transparent, if you work in a smaller companies with more or less ‘flat’ hierarchy and informal communication.

Excitement about the project comes from inspiration. It could be something cool, that brings value to the market. Aspirational team, that challenges you, while you challenge them. This makes it extremely easy to go & do your job day by day. Such teams later stick together, even working on different products, to exchange ideas and share experience (as we did with Ufa42 Conference).


Once the project is exciting, challenging – person starts to work hard in order to bring his valuable contribution. Developer, manager, designer, analyst – everyone is involved into general decisions, everyone is able to improve the product from the inside. Which means he can apply his skills in a good way, practice fresh approaches and technics, learn on mistakes, tune the workflow.

However, lack of involvement in product creation (aside from simply doing your job), vertical hierarchy and formal chain of command – it all kills the motivation. This brings us back to our equation: team is unhappy, not motivated = product not exciting. World doesn’t need boring products. Don’t forget: awesome pros won’t stick with something dull for a long time, they will leave as soon as they can. And we all know, that finding great teams is something almost impossible 🙂

How to accurately estimate external projects. Part 1 – Delays caused by communication


This is a first article from “How to accurately estimate incoming projects” series, aimed to help you see the possible future pitfalls. This includes both outsourcing projects and the ones where different teams around the world are involved.IT industry is dynamic. Companies change APIs, IDEs, upgrade hosting servers software, raise new compatibility issues. Of course improvements are welcome, but there is no way you will have a perfect product once and forever – it needs to be re-iterated. Don’t forget about hundreds of different environments that the system should work on. And people.

1. Client Interaction Time

It’s not a big deal when we are talking about local business (and even in such close distance email response delay time could be significant and expensive), but when you’re dealing with international clients and partners, this becomes a more significant issue.

There are several simple rules that are wise to follow in order to keep up with the deadlines:

  • Don’t underestimate time needed for interaction;
  • Client won’t run and read your email instantly, he has work to do;
  • Response time could vary, but prepare for the worst.

Let’s look at an example: you are building an ecommerce website. The catalogues structure is a bit tricky so you need to clarify where a product recommendation slider leads.

  1. You send the request;
  2. Client reads it in 2 hours;
  3. Gets back to you with some questions in order provide proper answer;
  4. When you answer him – you are already off from work;
  5. You read the final response the next day only.

Of course it’s not what may happen every time, but you need to take such issues into account before they happen. Here is what could cause “lags” on the client side as well:

  • Clarification from a third party (could be a hosting provider, lawyers, content providers, etc);
  • Interaction between departments;
  • Approval of department manager and other bureaucratic procedures.

In addition to that, there’s been quite a few times, when our clients from other countries needed to clarify detailed info with a a third-party with no people on that side speaking English at all.
The main point of this section is to make you understand how heavily client interaction lag can affect the entire project. It’s worth mentioning because these things rather frequently fall out of scope of attention.

How to avoid possible adverse effects? A checklist or a roadmap will be helpful to manage handling tasks in advance. In Codebranch, we prepare a project roadmap with Freeze dates, which are the last dates that a certain part of team-client interaction is due. For instance, there are:

  • Design Freeze Date – this is when the client takes a final approval and signoff to the proposed design, all the amendments and improvements to the design have to go before that date.
  • Functionality Freeze Date – the milestone by which the final application functionality should be agreed upon.
  • Content Delivery Date – this is when the content provided by client is due, so the client would know the timing in advance and have enough time to gather the content.
  • Hosting or CDN accounts purchase dates, domain name registration deadline – when, and no later, the accounts need to be available to the development team in order to set the environment up and deploy on time.

These dates are elaborated together with the client, basing on the delivery timelines that the client suggests, and adjusted accoring to the internal development milestones. This approach helps both the team and the client meet the responsibilities in working on a web project, and contributes into building a good working relationship.

Codebranch: an external web development team is now active!

crosspost x codebranch

We are Codebranch – an external web development team. For the last couple of months we’ve been preparing the grounds to run – now the website is up, our 3 offices in Finland, Russia and Turkey fully operational, so we’re good to go!

Codebranch Website

We aimed to make our website content-centric, so you won’t find awesome charts and colorful pictures. You can find important information like what we do and how to reach us almost instantly.
The same applies to the whole approach of our company – we work in a transparent, leanand efficient way.

The External Web Development Idea

When we created Codebranch, the idea was simple: we wanted to be team which is not a spare pair of hands, but an extra brain for external development.
So this is what we do:

  • develop stable, reliable solutions;
  • consult on the workflow;
  • aim to point out possible pitfalls.

Our final mission is not just the completed solution, but also complete understanding between developers and client in the course of work.

Our Web Development Team

Each of our developers has between 3+ and 8+ years of experience. We are really proud of our team’s professionalism, but what makes us really great is shared development experience. Our team has been working together for almost 2 years, and we believe that a well-shaped team brings more advantages to the working process.

Our Approach to Development

Everything we do – we execute with care.

  • We ask the right questions to clarify important matters before we start the project. Always.
  • There are usually multiple ways to achieve a goal. We can suggest more flexible solutions.
  • We aim to point out possible pitfalls and think how to avoid them.
  • Clear roadmap, displaying the project stages in dynamics will be given after the contract sign-off.
  • English is a must for everyone in the team.
  • Project Managers are the tech people too. Everyone is very fluent in project’s technical details.

Development Services

We have been developing Web Apps and Websites for a very long time – we live webdev! HTML5 + Canvas, Responsive, Facebook Applications, Complex Frontend and Backend coding – we can help you present yourself in the web, develop an additional module to your website, integrate it with your CRM system.

We can help you with CMS as well!

  • We love the buzz and community around WordPress. In fact, we build our own websites on WordPress as well!
  • In case you are looking for an enterprise solution – here comes our team, ready for some Drupal Develoment.

If you need / use a helpdesk, and Zendesk in particular: we can help you with its customization and integration. That’s something we’ve been working with quite often for the past 2 years.

We build mobile solutions as well. Whether it’s a mobile version of a website, native or a cross-platform app – don’t hesitate to ask a quote on your project.

We will share our thoughts on the industry, as well as development tips and tricks, be sure to visit our blog and leave us a comment =)