Scrum или Kanban: не нужно выбирать, лучше дополнять

Как команде разработки внедрить скрам-процессы и улучшить их с помощью инструментов Kanban.

Когда лид команды решает внедрить Agile, у него появляется естественный вопрос: что выбрать — Scrum или Kanban? Выбор в пользу того или иного подхода всегда основан на контексте проекта: какие у него цели и особенности, какие возможности есть у команды. Но подходы могут дополнять друг друга — и можно не выбирать, а объединить их. Командам разработки ближе Scrum. Расскажем, как внедрить его, а затем улучшить с помощью инструментов Канбан-метода.

В подготовке текста нам помогала Арина Барлова, сертифицированный проектный менеджер с общим опытом более 10 лет, а в IT в роли проджект-менеджера и бизнес-аналитика — больше 6,5 года. Про управление проектами она рассказывает в своем блоге.

Scrum — фреймворк для организации процессов, целью которых является создание ценности (продукта) и адаптивное решение комплексных проблем. Чаще используется в высокотехнологичных и IT-стартапах, когда компания разрабатывает инновационный продукт, например мобильное приложение.

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

Фундаментальная в Scrum единица — спринт. Это промежуток времени, чаще всего две недели, в течение которого команда должна прийти к запланированному результату.

Вокруг спринтов выстроена система, призванная обеспечить эффективность работы:

Чтобы внедрить и использовать фреймворк, нужно:

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

2. Собрать кросс-функциональную команду. Это команда взаимозаменяемых и дополняемых специалистов, от трех до семи человек. Перед разработкой их не нужно ограничивать в способах достижения поставленных целей, но надо обозначить, что должно получиться на выходе, и помочь самоорганизоваться.

3. Выделить Scrum-мастера. У него нет полномочий относительно продукта, и он не может принимать решения за команду или отдельных ее участников. Задача Scrum-мастера — помогать команде работать с этим фреймворком, соблюдать церемонии (события) и фасилитировать командную работу.

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

5. Обучить основам работы по Scrum. Обучить нужно саму команду, а заказчикам и всему окружению презентовать ее порядок работы, чтобы минимизировать влияние на команду извне.

Scrum помогает сформировать каркас рабочего процесса, когда команда точно понимает, какую часть работы и в какие сроки должна выполнить. Но здесь могут возникнуть две проблемы:

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

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

Наладить Scrum-процессы помогут следующие Канбан-практики:

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

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

Так Kanban помогает реализовать требование прозрачности в Scrum: появляющиеся процесс и работа должны быть видны и тем, кто выполняет работу, и тем, кто получает результаты. Метод помогает провести инспекцию текущих процессов.

2. Ограничить незавершенную работу. Когда задачи визуализированы, становится понятно, что чем больше задач берет в работу команда, тем меньше она успевает. Важно не допускать концентрации большого количества дел на одном этапе — здесь помогают work in progress limits (WIP-лимиты). Такие лимиты могут быть установлены на основании метрики Velocity, которую чаще рассматривают в Scrum. С ними, пока текущие задачи не выполнены, новые не могут поступить. Принудительное ограничение работы до момента выполнения всех застрявших задач поможет начать новый спринт с более жесткими ограничениями на лимит задач и более правильным пониманием загрузки команды. Это позволяет команде сосредоточиться на доведении своих дел до конца.

3. Управлять потоком работы. Эта практика про устранение узких мест, главная ее цель — уменьшить время производства продукта, при этом непрерывно поставлять ценность. Нужно разобраться с текущими заблокированными задачами, а для этого снять метрики:

Когда картина становится понятна, для каждого процесса подбирается свое решение.

Например, в компании отдел разработки выполняет мало задач — половина из них находятся в статусе «В ожидании». Кажется, что нужно накидывать разработчикам больше задач, но после снятия метрик становится понятно, что сама разработка (Cycle Time) занимает всего 30% времени в общем Lead Time, а зависают задачи в отделе аналитики. Это узкое место. При этом разработчики, чтобы не простаивать, принимают сырые задачи от менеджеров и постоянно возвращаются к аналитикам, забивая и без того узкое горлышко. Решить ситуацию поможет выделение Discovery-цикла в отдельный процесс. Им занимаются аналитики. Он должен работать вне системы спринтов, а в потоке и поставлять свои задачи к моменту актуализации бэклога продукта и спринта.

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

5. Регулярно устраивать обмен обратной связью. В Канбан-методе в этом помогают каденции — регулярные командные встречи, обязательные ритуалы, которые формируют цикл по сбору обратной связи на всех уровнях. Цель встреч заключается в том, чтобы проанализировать данные о рабочем процессе, выделить системные проблемы и принять управленческие решения.

Так Scrum, обрастая техниками из Канбан-метода, превращается в Scrumban.

В перспективе улучшение Scrum-процесса приводит к тому, что:

В идеальной ситуации у топ-менеджмента появляется доска, которая отражает стратегическое портфолио компании. Это уровень, на котором движутся элементы стратегии: что компания делает сейчас, за счет чего ей расти. На этой доске происходит разделение на два типа:

Поделитесь в комментариях, есть ли в вашей компании опыт использования Scrum или Kanban и пробовали ли дополнять один подход инструментами другого?