Кейс 🧳 Бэклог скрам-мастера
Привет! В первой статье коротко представлюсь и расскажу о последнем месте работы.
Меня зовут Артем, работаю Agile лидом в крупном телеком операторе. Отвечаю за agile практики, найм и развитие скрам-мастеров и аджайл коучей в кластере (у нас кластер - структура от 300 до 2000 человек, состоящие преимущественно из it-специалистов в продуктовых командах). Кластер, в котором я работаю, состоит из 1000+ человек и 30+ продуктов экосистемы компании, преимущественно b2c. Сейчас в нашем кластере 14 скрам-мастеров и аджайл коучей, рад и горд работать с каждым из них. Теперь перейдем к самой теме статьи.
____________________________________________________________________________
На мой взгляд, главная польза от скрам-мастера - в диагностике, особенно построенной на метриках и артефактах. Но диагностику не делают. Если и делают - то понимают под этим разное (от цифр и метрик, что мне ближе, до взаимодействия команды внутри, настроений и конфликтов). При этом часто встречается такой подход:
💭 "В продукте нет DoD и DoR. Cрочно поставить встречу и сформировать с командой!"
💭 "команда не проводит PBR, у них наверное с бэклогом и планированием беда - надо срочно их спасать."
💭 Мое любимое - “в команде дейли больше 15 минут! Ретро не проводят! Камеру не включают! Там еще работать и работать!”
Сами по себе эти предположения не плохие и не хорошие, просто их важность и влияние не обоснованы.
🤔 Почему именно PBR сейчас наиболее важен?
🤔 Есть ли в команде процессы, решающие эти проблемы без PBR?
🤔 Что именно плохого в том, что дейли не укладывается в 15 минут? и так далее. В нашем кластере мы со скрам-мастерами решили поэкспериментировать.
📜 Мы договорились о следующем формате и этапах:
1️⃣ Диагностика
В начале важно понять, как работает текущий процесс as is. Если этого не сделать, то сначала будет сложно обосновать само изменение, а после - эффект от этого изменения.
🧩 Value Stream Mapping (VSM) в Miro (под этим могут пониматься разные действия. Ссылка ведет на мою статью о VSM)
🧩 чек-листы диагностики. Это могут быть как чек-листы, принятые в компании (матрицы зрелости), так и кастомные
🧩 слепок по метрикам (как минимум за квартал). Сейчас в компании есть автоматизированный дашборд, но раньше мы без особых проблем брали это руками из Jira
🧩 анализ CFD(cumulative flow diagram).
🧩 серия интервью с ключевыми участниками о важных проблемах (СРО/PO, СТО и кто угодно еще).
2️⃣ Бэклог гипотез о проблемах
Данные с предыдущего шага позволят нам комплексно посмотреть на процесс и сформировать наши гипотезы о проблемах. Это именно гипотезы. Мы предполагаем, что это является проблемой. Если эта гипотеза покажется важной и мы возьмем ее в работу, то после реализации решения мы поймем, было ли это проблемой на самом деле. Как PO проверяет гипотезы своего продукта, так и мы проверяем гипотезы своего процесса.
3️⃣ Бэклог гипотез о решениях
На этом этапе мы формируем гипотезы того, что может решить ту или иную проблему. Мы предполагаем, что настройка PBR поможет улучшить качество планирования и соответсвенно прогнозы. А может и нет. Если бэклог Спринта меняется в течение самого спринта и не раз - то какая разница, что переносить/убирать/добавлять и в итоге не доделывать?)
Только на этом этапе мы формируем то, что раньше делали сразу. Но уже формируем эти идеи не потому, что этого нет в процессе сейчас, а потому что нашли, какую это может решить проблему и на что повлиять.
4️⃣ Метрика
Для каждой гипотезы проблемы/решения, где это возможно - мы формулируем метрику. Это можно сделать не всегда, но почти всегда.
Например, по серии интервью мы поняли, что важным источником неудовлетворенности является большое количество багов. Проблема ли это? не ясно.
🤔 Большое количество - это какое? Мы можем посмотреть их число, даже в привязке к релизу/эпику.
🤔 Второй вопрос - много за какой период? за спринт? или за квартал? или был большой релиз, он был такой один уникальный и вот с него пришло много багов?
🤔 Третий вопрос - багов каких? с прода? при тестировании? и так далее
В зависимости от ответов на эти вопросы может меняться и способ решения.
Любые слова “долгий”, “мало”, “много”, “плохой” и другие подобные должны служить триггером для уточнения.
В конце этого этапа гипотезы о проблемах нужно приоритизировать. Можно просто поговорить с СРО/СТО/другими основными участниками и вместе с ними выявить наиболее важные. Мы так же используем построение связей и зависимостей для упрощения приоритизации.
5️⃣*Построение связей
Некоторые скрам-мастера в работе с бэклогом пошли дальше и сформировали причинно-следственные связи. Это позволило выявить решения, которые могут повлиять сразу на несколько проблем. Можно строить связи стрелочками, а можно упороться и построитьCLD.
6️⃣ Action Plan
То, с чем мы идем договариваться с командой. К этому моменту помимо самого плана у нас есть данные as is. Каждый пункт из плана можно аргументировать. А после изменения - проверить эффект. Вместе с командой мы можем обсудить этот план и скорректировать.
🏁 Заключение
В итоге мы получаем то, с чем можно работать и проверить, в отличие от уровня доверия, напряженности и подобного. Поэтому этим субъективным моментам в диагностике я уделяю меньший приоритет, но тоже делаю при необходимости.
Этот подход сейчас используют все скрам-мастера нашего кластера. В этом подходе нет “серябряной пули”, сакрального секрета и чего-то уникально нового. Но у нас это работает хорошо. Может и у тебя сработает?