Когда команда хронически не завершает работу в Спринте, то это становится причиной фрустрации и разочарования для нее. Давайте обсудим, как можно помочь команде выйти на новый режим работы.
Системы, паттерны и структуры.
Команда Разработки является системой с общей целью и взаимозависимыми между собой элементами (разработчики). Если события в системе повторяются, то они становятся паттерном. За каждым паттерном скрывается подкрепляющая структура. В данном случае паттерн системы — хроническое незавершение задач в Спринте.
Поиск структуры.
Задача Скрам-мастера — в партнерстве с командой найти структуру, которая вызывает паттерн и изменить ее. Для этого Скрам-мастер может предложить команде использовать на Ретроспективе инструменты системного мышления:
- Пять почему
- 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. Слишком длинный Спринт.
Среда и рынок вокруг команды меняются слишком быстро. Возникают более важные задачи, чем те, которые лежат в Бэклоге Спринта. Решение: уменьшить длину Спринта. Вплоть до одного дня. Скрам-команды, работающие в стиле моб-программирования, часто пользуются однодневными Спринтами.
Подытоживая, скажу, что главная мысль статьи — ищите системные причины. Подход «виноват Скрам» не работает. Скрам это легко! Просто используйте его как есть! В этом случае проблемы останутся, их просто убирают с глаз долой. Отказ от Скрама или его частей не делает команду гибче и сильнее, а лишь сохраняет статус кво и снижает прозрачность.
Верю, что у вас все получится. Удачи!
