8 причин хронического незавершения работы в Спринте

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

Системы, паттерны и структуры.

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

Поиск структуры.

Задача Скрам-мастера — в партнерстве с командой найти структуру, которая вызывает паттерн и изменить ее. Для этого Скрам-мастер может предложить команде использовать на Ретроспективе инструменты системного мышления:

  • Пять почему
  • Fishbone
  • Causal-Loop Diagrams(CLD)
  • Дерево реальности
  • Метод А3

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

Причина 1. Зависимости.

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

Причина 2. Давление.

Команда пытается взять в Спринт больше, чем может на самом деле. Не заканчивает и берет еще больше, чтобы нагнать упущенное. И так далее. Формируется порочный круг. Решение: Начать брать в Спринт меньше работы, но делать ее более качественно строго в соответствии с критериями готовности (DoD). Со временем команда выйдет на восходящую спираль и сможет делать больше. Этот паттерн называется “Team That Finish Early Accelerate Faster”.


Причина 3. PBI(s) недостаточно проработаны.

Это создает высокую вариабильность на входе в Спринт и, как результат, большой объем возникающей работы в Спринте. Решение: более качественное проведение PBR и усиление определения «ready». Этот паттерн называется “Definition of Ready” и я рекомендую командам иметь свой чек-лист, к которому они приводят элементы Бэклога Продукта перед каждым Спринтом.

Причина 4. Слабый DoD.

Большой объем Undone работы из прошлых Спринтов «прилетает» в самый неподходящий для этого момент. Решение: усиление DoD и стандартов качества.


Причина 5. Потеря фокуса в Спринте.

Команда в один момент времени работает над большим количеством фич. Это порождает мультизадачность, переключения и повышает время цикла (Cycle Time). Решение: Предложить техники и подходы для уменьшения Work In Progress (WIP), такие как парное программирование, mob-programming, swarming, Канбан и другие.

Причина 6. Большое количество дефектов.

Они «прилетают» из промышленной среды или других подразделений компании. Решение: усиление DoD, принятие политики Stop & Fix, усиление инженерных практик.

Причина 7. Работа с большим количеством прерываний.

К примеру, команда может заниматься поддержкой продукта и не иметь возможности целиком запланировать Бэклог Спринта на неделю вперед. Решение: резервирование части Спринт Бэклога под незапланированные задачи. Скрам прекрасно работает в средах с большим количеством прерываний. В этом случае команды берут совсем небольшой объем новой работы в Спринт и формулируют соответствующую Цель Спринта. Есть интересный паттерн “Illegitimus non Interruptus”, который описывает подобную динамику.

Причина 8. Слишком длинный Спринт.

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

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

Верю, что у вас все получится. Удачи!

Scrum ON!

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *