Перейти до вмісту

Тринадцять записаних доповідей на Global Agile Summit 2026, день другий

Нотатки віддаленого учасника про записані сесії. Живі сесії питань-відповідей описано окремо.

Логотип 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-трансформацій радше облесливо оминає, ніж адресує.

Спостереження про типову рису, яке вона зробила, широко відоме - що так склалося, що розробка ПЗ є однією з небагатьох областей, де нейровідмінне мислення пасує до роботи природно. Гіперфокус, письмова комунікація, індивідуальна глибока робота, креативні, проте точні патерни. Це також одне з небагатьох місць, де бути іншим має, її словами, інакшу конотацію, ніж у фінансах чи продажах.

Маркус Г'йорт — Від промпту до гри: побудова ШІ-нативних ігор з гнучкістю

Ігровий трек. Маркус - співзасновник і CTO Bitmagic, вебплатформи, де ти описуєш гру в промптах і отримуєш назад 3D-гру. Він пише код ще з Commodore 64, з двома роками між періодами кодування, проведеними як Agile-коуч у фінських компаніях, від маленьких стартапів до Nokia. Коучинговий патерн лишається корисним, сказав він, навіть коли ти сам нічого не можеш виправити.

Найсильніший аргумент доповіді - той, що суперечить тому, як більшість із нас вчили читати код. Думка Маркуса: ШІ не завжди чистіший на рівні рядка, ніж уважна людина, але мірило здорової кодової бази змінилося. Старий тест був: чи може людина прочитати це, як книжку. Новий тест: чи зможе агент послідовно застосувати патерни й абстракції цієї кодової бази протягом наступної зміни. Він навів приклад рефакторингу на п'ять тисяч рядків, який ШІ завершує за годину, той тип роботи, що раніше, вручну, призводив до того, що в одному проєкті нашаровувалися дві епохи стилю, бо ні в кого не було часу мігрувати. З ШІ міграція дешева, тож нашарованої спадщини більше немає.

Хочу позначити, де я не згоден, бо чесна відповідь для мене - десь між його й старішим поглядом. На тій самій перебудові пошукового шару про великих котів я навмисно попросив ШІ зберегти робочі старіші патерни навіть там, де вони були менш елегантні за нові. Для системи на одну людину, яка має й далі працювати, поки її ітерують, вартість повної міграції зависока; збереження робочого патерну перемагає архітектурну послідовність. Формулювання Маркуса припускає здорову команду й безперервний темп міграції. Моє - ні. Обидва праві у своєму контексті.

Його завершенням було Embrace Change, підзаголовок Extreme Programming Explained. Ця книжка була й моєю першою книжкою про agile. Двадцять п'ять років по тому підзаголовок усе ще працює як теза.

Ебеле Окочар та Джим Дамато — IDD: Industrialization Driven Development

Будівельний трек, спільна доповідь. 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-трансформацій: театр поверх тієї самої підспідньої фрустрації.

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

Записана форма - це те, що я передивлятимуся, коли захочу конкретну тактику. Живі сесії питань-відповідей - це там, де насправді проявилися припущення доповідачів.

Увімкніть коментарі, прийнявши куки.

Необхідні куки працюють завжди. Куки для статистики та коментарів використовуються лише з вашої згоди. Докладніше