Почему вопрос «Канбан — это Agile?» сформулирован неудачно
«Канбан — это Agile или нет?» звучит как вопрос с ответом «да» или «нет». Его задают менеджеры, разработчики, Scrum Master и руководители, когда пытаются навести порядок в процессах и не утонуть в терминологии. Беда в том, что любой односложный ответ здесь вводит в заблуждение.
Путаница растёт из одной подмены: Agile воспринимают как набор фреймворков, а Канбан — как один из них. На деле Agile — это система ценностей и принципов, а Канбан — способ управлять потоком работы. Они пересекаются, но не совпадают. Попытка «записать» Канбан в Agile или, наоборот, вычеркнуть из него одинаково ломает смысл обоих понятий.
Когда инструментом подменяют причину
Стоит появиться проблемам с процессами, дедлайнами или перегрузом команд, и фокус смещается на выбор метода. Возникает версия: взяли не тот подход, Scrum вместо Канбана или наоборот. Канбан в этой логике подают как спасение и берут, потому что «Agile не работает», «Scrum не взлетел», «команда устала от спринтов». Что именно не работало и почему — почти не разбирают.
Здесь и прячется ошибка. Ни Agile, ни Канбан не лечат плохие управленческие решения. Если приоритеты скачут, цели туманны, а ответственность размыта, плохо будет выглядеть любой подход: и потоковый, и итеративный.
Проблема почти всегда системная, и Канбан обычно внедряют туда, где контур управления уже сломан: решения принимаются хаотично, работа постоянно прерывается, команды живут в режиме вечного «срочно». В такой среде Scrum действительно может не работать: спринты рвутся, планирование превращается в фикцию, ретроспективы теряют смысл. Канбан кажется честнее: он просто показывает хаос, не пытаясь структурировать его заранее. Но если им оправдывают отсутствие управления, он становится ширмой. Поток визуализирован, доска красивая, а система принятия решений прежняя — это уже не метод, а фиксация проблемы.
Где эксперимент, а где отказ что-либо менять
Ошибаться при выборе между Scrum, Канбаном и другими подходами неизбежно: контекст у каждой команды свой, универсально «правильного» ответа нет. Попробовать Канбан как эксперимент — нормальная ошибка: команда видит, что работа плохо укладывается в спринты, и пробует поток. Если это осознанный выбор с гипотезами и критериями успеха, из него выходит обучение.
Другое дело — брать Канбан, чтобы ничего не менять. Когда подход выбирают не ради улучшения системы, а чтобы уйти от сложных разговоров о приоритетах, ответственности и фокусе, он начинает вредить. Граница между рабочей ошибкой и имитацией проходит там, где Канбан называют Agile, не понимая, что за Agile стоит. Если ценности прозрачности, обратной связи и постоянного улучшения игнорируются, доской это не компенсировать: меняется расположение карточек, а не способ принимать решения. Рядом живёт слепое следование инструментам: WIP-лимиты есть, колонки есть, метрики считаются, а решения по-прежнему принимаются интуитивно или под давлением. И противоположная крайность — отвергать Канбан как «не Agile» из-за того, что в нём нет итераций и ролей: это выдаёт понимание Agile как набора ритуалов, а не принципов.
Как это проявляется в discovery, delivery и коммуникации
Чтобы понять, Agile ли Канбан в конкретной команде, надо смотреть не на термины, а на повседневную практику: как люди думают, принимают решения и реагируют на изменения. Полезно держать в поле зрения несколько сигналов:
- в discovery — готова ли команда пересматривать гипотезы и признавать неопределённость, или задачи приходят готовыми решениями, а discovery существует для галочки;
- в delivery — меняется ли поведение после того, как доска подсветила узкие места, или визуализация есть, а решения прежние;
- в коммуникации — превращается ли прозрачность в регулярную обратную связь и реальные изменения, или всем всё видно, но обсуждения ни к чему не приводят.
В discovery Agile-мышление — это готовность пересматривать гипотезы и признавать неопределённость. Канбан здесь нейтрален: сам по себе он не задаёт ритм discovery и ему не мешает. Если команда работает по Канбану, а discovery отсутствует или существует для галочки, виноват не Канбан, а фокус на выполнении задач вместо поиска ценности. Встроить discovery в поток и дать ему влиять на приоритеты вполне можно.
В delivery Канбан силён тем, что показывает реальное состояние системы: узкие места, очереди и перегрузки становятся видимыми. Но Agile начинается там, где команда пускает эту информацию в дело. Есть визуализация, а поведение не меняется — значит, перед вами просто доска задач. В Scrum улучшения зашиты в итерации, в Канбане они держатся на зрелости и дисциплине.
В коммуникации прозрачность Канбана снимает часть догадок и скрытых конфликтов: всем видно, что происходит и где работа застряла. Только Agile-коммуникация — это ещё и регулярная обратная связь. Если обсуждения ни к чему не приводят, прозрачность сама по себе Канбан в Agile не превращает. Разница не в формате, а в намерении и культуре.
Зрелость видно без слов
Зрелый Канбан редко ограничивается доской. В нём есть политики работы, явные правила приоритизации, договорённости о качестве и критериях завершения. Незрелость выдаёт себя, когда всё сводится к визуализации задач: колонки есть, а объяснить, почему работа движется именно так и что делать при перегрузе, никто не может. Способность системы адаптироваться — вот где видно Agile-мышление, и наличие спринтов тут ни при чём. Канбан на это способен, но не автоматически.
На чём спотыкаются при переходе на Канбан
Половина типичных провалов — про управление, и почти все узнаются с первого взгляда на доску:
- Канбан заводят как замену управлению: доска есть, а решения по-прежнему никто не принимает.
- Явных правил работы нет, поэтому непонятно, как задача попадает в поток и когда считается завершённой.
- WIP-лимиты игнорируют, и без ограничения незавершёнки поток превращается в обычный таск-трекер.
- Ownership размыт: за состояние системы в целом не отвечает никто.
- Побеждает культ скорости, при котором качество и ценность уходят на второй план.
Вторая половина — про непонимание сути. Канбан и Scrum смешивают без логики: спринты вроде есть, но WIP не соблюдается, и получают худшее от обоих. Качеством жертвуют ради движения карточек, обратную связь не собирают, от улучшений отказываются, оставляя доску как есть. И главное заблуждение, замыкающее список: вера, что Канбан сам по себе делает команду Agile. Не делает. Гибкость определяют решения, а не колонки.
Две фразы стоит держать как красные флаги. «У нас Канбан, поэтому планирование не нужно» — обычно это отсутствие стратегии; Канбан не отменяет необходимость думать о будущем. И «Канбан не Agile, поэтому ценности не важны» — так подход превращают в механический процесс без смысла.
Пример: переход со Scrum
Команда работала по Scrum и постоянно срывала спринты. Приоритеты менялись, бизнес вмешивался в середине итерации, люди выгорали. Scrum обвинили в негибкости и решили перейти на Канбан.
Спринты убрали, ввели доску и WIP-лимиты. Работа стала честнее: сразу стало видно, сколько всего висит в системе. Первые недели показали реальный масштаб перегруза: очереди росли, задачи зависали. Напряжение выросло, но появился и материал для разговора.
Дальше команда начала менять правила: ограничили входящий поток, договорились о приоритетах, пересмотрели ожидания бизнеса. Канбан стал инструментом изменений, а не просто доской. Параллельной работы стало меньше, качество и предсказуемость выросли. Agile-ценности начали реализовываться через Канбан, а не вопреки ему.
Пример: формальный Канбан без управления
В другой компании Канбан жил давно и формально числился «Agile-подходом». Доска настроена, задачи перемещаются, время цикла считается, руководство уверено, что команда работает гибко.
На практике команда сидела под постоянным давлением. В работу попадало всё, что казалось важным в моменте. WIP-лимиты нарушались «по исключению», и исключения быстро стали нормой. Поток визуализировался, но не управлялся. Discovery фактически не было: задачи приходили уже в виде готовых решений, а обсуждение улучшений сводилось к тому, как ускорить доставку, а не переосмыслить ценность.
Agile Coach начал не с доски, а с управленческого уровня. Помог зафиксировать политики входа работы, договориться о классах обслуживания, сделать приоритеты явными. Это встретило сопротивление: пришлось отказываться от части «срочных» задач. Постепенно поток стал стабильнее, команда начала завершать работу, а не накапливать её, появилось пространство разбирать причины задержек. Канбан не превратился в Scrum и не обзавёлся итерациями, но заработал в духе Agile: сменилось не название подхода, а качество управленческих решений.
Что стоит держать в голове
Проверить себя помогает несколько честных вопросов. Понимаем ли мы, зачем вообще используем Канбан, и есть ли явные правила входа работы и критерии завершения. Соблюдаются ли WIP-лимиты на практике, а не на бумаге, и есть ли у команды ownership за поток целиком. Используем ли мы данные о потоке для улучшений и понимаем ли причины задержек и возвратов, или метрики считаются, но на решения не влияют. И, наконец, обсуждаем ли мы ценность, а не только скорость, оставляем ли место для discovery рядом с delivery и меняется ли поведение системы благодаря Канбану. Если на большинство ответ отрицательный, доска есть, а Канбана — нет.
Сам по себе Канбан не Agile-фреймворк, но вполне может быть Agile по духу, потому что Agile задаётся ценностями, а не инструментами. Всё решает то, как именно им пользуются:
- ради прозрачности, адаптации и улучшений — он работает в Agile-парадигме; ломается в тот момент, когда доску заводят, а управление оставляют прежним;
- как способ управлять потоком рядом со Scrum — работает, когда оба метода понимают и WIP реально соблюдают; разваливается в гибрид «спринты есть, а незавершёнка не ограничена»;
- после неудачного Scrum — работает, если команда разбирается, почему Scrum внедряли формально, не трогая управленческий контекст; остаётся декорацией, если Канбан берут лишь на волне разочарования, за то, что он честнее и не прячет хаос за итерациями.
Противопоставлять Канбан и Scrum бессмысленно: они решают разные задачи. Scrum задаёт ритм и структуру, Канбан управляет потоком, и выбор на практике зависит от характера работы и зрелости системы, а не от идеологии. Быть Agile без Scrum можно: Scrum лишь один из способов реализовать принципы, и Канбан, XP и другие подходы тоже бывают Agile, если поддерживают адаптацию и ориентацию на ценность.
Гибче работу делает не сам Канбан, а управление потоком и ограничениями. WIP-лимиты здесь ключевые: без них поток не контролируется, а Канбан вырождается в таск-трекер: именно ограничение незавершёнки создаёт то напряжение, которое запускает улучшения. Сочетать его со Scrum можно, но только понимая оба: гибрид держится на ясных правилах, иначе выходит «спринты есть, а WIP не соблюдается». Для продуктовой разработки Канбан подходит, особенно при высокой неопределённости и нестабильном входящем потоке, но без discovery и работы с ценностью рискует зафиксировать неверный фокус — это инструмент, а не стратегия продукта. И к улучшениям он часто не приводит по простой причине: улучшения требуют решений, а не визуализации. Работающий Канбан всегда немного неудобен. Если доска есть, а разговоры и решения прежние, вопрос не в том, Agile ли Канбан, а в том, готовы ли вы принимать решения, которые он делает неизбежными. Именно это отличает живую систему от формальной.