Избегайте 100% использования и включите Flow внутри и вокруг команд

«Осуществление процесса разработки продукта почти на полную мощность - это экономическая катастрофа».

Дон Рейнертсен

Введение: катастрофа 100% использования

Вот вопрос к Scrum-командам: когда вы планируете свои спринты, какой процент емкости вы загружаете в свой бэклог итераций: это «полный объем»? Если да, я настоятельно рекомендую вам подумать еще раз.

Планирование спринтов, полностью загруженных и загруженных на 100%, предотвращает гибкость по двум важным причинам.

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

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

Чтобы понять, почему это так, представьте, что движение на загруженной автомагистрали / шоссе заблокировано. Пропускная способность автострады загружена на 100%! Это полная эффективность? Конечно, нет.

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

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

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

Скорость

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

Во-первых, разберитесь со скоростью команды: сколько работы вы в среднем делаете в каждом спринте? Это хорошая отправная точка. Среднее число последних x спринтов - хорошее практическое правило: я предлагаю 3 или 4 ваших последних спринта. Определите среднее количество доставленных предметов или сумму набранных очков: все, что лучше всего подходит для вашей команды.

Емкость и как мы ее используем

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

Сколько работы по каждому виду мы должны выполнять? На высоком уровне здесь нам нужно согласие, и заинтересованные стороны команды должны поддерживать наш выбор. Владелец продукта: команде Scrum нужна ваша помощь. Скрам-мастер: помогите здесь, где можете.

Распределены ли наши мощности 50/50 или это что-то еще? Рассмотрение работы поддержки как «неизвестного» придаст спринту некоторую гибкость. Если мы знаем, что примерно 20% нашей работы тратим на срочные запросы поддержки извне, нам нужно выделить для этого ресурсы и использовать методы Канбан, чтобы помочь нам управлять этой работой, когда она поступает в систему. Мы не можем планировать рабочие элементы, но можем выделить ресурсы, чтобы обеспечить гибкость. Это поможет повысить гибкость итераций и позволит сотрудничать с другими командами.

Гибкость

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

Вот ключевой момент: не начинайте итерацию, если загружено более 80% вашей мощности. Такое планирование оставляет пространство для маневра внутри команды.

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

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

Поток

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

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

Преимущества

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

Один из рисков такого подхода: нам нужно обещать меньше в краткосрочной перспективе. Владелец продукта: нам нужна ваша помощь и поддержка в этом вопросе!

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

Мы станем более предсказуемыми и надежными для наших клиентов и заинтересованных сторон. Также мы будем способствовать более частой сдаче иждивенцев. Скрам-команда не будет постоянно находиться в «горячем состоянии». Он должен чувствовать себя лучше.

Закрывать

Прежде чем закончить, я хочу поблагодарить troy.magennis и Дона Рейнертсена, которые сильно повлияли на этот пост. Попробуйте здесь, чтобы получить отличную презентацию Трои, или здесь, чтобы получить чрезвычайно влиятельную книгу Дона Райнерсцена.

Я также сделал видео в поддержку этого сообщения на Vimeo (спасибо Марти де Йонге, Скотту Ричардсу и Марии Чек за все ценные отзывы, которые помогут отточить видео и вывести меня из моей зоны комфорта!).

В заключение позвольте мне внести ясность: не планируйте спринты на 100%!

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

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

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

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