Что делает Agile Coach, когда ретро идут, а релизы срываются

Ретро идут, доски висят, а релизы срываются так же, как в январе. Через три месяца после найма Agile Coach руководитель направления спрашивает, за что компания платит. Коуч при этом может работать честно. Вокруг роли Agile Coach много путаницы, и компания часто сама не знает, что купила.

Для одних это почти «старший Scrum Master». Для других внутренний консультант по трансформации. Третьи ждут человека, который проводит ретроспективы, следит за доской и уговаривает команды делать daily. Где-то роль висит между HR, delivery и руководством без внятного набора обязанностей. Отсюда две крайности: коуча сводят к «хранителю ритуалов» или ждут, что он в одиночку починит всю систему. Обе мешают понять, за что ему платят.

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

Главное слово в названии действительно «coach». Он не командует и не делает работу за команду. Он помогает команде и руководителям научиться работать лучше. Так, чтобы это держалось и после его ухода. Следить за выполнением задач в его работу не входит.

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

Узкое место одной команды почти всегда растет из того, как вокруг нее устроены приоритеты и зависимости. Лечить его только внутри команды бесполезно: проблема просто переедет к соседям. Коуч нужен, чтобы увидеть картину целиком и понять, откуда проблема берется.

Роль появляется, когда рост ломает старую координацию

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

Потом команд становится больше, и число связей между ними растет быстрее самих команд. У трех команд три возможные пары, у восьми уже двадцать восемь: пары считаются как n(n-1)/2, то есть почти квадратично. Каждая пара означает общий релиз, очередь согласований или спор о приоритетах.

Старые способы координации в этот момент ломаются. То, что раньше решалось одним разговором, требует трех встреч. То, что было понятно интуитивно, требует явных правил. А то, что казалось «нормальной гибкостью», превращается в хаос из параллельных задач, срочных вбросов и неясных приоритетов.

Цену этого хаоса видно, если разложить жизнь одной задачи. Допустим, чистой работы в ней на три дня, а от взятия в работу до релиза проходит пятнадцать. Двенадцать дней задача ждет: ревью, согласования юристов, свободного тестировщика, окна релиза. Эффективность потока здесь 3 / 15 = 20%, и для команд с большим количеством передач это скорее обычная картина, чем исключение. Ускорять людей в такой системе почти бесполезно: даже если работа пойдет вдвое быстрее, задача пройдет путь за 13,5 дня вместо пятнадцати.

Компании обычно лечат это ритуалами. Внедряют Scrum или Kanban-доски, начинают считать velocity, нанимают Scrum Master и ждут, что система соберется сама. Если до этого было совсем пусто, это помогает. Чаще эффект ограничен.

Церемонии появляются, а команды по-прежнему тащат много задач сразу, разработчики страдают от переключений, бизнес жалуется на скорость. Так выглядит «театр Agile»: снаружи модель правильная, а качество решений и потока почти не меняется.

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

Вот здесь и появляется реальная потребность в Agile Coach. Не как в человеке, который еще раз объяснит, как устроен Scrum, а как в специалисте, который видит, где именно система перестает работать, и помогает организации научиться это исправлять. Компании уже мало просто знать практики. Ей нужно связать людей, поток, метрики и решения руководителей в одну рабочую систему.

Что становится лучше благодаря коучу

Роль проще всего понять через один вопрос: что в системе стало лучше благодаря его работе? Ответ «команда начала делать daily» слишком слабый. Ответ «команда держит в работе вдвое меньше задач, сама замечает пробки и договаривается с бизнесом о приоритетах без эскалаций» уже описывает суть.

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

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

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

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

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

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

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

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

Scrum Master отвечает за команду, менеджер проекта за план, коуч за систему

Scrum Master и коуча путают чаще всего, и понятно почему. Обе работают с командами, обе говорят про самоорганизацию, препятствия и прозрачность. Разница в масштабе и в том, к чему привязана работа.

Scrum Master отвечает за то, насколько хорошо работает его Scrum-команда. На бумаге у него есть обязанности и перед организацией, например учить ее Scrum и убирать барьеры между заказчиками и командами. В жизни его день почти целиком уходит на одну команду или небольшой контур, а набор инструментов задает сам Scrum: события, артефакты, работа с Product Owner, снятие препятствий (impediments).

Agile Coach к фреймворку не привязан. Он может работать сразу с пятью командами, их руководителями и межкомандными зависимостями и выбирать между Scrum, Kanban и смешанной моделью по контексту. Scrum Master делает команду сильнее внутри текущей модели. Коуч ищет ограничения, которые лежат выше команды, и помогает их снять.

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

Называть коуча «старшим Scrum Master» поэтому неверно. Из одной роли действительно можно вырасти в другую, но тип работы меняется. Если это различие упустить, от коуча ждут командной рутины и разочаровываются раньше, чем он успеет что-то изменить. В небольшой компании опытный Scrum Master вполне может взять на себя коучинг нескольких команд, но только с явным мандатом: правом приходить к руководителям с системными вопросами и временем, освобожденным от своей команды.

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

Рядом с менеджером проекта (project или delivery manager) роль коуча кажется странной: он вроде бы ничем не управляет. Delivery-менеджер отвечает за то, чтобы нужный объем вышел в срок. Он следит за рисками, зависимостями и обязательствами и поднимает проблемы наверх. В сложных проектах это сильная и нужная роль, и вся она строится вокруг выполнения плана.

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

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

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

Три роли рядом: кто за что отвечает

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

Строка «признак успеха» подсказывает, за что спрашивать с Agile Coach: за то, насколько реже поставка ломается без ручного вмешательства. Сданный в срок объем остается зоной delivery-менеджера, и спасать сроки коучу не положено.

С командой коуч начинает с наблюдения

Первые две-три недели в новой команде сильный коуч в основном смотрит. Как люди на самом деле планируют и берут работу? Что происходит на daily: управление потоком или статус-театр? Насколько безопасно спорить? Понимают ли люди, зачем делают именно эти задачи? Где работа застревает при переходе между ролями?

Без такой диагностики коуч превращается в переносчика рецептов. Фраза «вам нужен Scrum» в первый день почти всегда ошибка. Боль бывает очень разной. Иногда это пробка в тестировании, иногда отсутствие Definition of Done или постоянные срочные вбросы сверху. Бывает, что команда много делает, но не знает, что считается успехом. А бывает, что в ней копится конфликт, который тормозит поток сильнее любого процесса.

Потом начинается собственно коучинг. Коуч помогает команде договориться о нескольких вещах:

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

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

Отдельная тема: события. Daily, planning, review и ретро существуют ради решений по работе. Daily, превратившийся в статус-митинг, и ретро, где жалуются без последствий, ничего не дают. Коуч возвращает им смысл. С ретро команда уходит с одним изменением, которое действительно внедрит. На planning формулирует цель итерации вместо набора случайных задач. На review после показа инкремента обсуждает, какой сигнал ценности ждет после релиза.

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

Хорошая фасилитация оставляет проверяемое решение

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

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

Коуч в таких ситуациях строит разговор так, чтобы ответ родился внутри системы. Это ретро, где команда наконец обсуждает причины вместо симптомов. Это разбор инцидента без поиска виноватых (blameless postmortem), где разбирают причинную цепочку.

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

На приоритизации это выглядит так. Пусть три инициативы спорят за одну команду. Первая приносит, по оценке бизнеса, 30 тысяч в неделю и занимает шесть недель. Вторая дает 10 тысяч в неделю и делается за одну. Третья дает 20 тысяч и занимает две.

Пока спорят мнения, побеждает самая крупная, первая. Коуч предлагает посчитать стоимость задержки, деленную на длительность (метод CD3, который описал Дональд Рейнертсен в книге «The Principles of Product Development Flow», 2009): у первой 30 / 6 = 5, у второй 10 / 1 = 10, у третьей 20 / 2 = 10.

Порядок меняется: сначала короткие вторая и третья, потом первая. За первые три недели команда отдает две инициативы, которые вместе приносят 30 тысяч в неделю, а крупная сдвигается всего на три недели. Важнее самих цифр то, что спор переехал с «чья задача важнее» на «где ошибочна оценка». Такой спор решается данными.

Работу фасилитатора поэтому оценивают по тому, что осталось после встречи: решение, эксперимент или правило, которое через месяц можно проверить. Два часа восьми участников стоят шестнадцать человеко-часов. Если после такой сессии проверять нечего, встреча обошлась дорого и ничего не дала.

Поток и его метрики первыми показывают вклад коуча

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

Именно здесь на первый план выходит Lean/Kanban-мышление. Дэвид Андерсон в книге «Kanban» (2010) сформулировал его исходный принцип: начать с того, что есть сейчас, визуализировать поток, ограничить незавершенную работу и менять систему небольшими шагами. Для коуча это родная логика. Объявлять, что с понедельника все живут по новому процессу, он не станет. Он ищет минимальное изменение, которое можно проверить быстро и безопасно.

Команда часто не замечает, как сильно ее тормозит параллельная работа, пока это не проявится на доске и в cycle time, то есть во времени от начала работы над задачей до ее готовности. Несколько команд могут годами срывать друг другу сроки просто потому, что вход в работу устроен без явных правил и без общего понимания загрузки. Иногда достаточно ввести WIP-лимиты, явные классы обслуживания или правило входа новой задачи, чтобы система заметно успокоилась.

Допустим, команда из пяти человек держит в работе пятнадцать задач и закрывает пять задач в неделю. Три величины здесь связаны простой арифметикой очереди: среднее время задачи в системе равно объему незавершенной работы, деленному на пропускную способность. Здесь это 15 / 5 = 3 недели. Большую часть этих трех недель задача ждет, хотя загрузка людей выглядит стопроцентной.

Теперь команда вводит WIP-лимит в шесть задач. Первые две недели кажется, что скорость упала: люди сидят без новой работы и помогают друг другу доводить начатое. Если пропускная способность осталась прежней, пять задач в неделю, среднее время прохождения падает до 6 / 5 = 1,2 недели, примерно до шести рабочих дней. Пока пропускная способность не меняется, единственный рычаг для сокращения cycle time лежит в WIP.

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

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

Коуча часто считают чисто «человеческой» ролью: атмосфера, коммуникация, встречи. Это слишком узко. Сильный коуч работает с цифрами постоянно, только кнутом они у него не становятся. Он использует их, чтобы понять систему.

Набор зависит от уровня:

• поток: lead time, cycle time, пропускная способность, доля заблокированной работы;
• качество: дефекты после релиза, инциденты, откаты, переоткрытые задачи;
• продукт: активация, вовлеченность, удержание, монетизация.

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

Здесь помогает подход North Star, который популяризировала компания Amplitude в своем North Star Playbook. Команда выбирает одну главную метрику ценности для клиента и несколько метрик, на которые влияет напрямую. Так коучу проще связать изменения в процессе с результатом. Ускорение само по себе ничего не дает, если команда по-прежнему выпускает объем без эффекта.

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

Неделя коуча на пять команд

Многим трудно представить эту работу в обычной неделе. Снаружи она выглядит либо как сплошные встречи, либо как абстрактная «трансформация». Примерно так раскладывается неделя коуча, который ведет пять команд и работает около сорока часов:

• 10-12 часов наблюдения: daily, refinement, доски, места, где застревают задачи;
• 6-8 часов встреч один на один с тимлидами, Product Owner и руководителем направления;
• 8-10 часов фасилитации: ретро, приоритизация, воркшоп по Definition of Done;
• 5-6 часов анализа потока и метрик, подготовки следующих экспериментов;
• оставшееся время на разговоры с руководством о системных ограничениях.

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

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

Коуч проваливается, когда занимает чужое место

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

Самая быстрая поломка случается, когда коуч получает формальную власть: оценивает людей, решает за них, административно требует «правильного поведения». Коучинг в этот момент заканчивается, хотя должность остается прежней. Люди начинают подстраиваться, им важнее выглядеть соответствующими, чем становиться сильнее. Чаще всего так бывает там, где от роли ждут быстрых результатов и втихую делают из нее инструмент контроля.

Противоположный перекос выглядит безобиднее. Коуч организует созвоны, напоминает про ретро, заполняет шаблоны, и со стороны кажется, что все при деле. Но секретарь ритуалов обслуживает церемонии, а команде нужно научиться пользоваться ими как инструментами. Через полгода такой «поддержки» ритуалы держатся только на нем. Проверить легко: отправьте коуча в отпуск на две недели и посмотрите, проведет ли команда ретро сама.

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

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

Коуч окупается с трех команд и общих релизов

У скептиков есть серьезный аргумент, и его стоит изложить честно. Коуч стоит денег, но сам ничего не производит. Его вклад трудно отделить от работы команды. Хорошие тимлиды с инженерной культурой давно умеют проводить ретро, ограничивать WIP и договариваться с бизнесом. Внешний человек со своим словарем, по этой логике, добавляет еще один слой встреч и размывает ответственность: если поток ускорился, непонятно, чья это заслуга.

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

Аргумент перестает работать, когда проблема пересекает границы команд. Тимлид отвечает за свою команду. Переписать правила входа в работу для соседей или убедить финансового директора сменить KPI он не может, а коуч с мандатом на всю систему может. Отсюда рабочее правило: если команд три и больше, у них общие релизы или общий бэклог, а локальные улучшения не держатся дольше квартала, коуч окупает свою ставку. Если хотя бы одно условие не выполнено, начните с тимлидов.

Окупаемость можно прикинуть заранее. Software Engineering Institute при Университете Карнеги-Меллон пересказывает оценку Джеральда Вайнберга из книги «Quality Software Management»: человек, который ведет два проекта одновременно, теряет на переключение около 20% времени, а при пяти проектах уже около 75%. По той же таблице три потока съедают около 40%. Это эвристика из опыта, контролируемым исследованием она не является, но порядок величины полезен.

Допустим, в пяти командах 35 человек, и двенадцать из них постоянно разрываются между тремя потоками работы. Потери: 12 × 0,4 = 4,8 ставки. Если WIP-лимиты и правило входа сократят параллельность до двух потоков, потери станут 12 × 0,2 = 2,4 ставки. Освобождаются 2,4 ставки, больше, чем стоит один коуч даже по цене сильного senior-специалиста. Числа здесь условные. Подставьте свои, и спор о вере в Agile превратится в обычный расчет.

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

Кроме этого правила, коуча стоит звать в четырех узнаваемых сюжетах.

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

Второй звучит как «Agile вроде внедрили», а эффекта нет. Церемонии идут, доски висят, роли назначены, но бизнес не чувствует ни скорости, ни качества, команды выгорают. Платить за очередное внедрение практик бессмысленно, их уже хватает. Не хватает связи между ними и реальными ограничениями: конфликтующими KPI, перегруженными согласованиями, правилами входа в работу, которых никто никогда не записывал.

Третий возникает при смене модели работы: переходе к продуктовой организации, к ориентации на outcomes, к PLG или North Star-логике, к автономным кросс-функциональным командам. Сами собой такие переходы идут плохо, потому что менять приходится одновременно руководство, метрики, поток и договоренности, а у каждой части свой владелец.

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

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

На собеседовании проверяйте мышление коуча

Agile-языком сегодня владеют многие, поэтому собеседование должно проверять, как кандидат думает.

Сильного кандидата выдает умение различать контекст. Кто говорит о Scrum и Kanban как о двух религиях, тот будет внедрять одну из них. Сильный коуч начинает с вопроса «что у вас болит и почему система так работает», а ваш фреймворк интересует его во вторую очередь. Он сам переводит разговор с церемоний на поток, ограничения и потери.

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

Лучше любых деклараций работают кейсы, рассказанные как причинный разбор без геройства: контекст, проблема, вмешательство, метрики до и после, что не сработало. Попросите назвать цифры. Кандидат, который говорит «lead time стал заметно короче» и не может сказать, с какого значения и до какого, скорее всего, его не измерял.

Несколько прямых вопросов быстро покажут уровень. Что вы делаете, когда команда формально живет по Scrum, но тащит двадцать задач одновременно? Как поймете, где проблема: в команде или в системе вокруг нее? Как связываете изменения процесса с продуктовыми метриками? Ответ на уровне практик звучит как список действий. Ответ на уровне системы начинается со встречных вопросов.

Сертификаты вроде ICAgile Certified Professional in Agile Coaching (ICP-ACC) или Certified Team Coach от Scrum Alliance показывают, что человек прошел обучение. Не больше. Кейс с цифрами говорит о нем куда больше любой корочки.

Первые 90 дней решают, продлевать ли контракт

Мандат без плана быстро превращается в «посмотрим, как пойдет». Рабочая раскладка на первый квартал выглядит так (сроки ориентировочные):

1. Недели 1-2: наблюдение и 8-10 коротких интервью с тимлидами, Product Owner и руководителями. На выходе базовые цифры: медианный lead time, число задач в работе на человека, число срочных вбросов за спринт.
2. Недели 3-6: один-два эксперимента в одной-двух командах, например WIP-лимит или правило входа новой задачи. Критерий успеха записывается до старта.
3. Недели 7-10: перенос сработавшего на остальные команды и работа с руководством над главным системным ограничением, которое нашлось на интервью.
4. Недели 11-13: разбор с заказчиком роли. Цифры сравниваются с базой, и принимается решение продолжать, менять фокус или сворачивать.

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

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

Первым сдвигается поток. Незавершенной работы меньше, lead time короче, разброс сроков уже. В примере с WIP-лимитом выше среднее время задачи падает с трех недель до шести рабочих дней. Все метрики сразу не вырастут, но команда и лидеры должны заметно лучше понимать, как устроена их работа.

Рядом с ускорением обязательно смотрите на качество: долю дефектов, найденных после релиза, или число переоткрытых задач. Если lead time упал вдвое, а дефектов стало больше, команда просто перестала доделывать работу. Еще один показатель, помягче: короткий ежемесячный опрос команды о перегрузке.

Вслед за потоком меняется характер разговоров. Посчитать это трудно, зато легко услышать. Вместо «кто виноват» и «почему опять все горит» звучат вопросы про гипотезу, риск, узкое место и эксперимент. Следом появляется связь с ценностью: команда видит, как ее способ работы влияет на продуктовые метрики и выручку.

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