Scrum Mastery Club - развитие в Scrum

💡 VSM «снаружи-внутрь»: как найти простои там, где Jira показывает 100% скорость? Большинство ИТ-руководителей свято верят своим дашбордам в Jira. На графиках всё идеально: velocity растет, спринты закрываются вовремя, внутренняя скорость разработки (иногда вы найдете термин - IT Lead Time) стремительно падает. ИТ-блок уверен, что работает со стопроцентной эффективностью. Но у бизнеса паника - клиенты по-прежнему ждут банальную фичу месяцами, а компания упускает окна возможностей. Почему возникает эта иллюзия? Потому что классические таск-трекеры измеряют процессы «изнутри наружу» (Inside-Out) - от статуса «В работе » до статуса «Готово» внутри производственного силоса. Система полностью слепа к тому, что происходит с задачей до и после написания кода. Чтобы вскрыть этот обман и увидеть реальную картину, профессиональному агенту изменений нужен взгляд «снаружи внутрь» (Outside-In) и инструмент Value Stream Mapping (VSM) - картирование сквозного потока ценности глазами клиента. Картирование позволяет переключить фокус менеджмента с локальной оптимизации (заставить программистов быстрее нажимать на кнопки) на оптимизацию сквозного потока (убрать простои на стыках между отделами). 🤖 Кейс: Как ИИ-анализ взламывает слепые зоны процессов В одном из последних проектов мы решили пойти дальше классического рисования стрелочек на флипчарте. Мы провели картирование не просто потока, а смоделировали сквозной путь ценности в Lucidchart и подключили встроенных ИИ-агентов для глубокого организационного анализа. Вот какие жесткие цифры и аномалии вскрыл ИИ-анализ на карте потока: - Парадокс Touch Time: чистая, полезная работа инженеров над кодом (Touch Time) занимает всего от 4 до 8 рабочих дней. - Общий календарный срок (Lead Time) прохождения сквозного изменения составляет от 82 до 104 рабочих дней. - Эффективности потока (Flow Efficiency): Эффективность конвейера составила всего 12–15%. Это значит, что более 85% времени задача просто «протухает» в очередях - в ожиданиях ответов от смежных колодцев и в циклах согласований. Даже если разработчики ускорятся в два раза и начнут писать код за 2 дня вместо 4, сквозной Time-to-Market для клиента не изменится ни на час. Проблема лежит в ошибочном дизайне организационной связанности (Coupled Design). 🚀 Отработаем эту технологию на практике в клубе Scrum-Mastery Теория без практики мертва. На ближайшем живом воркшопе нашего закрытого клуба мы разберем эту инженерную технологию до винтиков. Вы сможете прийти со своими кейсами и картами процессов. Что мы сделаем вместе на занятии клуба: 1. Пошагово спроектируем сквозной VSM в Lucidchart 2. Разберем, как правильно настраивать промпты для ИИ-агентов 3. Упакуем результаты анализа в понятный b2b-язык для C-level Доступ на проектировочную сессию и к библиотеке промптов открыт только для резидентов клуба. Занимайте свое место, забирайте готовые инструменты и переводите свою карьеру на уровень системного инжиниринга. 👇 Ссылка на оформление абонемента и вход в клуб Scrum-Mastery 👉 Ссылка скрыта #ScrumMastery #OrgDesign #ValueStreamMapping #FlowEfficiency #Lucidchart #AIinManagement #InsideOut #SystemicThinking #Management

📝 Анатомия очередей: как с помощью HeatMap бэклога доказать, что команды утилизируют сами себя Знакомая картина? ИТ-директор на комитетах требует расширения штата, заявляя о 100% выгорании и перегрузке своих сотрудников. Разработчики действительно в мыле, Jira трещит от тысяч закрытых тикетов, аналитики пишут тонны ТЗ. Но нужные рынку фичи не выходят месяцами. Чтобы вскрыть этот парадокс, профессиональному агенту изменений нужен жесткий инструмент - HeatMap (тепловая карта) бэклога. Как устроена «фабрика» ложной занятости? Когда организация нарезает ИТ-структуру «изнутри наружу», например, плодит десятки изолированных компонентных команд (команда базы данных, команда интеграционной шины, команда АБС), она попадает в утилизационную ловушку. Чтобы выпустить одну сквозную фичу для клиента, продуктовая команда вынуждена встать на поклон в 7–10 таких технологических колодцев. Каждая задача застревает во встречных очередях Change Requests (CR). И вот тут начинается самое интересное. Если выгрузить бэклог и раскрасить задачи в цвета тех компонентных команд, которые должны делать интеграции, мы увидим страшный HeatMap. Что показывает HeatMap бэклога в реальности: 1️⃣ ИТ-отдел утилизирует сам себя: инженеры платформы загружены «с горкой», но 80% их энергии уходит на перекладывание задач из одного ИТ-силоса в другой, согласование внутренних интерфейсов и бесконечные созвоны по стыковке компонентов. Это ложная, паразитная утилизация. 2️⃣ Время «протухания» задач превышает время работы: чистая разработка фичи занимает 3 дня, но более 60% календарного времени жизненного цикла задачи — это чистый простой в очередях ожидания ответов от смежников. 3️⃣ Паралич квартального планирования: попытка расписать «головы» компонентных команд на 3 месяца вперед в динамичном бизнесе создает лишь иллюзию порядка. Как только одна команда сдвигает сроки на неделю, по принципу «эффекта домино» рушатся планы остальных колодцев, превращая бэклог в хаос. Проблема не в лени программистов, а в том, что структура спроектирована под обслуживание ИТ-систем, а не под путь клиента. Нужно перестать делить "головы" на квартальных планированиях и пересобрать инженеров в кросс-функциональные домены. 🚀 Что мы будем делать на практикуме в клубе Scrum-Mastery? Построение и защита HeatMap бэклога - это высший пилотаж организационного консалтинга, который мгновенно переводит агентов изменений из роли «модератора встреч» в статус стратегического партнера для C-Level. На ближайшем потоке клуба мы вместе возьмем реальный обезличенный бэклог компании, находящейся в утилизационном тупике, и по шагам разметим его тепловую карту и вместе проанализируем. 🎟 Доступ к практикуму, шаблонам и видеозаписи открыт для всех резидентов клуба. Занимайте свое место в контуре изменений по ссылке:Ссылка скрыта 👉 Оформить абонемент и войти в клуб Scrum-Mastery #ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency #HeatMap #InsideOut

💡 Аксиоматика Нама Су: как развязать организационные узлы и спроектировать автономную команду полного цикла Бывало ли у вас так: вы собрали отличную команду, настроили процессы, РО горит идеей, но фичи все равно выходят раз в квартал? Вы заходите на ретроспективу, а разработчики разводят руками: «Мы все написали за два дня, но задача уже месяц висит на согласовании в безопасности, ждет ответа рисков и доработок от команды интеграционной шины». Поздравляю, вы уперлись в «паразитный замок» организационной связанности. Когда команда делает руками только 30% задачи, а остальные 70% времени фича простаивает в очередях к смежникам — это не проблема плохих людей или плохой фасилитации. Это ошибка проектирования структуры. И лечится она не тренингами, а методологией аксиоматического проектирования MIT (теория Нама Су). Три типа организационного дизайна: В каком лабиринте вы застряли? Нама Су разделил архитектуру любых систем (включая оргструктуры) на три типа по уровню связанности элементов (Coupling): 1️⃣ Связанный дизайн (Coupled Design): Это то, где сейчас живет 90% корпоративного рынка. Ситуация, когда для выполнения одной бизнес-задачи требуется одновременное, синхронное участие множества смежных компонентных команд, ИТ-комитетов и согласующих органов. Система блокирует сама себя. Шаг изменений тут равен не спринту, а кварталу - пока все колодцы не согласуют ресурсные планы. 2️⃣ Последовательный дизайн (Decoupled Design): Зависимости между командами существуют, но они асинхронны и стандартизированы. Команда автономна, потому что все ключевые эксперты (бизнес, ИТ, Риски, ИБ) физически выведены из своих «функциональных колодцев» и на 100% времени выделены внутрь продуктовой группы. Смежники больше не пишут друг другу Change Requests - они собирают фичи на лету. 3️⃣ Независимый дизайн (Uncoupled Design): Каждый юнит закрывает свою бизнес-потребность полностью самостоятельно. Изменение приоритетов одного процесса никак не аффектит другие. Большинство агентов изменений пытаются разогнать команду, находящуюся в жестком Coupled-дизайне, с помощью локальных действий: сокращают дейли, меняют форматы ретро. Но законы физики оргдизайна неумолимы: локальная оптимизация в связанной системе дает нулевой эффект на выходе. Чтобы сдвинуть сократить t2m, Скрам-мастер обязан действовать как архитектор: взять матрицу взаимодействия, найти связанные узлы, убрать паразитное вето смежников и помочь топ-менеджменту пересобрать «наилучшую комбинацию команды полного цикла». На ближайшем потоке нашего клуба мы переходим от теории к суровому орг.проектированию. Мы будем учиться перестраивать системы «снаружи внутрь» - от клиента и бизнес-целей. И одно из первых занятий будет посвящено как раз практике аксимоматического проектирования. Что хотим сделать: - Разберем живой, реальный кейс, который застрял в утилизационной ловушке. - Своими руками построим Матрицу связанности и найдем точки разрывов. - Спроектируем целевую Decoupled-структуру пилотного контура. - Сформируем пошаговый тактический бэклог задач, который Скрам-мастер может внедрить в своей компании уже на следующий день. Доступ на воркшоп открыт только для действующих участников клуба. Чтобы занять свое место на проектировочной сессии, забрать готовые шаблоны матриц и развернуть свою карьеру в сторону системного консалтинга - оформляйте абонемент по ссылке ниже. 👉 Оформить абонемент и стать участником клуба Scrum-Mastery #ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency #AxiomaticDesign

❓Почему 9 из 10 agile-трансформаций не дают результата, или как перестать быть «секретарем Jira» Коллеги, давайте честно. Большинство из нас - Скрам-мастеров, Agile-коучей и лидеров трансформаций совершают одну и ту же классическую ошибку. Сценарий почти всегда одинаковый: 1. Приходим в команду / контур. 2. Видим симптомы: «дейли затянуты», «бэклог непрозрачен», «ретроспективы стали формальностью (если вообще есть)». 3. Начинаем «лечить» доступными инструментами: учим фасилитации, перенастраиваем воркфлоу в Jira, проводим очередные базовые тренинги. 4. Результат через 3 месяца: процессы буксуют в тех же точках. Почему? Потому что корень проблемы лежал вообще не в ритуалах. Главная ошибка: мы смотрим «изнутри наружу» (Inside-Out) Мы привыкли оценивать систему по локальным маркерам: по аккуратности логирования задач, по скорости закрытия тикетов, по утилизации и 100% загрузке разработчиков. Это классическая ловушка локальной оптимизации. Команда может идеально проводить дейли и закрывать спринты, но ценность до клиента не долетает месяцами, потому что задача «гниет» в очередях между ИТ-колодцами. Как перевернуть мышление: взгляд «снаружи внутрь» (Outside-In) Профессиональный организационный дизайн требует смотреть на систему глазами клиента и сквозного потока ценности. Нас должно волновать только одно: сколько календарных дней проходит от зарождения бизнес-идеи до ее фактического появления на продакшне (сквозной Time-to-Market), и какой процент времени задача реально разрабатывалась, а не висела в ожиданиях (Flow Efficiency). Но как только мы переводим фокус на сквозной поток, базовых Agile-гайдлайнов становится катастрофически не хватать. Чтобы поставить системе точный диагноз, «архитектору изменений» нужны фундаментальные инженерные инструменты: - Аудит организационного соответствия (например, Звезда Гелбрайта): чтобы увидеть, как метрики и структура компании прямо противоречат ее же рыночной стратегии. - Матрица функциональной связанности (Coupled/Decoupled Design по Наму Су): инструмент из методологии аксиоматического проектирования MIT, позволяющий математически точно вскрыть паразитные связи и блокирующие «права вето» между подразделениями. - Экосистемный VSM (Value Stream Mapping) «снаружи-внутрь»: картирование пути клиента, которое обнажает реальные «черные дыры» и простои на стыках между отделами (бизнесом, ИТ, рисками, ИБ). - Продуктовый HeatMap бэклога: тепловая карта, наглядно показывающая, какая доля задач команды намертво заблокирована внешними зависимостями, компонентными командами ядра или вендорами. От фасилитатора встреч к архитектору потока Будем откровенны: большинство агентов изменений на рынке не используют эти инструменты. Кто-то про них не знает, а кто-то сознательно избегает, потому что проектировать организационные интерфейсы гораздо сложнее, чем «провести ретро по-новому». Но именно этот технологический стек отличает модератора командных встреч от системного организационного инженера, способного разгрузить топ-менеджмент от микроменеджмента очередей и вернуть бизнесу коммерческую маневренность. В нашем клубе Scrum-Mastery мы будем полностью переворачивать понимание роли Скрам-мастера/агента изменений и переходить от фасилитации ритуалов к инженерии оргструктур. В следующих публикациях мы детально разберем каждый из этих инструментов, а в клубе будем разбирать примеры с реальными кейсами и оцифрованными результатами. Подключайтесь, чтобы не пропустить 👇 Ссылка скрыта #ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency

За последние месяцы я работал в нескольких проектах организационной диагностики. И каждый раз натыкался на одно и то же: Компания нанимает Agile-коучей, проводит тренинги по Scrum, внедряет Jira, рисует стикеры на ретро... А через полгода - те же жалобы: «время поставки не сократилось», «бизнес недоволен ИТ», «ИТ, как всегда, в шоколаде». И каждый раз я ловил себя на мысли: проблема не в людях. Проблема в дизайне системы. Можно бесконечно учить команды «правильно проводить дейли». Но если организационная структура связана так, что для выпуска одной фичи нужно синхронное согласие 9 ролей - никакие тренинги не помогут. Я уверен: без системного подхода к оргдизайну любые Agile-инициативы обречены. Это не вопрос «культуры» или «мотивации». Это вопрос архитектуры. Поэтому в новом сезоне клуба я решил сфокусироваться именно на этом. На инструментах, которые позволяют диагностировать систему, а не лечить симптомы. 🎯 Обновленный формат Я долго думал, как сделать сезон по-настоящему полезным. И понял: теория без практики бесполезна. Поэтому формат будет такой: 🛠 Разбор реальных практик - на каждом занятии разбираем живые кейсы из проектов: цифры «до/после», ошибки, подводные камни, как преодолевалось сопротивление стейкхолдеров. 📋 Домашка для работы со своими командами - после каждого модуля вы получаете готовый шаблон (опросник, матрицу, VSM, HeatMap), который применяете прямо на следующей неделе к своей собственной команде или проекту. Учитесь на своих реальных задачах. 🤝 Коллективный разбор результатов - каждое занятие начинаем с разбора ваших домашних работ: что сработало, где возникли затыки, как адаптировать инструмент под вашу специфику. Экспертная обратная связь + свежие идеи от сообщества. Готовим материалы. Кто с нами - ссылка здесь: Ссылка скрыта