Почему вокруг вопроса столько споров
Сама формулировка "Kanban это Agile?" часто ломается о то, что люди вкладывают в слово Agile разные значения:
- Agile как набор ценностей и принципов (мышление, культура, способ принятия решений).
- Agile как семейство методов (Scrum, XP, Kanban, Crystal и т.п., как ярлыки, по которым компании себя называют).
- Agile как "ритуалы" (спринты, дейлики, ретро), самый распространённый, но самый неточный взгляд.
Когда спорят люди из разных "словарей", получается классическое: один доказывает про ценности, другой про происхождение, третий про практики. Поэтому корректнее отвечать так: Канбан может быть Agile-подходом по сути, но не обязан им быть по форме.
Две вещи, без которых Канбан не Канбан
Раз спор упирается в определения, начать стоит с самого Канбана. Чтобы дальше не путать понятия, важно разделить Kanban-доску (визуализация задач) и Kanban-метод (управление потоком + ограничения + обратная связь + улучшения). Доску может вести любая команда в любом стиле, даже в классическом "водопаде", и это ещё не делает процесс Agile. Канбан-метод начинается там, где команда использует доску как инструмент управления потоком и контроля незавершённой работы. Канонические описания метода прямо подчёркивают ключевой механизм: Kanban требует ограничивать НЗР (незавершённую работу) и экспериментировать с настройками процесса, наблюдая влияние на время выполнения, качество и предсказуемость.
Признаки Agile без привязки к названию
От различия доски и метода перейдём к сути дела. Если отбросить ярлыки, любой подход можно проверить на признаки, которые обычно и делают работу Agile. Первый это короткая цепь обратной связи: команда регулярно получает сигнал "мы делаем правильное?" и "мы делаем это правильно?" и меняет курс на основе фактов. В Kanban это часто обеспечивается метриками реального времени, например lead time (время от согласованной точки поступления запроса до его завершения) и видимостью узких мест прямо на доске. Второй это pull вместо push: работа вытягивается командой по готовности, а не "проталкивается" извне без учёта пропускной способности; в канонических описаниях Kanban это прямо связывается и с Lean (JIT), и с Agile-практиками, где команда сама выбирает, когда и сколько работы брать.
Третий признак это управление незавершённой работой: меньше начатого значит больше законченного, а WIP-лимиты снижают переключение контекста и вскрывают пробки. Четвёртый это адаптация к изменениям без разрушения системы: условия поменялись, приоритеты корректируются так, чтобы система продолжала работать, а не рассыпалась от "срочного". В классической трактовке Kanban отмечается, что метод обычно позволяет реагировать быстрее, чем Scrum, что соотносится с ценностью Agile "реагирование на изменения важнее следования плану". Если эти признаки есть, по сути это Agile-способ работы, даже если никто не произносит слово "Agile".
Почему Канбан считают Agile
Эти признаки и объясняют, почему многие практики уверенно относят Канбан к Agile. Здесь важно не "к какому лагерю относить", а почему он считается Agile многими практиками. Во-первых, Kanban соответствует важным принципам Agile: канонические описания прямо говорят, что Scrum и Kanban "достаточно хорошо вписываются" в ценности и принципы Agile, приводя примеры pull/JIT, Kaizen и реагирования на изменения. То есть по "сердцевине", то есть адаптации, эмпирике и быстрой обратной связи, Kanban ведёт себя как Agile-подход.
Во-вторых, Kanban создаёт прозрачность и управляемость потока: узкие места видны не "по ощущениям", а буквально на доске: колонка переполнена, следующая пустая, и управление работой превращается из разговоров в наблюдаемую систему. В-третьих, метод встроенно поддерживает непрерывные улучшения. И Scrum, и Kanban эмпиричны: вы меняете процесс, смотрите, что получилось, и меняете снова. Канонический подход к Kanban исходит из того, что важна сама идея цепи обратной связи и экспериментов с процессом, в том числе через WIP-лимиты, а это очень "Agile" по смыслу: улучшать способ работы на основе фактов.
И почему кто-то говорит "не Agile"
Симметрично стоит разобрать и обратную позицию. Такая позиция тоже не взята с потолка: она обычно опирается на несколько тезисов. Первый: Канбан исторически сильнее связан с Lean, чем с "Agile-брендингом". Многие воспринимают его как продолжение Lean, теории ограничений и потокового мышления, и в канонических описаниях метода даже есть отдельный акцент на Kaizen и JIT, классические Lean-опоры. Отсюда позиция "Kanban это Lean, а Agile другое". Практически же в продуктовой разработке Lean и Agile часто переплетены, поэтому спор обычно терминологический.
Второй тезис: Kanban накладывает меньше ограничений и не задаёт "упаковку" процесса. Scrum более директивен (роли, спринты, обязательные события), тогда как Kanban задаёт меньше "обязательных элементов", оставляя больше параметров настройки; если человек считает, что Agile = "итерации + церемонии + роли", то Kanban действительно кажется "не Agile". Третий, ключевой практический контраргумент: Канбан можно внедрить как инструмент контроля, а не как способ обучения. Можно повесить доску, заставить всех таскать карточки, увеличить отчётность и получить "псевдо-Канбан", который не про самоорганизацию и улучшения, а про контроль. Такой процесс может выглядеть современно, но по сути будет далёк от Agile.
Как это применять без лагерей
Сведём обе позиции в одну рабочую рамку, без лагерей. В реальной практике чаще всего работает так: Kanban-метод совместим с Agile-мышлением и часто применяется как Agile-подход, но Kanban-доска сама по себе не делает работу Agile, а Kanban можно использовать и в не-Agile культуре, если цель только видимость и контроль, без эмпирики и улучшений. То есть вопрос не в названии, а в том, как именно применяется.
Поэтому корректный ответ, которым можно пользоваться в компании, звучит без философии и споров. Kanban это метод управления потоком. Он совместим с Agile и часто используется как Agile-подход, потому что поддерживает pull, эмпирические улучшения и адаптацию к изменениям. Если Kanban используется как система обучения и улучшений, это Agile по сути. Если Kanban это только доска и контроль, это не про Agile, даже если выглядит похоже.
Scrum и Kanban: два двигателя обратной связи и гибриды
Определившись с рамкой, полезно сравнить Kanban со Scrum как два разных двигателя обратной связи. Оба подхода эмпирические, но "двигают" изменения по-разному. Scrum опирается на обратную связь через фиксированные итерации: спринт это главный ритм, планирование → выполнение → обзор → улучшения. Kanban даёт обратную связь через поток и метрики реального времени и позволяет настроить цикл улучшений под частоту анализа метрик: слишком длинный цикл замедляет улучшения, а слишком короткий не даёт процессу стабилизироваться. На практике это означает, что Kanban часто удобнее там, где работа "неровная" и приоритеты меняются постоянно.
В жизни команды часто приходят к смешанным моделям, не из моды, а из прагматики. В классических описаниях упоминается, что и для Product Backlog в Scrum можно применять Kanban-подход: ограничивать размер и задавать правила приоритизации. Есть и обратная мысль: когда итерации становятся всё короче, команда по сути приближается к Kanban, а если речь заходит об итерациях меньше недели, можно отказаться от фиксированных итераций. Это не "правильно или неправильно", а способ подобрать механизм обратной связи под контекст.
Где Kanban заходит быстрее, а где Scrum
Из этого различия двигателей следует и разница в том, где каждый подход приживается быстрее. Есть тип работ, где Kanban обычно легче внедряется и быстрее даёт эффект. Это поддержка, инциденты и операционная разработка: когда приоритеты действительно меняются ежедневно, фиксированный объём работ на спринт становится нереалистичным, и классическая трактовка метода описывает характерный кейс, где менеджеры выбирают Kanban как логичную отправную точку именно потому, что приоритеты менялись каждый день, а спринты "не очень подходили". Хорошо ложится Kanban и там, где много входящих задач разного типа и размера: он позволяет явно настроить классы работ (пути на доске, правила выбора, SLA-логика), не ломая всё под одинаковый таймбокс. А когда на общую доску смотрят несколько команд, помогает то, что формат ежедневной встречи в Kanban часто более "доско-ориентированный" (фокус на узких местах) и лучше масштабируется на общий поток.
Обратная ситуация возникает там, где Scrum чаще даёт более быстрый порядок, особенно для новичков. Kanban оставляет больше свободы и требует зрелости в управлении процессом, тогда как Scrum, будучи более директивным, помогает командам без дисциплины научиться планировать и фиксировать цель короткого периода, договориться о "готово" и критериях качества и выстроить регулярные точки синхронизации. Канонические описания метода формулируют это прямо: Kanban накладывает меньше ограничений и даёт больше "ручек" настройки, и это может быть плюсом или минусом в зависимости от ситуации и знакомства с инструментом.
Быстрый тест: у вас Kanban как Agile или просто доска?
Чтобы перевести всё это из теории в практику, полезен быстрый тест. Проверить можно по пяти вопросам. Если на большинство ответ "да", то Kanban у вас живёт как Agile-подход.
- Есть ли явные WIP-лимиты хотя бы на одном этапе?
- Есть ли правила "как работа попадает в систему" и "как выбирается следующая"? (политики выбора)
- Смотрите ли вы хотя бы раз в 1-2 недели на lead time / cycle time / узкие места и меняете процесс на основе данных?
- Обсуждает ли команда ежедневную работу "от доски" (что застряло, где пробка), а не делает по кругу статус-отчёты?
- Появляются ли регулярные улучшения процесса, а не только "выполнение задач"?
Если ответы "нет", то чаще всего это "доска задач", а не Kanban-метод, и вопрос "Agile это или нет" становится бессмысленным, потому что нет главного: эмпирики и улучшений.
Что убивает Agile в Kanban и как починить за 2-4 недели
Если тест показал "просто доску", стоит разобрать, что именно убивает Agile в Kanban и как это вернуть. Метод перестаёт быть Agile по смыслу из-за нескольких типичных ошибок. Когда WIP-лимитов нет, потому что "мы и так справляемся", доска перестаёт выявлять пробки и превращается в каталог задач. Когда "срочное" не ограничено и expedite-поток бесконечный, система всегда в режиме пожара, и Agile-поведение не появляется: команда не учится, а выживает. Когда метрики смотрят "для отчёта", ничего не меняется, хотя в канонической трактовке Kanban подчёркивается ценность метрик реального времени и выбор длины цикла обратной связи под частоту улучшений. И наконец, Канбан иногда внедряют как "самый мягкий способ ничего не менять", чтобы избежать тяжёлых организационных разговоров о приоритетах, ответственности и ожиданиях стейкхолдеров; тогда доска появляется, а поведение остаётся прежним.
Развернуть это в обратную сторону можно без больших реформ, за 2-4 недели, только практическими шагами:
- Нарисовать реальный workflow, а не "To Do / Doing / Done".
- Поставить WIP-лимит на самый проблемный столбец (там, где очередь).
- Ввести короткую ежедневную синхронизацию "от доски": что застряло, что закрываем сегодня, где пробка.
- Начать смотреть lead time и фиксировать узкие места как основу для улучшений.
- Раз в неделю выбирать 1 изменение процесса и проверять, что оно поменяло в потоке.
Так Kanban становится не "стеной с карточками", а машиной обратной связи, а именно это и роднит его с Agile, потому что ценность всегда была не в самой доске, а в дисциплине наблюдать за потоком и менять его на основе фактов.