Разбор Scrum и Kanban. Что выбрать?

Scrum — быстрая разработка сырых User Stories.
Kanban–медленная разработка проработанных User Stories.

Немного утрировано, но так легче разобраться, когда лучше использовать Scrum, а когда Kanban. Оба Agile подхода позволяют гибко управлять созданием и развитием продукта, но отличий у них намного больше.

Дисклеймер: мною написанный текст лишь мое собственное мнение и он не претендует на истину. Статья появилась на основе интервью в продуктовых командах и в процессе создания и развития продуктов по Scrum и по Kanban.

Моя цель — прояснить ситуацию с двумя подходами, помочь вам сэкономить время и сделать правильный выбор.

Мы не будем рассматривать все ритуалы Scrum и Kanban. Но исследуем почему применить Scrum удается не всем, и почему чаще всего лучше использовать Kanban.

Если даже один ритуал фреймворка не выполняется — это уже не Scrum. Да, в жизни идеальных условий не бывает, но ритуалы придумали не для галочки. Kanban не такой требовательный, и поэтому легче прижился в продуктовых командах. В то же время, Scrum более модный, и в желании не отставать от трендов появился народный SсrumBan (Scrum + Kanban).

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

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

Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Процесс примерно такой:
— оценка US и запуск спринта;
— разбивка US на задачи;
— ежедневные встречи (Stand up);
— фиксирование скорости команды (в Story Points);
— уточнение бэклога продукта;
— релиз (выпуск обновленного продукта);
— обзор спринта;
— ретроспектива.
Мы не тратим время на блок-схемы и на согласования, но тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.

Да, задачи не согласованы и не проработаны так тщательно, как, например, в Kanban. Но мы потратили всего 2 недели. Даже если ошиблись с гипотезой (что часто бывает), мы не растягивали процесс во времени и обошлись ресурсами небольшой команды (Product Owner, Scrum Master, Dev team).

Работа по Scrum это бесконечный процесс формирования и валидирования гипотез. Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Тем лучше это будет сказываться на продукте.

Шагая в неизвестность, необходимо устранять любые неопределенности, например: скорость команды. Нам важно знать когда мы сделаем обновление продукта и когда соберем обратную связь. Если в итоге гипотеза окажется неверна, будет поздно. Поэтому мы добросовестно выполняем все ритуалы. Например Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе, чтобы в следующем спринте равномернее закрывать задачи. В таком ритме это жизненно необходимо.

Подробнее о фреймворке Scrum здесь

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

Один цикл, от поступления задачи до ее выпуска на продуктиве, может затрагивать широкий круг специалистов из разных команд:
— анализ и разработка блок-схем;
— согласование со всеми заинтересованными лицами (ЗЛ);
— UX/UI дизайн;
— backend разработка;
— frontend разработка;
— тестирование;
— доработка;
— релиз (выпуск обновленного продукта).
Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Например: скопилось много задач по дизайну, и разработчики сидят без дела, скорей всего команде нужны еще дизайнеры. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать. Это сделает процесс еще прозрачнее и разработчики не будут тратить время на переключение с одного таска на другой.

В Kanban тоже есть свои ритуалы, но они не такие ресурсоемкие. Сбор метрик и обратная связь от пользователей важны, но не настолько критично как в Scrum. Ваш заказчик может быть одновременно пользователем вашего продукта. Если весь цикл вы согласовывали с ним каждый шаг, будет странным если завтра он попросит все переделать.

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

В крупных компаниях руководство или заказчики требуют список задач на месяцы вперед. Если вы делаете продукт на внешний рынок и используете Scrum, то ваш список задач может выглядеть примерно так:
— Увеличить Retention на x% к дате n;
— Повысить NPS на x значений к дате n;
— Повысить LTV на x% к дате n.

Подробнее о полезных метриках здесь

Чувствуете как непросто принять фактически отсутствие плана? Если мы будем прописывать конкретные задачи и функционал, мы сами себя ограничим. Что важнее, сделать продукт с набором функций или продукт, который достигает product/market fit? Когда клиенты выстраиваются в очередь. Небольшое изменение в фокусе и вы уже создаете не функции, а продукт с конкурентными преимуществами, соответствующий потребностям рынка.

Подробнее о product/market fit здесь.

Никаких конкретных задач, только улучшение показателей продукта, потому что каждые 2 недели вы будете пересматривать бэклог опираясь на полученные данные. Стратегическая цель от этого не меняется — улучшить метрики и повысить лояльность ваших пользователей. А что может быть важнее? Тем более когда вы выпускаете сырые US на продукте. Да, мы будем проводить интервью с потенциальными клиентами перед началом работ, но окончательную точку, в отношении вашей гипотезы поставят только метрики продукта и обратная связь пользователей.

Если вы решились идти по Scrum, помните, что команда должна быть кросс-функциональной. Компетенций должно быть достаточно для выполнения полного объема работ с минимальным привлечением сторонних команд. Полное погружение в один продукт/сервис/проект. Иначе не получиться давать оценку US в Story Points и фиксировать скорость, так как вы отвечаете только за часть функционала. Не сможете контролировать время выхода релиза и вовремя получать данные. Обычно это приводит к скоплению не проработанных и не проверенных US в продукте, и к его закрытию в итоге.

Если все же сомневаетесь, ниже список из 10 пунктов, когда Scrum, скорей всего не подойдет:

1. Команда не видит смысла в некоторых ритуалах Scrum.

2. Команда не кросс-функциональна, выполняет только часть US.

3. Не настроены метрики продукта (Retention и LTV) или настроены, но не анализируются (если продукт ориентирован на внешний рынок).

4. Product Owner самостоятельно или совместно с заказчиком принимает решение куда развивать продукт не опираясь на обратную связь от пользователей и анализ метрик продукта (если продукт ориентирован на внешний рынок).

5. В текущий спринт вам постоянно подкидывают новые задачи.

6. Роли не зафиксированы, и каждый участник команды может выполнять не одну роль.

7. Команда работает над двумя и более продуктами.

8. Команда не фиксирует скорость, не анализирует Burn Down Chart и вообще не видит в этом смысла.

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

10. Road map в виде конкретных задач, а не в виде улучшения показателей продуктовых метрик.

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

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

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

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

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

Неважно, что вы используете, главное не отчаиваться, если с первого раза у вас не получилось. Оба подхода предназначены для того, чтобы спринт за спринтом (Scrum) или цикл за циклом (Kanban) совершенствовать применение. Исключением является ScrumBan, где происходит топтание на месте, с небольшими отклонениями то в сторону Scrum, то в сторону Kanban.