Автор: Майк Коун (оригинал: Mike Cohn)
Введение — сцена и контекст
Майк Коун начинает своё выступление с непринуждённого вступления: он шутит над тем, что вынужден стоять на синей коробке, поэтому будет ближе к тем, кто рядом. Это подчёркивает его формат — не лекция «с кафедры», а живой разговор с практиками, сталкивающимися с ежедневными операционными проблемами.
Тему он впервые подготовил в 2014 году и с тех пор неоднократно выступал с ней на конференциях и для корпоративных аудиторий. Накопленный практический опыт — поездки по компаниям, наблюдение за разными трансформациями (успешными и не очень) — стал основой его выводов.
Мы общаемся в Telegram канале - Канбан клуба - присоединяйся
Истоки: Манифест Agile и практики
Коун напоминает, что Манифест Agile возник не из воздуха: его создатели практиковали парное программирование, работали с заказчиком на месте (on‑site — заказчик на месте), регулярно демонстрировали рабочий тестируемый продукт. Эти практики легли в основу ценностей и принципов манифеста.
Ключевая мысль автора: за абстрактными ценностями стоит конкретная организационная модель — маленькая кросс‑функциональная команда, регулярно выпускающая инкремент ценности. Эта практическая конкретика часто теряется, и тогда организации сводят всё к лозунгам и ритуалам, но теряют способность действительно доставлять ценность.
Три перспективы на Agile: культура, практики, структура
По наблюдению Коуна, под «agile» могут пониматься три разные вещи:
- Культура — акцент на ценностях и изменениях мышления.
- Практики — набор ролей, церемоний и техник (TDD, парное программирование и т.п.).
- Структура — организационные конструкции, которые делают практики работоспособными: команды, бэклоги, Definition of Done.
Автор указывает, что попытки начать преобразование с культуры или с практик, рассчитывая, что структура образуется сама собой, обречены на провал. Без инфраструктуры (поле и ворот) «игра» не состоится.
Что понимает автор под «структурой»
Коун выделяет три проверяемых элемента структуры:
- Команда. Кросс‑функциональная и автономная, способная закрывать требуемый инкремент. В примерах из залов конференций он отмечает, что в больших аудиториях редко кто действительно формирует такие команды.
- Бэклог. Элементы должны соответствовать критериям INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable — Независимые, Переговорные, Ценные, Оцениваемые, Небольшие, Тестируемые): независимые, переговорные, ценные для заказчика, оценимые, небольшие и тестируемые. Бэклог, состоящий из размытых тем или чисто инженерных задач, бесполезен.
- Рабочее протестированное ПО (критерии готовности (DoD)). Готовность должна означать реальную готовность — задеплоено, протестировано, проверено заказчиком. Частичный кредит («90% готово») скрывает технический долг и создает «секретный» невидимый бэклог.
Без этих трёх элементов никакие ритуалы — стендапы или ретроспективы — не принесут бизнес‑выгоды.
Ясность, ответственность и измеримость — операционные принципы
Автор связывает эти понятия с мотивацией и предсказуемостью:
- Ясность — команда понимает, что строить.
- Ответственность — стабильная команда может брать на себя и держать обязательства.
- Измеримый прогресс — при оценённом бэклоге и строгом критерии готовности (DoD) становится возможна предсказуемость.
Коун часто обращается к идеям Дэна Пинка: autonomy, mastery, purpose — и показывает, что именно структура (бэклог, стабильная команда, критерии готовности (DoD)) даёт людям автономию, возможность мастерства и ощущение смысла.
Типичные препятствия в крупных организациях
Автор перечисляет практические барьеры:
- Матрица. Распыление специалистов по множеству проектов мешает формированию стабильных команд.
- Многочисленные зависимости. Платформы, общие сервисы, мейнфрейм — всё это создаёт очереди и блокировки.
- Технический долг и жёсткая связанность (tight coupling). Без декомпозиции архитектуры невозможно собрать команды, покрывающие весь стек.
- Неопределённость принятия решений. Когда никто не отвечает за приоритеты в пересекающихся областях, проекты стоят.
Коун называет пример CIO с большим стеком технологий и отмечает: когда отсутствует инкапсуляция, формирование автономных команд требует архитектурных изменений либо явного управления зависимостями.
Компас трансформации: четыре квадранта
Коун предлагает модель с осями «предсказуемость ↔ изменчивость» и «конвергенция ↔ эмпирическое возникновение решений». Из неё получаются четыре сценария:
- предсказуемо‑конвергентный — системы, ориентированные на выполнение плана; уместны для систем учёта и ядро банка.
- адаптивно‑эмергентный — подход бережливый стартап, ориентированный на эксперименты и быструю проверку гипотез.
- стихийный/героический режим — хаотичная «героическая» работа при попытке сохранить предсказуемость.
- адаптивно‑конвергентный — гибрид, позволяющий делать небольшие обязательства и при этом адаптироваться.
Коун констатирует: частая ошибка — запуск пилота в условиях Adaptive‑Emergent и попытка перенести практики на Predictive‑Convergent без устранения зависимостей — поэтому масштабирование не даёт результатов.
Теория трансформации и практический маршрут
Основной тезис Коуна: трансформация — это про формирование команд, качественные бэклоги и способность доставлять рабочее протестированное ПО. Всё остальное — управление, сети команд, метрики и инструменты.
Практические шаги, предлагаемые автором:
- Стабилизация. Создание «ядра» (экспедиция) команд, формирование бэклогов с учётом зависимостей, налаживание заблаговременное планирование и оркестрация там, где инкапсуляции нет.
- Снижение batch‑size. Перевод больших проектов на более мелкие релизы (год → полгода → квартал → 6 недель), что требует непрерывная интеграция и доставка, автоматизации тестирования и изменений в релиз‑менеджменте.
- Рефакторинг и декомпозиция. Переход к сервисной архитектуре, компонентизации и платформизация для уменьшения связности.
- Освобождение и масштабирование. По мере декомпозиции уменьшать оркестрация и давать автономию командам.
Для планирования Коун использует метафору «экспедиций» и «базовых лагерей»: взять группу из 10–15 команд и проводить их через этапы стабилизации, уменьшения партии, декомпозиции — это делает трансформацию прогнозируемой.
Тактические приёмы в реальности
Коун рекомендует ряд практических тактик:
- Бэклог‑отряд. Малый межфункциональный отряд (архитектор, продакт‑менеджер, аналитик), который занимается декомпозицией эпиков и подготовкой dependency‑aware бэклогов для нескольких команд.
- Компоненты и оркестрация. Пока инкапсуляции нет — оркестрация (релизный поезд, программное планирование) необходима.
- Критерии готовности (DoD) и «никакого частичного кредита». Автор предупреждает: частичная «готовность» маскирует технический долг.
- SAFe — масштабируемый фреймворк как планировочная обёртка. SAFe — масштабируемый фреймворк полезен, когда поток ценности инкапсулирован; если нет — SAFe — масштабируемый фреймворк покажет слабые места на масштабе.
Контракты и госзаказ: как работать в условиях ограничений
Коун подчёркивает, что при фиксированном контракте время и бюджет — не оценки, а ограничения. Тогда задача — оптимизировать вероятность соблюдения обязательств, разбивая эпики на минимально‑приемлемые элементы и делая компромиссы на уровне бэклога.
Роли и управление: менеджеры, владельцы продукта, скрам‑мастера
Автор отмечает, что менеджеры не исчезают — их роль смещается в сторону управления контекстом: приоритеты общих сервисов, ресурсы, архитектурные решения. Scrum Master остаётся важным фасилитатором, но если ему постоянно приходится «защищать» команду от системных проблем, это симптом того, что система требует изменений, а не временных защит.
Коун предлагает смотреть на роли как на функции: если функция выполнена (бэклог подготовлен, препятствия устранены, архитектура обеспечена) — формальный титул не так важен.
Метрики и экономическая логика
Трансформация должна быть измеримой и экономически обоснованной:
- Baseline (базовый уровень — исходные метрики): текущая скорость (скорость команды), lead time (время прохождения задачи — от запроса до доставки), частота релизов, % инкрементов по критериям готовности (DoD).
- Цели: сократить lead time (время прохождения задачи — от запроса до доставки), уменьшить объём незавершённой работы (WIP), увеличить частота релизов, повысить долю ценностных инкрементов.
- Экономика: оценка стоимости текущего состояния (латание багов, задержки) и ожидаемого эффекта от автоматизации и декомпозиции.
Руководству нужна дорожная карта с вехами и бюджетом: например, 6 месяцев на стабилизацию 2–3 потоков ценности; 9–12 месяцев на уменьшение batch‑size и автоматизацию; 12–24 месяца на рефакторинг ключевых платформ.
Типичные вопросы и ответы из аудитории
- «Как оперировать в условиях большой неопределённости?» — Коун: эмпирика важна, но до предоставления полной свободы командам нужно обеспечить стабильную платформу: инкапсуляцию и понятный бэклог.
- «Нужно ли изолировать часть компании?» — ответ: не обязательно изолировать, но стоит выделять вертикальные срезы, которые можно стабилизировать и масштабировать.
- «Куда идут менеджеры?» — менеджеры управляют контекстом: бюджетами, зависимостями, архитектурными инвестициями — их роль трансформируется.
Заключение: прагматичность как путь к устойчивому Agile
Коун утверждает: вера в ценности Agile — хороша, но недостаточна. Нельзя рассчитывать на магию «включи практики — и всё само произойдёт». Agile — это инженерная дисциплина организационной работы. Нужны инвестиции в структуру: стабильные команды, чистые бэклоги и строгий критерии готовности (DoD). Лишь тогда возникает долгосрочная предсказуемость и возможность масштаба.
Мы общаемся в Telegram канале - Канбан клуба - присоединяйся