Почему ваши Daily Scrum встречи не работают и как это исправить

Лонгрид ниже - перевод статьи Lucas F. Costa "Why your daily stand-ups don't work and how to fix them" с моими небольшими комментариями и дополнениями.

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

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

Вот симптомы, указывающие на то, что вы проводите стендапы неправильно, и искажаете их смысл:

Если в вашей команде присутствуют три или более из этих симптомов, диагноз ясен: ваши стендапы бесполезны.

В этом посте я объясню реальную цель стендапа и почему это продуктивная встреча, если проводить ее правильно. Кроме того, я объясню, что означает «правильно» и нюансы, связанные с адаптацией стендапа в соответствии с вашими потребностями. Как обычно в индустрии разработки ПО, не существует такого понятия, как «один размер подходит всем».

Как и в случае с каждым отдельным принципом Agile-манифеста, мы превратили набор принципов в набор предписывающих правил. Мы забыли, что «нашим наивысшим приоритетом является удовлетворение клиента за счет максимальной быстрой и непрерывной поставки программного обеспечения, несущего в себе какую-то ценность», и начали думать, что быть гибким (agile) означает принятие жестких рамок, таких как Scrum и экстремальное программирование. Мы превратили наши средства в цели.

Почему мы это сделали? Мы сделали это, потому что легче слепо следовать набору правил, чем понять принципы, лежащие в основе, и настроить их для достижения своей цели.

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

Вот что Scrum.org говорит о цели ежедневного стендапа:

Как описано в Руководстве по Скраму, цель Daily Scrum — инспекция прогресса в достижении Цели Спринта, адаптация Бэклога Спринта по мере необходимости, корректировка запланированной предстоящей работы.

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

Теперь подумайте о своих ежедневных стендапах:

Что произошло со стендапами, так это то, что мы сместили акцент с «довести дело до конца» на «убедиться в том, что люди работают».

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

Классический пример стендапа как оружия против команды — это стендап в первую же минуту рабочего дня.

«У нас гибкий график работы», — говорят они. Конечно, но ровно в 8:30 состоится встреча, чтобы убедиться, что все уже на местах.

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

Стендапы могут быть полезными: это отличный способ без лишних затрат создать каденцию (ритм). Когда каждый день в календаре у каждого члена команды есть фиксированное время, люди организуются вокруг него, сокращая накладные расходы на планирование встреч с занятыми коллегами.

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

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

Вот что я рекомендую сделать командам, чтобы улучшить свои стендапы:

За исключением последнего пункта, остальные я не считаю обязательными. Это рекомендации.

Теперь я объясню, почему каждая рекомендация обычно работает, и поделюсь некоторыми предостережениями.

Прекратите болтать. Пройдитесь по Канбан-доске

Что ты делал вчера? Что ты собираешься сегодня делать? Возможно, это худшие вопросы, которые можно задать во время стендапа.

"Как идут дела?" - тоже не очень хороший вопрос. Этот вопрос является воплощением стиля управления MBWA (Management By Walking Around), и столь же бесполезен.

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

Работа с доской Канбан решает все эти проблемы. Это мотивирует людей быть краткими, потому что фокус на цели спринта, а не на чьей-то продуктивности. Вместо того, чтобы объяснять, что они делали, и все мельчайшие технические детали, инженеры сосредотачиваются на том, нужна ли им помощь и что они должны сделать, чтобы переместить конкретный элемент в правую часть доски: в колонку «Готово».

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

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

Только будьте осторожны, чтобы не начать управлять исключительно метриками! Метрики помогают обнаруживать аномалии, но ничего не говорят о том, как исправить эти аномалии или почему они произошли, хотя могут дать полезную информацию.

Отдайте предпочтение решению давних затянувшихся проблем.

Найдите минутку, чтобы взглянуть на актуарную таблицу смертности в Соединенных Штатах. Как видите, по мере увеличения возраста численность населения этого возраста, очевидно, уменьшается.

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

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

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

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

Фокусируясь на затянувшихся проблемах, вы естественным образом перестанете тратить время на простые задачи и начнете вкладываться в решение сложных.

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

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

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

СОВЕТ: JIRA и большинство других программ для управления проектами позволяют выделять проблемы старше определенного возраста. Воспользуйтесь этой функцией, чтобы сделать канбан-доску вашей стендапа более интуитивно понятной.

Сосредоточьтесь на блокирующих работу факторах

Фокус на блокерах имеет тот же эффект, что и фокус на затянувшихся проблемах. Он направляет инвестиции времени на важные вопросы.

Если проблема только проявилась, возможно разработчику не стоит сообщать о ней всем, если только это не блокер или есть вероятность скорого появления блокера.

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

По моему опыту, как только команды начинают сосредотачиваться на блокерах и затянувшихся проблемах, их апдейты статуса переходят от технической болтовни, например:

Я обнаружил сдвиг частоты нановолн в плазменном глюонном кристалле. Сегодня я переверну транспортер ионов и заменю торсионный новообразованный кожух. Интересно, есть ли временная аномалия в спинном кронштейне биполярного двигателя? Что все думают? [вставьте сюда длинное бессмысленное обсуждение]

к следующему виду:

Все идет хорошо. Никаких блокеров.

Насколько это лучше?

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

Пригласите всю команду, включая продакт-менеджеров и дизайнеров

Людей, которых вы называете сейлами, продакт-менеджерами, дизайнерами и инженерами-программистами, я называю командой. Продукт представляет собой комбинацию всех этих функций. Поэтому, если вы хотите создать успешный продукт, вы должны вовлекать в работу все функции (роли).

Задачи блокируются не только сложными техническими проблемами. Их часто блокируют запутанные спецификации, пробелы в дизайне, неприемлемые бизнес-возможности.

Включение людей с разными ролями в ваши стендапы упрощает решение блокеров, зависящих от иных функций кроме собственно разработки ПО — а это происходит очень часто.

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

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

Кроме того, это помогает отделам продаж, маркетинга и дизайна скорректировать свои приоритеты в соответствии со скоростью работы команды разработчиков. «Мультифункциональные» стендапы помогают всем.

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

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

Переместите детальные обсуждения в асинхронный режим

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

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

Воспринимайте стендап встречу как время для выявления проблем, а не как время для их решения.

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

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

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

Стимулируйте самоуправление и создавайте атмосферу психологической безопасности

Этот последний совет является единственным, которому я считаю обязательным следовать.

Когда людей наказывают за выявление проблем, они перестают это делать. Следовательно, проблемы проявятся только тогда, когда они станут слишком критичными или почти неразрешимыми. Вместо этого вы должны стимулировать команду озвучивать проблемы, как только они появляются.

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

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

Кроме того, я считаю, что психологическая безопасность является правом работника. Никто не заслуживает жить в страхе и беспокойстве из-за вещей, которых он не понимает, особенно учитывая, что в большинстве случаев это не его вина. Даже если это не так, это не имеет значения. Разработка продукта — это не про поиск виноватых. Обвинение других не поможет вам достичь ваших целей. Поиск ответов на вопросы и решение проблем – поможет.

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

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

Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами. — Agile-манифест

Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.

Стендапы сами по себе не являются пустой тратой времени. Они стали пустой тратой времени из-за того, как их проводит большинство команд.

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

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

Для улучшения стендап встреч и достижения своих целей я рекомендую следующее: