Приятно видеть, что на мою просьбу прокомментировать  «Кейс о поломанном Daily Scrum» откликнулось много практиков и вместе собралось достаточное количество рекомендаций. Считаю своим долгом обобщить высказанные идеи и поделиться ими со всеми, кто не следил за дискуссией.

Напомню кратко суть кейса… Команда, которая относительно недавно практикует Scrum методологию управления проектами, проводила ежедневные координационные встречи (Daily Scrum) по 40 и более минут, вместо рекомендуемых 15. Скрам Мастер обратил внимание команды на это и начал вводить дополнительные правила, помогающие сосредоточится на синхронизации усилий, а все вопросы выносить на второй круг обсуждений. Встречи стали проходить быстро, на второй круг уже никто не хотел говорить, при этом в целом оставалось ощущение недосказанности.

Поскольку коментирующие правильно заметили, что «тяжело определять симптомы по фотографии», я обобщаю возможные причины, чтобы другие при случае могли примерять «пилюли» и на свои команды.

Совет первый «Плохо сделанное домашнее задание»

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

????? ????? пишет:

Рискну предположить, что долгая дискуссия пораждается недостаточной коммуникацией во время планирования спринта (сколько вы тратите времини на планинг сессию?), тем самым команда восполняет те пробелы в виденьи технической реализации, которые можно было заполнить чуть ранее.

В эту же категорию можно смело отнести недостаточную подготовку участников к самой встрече. Как заметил ?????? ??????.

Тогда может проблема в кол-ве одновременно решаемых одним человеком задач или в их сложности? Уменьшение размера или кол-ва задач поможет уменьшить время затрачиваемое одним членом команды на описание того что сделал и планирует.

Совет второй «Пишите, Шура, пишите»

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

???? ???????? прокомментировала это так:

Ключевой момент здесь – не забыть кто и о чем хотел поговорить. Мы записываем на доске кто, с кем и о чем хотел поговорить. Получается списочек вопросов или проблем.

Следующий ключевой момент – проследить чтобы эти пункты действительно обсудили. В течение дня я спрашиваю указанных людей – этот вопрос решили? Если нет – решайте.

И с ней согласилось большинство комментирующих :-). Так что если вы Скрам Мастер – делайте свою работу: записывайте и визуализируйте.

Совет третий «Осторожно Scrum-зомби»

Обычно это следствие более глубокой проблемы – сведения Scrum к небольшому числу ритуалов (Планирование-Стэндап-Демо-Ретро). На самом деле самое важное поле для взаимодействий – сотрудничество и обмен информацией в явном и неявном(“tacit” по Nonaka и Konno) виде  на уровне эпизода разработки, в то время как Стэндап это просто safety net. Соответственно решать нужно корневую проблему, а не ее симптом – “как лучше проводить Скрам митинги”. […]
Для Скрам мастера именно эта область всегда наиболее сложна для фасилитации и коучинга, но пересекая эту черту команды становятся действительно “Гибкими”.

Как правильно обратил внимание Александр Якима, длинные ежедневные встречи могут быть признаком того, что отсутствует совместная работа в команде. Подобную же мысль высказали несколько других комментирующих. Цитируя ?????? ???????: «если они просто проговаривались, но их никто не слушал, то это проблема не девелопмент процесса, а личного общения, все хотят, чтоб их слушали».

Совет четвертый «Проблему должны решать те, для кого это проблема»

Проженный Опытный коуч ????? ?????? сразу для диагностики задал правильные вопросы:

У меня два вопроса ))
Первый – а почему это проблема?
И второй – чья собственно это проблема? ))

Все практикующие Скрам Мастера, которые писали, что у них была похожая проблема, решали ее путем того, что делали проблему видимой для команды и давали команде самим найти решение. Если «решить за них», то люди не будут чувствовать ценности такого решения и следовать ему. Даже если вы знаете решение, то лучше дать участникам команды ссылку на эту статью, чем самостоятельно вводить новые правила 😀

Другое дело, что в «коуч»-составляющую работы Скрам Мастера входит напоминание команде о договоренностях и помощь в следовании этим договоренностям: жесткий контроль времени, записи тем для обсуждения, напоминания ответственным за ту или иную проблему и т.п.

В конце-концов, необходимо некоторое время для формирования привычки. В моем личном опыте команда из 11 человек, распределенная между двумя странами успевала синхронизировать свои усилия меньше чем за 10 минут. Уверен, для сидящей вместе команды из 7 человек это точно не проблема.

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

Спасибо всем, кто принимал участие в обсуждении – оставайтесь с нами и следите за новыми темами для обсуждений через RSS, Twitter, Facebook или просто периодически посещая сайт 😉