Agile communication in distributed, non-overlapping teams

    The main question of this post: what changes does agile communication (and scrum, in particular) undergo, stretching for distributed teams?

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

    1. strategic rallies (planning / retrospective)
    2. daily synchronization (including daily standups)
    3. clarification of working issues

    image

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

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

    2. Distributed teams with overlapping business hours.
    Typical examples: USA - Chile (2 hours difference), Netherlands - India (4.30)

    • Here you can do daily synchronization, and planning, and a retrospective without much pain.
    • The moment of clarification of the problem is lost, but in general everything works, because Skype or hangouts are always just a click away.
    • But remember, Padawan, no matter how focused your team is, there will be a lag in communication in all cases when one of the team runs out of working hours

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

    3.1 Team liason (i.e. a team representative). This is when one of the team in one part of the world stays outside working hours for himself, and during working hours for colleagues in another location <usually this is the person who is the product, and synchronizes with the development team, but not once accounted 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 Teams, 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, and for the second part of the team, on the contrary, the working day from 9 to 6 shifts 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 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 configure the communication process so that it is convenient for everyone in a distributed team.

    • 3.3.1 First of all, this means people participate in planning and retrospectives fully, as these events are held once every 2-3 weeks. But in a coincidence, it is necessary to make these events well-pressed out with specifics, and with the preparation of the points for these meetings. In no case, do not allow abstract chatter, save time for everyone, communicate only on business.
    • 3.3.2 Secondly, this means that the daily synchronization (or, if you work on scrum - daily standup) is done in the text at the end of the working day for the teams. For everyone to see who was doing what (you can refer to the branch in which the work was going on, but the fact is that everyone has a squeeze of the day). Someone suggests making Asynchronous video calls (IBM used to do this at one time, Dave Snowden told me about this) - where you record how you spent the day on the video, and, if necessary, do screenshots when you need to explain something clearly.
    • 3.3.3 Thirdly, this means that clarifications on any problems there are made upon request. And the rally is planned for a convenient and compromise time, so that no one feels disadvantaged. And since global clarifications are not required every day, there is no need to torture your colleagues daily, taking their precious time. Well and, of course, standardization of requirements is far from the last role in this approach.
    • 3.3.4 Fourth, documentation and standards. The more you cover the rear areas with background information to 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 - you do not need to cover EVERYTHING with documentation, spending a myriad of time on it (I hope now it’s clear that this is not opposed to the agile manifesto item about “working software instead of overcomplicated documentation”). Moreover, when the team is triggered, it becomes a little easier to predict the questions of colleagues.

    And finally, an efficiently built 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 get to my favorite topic:
    4. Distributed teams with a language barrier, and without intersecting hours!

    • Well, here God himself ordered to prepare for the rallies in advance, and write down the main points. I think it is obvious that people who have problems with English usually cannot communicate on equal terms during the rally, and such rallies take a lot of time (and sprinkle a killed pinch with a pinch of frustration). But with an hourly rate, this is a pretty solid 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 the rally. You can add to this piece of paper some alternative solutions to the problem in advance, a kind of branching options, slightly anticipating the questions of colleagues.
    • More documentation. Correct communication standards, acceptance of requirements, design rules - all this greatly affects the employee’s understanding of the tasks facing 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 could it be without a team representative - a person who helps with English (fluent in it, for example) and moderates the conversation (during urgent meetings to discuss a solution to the problem). Of course, the ideal candidate is the developer / techlide himself, because the whole process of communication lies precisely in the technical details, especially when you need to quickly clarify something or plan another crutch. Otherwise, technical discussions take incredibly long preparation time, and often turn into a dead phone. You do not need this in any case, as it leads to the frustration of a colleague who spends his non-working time on this synchronization.

    To summarize

    In my experience, as well as wandering around blogs, you can find enough examples of how people work and rally 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, the links to the materials of which (on the topic and their experience) - I provided at the end of the post. Even Sutherland (the scrum father) has an article on how Amsterdam worked with Bangalore, but the time zones there intersect for 3.5 working hours, and the key developers from India were transferred to the Netherlands for two months at the beginning of the project to transfer knowledge, so their experience We did not particularly help in the construction of the process.

    And in conclusion, I won’t tire of repeating that a well-organized process in an organization is always transparent and convenient for everyone, team motivation from well-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 related articles that can be read to understand who works with distributed teams (collected for a long time, read for six months):


    Also popular now: