Agile коммуникация в распределенных командах, без пересекающихся рабочих часов18.01.2018 12:03

Главный вопрос этого поста: какие же изменения претерпевает agile коммуникация (и скрам, в частности), натягиваясь на распределенные команды?

Для этого, давайте сначала классифицируем коммуникацию:

стратегические митинги (планирование / ретроспектива)
ежедневную синхронизацию (в том числе daily standups)
прояснение рабочих вопросов

Давайте добавим еще одно измерение! Если попробуем наложить вышеприведенную классификацию на географию, то появляются дополнительные срезы для вышепреведенного:

1. Collocated teams (анг. термин для команды, сидящей друг рядом с другом) — тут проблем нету на все 3 коммуникационных «ивента». У команд, работающих по любой методологии (включая скрам), и которые находятся географически в одном месте, нет никаких проблем проводить все три типа митингов лицом к лицу.

2. Распредененные команды с пересекающимися рабочими часами.
Типичные примеры: США — Чили (2 часа разницы), Нидерланды — Индия (4.30)

Тут можно делать ежедневную синхронизацию, и планирование, и ретроспективу без особой боли.
Теряется сиюминутность прояснения проблемы, но в целом все работает, потому что скайп или hangouts всегда находится на расстоянии одного клика.
Но помни, падаван, что какой бы focused, твоя команда не была, лаг в коммуникации будет во всех случаях, когда у кого-то из команды закончились пересекающиеся рабочие часы

3. Распределенные команды без пересекающихся часов (8+ часов разницы).
Подходы:

3.1 Team liason (то есть представитель команды). Это когда кто-то из команды в одной части света остается во вне рабочее время для себя, и в рабочее время для коллег в другой локации <обычно это человек, который product'ом является, и синхронится с командой разработки, но раз на раз не приходится>. Или же если человек от одного куска команды в одном полушарии синхронится с другой командой (как скрам мастеры в scrum of scrums).

3.2 Команды, изменяющий свой распорядок дня, для синхронизации, компромиссный подход. Например, двигается рабочий день для первой части команды с 10 утра на 9 утра, а у второй части команды наоборот, рабочий день с 9 до 6ти сдвигается до с 10 до 7 ми). Делается это для того, чтоб достичь пересечения рабочего вреемни, и, соответственно, можно начинать применять техники, используемые Распределенными командами с пересекающимися рабочими часами). Но это все зависит от разницы во времени, и комфортности для команды, и специфики задач.

3.3 А можно настроить процесс коммуникации, чтоб он был удобен всем в распределенной команде.

3.3.1 Во-первых, это значит люди участвуют в планировании и ретроспективах полноценно, так как эти ивенты идут раз в 2–3 недели. Но при стечении обстоятельств, надо делать эти ивенты хорошо выжатыми с конкретикой, и с подготовкой по пунктам к этим митингам. Ни в коем случае, не допускать отвлеченной болтовни, экономить время всем, общаться только по делу.
3.3.2 Во-вторых, это значит, что ежедневная синхронизация (или, если вы работаете по скраму — daily standup) делается текстом, в конце рабочего дня у команд. Чтобы все видели кто чем занимался (можно сослаться и на ветку, в которой шла работа, но факт в том, что выжимка дня есть у всех). Кто-то предлагает делать Асинхронные видео звонки (IBM, в свое время так делал, об этом мне рассказывал Дейв Сноуден) — где ты на видео записываешь как провел день, и, если надо — делаешь скриншеринг, когда необохдимость что-то объяснить наглядно.
3.3.3 В-третьих, сие значит, что прояснения по всяким там проблемам делается по запрсу. И митинг планируется на удобное и компромиссное время, чтоб никто не чувствовал себя ущемленным. А так как прояснений каждый день глобальных не требуется — нет необходимости пытать своих коллег ежедневно, отнимая их драгоценное время. Ну и, естественно, стандартизация требований — это далеко не последняя роль при подобном подходе.
3.3.4 В-четвертых, документирование и стандарты. Чем больше вы прикроете тылы справочной информацией к возможным вопросам коллег из другого часового пояса, тем меньше времени они будут в подвешенном состоянии. Тем не менее, главное тут не перестараться и использовать здравый смысл — не надо покрывать документацией ВСЁ, тратя на это несметное количество времени (надеюсь, теперь понятно, что это не противопоставление пункту agile manifesto про «работающий софт вместо переусложненной документации»). Тем более, когда команда срабатывается — предугадывать вопросы коллег становится чуть проще.

