П'ять записів із саміту, із запізненням на три тижні

Global Agile Summit завершився 6 травня. Ці п'ять записів я подивився за пару тижнів по тому, коли Oikosofy виклала їх до відеобібліотеки. Воркшоп із мобпрограмування від Вуді Зуйла, чотири живі наступні сесії запитань-відповідей із Джейсоном Літтлом, Маркусом Буллоком, Клінтоном Кітом і Джошуа Талером, приблизно п'ять годин матеріалу, втиснутих у тиждень вечорів.

Затримка була ненавмисною, але виявилася продуктивною. Перегляд сесій, що відбулися з різницею в кілька днів, одна за одною, у тихий тиждень, проявив нитку, якої я не вловив би наживо: кожен із цих спікерів, із різних кутів і різних треків, раз по раз приходив до одного й того самого операційного питання: як утримати людську директиву, коли інструменти достатньо швидкі, щоб зробити людину необов'язковою?

Зуйл відповів грою. Літтл збудував структуру тек. Буллок виявив це, коли чотири тижні автоматизації минули без жодної розмови з клієнтом, а Кіт — коли підрахунок голів на парковці виміряв не те. Талер приніс меча.

Вуді Зуйл — Mob Gaming with Woody Zuill

Це був воркшоп, а не доповідь (єдиний у цій порції). Група Зуйла грала в Baba Is You, головоломку, де правила світу є фізичними текстовими блоками, які можна переставляти, застосовуючи техніку мобпрограмування. Одна людина веде клавіатуру, одна навігує, задаючи намір, решта спостерігає й чекає своєї черги.

Я дивився запис за тижні після саміту. Мене вразило те, що процес воркшопу й був контентом. Головоломки — це засіб; те, що бачиш, це як люди вчаться передавати високорівневий намір, не даючи покрокових інструкцій.

Перша фраза Зуйла: «Я тут не для того, щоб казати вам, що робити. Я тут просто щоб поділитися з вами тим, що я зробив». Він називає свої настанови піратським кодексом — це радше орієнтири, ніж правила. Базовий принцип походить від Левелліна Фалько: щоб ідея перейшла з чиєїсь голови в комп'ютер, вона має пройти крізь руки когось іншого. На практиці навігатор каже «відʼєднай твердження „прапор — це стоп“, щоб ми могли вільно рухатися», а не «натисни вліво тричі, потім вниз». Зуйл вибудовує три рівні інструкції: намір, інструкції, локація. Навігатор націлюється на найвищий рівень, на якому водій може працювати.

Момент, який я записав: навігатор застрягає на головоломці. Зуйл дає слово: хтось має ідею? Учасник підіймає руку й пропонує спостереження: кілька каменів можна штовхнути одночасно, що могло б зламати одне з логічних тверджень гри. Але пропозиція йде навігаторові, а не водієві. Навігатор вирішує, чи пробувати це. Зуйл робить соціальний контракт явним: помічники пропонують, навігатор обирає, ніхто не перебирає кермо.

Це накладається на те, як я працюю з AI-агентами. Коли я скеровую Claude Code на завдання, я лишаюся на рівні наміру («полагодь детекцію фліп-флопу в перекладацькому пайплайні») і даю агентові самому з'ясувати підхід. Коли він дрейфує, я коригую. Коли я застряг із напрямком, я прошу альтернативи й обираю. Протокол «водій-навігатор», якого Зуйл навчає групу людей, майже ідентичний патерну взаємодії, який я вже веду з групою агентів.

Під час рефлексії один учасник сказав: «Я ніби перемудровую. Я думаю на п'ять кроків наперед і часом не пробую». Інший помітив, що «є бажання спершу дати правильну відповідь». Відповідь Зуйла: щоразу, коли тобі здається, що щось не спрацює, це гарний час поекспериментувати. Невдачу можна скасувати — клавіша Z скидає все, так само як контроль версій.

Ось де мобпрограмування розходиться з тим, як працює більшість команд. У мобі спробувати неправильне дешево, бо всі бачать невдачу й вчаться з неї разом. Працюючи наодинці, невдача лишається невидимою, а навчання замикається в одній голові. Я проводив джуніорів саме через цей перехід — від страху пробувати до спокою в невдачі, бо команда вбирає результат. Мобпрограмування пришвидшило б це.

Зуйл завершив фразою, яку я раз по раз прокручую: «Командна робота не замінює роботу наодинці, а робота наодинці не замінює командну. Ми можемо мати й те, й те». Тоді він додав, що коли якесь завдання здається таким, що мусить бути сольним, бо це проста рутинна праця - можливо, саме час його автоматизувати. Для когось, хто будує оркестрацію агентів, аби та брала на себе повторювану частку саппортної роботи, це мене зачепило.

Коротшу думку про цей воркшоп я написав постом у LinkedIn. Довший формат тут дав мені посидіти із самим процесом — геймплей як засіб навчання, траєкторія фасилітації від суворого до відкритого, паралель «водій-навігатор» зі скеруванням AI, яку Зуйл ніде не згадує, але яку я простежив наскрізно.

Джейсон Літтл — Onboarding your AI Employees (LIVE Q&A)

Підготовлена доповідь Літтла (розглянута в зведеному матеріалі за День 2) представила фреймворк: ставитися до AI-агентів як до співробітників — з онбордингом, тренувальними даними та командними робочими домовленостями. Ця сесія запитань-відповідей зайшла в операційну реальність роботи цього сетапу день у день.

Опорною тезою було його правило 95%. Коли AI робить щось несподіване, у 95% або більше випадків проблема в твоєму промпті, інструкціях чи контексті, а не в моделі. Літтл подає це як розуміння того, що LLM — це рушії зіставлення патернів без жодного наміру. «Тут немає мислення. За цим немає інтелекту». Щойно це засвоїш, твоє промптування змінюється.

Що сесія підкріпила: я будую власну оркестрацію так само, як Літтл будує свою екосистему Claude: єдина точка входу, розгалужена на спеціалізовані скіли, кожен зведений до однієї відповідальності. Архітектура та сама: тека інструкцій, вузько зведені тренувальні дані, цикл зворотного зв'язку, що періодично звіряє вихід агента з тим, чого я насправді хотів.

Частина, що штовхнула мене далі, це антисикофантство. Літтл описав скіл адвоката диявола, який має називати фігню в його стратегічних рішеннях. «AI поступливий… його треба тригернути». Один зі слухачів заперечив: просто попросити незгоду — це породити штучну незгоду. Літтл погодився. Коли критику обґрунтовано зовнішнім орієнтиром, а не просто «будь жорстким», вона стає слушною, а не показною. Я вже використовую промптування з кількома опціями у своїй роботі з розслідування тікетів саме тому, що єдина відповідь від поступливої моделі ненадійна. Але я не збудував окремого змагального агента для свого власного стратегічного мислення. Ось та конкретна річ із цієї сесії, яку я планую спробувати.

Найгостріший обмін був між Літтлом і слухачем, який доводив, що AI-зумовлена неефективність організаційної роз'єднаності у великих підприємствах фундаментально відрізняється від старої боротьби з аджайл-трансформацією: «швидкість створення неефективності й шуму в 1000 разів вища». Літтл тримав свою позицію: патерн змін той самий, незалежно від швидкості. Культурна проблема в основі — мислителі проєктують процес, виконавці приймають спущений мандат — не змінилася за п'ятдесят років. Я зловив себе на тому, що погоджуюся з обома. Патерн той самий. Швидкість робить його гіршим.

Маркус Буллок — Resilience, Trust & Second Chances (LIVE Q&A)

Сесія Буллока стояла далі від його підготовленої доповіді, ніж в інших. Якщо доповідь (розглянута в підсумку за День 1) була про побудову людиноцентричних технологій, то сесія зайшла в його власну траєкторію: тюрма в 15, заснування Flikshop, побудова Flikshop School of Business усередині тюрем і операційна напруга між масштабуванням за допомогою AI і збереженням людського контакту.

Момент, що зостався зі мною: Буллок описав, як будував автоматизовані дашборди для партнерів за допомогою Claude Code. Робочий процес був чистим: від першої взаємодії з клієнтом до персоналізованої звітності, повністю автоматизований. Тоді він усвідомив, що минуло чотири тижні без жодної живої розмови з клієнтом. «Те, як ми вирощували компанію, полягало в тому, щоб робити речі, які не масштабуються… а потім з'ясовувати, як збудувати системи навколо того, що не масштабується, так, щоб це дозволяло нам масштабуватися у фоні».

Це речення — найчесніша в операційному сенсі річ, яку я почув за всі п'ять сесій. Ти не починаєш із масштабованої версії. Ти робиш ручну роботу, дізнаєшся, що має значення, а тоді автоматизуєш навколо цього, зберігаючи людські частини, які від початку й змусили цю штуку працювати.

Коли хтось запитав про лідерський ризик, Буллок відповів негайно: лідер бере на себе негативні наслідки. Не як гасло з плаката — як операційний принцип. «Питання насправді не в тому, чи є ризик, а в тому, хто бере на себе негативні наслідки цих ризиків?»

Я брав людей із мінімальним досвідом і за роки виростав їх до мідл-рівня. Переконання Буллока про другі шанси, що талант криється там, де більшість організацій уже вирішили не дивитися, резонує з тією роботою. Механізм різниться. Операційне переконання те саме: середовище формує результат більше, ніж самі лише природні здібності, і більшість організацій недоінвестують у середовище.

Обмін про доступ до AI проти результатів був найгострішим поворотом. Один учасник сформулював це як модель наркоторговця: безкоштовні семпли зараз, плата за залежність потім. Буллок штовхнув до чогось конкретнішого: «Доступ маркетингують як рівний, але результати швидко формуються тим, кого по-справжньому включено, кого підтримано й в кого взагалі вкладено». Доступ без підтримки — це не доступ. Це формулювання застосовне поза AI-інструментами.

Клінтон Кіт — Game Development, as we know it, is ending (LIVE Q&A)

Кіт написав Agile Game Development with Scrum і вже два десятиліття є центральним голосом про аджайл в іграх. Як той, хто стежить за процесом ґеймдеву зі споживацького боку, я найбільше хотів почути саме цю сесію.

Історія з метриками кранчу зосталася зі мною найдовше. Кіт описав себе як «майстра примусового кранчу», менеджера, який наказував працювати у вихідні й вважав себе хорошим лідером, бо був там разом із командою. Тоді він прийняв скрам і почав вимірювати фактичну швидкість постачання фіч за спринт замість підрахунку годин у будівлі.

Дані: на 50% більше часу в студії давало на 20–30% більше фіч у перші кілька тижнів. Після трьох тижнів виробіток різко впав. Через місяць команди постачали менше фіч за спринт, ніж до початку кранчу. Він уже знав це інтуїтивно. Але метрика — прозора, видима — змінила його поведінку, бо він уже не міг відвести погляд. «Зробити вплив кранчу видимим — це одна з речей, які може дати Agile. Що ти робиш із цим, на жаль, не завжди означає прийняти правильне рішення».

Збудувати довіру з командами, щоб ті брали зобов'язання самі, забирає місяці. Зруйнувати ту довіру поверненням до примусового кранчу — достатньо однієї ночі. Кіт описав команди, які почали самокранчити, щойно стали власниками своїх зобов'язань, і як його роль змінилася з «прийди в ці вихідні» на «тримайся подалі», не з доброти, а тому що метрики показували: більше годин дасть менше виходу.

Останнє питання зачепило Кіта помітно: «Ти ніколи не переживаєш, що аджайл насправді використали як механізм пристосування, а не як ліки?» Він розповів, як заходив у велику студію, навчав сотні розробників скраму, а тоді отримував п'ятнадцять хвилин із топменеджментом — який весь сидів у телефонах. «Має існувати цей фундаментальний шар хорошого лідерства, який мусить існувати. Та були організації, у які я заходжу, де його немає».

