ScrumTrek

Фотографии с AgileDays FEST готовы 📸

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

Вспоминаем, как это было, и сохраняем себе самые удачные кадры, чтобы пересматривать пока ждём следующую конференцию!

👉 Смотреть и скачивать

Менеджеров с агентами недостаточно, чтобы делать всю работу?

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

Но тогда возникает вопрос: в чем польза от сотрудников-исполнителей? В условиях, когда многие из нас с агентами теперь могут творить чудеса, польза неочевидна 🤷‍♂️.

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

➡️ Зачем компании исполнители, если есть агенты
#статья для чтения на выходные

➿➿➿
Ну, и к той же теме вот летние посты из нашего канала 👇. Они про необходимость того опыта, которые есть у специалистов:

🔹Мой кейс с 1С: не будучи специалистом в этой области, я с агентом быстро сделал интеграцию с бухгалтерий, но потом оказалось: все наполовину неверно... а специалист бы сэкономил кучу времени.

🔹Если судить по манифестам ИИ-разработки, которые проанализировал @askhatu, к 2026 году сообщество уже пришло к выводу: обязательно понимать, как работает создаваемая система. Т.е. типичный менеджерский подход «мне всё равно, что внутри, лишь бы работало» нежизнеспособен на масштабе.

Всё это намекает на то, что в паре с менеджером нужен минимум один специалист, который разбирается в деталях и может потратить время на проверку / настройку автоматических проверок агентами. А в случае работы с клиентами он ещё и живое лицо компании (в той же статье есть статистика о том, почему ИИ-аватарами тут обойтись нельзя).

Получается tiny team: менеджер, профильный исполнитель и их агенты. Заодно такая микрокоманда помогает выбраться из кокона ИИ-одиночки — есть с кем обсудить решения.

➿➿➿
Но все-таки ИИ забирает многое у людей-исполнителей , так что тема эта неоднозначная. Пишите в комментарии, если вы тоже думали над этими вопросами.

Ну, и если почитаете статью — задумаетесь ещё больше 😉

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

Аргумент железобетонный, если считать часы, а не прирост продукта.

Цифры Cockburn и Williams говорят другое: часов уходит на 15% больше, а не вдвое, дефектов на 15% меньше, кода на 20% меньше. А читаем мы код раз в десять дольше, чем пишем.

Сергей Баранов обновил статью про парное программирование, добавил раздел про AI.

Что внутри:
🧡пять стилей: штурман/водитель, строгий пейринг, пинг-понг под TDD, смешанный, mob;
🧡почему это навык, а не рассадка двух людей рядом, и три антипаттерна, которые убивают сессию;
🧡пара джун-сеньор: как не дать сеньору стать Keyboard Dominator;
🧡что делать, когда знаний не хватает одному партнёру, и что — когда обоим (иногда задача не решается вообще);
🧡AI в паре. Не «разработчик + AI», а «два разработчика + AI»: машина снимает механику и ровно поэтому поднимает цену ошибки штурмана.

17 минут чтения, в конце шесть шагов для старта.

🔗 Изучить полезное чтиво

Семь раз отмерь. Один раз назови срок заказчику 📐

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

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

Завтра, 22 сентября, в 19:00 (МСК) Александр Рыжков на вебинаре «Как прогнозировать сроки без гаданий?» расскажет, как при формировании сроков оперировать этими понятиями:
🧡lead time
🧡throughput
🧡перцентили
🧡SLE

За такую оценку и ответственность нести не стыдно и аргументировать всегда будет чем.

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

🔗 Зарегистрироваться на бесплатный вебинар

Как проходит фестиваль 🎉

Собрали самые красивые моменты этого дня, чтобы вы почувствовали атмосферу через экран, если сегодня не тут, или с теплыми воспоминаниями пересматривали, если всё же смогли побывать AgileDays FEST 🧡

❣️У хорошей конференции всегда есть соучастники❣️

До AgileDays ФЕСТ 2026 — уже совсем немного. И пока мы собираем последние детали, хочется поблагодарить тех, кто помогает создавать атмосферу завтрашнего дня.

Ингосстрах, Единый ЦУПИС и Т1-Сфера — партнёры AgileDays ФЕСТ 2026, благодаря которым у участников будет ещё больше поводов задержаться между докладами, познакомиться, пообщаться и увезти с собой что-то на память. Для участников они подготовили памятные подарки, а Ингосстрах ещё и встретит гостей на собственном стенде — с активностями и дополнительными подарками.

За игристое настроение в этом году отвечают наши партнёры Bruni. Их prosecco родом из Венето и Пьемонта, а на фестивале станет частью фуршета и вечерней атмосферы.

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

Спасибо партнёрам, которые помогают нам собирать этот день вместе.

✨Уже завтра увидимся на AgileDays ФЕСТ 2026!

Вебинар про подготовку встречи уже сегодня❗️

У фасилитации всегда есть невидимая сторона — работа с запросом. Сегодня в 18:30 на бесплатном эфире Дарья Охохонина разберёт и структурирует практические аспекты этой работы.

Что унесёте с эфира:
🧡вопросы, которые задают заказчику, чтобы понять точно понять его запрос;
🧡как честно взвесить свои силы и свою роль в предстоящей встрече;
🧡по каким признакам видно, что формат стоит поменять или сессию вообще не проводить.

Полезно тем, кто только осваивает фасилитацию, ведёт встречи как руководитель команды или проекта, собирает стейкхолдеров как продакт или фасилитирует внутренние сессии в роли HR.

Длительность: 45 минут
Платформа: Zoom

🔗Записаться на бесплатный вебинар

Лимит — это для вас какая-то шутка? 🧮

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

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

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

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

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

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

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

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

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

6–7 октября Александр Рыжков проводит двухдневный онлайн-тренинг «Основы Канбан-систем (KSD)» — как раз про то, как читать эти сигналы и чинить процесс. Ставить WIP-лимиты и опираться на статистику Throughput, находить задержки в потоке, называть срок с вероятностью 80–90%.

👉 Записаться на тренинг

Нам как менеджерам проще 👇 работать с ИИ-агентами, чем исполнителям, даже технарям.
(это #дайджест постов Кактуса в новом формате)

Если помните, я писал про эксперимент Итана Моллика: студенты MBA без навыков программирования за 4 дня сделали с ИИ больше, чем прежние потоки за семестр. Им помогли как раз навыки управления.

Вот что руководители делают с агентами "на автомате":

1️⃣Ставят задачу как живому сотруднику. Дают контекст и чек-лист, по которому агент проверит себя сам, а главное — озадачивают ИИ именно тем, что хорошо делегируется. Когда отдавать задачу ИИ выгодно.

2️⃣ Не микроменеджат. Указывают главное, что не так с результатом, и просят самого агента обновлять свои инструкции. Как перестать микроменеджить ИИ.

3️⃣Легко выбрасывают плохие результаты ИИ, и уж тем более не правят их сами. Когда умение говорить «нет» агенту становится активом человека и компании.

4️⃣Выстраивают прозрачный адаптивный процесс с human in the loop. В котором агент сам предлагает решения и улучшения, но согласовывает их с человеком. «Скрам» для ИИ-агента.

➿➿➿
Правда, чисто менеджерского подхода к работе с ИИ бывает мало, так что люди-"исполнители" тут тоже нужны. Я (Алексей Евдокимов) скоро напишу об этом. А пока накидывайте плиз в комментарии: в чем видите практические отличия между управлением агентами и людьми?

Ненужную встречу можно распознать на десятой минуте, а испортили её накануне

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

Упражнениями здесь не помочь. Здесь только исследовать и выяснять конкретный запрос за неделю до.

16 сентября в 18:30 проводим открытый эфир про подготовку к фасилитации сессий. Сорок минут плюс вопросы.

Тема: Подготовка встречи: какие вопросы перед встречей стоит задать себе и заказчику

Разберём как устроен этап подготовки:
❣️ какие вопросы задать заказчику;
❣️ какие вопросы задать себе, чтобы честно оценить свои силы, роль, и на что смотреть, чтобы распознать ситуации;
❣️ где фасилитатору лучше отказаться от выбранного формата или проведения сессии вообще.

Ведёт Дарья Охохонина: Agile-коуч, бизнес-тренер, фасилитатор в гештальт-подходе.

Зарегистрируйтесь и мы пришлём вам инструмент для самостоятельной проверки необходимости встречи.

📣 Регистрация на эфир 16 сентября

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

Что, если вы свернули слишком рано? 🗺

В этом году мы посмотрели на AgileDays ФЕСТ через метафору горы и базового лагеря.

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

В реальном бизнесе всё сложнее. Agile для разных компаний сегодня выглядит совершенно по-разному: кто-то только внедряет его и пока не видит результата, а кто-то уже движется дальше — к адаптивности, клиентократии и новым моделям управления. И здесь возникает важный вопрос: если мы не дошли до результата с Agile — не повторим ли тот же маршрут с ИИ?

🗺️ Можно годами идти в правильном направлении — и так и не дойти до вершины. Поэтому базовый лагерь — место не для соревнования, а для обмена важными деталями, стратегиями и маршрутами.

На конференции AgileDays ФЕСТ 2026 будет возможность остановиться, оглянуться на пройденный путь и понять: куда идти дальше? И главное — до какой вершины вы на самом деле хотите дойти.

17 сентября, Москва, Goelro Space.

Как прогнозировать сроки без гаданий?

Вы наверняка замечали, что прогноз погоды не утверждает, что будет дождь, а говорит, что вероятность осадков 70%. Американская метеослужба перешла на такие прогнозы в 1965-м, а до этого публиковала всего одно слово: дождь или ясно.

При определении сроков многие до сих пор руководствуются методами из 1964-ого, отвечая только "дождь" или "ясно". Магне Йоргенсен свёл опросы практик оценки в разных компаниях и получил следующее: от 62 до 86% сроков называют экспертным суждением, то есть, холодный расчёт остаётся в меньшинстве, уступая наитию, прошлому опыту, либо конкретному дедлайну.

Есть ещё более-менее наукообразный способ —по среднему, но он очень коварный. Скажем, за квартал команда закрыла сто задач: 60 за 5 дней, 25 за 12, 10 за 25 и 5 за 45 дней, соответственно. Средний срок выполнения задачи — 11 дней, только в эти 11 дней не уложились сорок задач из ста, а половина закрылись за пять. Среднее сильно увеличили те пятнадцать штук, что шли дольше всех и быть валидным оно перестало.

Ещё добавим к этому буфер (запас, который накидывают к оценке), чтобы перестраховаться, умножим 11 на два и обозначим заказчику срок в 22 дня, ведь в 22 дня действительно укладываются 85 задач из ста.

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

На самом деле, для более точного определения сроков считать почти ничего не надо. Всего лишь отсортировать задачи от быстрых к медленным и посмотреть три из них. 50-я идёт 5 дней, так выглядит обычная задача, 85-я идёт 12 дней: в этот срок мы попадаем в 85 случаях из ста. 95-я — 25 дней, это почти гарантия.

При таком раскладе можно назвать заказчику два числа: срок и вероятность. За 12 дней закрываем в 85 случаях из ста, но если нужно надёжнее, тогда срок 25 дней. Он выбирает сам, так же как вы сами решаете, брать ли зонт при вероятности 50% дождя.

Выбранная пара чисел называется SLE (Service Level Expectation). Дальше команда замеряет сроки по ней: сколько задач за месяц уложилось в обещанные 12 дней. Если заметно меньше 85, то в процессе что-то изменилось и обещание пора пересматривать.

🗓 22 сентября в 19:00 Александр Рыжков, тренер Scrum и Kanban в ScrumTrek, покажет на бесплатном вебинаре, как собрать такой прогноз, оперируя данными: lead time, throughput, перцентили и SLE.

Зарегистрироваться на бесплатный вебинар «Как прогнозировать сроки без гаданий»