Обычный рабочий день. Тот же самый daily standup, который вы посещаете годами. Вы приходите в одно и тоже время. Немного общаетесь со своими товарищами по команде. Потом руководитель интересуется, как вчера прошла чья-то работа.
Получаете информацию о проделанной работе. Обсуждаете детали предыдущего дня. В конце вам объясняют план на текущий день. Повторяете с человеком из своей команды, пока не завершится daily standup.
Этот формат вроде как… работает.
Я имею в виду, что для одних команд это нормально, а для других — отстой. Почему люди жалуются на daily standup на командных встречах? Почему одним это нравится, а другим нет? Поразмыслив над этим в течение нескольких лет, я пришел к следующему выводу:
Меня не волнует, что ты сделал вчера.
Меня не волнует, что у вас были совещания по поводу побочного проекта. Мне все равно, сколько часов вы потратили на написание кода. Меня не волнует, был ли у вас запланирован прием стоматолога.
Меня волнует, насколько команда продвинулась к своим целям.
В этом посте я собираюсь рассмотреть проблемы, которые возникли у моих команд с форматом daily standup. Я объясню формат, который мы используем и который лучше масштабируется растущей командой. Затем я рассмотрю другой вариант:
Имеет ли значение daily standup?
Что такое daily standup?
Если вы не знакомы с daily standup, то это ежедневное собрание команды для обсуждения текущего проекта. Оно длится порядка 15 минут и предполагает, что каждый человек отвечает на следующие вопросы:
Что я сделал вчера, что принесло пользу команде?
Что я планирую сделать сегодня, чтобы внести свой вклад в команду?
Какие препятствия мешают мне или команде достичь поставленных целей?
Во время daily standup следует избегать подробных обсуждений. Вместо этого, эти темы должны быть продолжены после окончания встречи. Я подчеркиваю «следует», потому что на практике подобных дискуссий трудно избежать.
В оставшейся части этого поста я буду называть этот формат «традиционным».
Проблемы формата Daily Standup
Проблемы с традиционным daily standup — это отсутствие фокуса и обсуждение не по теме. Когда я прихожу на эту встречу, у меня в голове возникают следующие мысли:
Я начинаю думать о своем вкладе, чтобы доказать свою полезность;
Люди отключаются, когда товарищ по команде начинает говорить о том, что их напрямую не касается;
Наконец-то настала моя очередь сообщать о проделанной работе. Но никто не слушает, кроме руководителя;
Мы выходим за временные рамки и заканчиваем, когда другая команда начинает мельтешить у входа в комнату в ожидании своего daily standup.
Я не помню большую часть информации, которую я слышал на ежедневных выступлениях. Это заставляет меня задавать дополнительные вопросы своей команде. Мои коллеги вынуждены повторять информацию, которую они уже рассказали. Единственная разница в том, что сейчас я слушаю.
Я считаю, что традиционный формат daily standup подходит для небольших команд. Если анонс сделанной работы укладывается в пять минут, то дополнительные десять можно потратить на то, чтобы углубиться в конкретные темы. В небольшой команде замечательно то, что эти дополнительные темы затрагивают всех.
Все идет наперекосяк, когда команда становится больше семи человек или около того. В больших командах возникают новые проблемы:
Больше людей приносят больше нововведений.
Больше нововведений — больше информации, на которую другим людям будет наплевать.
Команда может работать сразу над несколькими проектами.
Если у команды есть клиенты, то регулярно будут озвучиваться особые виды деятельности.
Проще говоря, традиционный формат daily standup не масштабируется.
Масштабируемый формат daily standup: «Walk the Board»
Я добился большого успеха в использовании формата «Walk the Board» для больших ежедневных выступлений. Этот формат по-прежнему отвечает на критические вопросы:
Что было сделано вчера?
Что запланировано на сегодня?
Что мешает команде добиться прогресса?
Главное изменение — мы перестаем озвучивать информацию от каждого члена команды о проделанной им работе. Вместо этого мы получаем информацию обо всем тикетами на доске.
Этот формат работает следующим образом:
Создайте доску, на которой будет отображаться статус каждого элемента, над которым работает команда.
Начиная с самого правого столбца, получите обновления для каждого тикета в столбце.
Обязательно спросите: «Что нужно, чтобы переместить этот элемент на следующий этап прогресса?»
Выделите проблемы, мешающие работе.
Перейдите к следующему столбцу слева и получите обновления для каждого тикета в этом столбце.
Продолжайте, пока не дойдете до самого левого столбца.
Этот формат хорошо подходит для больших команд. Все более сосредоточены, поскольку мы говорим о конкретных вещах в четком порядке. Мы не ходим по темам в зависимости от того, в какой порядке выступают сотрудники. Всем легче подготовить свои выступления, поскольку они знают, что будет дальше.
Теперь может показаться, что этот формат занимает много времени. Но это не так!
Поскольку вы говорите о конкретных вещах, выступления будут короче. Более сфокусированная дискуссия также предотвращает появление побочных тем.
Что делать, если формат «Walk the Board» слишком долгий?
Если этот формат занимает у вашей команды слишком много времени, значит, у вас появились другие проблемы..
Если вам нужно обсудить слишком много вещей , стоит подумать, как ваша команда может взять на себя меньше элементов? Как исправить это — тема для другого разговора. А пока я рекомендую прочитать книгу Agile Project Management with Kanban.
Может быть, проблема в организаторе встречи. Он может позволять людям слишком долго говорить на темы и терять счет времени.
Вышеупомянутые проблемы могут не относиться к вам; каждая команда уникальна. В этом случае потратьте время на изучение проблем, с которыми сталкивается ваша команда. Глубокое понимание проблем облегчит поиск правильного решения.
Значение играет не сам Daily standup, а время после него.
После многих лет посещения daily standup я начал замечать кое-что особенное. Они зачастую были однотипны, но после встречи…
Все в команде общаются.
Это были не просто светские беседы. Во время этих бесед распространялась весьма значимая информация. Люди были поглощены решением проблем. В команде строилось доверие. Их не обременяли цейтнот или плохие чувства из-за «потери» времени на обсуждение различных тем.
Эта свобода позволяла каждому говорить о проблемах, которые его действительно волновали.
Это заставило меня понять, что настоящая ценность daily standup — не сама встреча, а время, которое наступает после неё.
Учитывая это, давайте перестанем пытаться оптимизировать саму встречу. Вместо этого используйте её как катализатор, чтобы увести ваших товарищей по команде от их рабочих мест. Используйте daily standup, чтобы начать разговор, но доверяйте команде, чтобы она сама закончила его.
Заключение
После всего этого я по-прежнему считаю daily standup полезным инструментом. Уловка в том, что необходимо сосредоточиться на реальной цели встречи.
Да, нам нужно координировать свою работу в команде. Определите проблемы, получите ответы на вопросы.
Но нам нужно придумать, как сделать разговор эффективным для команды в целом. То, что работает для команды из пяти человек, может не работать для команды из пятнадцати человек.
По мере роста вашей команды воспользуйтесь возможностью пересмотреть формат этой встречи. Поймите настоящие проблемы, с которыми сталкивается ваш формат, и приспосабливайтесь. Я считаю, что формат «Walk the Board» хорошо подходит для крупной команды, но, возможно, другие форматы подойдут лучше..
В конце концов, ежедневные выступления не сводятся к обсуждению проделанной работы. Речь идет о том, чтобы собрать вместе умных людей для совместной работы и решения сложных проблем.
Дата-центр ITSOFT — услуги размещения и аренды серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.
Frintezza93
Я не эксперт в аджайлах и прочих методологиях. Но если у вас слишком большая команда для стэндапа, то возможно она слишком большая ещё для чего-то? Я не обладаю большим опытом управления командами и построением процессов, но заметил, что применение практик «из коробки» хорошо работают на командах «из коробки» (размер, состав, структура).