Дещо з тих зусиль не змінило організацію. Але розробники несли вивчене у свою наступну студію. Вплив накопичується крізь зміни роботи, а не всередині організації, що заплатила за навчання. Це спостереження — одне з тих, що я впізнаю з іншої функції: довгострокова віддача наставництва проступає в наступній ролі людини чіткіше, ніж у її поточній.

Джошуа Талер — Building teams that AI can’t replace (LIVE Q&A)

Талерова сесія була найкоротшою, близько двадцяти семи хвилин, і найщільніше зведеною до однієї тези: люди лишаються необхідними там, де експертність глибока, контекстозалежна й обтяжена регуляціями.

Деталь про фехтування з його доповіді проступила першою. Талер обіймає керівну роль у Society for Creative Anachronism, волонтерській організації середньовічної реконструкції, і описав це як свій полігон лідерського вишколу. Ключовий скіл, який він назвав: «вплив без повноважень». Не можна наказати волонтерам коритися. Ти подаєш напрямок достатньо чітко, щоб іти за ним було природним вибором.

Саме це формулювання я найбільше асоціюю з тим типом лідерства, що мені до вподоби. Керуючи саппорт-командою в стартапі, я витрачаю більше часу на те, щоб дати людям змогу розв'язувати проблеми, ніж на розв'язання проблем за них. Коли мені щось потрібно від іншої команди, я подаю аргумент і чекаю. Талер прийшов до цього через фехтування. Я прийшов через роки техпідтримки. Шлях різниться; операційний принцип ні.

Щодо інтеграції AI-інструментів Талер запропонував один архітектурний принцип: слабке зв'язування через шар API. Кожен AI-інструмент суттєво зміниться протягом двох-трьох років. Збудуй middleware; міняй інструмент під ним. Це збігається з тим, що я зробив на своєму новинному пайплайні цьогоріч — повністю замінив джерело пошуку, а решта системи цього й не помітила.

Обговорення GDPR підняло загальногалузевий момент: AI хоче доступу до всього; регуляція захисту даних обмежує, що можна обробляти й як. Позиція Талера: «Довіряй, але перевіряй. Гадаю, тут трохи менше довіри». Очікувати, що якийсь AI-інструмент впорається з відповідністю без людського аудиту — це, як він висловився, наражатися на провал, від якого компанії банкрутують.

Дивлячись ці п'ять сесій за один тиждень, я виокремив не AI-дискусію: кожен конференційний трек у 2026-му торкається AI. Я виокремив те, наскільки послідовно кожен спікер приходив до одного й того самого операційного питання з іншої відправної точки.

Відповідь Зуйла, соціальний протокол: навігатор задає намір, водій виконує, ніхто не перебирає кермо. Відповідь Літтла, структура тек: агенти одного призначення, одне завдання на нитку, цикли зворотного зв'язку. Буллок знайшов це випадково: чотири тижні чистої автоматизації без жодної розмови з клієнтом показали йому, що людський контакт був продуктом, а не дашбордом. Відповідь Кіта, метрика: підрахунок голів на парковці казав, що кранч працює; дані спринту казали, що ні. Талер збудував шар middleware й очікував, що все під ним буде замінено.

Питання в основі всіх п'яти: коли виконавець рухається швидше, ніж директор устигає думати, що не дає судженню директора зникнути в оптимізації?

Воркшоп Зуйла дав найконкретнішу версію. Навігаторові не треба розв'язувати головоломку швидше. Навігаторові треба передати те, що має значення, достатньо чітко, щоб водій міг це виконати. Цей поділ не зникає, коли водій — це AI-модель. Якщо вже на те, він важить більше, бо модель виконає будь-що, описане достатньо чітко, включно з неправильним.

Я хочу колись спробувати моб-формат Baba Is You зі своєю командою. Не як регулярне мобпрограмування (моя команда для цього замала й надто розподілена), а як фасилітаційну вправу для того скілу, що важить найбільше, коли покроковий виконавець не має власного судження: задавати намір і стримувати поривання задати локацію.