Чем Канбан отличается от Scrum, и причем тут Agile

Примерно в 2015-2017 годах создателями Канбан-метода было принято решение развивать концепцию Business Agility — в противовес понятию Agile. И с этого момента Канбан-метод начал позиционировать себя как альтернатива Agile-подходам, а не их часть

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

Рассмотрим основные различия между Kanban-методом и фреймворком Scrum с точки зрения смысла, назначения и практики применения этих подходов.

Разница с точки зрения смысла

Scrum — это готовое руководство о том, как организовать итеративно-инкрементальную разработку нового продукта. Есть даже инструкция, которая называется Scrum Guide. Все элементы Scrum взаимосвязаны друг с другом, и при реализации Scrum нельзя выбросить ничего из того, что указано в Scrum Guide.

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

Разница с точки зрения целей

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

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

---

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

Можно конечно начать с применения Канбан-метода в отдельно взятом подразделении и улучшить там рабочие процессы, но конечной целью Канбан-метода является улучшение рабочих процессов во всей компании, ради достижения Business Agility

Разница с точки зрения принятия решений

---

Разница в смысле встреч и способе их проведения

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

---

Например, на ежедневном митинге возле Канбан-доски собираются данные о блокерах, трудностях, ожиданиях, которые препятствуют свободному движению потока задач, и менеджер решает как перераспределить ресурсы, чтобы обеспечить завершение задач, которые ближе всего к завершению

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

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

По итогу каждой встречи менеджер сервиса получает информацию для дальнейшего улучшения рабочих процессов и принимает управленческие решения

Разница с точки зрения предусловий

Чтобы Scrum начал приносить пользу, нужно сделать многое:

• Выделить Владельца продукта — специального представителя бизнеса, который:
  • будет наделен полномочиями для самостоятельного принятия решений о том, как должен выглядеть продукт, 
  • несет ответственность за наполнение продукта действительно ценным для клиента функционалом
  • будет тесно взаимодействовать с командой разработки
• Выделить на 100% всех необходимых специалистов в кросс-функциональную  Scrum-команду, и договориться с их линейными руководителями, что теперь задачи этим специалистам может ставить только Владелец Продукта.
• Выделить Scrum-мастера, который будет заниматься развитием самоорганизации в Scrum-команде.
• При необходимости — поменять регламенты, чтобы Scrum-команда могла поставлять результат короткими итерациями (1-4 недели).
• При необходимости — выделить Scrum-команде свой контур инфраструктуры, чтобы они могли самостоятельно делать end-to-end разработку.
• Обучить основам работы по Scrum всех участников Scrum-команды, заказчиков и все окружение, в котором работает Scrum-команда

---

Чтобы Kanban-метод начал приносить пользу, достаточно обучить руководителя или менеджера Канбан-методу и сделать первые шаги: 

• визуализировать рабочий процесс по вашему сервису;
• сделать соответствующую Kanban-доску;
• разместить на ней все текущие работы;
• проанализировать положение вещей и принять управленческие решения.

Вы можете пойти дальше и использовать другие инструменты Kanban-метода: WIP-лимиты, метрики, управление потоком, каденции и т.д. Но можете этого и не делать. Решение полностью за вами. Когда будете готовы к этому, тогда и используйте.

Совместимость Kanban и Scrum

Может создаться впечатление, что Канбан-метод и фреймворк Scrum совершенно несовместимы, но это не так.

Все инструменты Kanban-метода можно применять при работе по Scrum: сбор метрик, ограничение одновременно выполняемой работы (WIP-лимит), визуализация и тд. Это может быть очень полезно, так как даст Scrum-команде больше возможностей чтобы делать свою работу лучше.

Примеры применимости Scrum и Kanban

Малая команда

Нет смысла пытаться работать по Scrum, когда у вас в команде лишь 1-2 человека, и больше никто не задействован в работе над продуктом. Scrum в такой ситуации будет явно избыточен. Два человека и так легко договорятся, и какого-то специального процесса для этого не требуется.

---

Канбан-метод будет работать даже для одного человека. Есть понятие «Персональный Канбан», когда, вы ведете свои каждодневные рабочие дела на персональной Канбан-доске. Вам всегда видно, что у вас находится в работе, по каким задачам есть вопросы и блокеры, что в какой стадии завершенности, на что следует обратить внимание. 

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

Чисто операционная деятельность

Другой пример, когда нет смысла пытаться применять Scrum — работа операторов call-центра. Потому что Scrum предполагает эксперименты, исследование и терпимость к ошибкам, а работа операторов, как правило, заключается в точном следовании “скрипту” ответов на звонки, с правильной маршрутизацией запроса звонящего. В этой ситуации Scrum ничего не даст, так как все поведение заранее определено и уложено в инструкции, которым просто надо следовать.

С другой стороны, можно собрать рабочую группу по улучшению этого “скрипта”, чтобы он мог охватывать нестандартные ситуации и по-прежнему приносил пользу. Тут появляется поле для исследования и экспериментов, и такая группа вполне может работать по Scrum. Такие примеры вы можете посмотреть в докладе Agile в операционном управлении.

---

Канбан-метод, при наличии соответствующих инструментов, можно применять и в работе операционистов call-центра. Будут определенные трудности с визуализацией потока входящих звонков, так как частота их поступления весьма велика. Но если это удастся сделать, то у менеджеров call-центра появится возможность собирать данные о статистике обработки запросов от клиентов, и увидеть:

• на каких запросах чаще всего возникают трудности, задержки, затруднения;
• на что нужно обратить внимание, чтобы обеспечить бесперебойное обслуживание потока звонков.

На основе этой информации руководитель call-центра может принять управленческие решения и оптимизировать рабочий процесс.

Scrum и Канбан на масштабе крупной компании

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

Однако есть и разница. 

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

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

Так как у каждой Scrum-команды своя собственная Scrum-доска и свой пул задач, то в процессе совместного движения нужны синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Scrum-мастера или Владельцы продуктов). Цель таких встреч — сделать прозрачным для всех текущий статус движения к общей цели, текущие проблемы и подсветить зависимости по которым надо принять решение. 

---

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

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

С другой стороны, на разных уровнях иерархии надо собирать разные данные.

На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.

На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.

На низовом уровне — отслеживать работу конкретного отдела (команды, рабочей группы) над конкретными задачами, входящими в проект.

Чтобы связать данные по всем этим уровням между собой, придется создавать иерархию Канбан-досок, которые будут связаны между собой по вертикали, от стратегического уровня до тактического и обратно. Чтобы обеспечить синхронный сбор данных, прозрачность и актуальное состояние Канбан-досок на каждом уровне, нужно будет проводить координационные встречи не только “по горизонтали”, но и “по вертикали”. 

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

Заключение

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

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