Ну и, наконец, эффективно построенный процесс всегда подразумевает, что человек не застревает на одном месте, если у него нет ответа на какой-то вопрос.

Ну и мы подбираемся к моей любимой теме:
4. Распределенные команды с языковым барьером, и без пересекающихся часов!

Ну тут уже сам бог велел готовиться к митингам заранее, и основные тезисы записывать. Я думаю очевидно, что люди, имеющие проблемы с английским, обычно не могут на равных общаться во время митинга, и такие митинги отнимают много времени (и посыпают убитое время щепоткой фрустрации). А ведь с почасовой оплатой, это довольно солидная ноша, не так ли?) Например, человек, не владеющий свободно английским, может записать на бумажке свои тезисы, и прочитать их во время митинга. Можно добавить на эту бумажку какие-то альтернативные варианты решения проблемы заранее, эдакое ветвление опций, немного предвосхищая вопросы коллег.
Больше документирования. Правильные стандарты коммуникации, приемка требований, правила оформления — все это очень сильно влияет на понимание сотрудником задач, перед ним стоящих. Правила здравого смысла здесь преобладают — описание должно трактоваться однозначно, user story должна содержать конктетные пред-и-пост-условиыя, баги должны описываться воспроизводимыми шагами.
Ну и как же без представителя команды — человека, который помогает с английским (сам им свободно владея, например), и модерирует беседу (во время срочных митингов, чтоб обсудить решение проблемы). Безусловно, идеальный кандидат — это сам разработчик / техлид, ибо весь цимес коммуникации кроется именно в технических деталях, особенно, когда надо быстро что-то прояснить или запланировать очередной костыль. В противном случае — технические обсуждения занимают неимоверно больше времени на подготовку, и зачастую превращаются в глухой телефон. Вам это ни в коем случае не нужно, так как ведет это к фрустрации коллеги, который итак свое нерабочее время тратит на эту синхронизацию.

Подводя итог

В моем опыте, а также побродив по блогам, можно найти достаточно примеров того, как люди работают и митингуют только, когда есть в этом необходимость. И при всем при этом делают замечательные, сложные и вдохновляющие проекты. Это не только наш опыт, но еще и опыт git, atlassian, и других компаний, ссылки на материалы которых (по теме и их опыту) — я предоставил в конце поста. Даже у Сазерленда (скрам-батюшки) есть статья, как Амстердам работал с Бангалором, но часовые зоны там пересекаются на 3.5 рабочих часа, а ключевых разработчиков из индии на два месяца в начало проекта перевезли в Нидерланды, чтоб знания передать, так что их опыт нам особо не помог в построении процесса.

Ну и завершая, не устану повторять, что хорошо отлаженный процесс в организации всегда прозрачен и удобен всем, мотивация команды от слаженный работы будет трансформироваться в продуктивность, а распределенне команды будут рады еще и свободному времени после работы, не заваленное кучей митингов.

Ссылки на статьи по теме, которые можно прочитать, чтобы понять, кто как работает с распределенными командами (собирал долго, читал полгода):

www.disciplinedagiledelivery.com
snowdolphin.com/blog/2009/2/16/adventures-in-distributed-agile.html
agilemodeling.com/essays/communication.htm
www.atlassian.com/blog/confluence/4-simple-collaboration-strategies-distributed-teams
www.atlassian.com/team-playbook
msdn.microsoft.com/en-us/magazine/hh771057.aspx
www.atlassian.com/company/events/summit-europe/watch-sessions/2017/scale-extend/a-brave-journey-in-merge-waters-how-paysafe-consolidated-their-atlassian-tools
pdfs.semanticscholar.org/cde9/6fed7d2e2591bc8f697814ab1f33e3a84160.pdf
www.scrumalliance.org/community/articles/2013/july/managing-distributed-teams
medium.com/@MentorMate/what-i-learned-managing-a-remote-agile-software-team-fd2db22e22b1
www.researchgate.net/publication/263398659MoonlightingScrumAnAgileMethodforDistributedTeamswithPart-TimeDevelopersWorkingduringNon-Overlapping_Hours
www.agileconnection.com/article/five-agile-challenges-distributed-teams
www.agilealliance.org/wp-content/uploads/2016/01/Distributed-Agile-in-the-Enterprise-and-Virtual-Spaces-2012–08–16.pdf
www.research.ibm.com/pdfs/scrum/Chapter6Pearson20090706.pdf
www.thoughtworks.com/mingle/scaled-agile/2016/06/13/visualizing-time-zones.html
reqtest.com/general/working-efficiently-with-distributed-teams
www.methodsandtools.com/archive/archive.php? id=109