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

15 мар. 2019 г. 3 min read
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. Слишком длинный Спринт.

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

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

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

Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.