Agile communication in distributed teams that do not intersect at work time

The main question of this post: what changes agile communication undergoes (and scraps, in particular), under pressure on distributed commands?

To do this, let's first classify the communication:

strategic meetings (planning / retrospective)
daily synchronization (including daily standups)
clearing work issues

')

Let's add one more dimension! If we try to impose the above classification on geography, then additional cuts appear for the above:

1. Collocated teams (eng. Term for a team sitting next to each other) - there are no problems for all 3 communication “events”. Teams working on any methodology (including scrum), which are geographically located in one place, have no problems holding all three types of rallies face to face.

2. Distributed commands with overlapping working hours.

Typical examples: USA - Chile (2 hours difference), Netherlands - India (4.30)

Here you can do daily synchronization, and planning, and retrospective without much pain.
The momentary clarification of the problem is lost, but in general everything works, because Skype or hangouts is always a click away.
But remember, Padawan, that no matter how focused, your team was not, there will be a lag in communication in all cases when someone from the team ran out of intersecting working hours.

3. Distributed teams without overlapping hours (8+ hours difference).

Approaches:

3.1 Team liason (i.e. team representative). This is when someone from a team in one part of the world stays outside working hours for themselves, and during working hours for colleagues in another location <usually this is a person who is a product and synchronizes with the development team, but not once account for>. Or if a person from one piece of a team in one hemisphere synchronizes with another team (like scrum masters in scrum of scrums).

3.2 Commands, changing their daily routine, for synchronization, a compromise approach. For example, the working day for the first part of the team moves from 10 am to 9 am, while for the second part of the team, the working day is shifted from 9 to 6 and is shifted to from 10 to 7. This is done in order to achieve the intersection of the working time, and, accordingly, you can begin to apply the techniques used by the Distributed teams with intersecting working hours). But it all depends on the time difference, and comfort for the team, and the specifics of the tasks.

3.3 And you can customize the communication process so that it is convenient for everyone in a distributed team.

3.3.1 First, it means that people participate in planning and retrospectives fully, as these events take place every 2-3 weeks. But under circumstances, these events should be made well squeezed with specifics and point-by-point preparations for these rallies. In no case, do not allow abstract chatter, save everyone time, communicate only in the case.
3.3.2 Secondly, this means that daily synchronization (or, if you work on a scram - daily standup) is done with text, at the end of the working day for teams. For everyone to see who did what (you can also refer to the branch in which the work went, but the fact is that everyone has the squeeze of the day). Someone suggests making asynchronous video calls (IBM did that at one time, Dave Snowden told me about it) - where you record how you spent the day on video, and if you need to, take screenshots when the inexpediency is explained clearly.
3.3.3 Thirdly, this means that clarifications on all kinds of problems are done on request. And the rally is planned for a convenient and compromise time, so that no one feels slighted. And since global clearing is not required every day - there is no need to torture your colleagues daily, taking away their precious time. And, of course, standardization of requirements is far from the last role in this approach.
3.3.4 Fourth, documentation and standards. The more background information you cover with possible questions from colleagues from another time zone, the less time they will be in limbo. Nevertheless, the main thing here is not to overdo it and use common sense - it is not necessary to cover EVERYTHING with the documentation, spending an infinite amount of time for this (I hope it is now clear that this is not opposing the agile manifesto on “working software instead of overdeveloped documentation”). Moreover, when a team is triggered, it becomes a bit easier to anticipate the questions of colleagues.

And, finally, an effectively constructed process always implies that a person does not get stuck in one place if he does not have an answer to a question.

Well, we are getting to my favorite topic:

4. Distributed commands with a language barrier, and no overlapping clocks!

Well, here God himself ordered to prepare for meetings in advance, and write down the main theses. I think it is obvious that people who have problems with English usually cannot communicate on equal terms during a rally, and such meetings take a lot of time (and sprinkle time on the dead with a pinch of frustration). But with hourly pay, this is a pretty substantial burden, isn't it?) For example, a person who does not speak English fluently can write down his theses on a piece of paper and read them during a rally. You can add to this piece of paper some alternative solutions to the problem in advance, such a branching of options, slightly anticipating the questions of colleagues.
More documentation. Correct standards of communication, acceptance of requirements, rules of registration - all this greatly affects the employee’s understanding of the tasks before him. The rules of common sense prevail here - the description should be interpreted unambiguously, the user story should contain specific pre-and-post-conditions, bugs should be described in reproducible steps.
Well, how can it be without a representative of the team - a person who helps with English (he himself is fluent, for example), and moderates the conversation (during urgent meetings, to discuss solving the problem). Of course, the ideal candidate is the developer / techlide himself, because the entire cymes of communication lies in the technical details, especially when it is necessary to quickly clarify something or plan another crutch. Otherwise, technical discussions take incredibly more time for preparation, and often turn into a deaf phone. This is by no means necessary to you, since it leads to the frustration of a colleague who, therefore, spends his or her off time on this synchronization.

Summarizing

In my experience, as well as wandering around on blogs, you can find enough examples of how people work and hold meetings only when there is a need for it. And with all this they make wonderful, complex and inspiring projects. This is not only our experience, but also the experience of git, atlassian, and other companies whose links to the materials (on the topic and their experience) - I provided at the end of the post. Even Sutherland (Scrum-Fathers) has an article on how Amsterdam worked with Bangalore, but the time zones intersect there for 3.5 business hours, and the key developers from India for two months at the beginning of the project were transported to the Netherlands to transfer knowledge, so their experience didn’t help us much in building the process.

Well, to finish, I don’t tire of repeating that a well-organized process in an organization is always transparent and convenient for everyone, the team’s motivation for coordinated work will be transformed into productivity, and distributed teams will also be happy with free time after work, not overwhelmed with a bunch of rallies.

Links to articles on the topic that can be read to understand who is working with distributed teams (collected for a long time, read half a year):

Source: https://habr.com/ru/post/346904/

All Articles

Agile communication in distributed teams that do not intersect at work time

More articles: