Представьте, что вы являетесь владельцем продукта и руководите командой, разбросанной по всему миру, члены которой находятся в разных странах и часовых поясах. Ваше стремление к эффективному общению и совместной работе превращается в большое приключение, а повторяющиеся встречи угрожают отнять драгоценное время, как безжалостный дракон.
В моей недавней статье «Восстановление вашего времени: использование асинхронного общения и прощание с повторяющимися встречами» я углубился в преобразующую силу асинхронного общения.
Однако в огромном ландшафте производительности существует одна повторяющаяся встреча, которая стоит особняком, сияющая звезда среди хаоса.
Пришло время освободиться от цепей монотонных совещаний и исследовать новую сферу эффективности.
Ведь в вашем арсенале есть секретное оружие — могучий стендап!
Приступив к этому поиску оптимизированной производительности, вы вскоре поймете, что традиционный формат стендапа Scrum не может быть вашим верным мечом.
Сегодня мы отправляемся в путешествие, чтобы раскрыть скрытые сокровища этого уникального собрания.
Присоединяйтесь ко мне, и мы расскажем об удивительных преимуществах одной повторяющейся встречи в день, секретной жемчужины в сфере удаленного сотрудничества.
Страшные три вопроса
По мере того, как команда собирается, воздух наполняется чувством беспокойства, поскольку они знают, что их ждет — трио ужасных вопросов:
- 'Что ты делал вчера?'
- ‘Что ты собираешься делать сегодня?’
- «Есть ли какие-либо препятствия или блокираторы?»
Эти невинные запросы, которые когда-то предназначались для содействия сотрудничеству и прозрачности, стали проклятием существования каждого члена команды.
В этой статье мы отправляемся в путешествие, чтобы раскрыть скрытые недостатки и ограничения традиционного стендапа Scrum. Приготовьтесь, пока мы распутываем запутанную паутину неэффективности, траты времени и неуместных приоритетов. Приготовьтесь бросить вызов статусу-кво и открыть для себя новый подход, который привнесет сосредоточенность, мотивацию и значительный прогресс в ваши ежедневные командные ритуалы.
Среди моря стонов и закатывания глаз становится ясно, что традиционный стендап Scrum потерял свой блеск. Когда-то многообещающая возможность для сотрудничества превратилась в платформу для длинных монологов, где члены команды пользуются моментом, чтобы подробно рассказать о своих действиях предыдущего дня. Это похоже на театральное представление, где каждый актер вступает в свою очередь, рассказывая свои личные истории, оставляя остальную часть команды терпеливо ждать своей очереди.
Но по мере роста команды растут и временные затраты. То, что когда-то было коротким и целенаправленным совещанием, теперь затягивается, отнимая драгоценные минуты, которые можно было бы лучше потратить на продуктивную работу. Подобно марафону без финиша, стендап расширяется в геометрической прогрессии, заставляя членов команды жаждать побега, а их мысли блуждают по задачам, ожидающим их внимания.
И давайте не будем забывать об отсутствии внимания к наиболее важным элементам. В то время как члены команды усердно делятся своим прогрессом, становится очевидным, что акцент сместился с целей спринта на личные достижения. Каждый человек в свою очередь рассказывает о своих достижениях и обновлениях, но коллективное влияние на цели спринта отходит на второй план. Как будто команда упустила из виду более широкую картину, их глаза были сосредоточены на собственных ближайших планах.
Кроме того, повторяющийся характер традиционного стендапа может сказаться на психическом благополучии инженеров. Представьте себе давление необходимости придумывать что-то новое каждый день, независимо от того, был ли достигнут значительный прогресс или нет. Это становится сложной задачей, похожей на создание новой истории из воздуха, заставляя инженеров изо всех сил пытаться найти что-то, о чем можно сообщить, даже если это означает приукрашивание правды или выделение незначительных деталей.
Но есть лучший способ восстановить суть стендапа. Пришло время вырваться из оков обыденной рутины и принять новый подход, который оживляет совместную работу, мотивирует и способствует прогрессу. Смещая наше внимание с наблюдения за работником на наблюдение за работой, мы можем произвести революцию в стендапе и возродить его цель.
Прошли те дни, когда вы зацикливались на вчерашних достижениях или неудачах. Вместо этого давайте зададим себе один важный вопрос, который прорежет шум и подтолкнет нас к осмысленным действиям:
«Что мешает команде перевести рабочий элемент с наивысшим приоритетом в следующее состояние рабочего процесса?»
Устраняя препятствия и блокирующие препятствия, мы переключаем наше внимание на препятствия, которые действительно имеют значение, устраняя препятствия и расчищая путь к прогрессу.
Команда должна сосредоточиться на ответе на ОДИН вопрос: «Что мешает команде перевести рабочий элемент с наивысшим приоритетом в следующее состояние рабочего процесса?»
Это небольшое изменение в парадигме стендапа может показаться незначительным, но оно произведет революцию в том, как вы управляете стендапами.
Я намеренно использую «команда от вытягивания», а не «Я от вытягивания», так как это меняет право собственности и ответственность перед командой, а не перед отдельным человеком.
Я задаю вам этот вопрос: «Вы пытаетесь следить за работой или рабочим?». Я бы сказал, что цель состоит в том, чтобы следить за работой. Не рабочий. Поэтому переход от формата обхода комнаты, задающего каждому человеку три страшных вопроса, к «Что мешает команде перевести элемент с наивысшим приоритетом в следующее состояние рабочего процесса?» концентрирует внимание на следовании за работой.
Очередь историй должна быть упорядочена по приоритету. Чтобы самая приоритетная история всегда была наверху. Разговор начинается с этой истории. Объем каждого обсуждения должен быть только этой отдельной историей. Нет необходимости обсуждать другие истории, даже если инженеры, которые говорят, тоже работали над чем-то другим. Мы можем вернуться к этой истории позже, в зависимости от того, где она находится в приоритете, или мы можем даже не обсуждать ее. Это не вызов микроменеджмента, поэтому нам не нужно слышать обо всем, что они делали или пытались отслеживать свое время.
Если вы используете Scrum, у вас может быть только 3 столбца: TODO, INPROGRESS, DONE. Разговор начинается с текущей истории с наивысшим приоритетом, поскольку она имеет наивысший приоритет и ближе всего к завершению. Цель состоит в том, чтобы перестать начинать новую работу и начать заканчивать работу. Продолжайте движение вниз по очереди INPROGRESS до тех пор, пока критические истории для обсуждения не закончатся. Если есть важные истории, которые не были начаты, вы должны рассказать о них в следующий раз, даже если есть еще истории в процессе. Если будет время то можно вернуться к рассказам INPROGRESS. Если нет времени, не беда. В любом случае завершите вызов.
Если вы используете Канбан, у вас может быть несколько разных состояний рабочего процесса. Не только TODO, INPROGRESS и DONE. В этой методологии вы снова должны начать с критических историй, которые ближе всего к завершению, а затем перемещаться назад по горизонтали по состояниям рабочего процесса, обсуждая каждую критическую историю. Это может быть плавательная дорожка, определяемая вашими классами обслуживания. После того, как все критические истории будут освещены, вы можете перейти к следующему высшему классу обслуживания, наиболее близкому к завершению.
Преимущества такого метода управления работой:
- Сокращает микроуправление
- Сокращает время, затрачиваемое каждым инженером
- Лучше масштабируется по мере роста команды
- Сокращает время выполнения заказа и время цикла
- Привлекает внимание к самой важной работе
- Направляет внимание на завершение работы, а не на начало новой работы
- Повышает психологическую безопасность инженера
Коротко и мило: как всегда уложиться в 15 минут?
Если за 15 минут нужно охватить слишком много вопросов (или вы ищете альтернативные способы беседы), вам следует:
- Просто остановитесь, когда время истекло. Имеет ли значение, если мы покрываем всю работу каждый день? Не всем нужно говорить каждый день. Вы всегда можете оставить несколько минут в конце для открытого форума, если это необходимо, или беспокоитесь о том, чтобы все голоса были услышаны.
- Внедрите ограничения WIP (Work In Progress) или пересмотрите существующие ограничения. По сути, просто «ПРЕКРАТИТЕ ДОБАВЛЯТЬ НОВУЮ РАБОТУ НА ДОСКУ!»
- Посмотрите на устаревающие рабочие элементы (элементы, вызывающие увеличение нашего цикла или времени выполнения).
- Состояния рабочего процесса, вызывающие узкие места.
- Откажитесь от работы, которая больше не актуальна.
Стоячие антипаттерны
- Ответственность несет команда, а не человек.
- Большинство тикет-инструментов, таких как Jira, поощряют разрозненную работу, позволяя назначать истории только одному инженеру. Не попадайтесь в эту ловушку. Каждая история принадлежит команде.
- Не используйте в качестве мыльницы или ретроспективы.
- Не решайте проблемы во время звонка, найдите, кто может помочь, и обсудите после звонка.
- Доска должна быть обновлена ДО собрания. Встреча не для обновления доски.
- Каждый инженер по очереди дает обновления.
- Превышение отведенного времени.
Это способ освободиться от оков обыденной рутины и принять новый подход, который активизирует совместную работу, стимулирует мотивацию и способствует прогрессу.
Смещая наше внимание с наблюдения за работником на наблюдение за работой, мы можем произвести революцию в стендапе и возродить его цель.
Поэтому я прошу вас перейти к заданию ОДНОГО вопроса: «Что мешает команде перевести рабочий элемент с наивысшим приоритетом в следующее состояние рабочего процесса?»
Если вы зашли так далеко, я был бы признателен, если бы вы подписались на меня!
Если вы все еще не уверены, вы можете прочитать другие мои статьи, такие как:
