Тринадцать записанных докладов на Global Agile Summit 2026, второй день

Отдельный материал посвящён четырём сессиям вопросов и ответов в режиме реального времени, которые я посетил на второй день. А это записанные сессии: тринадцать из них на четырёх параллельных треках плюс два кейноута, которые их обрамляли. Сессии вопросов и ответов показывают, что докладчики говорят без сценария; записанные доклады — это то, что они подготовили.

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

Брайан Мелчер — Создание самоуправляющейся организации: уроки Field Verified

Кейноут строительного трека. Брайан руководит Field Verified, консалтинговой и тестирующей компанией, специализирующейся на ограждающих конструкциях зданий в Аризоне. До Scrum: двенадцать сотрудников, пятнадцать процентов маржи, нулевой рост в 2021 году. После Scrum: тридцать сотрудников, тридцать пять — сорок процентов маржи, шестисопроцентный рост прибыли за три года. Он встретил Фелипе Энджинира-Манрикеса (первый день, строительный трек) в самый переломный момент, несколько дней на острове под Стокгольмом в доме одного из авторов по тематике lean, где формулировка Фелипе о Scrum дала ему название для того, что он и так уже наполовину делал.

Больше всего запомнилась неудача с lean в туалете. В Field Verified прочитали стандартную книгу, которая советует начинать внедрение lean с графика дежурств по уборке туалета. Попробовали — провалилось. Брайан перечитал книгу перед всей компанией и швырнул её себе через плечо. Сразу же люди открыто заговорили о том, что на самом деле не так. Именно публичный отказ от провальной инициативы и стал тем шагом, который имел значение. После этого каждое изменение, которое он пробовал, получало настоящую обратную связь, потому что люди теперь верили: он отсекает то, что не работает.

А ещё был плакат с набором инструментов. Они повесили на стену плакаты полиграфического качества с перечнем того, что входит в каждый набор. Наборы по-прежнему получались неправильными. В конце концов кто-то признался: опустить взгляд на набор, а затем поднять его на плакат — это было просто слишком большое усилие. Они уменьшили плакат, приклеили его изнутри на крышку ящика для инструментов — и проблема исчезла. Первоначальная lean-идея не сработала; реальное решение оказалось проще, чем идея.

Ещё одно: ежедневная листовка Брайана стала фильтром для найма. Кандидаты приходят, видят доску — и либо загораются, либо отстраняются. Ему больше не нужно никого убеждать. Доска убеждает сама, ещё до того, как он скажет хоть слово.

Для меня это относится к бэклогу исправления багов, над которым работает команда Product Support — меньший по масштабу, но тот же подход. Это также поднимает вопрос, что делать с ресурсами, когда ты их высвободил. Брайан решил добавить роли, которые улучшают качество жизни: видеооператор, графический дизайнер, директор по внутренним операциям, ежемесячные встречи по карьерному росту для каждого. Он не стал увеличивать пропускную способность. Это осознанный компромисс, и я хочу и дальше воспринимать его именно как компромисс, а не как стандартное решение.

Джейсон Литтл — Введение в должность ваших сотрудников, работающих с ИИ

Кейноут, ИИ-трек. Джейсон Литтл написал книгу «Lean Change Management». Он использует Claude для девяноста пяти процентов своей работы и собрал вокруг себя небольшую команду агентов, у каждого из которых одна обязанность: проектный менеджер, ведущий его Kanban-доску, агент по анализу настроения, агент по бренд-гайдлайнам, знающий его стиль-гайд и логотипы, оценщик, решающий, какие отзывы о курсах достаточно хороши, чтобы опубликовать их в качестве публичных отзывов.

Фраза, которая у меня засела, принадлежала Рэйчел Дженнавей, и Джейсон её процитировал: человек ведёт, а не находится в петле. Именно на этом разломе между двумя формулировками большинство внедрений ИИ либо выживает, либо гибнет. Макс Пьехота позже в тот же день сказал то же самое другими словами. То же самое и Пер Бейнинг.

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

Предупреждение Джейсона о выгорании — это та часть, которую большинство разработчиков пропускают. Если раньше я мог завершить пять дел за неделю, то теперь могу завершить пять тысяч. Я буду так же измотан. Когда узкое место смещается с написания кода на мышление, потолок производительности поднимается, но человек остаётся прежним. Чёткого ответа на это пока нет — ни у него, ни у кого-либо другого, о чём я читал.

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

Пер Бейнинг — От растерянности к уверенности: размышления после проведения Claude Code-буткемпа

ИИ-трек. Пер начал пользоваться Claude Code в январе 2026 года и провёл три набора по примерно тридцать пять человек через буткемп для начинающих. Предпосылка: большинство людей застряли где-то на континууме между «я хочу принять ИИ» и «я его боюсь», а выход из этого континуума — ежедневно выпускать что-то небольшое.

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

Пер завершил, включив интервью Дэвида Боуи на BBC Newsnight 1999 года: интернет — это не просто инструмент, это инопланетная форма жизни. Интервьюер, Джереми Паксман, никак не может как следует расслышать, что говорит Бови, а Бови не смягчает формулировку, чтобы она легче дошла до слушателя. Вывод Пера о том, что мы сейчас находимся в точно таком же положении, и в большинстве комнат полно Паксманов, а не Бови, вполне уместен. У меня была такая же реакция, когда в начале этого года я перестраивал поисковый модуль в своём новостном проекте о крупных кошачьих, заставляя ИИ выполнять работу, которую сам едва ли смог бы сделать за разумное время.

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

Лучший фильтр, чем «сэкономить время». Он обнажает истинный вопрос.

Анита Калмане-Бут — Нейроразнообразие в командах разработчиков ПО

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

Совет Аниты с тренинга: нанимайте ради культурного дополнения, а не культурного соответствия. Наем ради соответствия кажется безопасным и порождает однородные команды, которым не хватает когнитивного диапазона, который на самом деле требуется предметной области. Наем ради дополнения ставит более сложный вопрос — чего здесь не хватает, что этот человек мог бы дать. Последствия для вакансий конкретны. Конкурентная зарплата ничего не значит; дай диапазон. Гибрид ничего не значит; скажи, сколько дней. Фотографии офиса имеют значение, особенно если это open-plan, потому что для значительной доли кандидатов open-plan — это решающий минус, о котором никто не пишет в вакансии.

Её наблюдения о системе образования тоже бьют по больному месту. Школа приучает людей сидеть тихо, осваивать темы, которые их не интересуют, и вести себя так, как ведут себя остальные. Затем мы их нанимаем и просим быть самоуправляемыми. Это настоящее противоречие, которое большинство проектов по agile-трансформации скорее льстиво обходит стороной, чем решает.

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

Маркус Гьорт — От промпта до игры: создание ИИ-нативных игр с гибкостью

Игровой трек. Маркус — соучредитель и технический директор Bitmagic, веб-платформы, где ты описываешь игру в промптах и получаешь в результате 3D-игру. Он пишет код ещё со времён Commodore 64, с двухлетними перерывами между периодами программирования, которые он проводил в качестве Agile-коуча в финских компаниях — от небольших стартапов до Nokia. Коучинговый паттерн остается полезным, сказал он, даже когда ты сам ничего не можешь исправить.

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

Хочу отметить, в чём я не согласен, ведь честный ответ для меня — где-то между его точкой зрения и более старой. При той же перестройке поискового слоя о больших кошках я специально попросил ИИ сохранить старые рабочие шаблоны даже там, где они были менее элегантны, чем новые. Для системы на одного человека, которая должна продолжать работать, пока над ней ведут итерации, стоимость полной миграции слишком высока; сохранение рабочего шаблона преобладает над архитектурной последовательностью. Формулировка Маркуса предполагает здоровую команду и непрерывный темп миграции. Моя — нет. Оба правы в своём контексте.

Его завершением стало «Embrace Change» — подзаголовок книги «Extreme Programming Explained». Эта книга была и моей первой книгой об agile. Двадцать пять лет спустя подзаголовок по-прежнему работает как тезис.

Эбеле Окочар и Джим Дамато — IDD: Развитие, обусловленное индустриализацией

Строительный трек, совместный доклад. Industrialization Driven Development — это то, что Джим, Эбеле и их коллега Пит разработали, когда осознали, что технические команды, внедряющие Agile, получают плохие результаты, потому что Agile по умолчанию не учитывает медленный цикл создания физических продуктов. Их переформулировка: работай в обратном направлении — от продаж к производству, к сертификации, к закупкам, к инжинирингу. Итоговая дорожная карта — это то, что ты берешь в PI-планирование, а не наоборот.

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

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

Гойко Аджич — Использование ИИ в разработке продукта: почему результаты по-прежнему превосходят готовый продукт

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

Пример с дизайн-системой — это то, что я из этого выношу. Он попросил Claude просканировать его существующий веб-сайт, задокументировать его визуальный язык и выдать дизайн-систему в виде набора статических HTML-страниц в системе контроля версий. С тех пор каждая новая функция прототипируется на основе дизайн-системы. Статические страницы версионируются вместе с производственным CSS, поэтому они остаются синхронными. Spec by example, но на визуализации. У него нет дизайнера; дизайн-система заменяет узкое место, которое создал бы дизайнер.

Еще один ход, который я бы скопировал, — трюк с диагностическим эндпоинтом. Он построил цепочку трассировочных эндпоинтов: сначала ping, затем who-am-I, а затем бизнес-эндпоинты — исключительно для того, чтобы агент мог сузить круг поиска и определить, где именно происходит сбой при развертывании. Затем он понял, что эта же цепочка дает отличную страницу проверки связи для пользователей. Когда пользователи в Израиле начали жаловаться, что приложение не загружается, он отправил им диагностическую страницу и получил в ответ точную информацию о том, что блокирует их провайдер. Инструментарий, созданный для агента, стал заодно и инструментарием для пользователя.

Его формулировка дизрапции острее, чем то, как об этом обычно пишут. Дизраптивная инновация — это не та в десять раз лучшая вещь, которая заменяет существующее решение. Это вещь, которая делает решение, ранее доступное только богатым, доступным для людей, которые раньше не могли к нему дотянуться. По этому определению ИИ-робот, над которым большинство из нас сейчас работает, является дизруптивным в строгом смысле.

Та же самая линза применима к более мелкой системе, которую я разрабатываю для себя — Telegram-вход, разветвляющийся на X, Bluesky и Friendica, с разбиением тредов, отслеживанием ответов между платформами и обработкой цитат, благодаря которой контент читается естественно на каждой платформе. Я её создал, потому что ручной кросс-постинг был невыносим. Кроссплатформенная оркестрация, которую она осуществляет, до сих пор требовала либо платного SaaS, либо собственной разработки. Я обдумываю, стоит ли её монетизировать. Формулировка Гойка — это самая чистая версия аргумента в пользу того, чтобы продвинуть этот вопрос вперёд.

Тара Скотт — «Разрывая петлю разрешения: агентство как суперсила»

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

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

Джошуа Талер — Создание команд, которые ИИ не сможет заменить

Игровой трек. Более тридцати лет в Riot и Zwift. Фокус на live-ops.

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

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

Среди его критериев найма: перестань начинать и начни завершать, как говорил Лэнс Стайтс из Riot. Я годами наблюдал ту же самую схему в работе технической поддержки; люди постоянно начинают дела и завершают их только под принуждением. Обозначение этой инверсии помогает.

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

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

Макс Пьехота — Инженерия доверия: позволь ИИ разгружать твой код

ИИ-трек. Доклад дня, который больше всего чтит инженерное наследие. Аргумент Макса: каждое беспокойство, которое люди испытывают по поводу кода, сгенерированного ИИ — галлюцинации, скрытые баги, ненадежные результаты — это те же самые опасения, которые организации испытывали в отношении кода, сгенерированного людьми, в течение последних сорока лет, и инженерное наследие уже решило большинство из этих проблем. Парное программирование, trunk-based development, TDD, флаги функций, наблюдаемость, метрики, поведенчески-ориентированные наборы тестов. Набор решений существует. ИИ просто делает объем сгенерированного кода достаточно большим, чтобы компании, которые игнорировали эти практики, больше не могли это игнорировать.

В его формулировке «vibe coding» была кульминация, которую стоит выделить. Vibe coding — это не что-то новое. Менеджеры десятилетиями занимались «vibe-кодированием» вместе с инженерами. Это предложение, сказанное вслух, развенчивает немалую часть дискурса вокруг ИИ-инструментария. Роль, в которой он описывает современного разработчика, — это надзиратель производства, а не ремесленник: ты строишь обвязку вокруг конвейера и проверяешь результат, но не читаешь каждую строку.

Его три критерия качества для работы, управляемой ИИ, конкретны. Спецификация в формате Markdown для каждой функции. Архитектурная диаграмма C4, сгенерированная из предметно-ориентированного языка, чтобы агент мог писать определения, пока ты читаешь картинку. Поведенчески-ориентированный набор тестов, скрывающий детали реализации и позволяющий агенту проверять поведение. Он показал пример кода, который Claude выдал на основе этих трех контрольных точек и который он запустил в производственную среду, не изменив ни одной строки. Это тот уровень зрелости, который может обеспечить обвязка, если ты её построишь.

Вопрос о выгорании, который он поднял, — тот же, что поднял Джейсон Литтл. Он наблюдает за собой, чтобы понять, адаптируется ли его мозг к переключению контекста между несколькими управляемыми ИИ рабочими потоками или же выгорает. Я провожу тот же эксперимент на себе.

Его вывод: уважай фундамент. Инструментарий ИИ меняется каждый день; фундамент — нет. Он взял за стандарт Claude Code через CLI и отказывается гоняться за новыми инструментами, которые не меняют фундаментального. Это правильная дисциплина.

Диана Ларсен — Лидерство в неспокойные времена

Трек о людях. Диана написала книгу «Lead Without Blame» совместно с Тришей Бродерик. Более тридцати лет опыта в agile-коучинге. Основная идея доклада заключается в том, что темп изменений не просто ускорился; он перестал делать паузы между изменениями, а это уже другая проблема, нежели просто скорость.

Модель «ведра перемен» Дианы: у каждого человека своя врождённая способность воспринимать изменения, и как только это ведро переполняется, никакая коммуникация или обучение уже не помогают. Агенты перемен обычно обладают большими ведрами, и именно поэтому мы снова и снова выдвигаем ожидания, которым наши коллеги не могут соответствовать. Знать и размер своего ведра, и уровень, на котором оно сейчас находится, — это часть честного лидерства. Версия на уровне команды — это задать четвёртый вопрос стендапа, приписываемый Митчу Лейси: насколько мы уверены, что достигнем нашей цели, и разобраться с теми ответами, которые расходятся с консенсусом.

Её переформулировка работы с ПО как работы с обучением, а не работы со знаниями — это та часть, о которой я всё время думаю. Работа со знаниями предполагает, что у тебя есть соответствующие навыки и ты их применяешь. Работа с обучением предполагает, что проблема каждый раз отчасти новая, и интеллект команды должен дорасти до неё. По этой формулировке почти всё, что я делаю на основной работе и в личных проектах, — это работа с обучением; части работы со знаниями исчезают, потому что ИИ их поглощает.

Дэн Холлинджер — Не просто ожидай, что что-то пойдет не так, а планируй это

Игровой трек. Дэн провёл два десятилетия в разработке игр и руководил инфраструктурной работой в команде Horizon Worlds в Facebook во время глобального сбоя, который заблокировал даже пропускные карты здания. Его темой был процесс SEV — Site Event, структурированный паттерн реагирования на инциденты, который Facebook использует внутри компании. Работа технической поддержки, которой я занимаюсь на основной работе, устроена похоже, просто другими терминами, поэтому большая часть доклада была непосредственно применима.

Два шаблона, которые я хочу укрепить в своей команде. Первый: положительное подтверждение при передаче. Создание тикета — это не передача; передача завершается, когда принимающий владелец подтверждает, что берет это на себя как свой P0. Без этого срочные тикеты лежат непрочитанными в чьей-то очереди по два дня. Любой, кто работал в очереди эскалаций, видел, как это происходит. Второй: владелец SEV ведёт к решению, но не обязательно является тем, кто исправляет. Его работа — найти нужного человека в цепочке и оградить его от помех, пока исправление не будет внедрено. Эта защита — именно та часть, которую большинство систем отслеживания тикетов не моделируют.

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

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

Майк Чайлз — Как заручиться поддержкой: повысь уважение, добивайся желаемых результатов

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

Ролевое упражнение, которое ведущий провёл с ним, заслуживает полной цитаты. Ты скептически настроенный суперинтендант, ты старый и ожесточённый, у тебя пять минут — продай мне Scrum. Ответ Майка: Я даже не буду пытаться обратить тебя в Scrum. Я спрошу, что тебя беспокоит. Люди обожают хвастаться шрамами, но не любят говорить о ранах. Когда подходишь близко к ране, они начинают ворчать. Я выясню, где твои раны, и попробую залечить одну из них. Переформулировка того, что сопротивление — это тоска по чему-то конкретному, а не позиция по отношению к твоей идее, — это то, что я хочу нести в каждый разговор об изменениях. Кэт Антонович в первый же день сделала то же самое наблюдение, опираясь на свой опыт социальной работы. Майк приобрел свой опыт с двадцати лет на строительных площадках.

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

Споры с календарём никогда не приносят победы. Оценка, как правило, верна.

Стягивая нитки

Две нити протянулись сквозь день.

Одна — это формулировка «человек ведет». Джейсон Литтл, Макс Пьехота, Пер Бейнинг и, косвенно, Джошуа Талер — все они сказали одно и то же разными словами. Разрыв между «человек в петле» и «человек ведет» — это разница между ИИ как заменой и ИИ как усилителем. Полезная работа вытекает из второй формулировки. Первая формулировка порождает посты в LinkedIn о двенадцатичеловеческих командах преобразований, которые теперь представляют собой одного человека, и не многое другое.

Другая — это рана под сопротивлением. Майк Чайлз назвал её наиболее прямо, но наблюдения Аниты Калмане-Бут о позднем посещении стендапов, ведра перемен Дианы Ларсен, паралич от разрешения Тары Скотт, команда Брайана Мелчера, раскрывшаяся лишь после того, как он публично похоронил провальную инициативу, — все это варианты одного и того же наблюдения. Сопротивление — это сигнал о чем-то реальном, скрытом под поверхностью. Протолкни изменение, не обращая внимания на то, на что указывает сигнал, и ты получишь то, что на самом деле порождает большинство agile-трансформаций: театр поверх той самой скрытой фрустрации.

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

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