Я не раз сталкивалась с этим запросом от моих менти и коллег скрам-мастеров.
🗣 Дебаты о том, как оценить работу скрам-мастера и понять, что он делает нефигню, ведутся уже очень давно в профильных чатах и комьюнити, на конференциях и митапах.
Потребность оценить, что и зачем делает агент изменений, связана с непрозрачностью причин изменений, которые он запускает. Гораздо проще, если видна прямая связь: вот проблема, а вот очевидное решение этой проблемы. Но чаще скрам-мастера внедряют изменения, которые играют вдолгую, и причины этого внедрения не сразу очевидны команде или менеджменту.
🔥 Ещё не пожар, ещё не горит, так зачем мы это делаем?
Тут мне на выручку приходит Causal Loop Diagram (CLD) — инструмент системного мышления.
Вообще CLD — это инструмент групповой работы, и его лучше использовать всей командой. Но также я использую CLD, чтобы объяснять логику своих решений.
🧩 Вот один из кейсов, которые мы сейчас разбираем с моим менти:
Его команда некоторое время назад перешла на канбан-метод, чтобы обеспечить себе предсказуемость поставки и нужную скорость выпуска задач. Провели STATIK, собрали доску, выбрали каденцию пополнения, договорились о WIP-лимитах, а предсказуемости как не было, так и нет 😕 Если смотреть на диаграмму распределения времени, то она пугает колоссальным разбросом срока выполнения — до 30 недель.
Несмотря на то что договорённость по WIP-лимитам есть, каждый раз на встрече по пополнению мой менти сталкивается с сопротивлением команды.
🤷♂️ Почему так важно брать одно и то же количество задач?
Как можно грамотно аргументировать и объяснить команде своё решение?
Я в таких случаях рисую CLD!
Вот как я бы объясняла команде ход своих мыслей:
Чем больше разброс в количестве задач, которые мы берём в работу, тем ниже консистентность данных. Чем она ниже, тем меньше точность статистики. Чем ниже точность статистики, тем меньше предсказуемость. А чем она ниже, тем больше тревожность бизнеса. Чем больше тревожность бизнеса, тем ниже его удовлетворённость. Ну а чем менее удовлетворён бизнес, тем меньше мотивация команды поддерживать одинаковое пополнение и тем меньше вероятность, что команда будет брать в работу каждый раз одно и то же количество задач.
👀 Как эта диаграмма выглядит, вы можете посмотреть на картинке внизу.
🖍 Как именно я создавала диаграмму?
1️⃣ Сначала выписала максимум понятных мне элементов системы, или переменных: предсказуемость поставки, стабильность количества задач, точность статистики, удовлетворённость бизнеса и так далее.
2️⃣ Потом проставила связи между этими переменными.
Важно помнить, что и переменные, и связи — нейтральные, их нейтральность помогает правильно читать CLD и видеть именно систему, а не набор случайно связанных друг с другом единичных событий.
3️⃣ Дальше я проверила, что CLD читается правильно и логично и действительно образует замкнутую систему. Для этого прочитала диаграмму сначала с условием, что команда пополняет систему каждый раз на одно и то же количество задач, а потом ещё раз перечитала при условии, что команда пополняет систему каждый раз по-разному.
4️⃣ Последним шагом я рассказываю команде эту логику на совместной встрече и отрабатываю возражения. Это я и предложила проделать моему менти.
Для того чтобы ваша логика была понятна команде и менеджменту, можно использовать и другие способы аргументации, но мне неизменно помогает Causal Loop Diagram. Этот инструмент помогает поднимать прозрачность и повышает осознанность команды.
Наташа 💫
🗣 Дебаты о том, как оценить работу скрам-мастера и понять, что он делает нефигню, ведутся уже очень давно в профильных чатах и комьюнити, на конференциях и митапах.
Потребность оценить, что и зачем делает агент изменений, связана с непрозрачностью причин изменений, которые он запускает. Гораздо проще, если видна прямая связь: вот проблема, а вот очевидное решение этой проблемы. Но чаще скрам-мастера внедряют изменения, которые играют вдолгую, и причины этого внедрения не сразу очевидны команде или менеджменту.
🔥 Ещё не пожар, ещё не горит, так зачем мы это делаем?
Тут мне на выручку приходит Causal Loop Diagram (CLD) — инструмент системного мышления.
Вообще CLD — это инструмент групповой работы, и его лучше использовать всей командой. Но также я использую CLD, чтобы объяснять логику своих решений.
🧩 Вот один из кейсов, которые мы сейчас разбираем с моим менти:
Его команда некоторое время назад перешла на канбан-метод, чтобы обеспечить себе предсказуемость поставки и нужную скорость выпуска задач. Провели STATIK, собрали доску, выбрали каденцию пополнения, договорились о WIP-лимитах, а предсказуемости как не было, так и нет 😕 Если смотреть на диаграмму распределения времени, то она пугает колоссальным разбросом срока выполнения — до 30 недель.
Несмотря на то что договорённость по WIP-лимитам есть, каждый раз на встрече по пополнению мой менти сталкивается с сопротивлением команды.
🤷♂️ Почему так важно брать одно и то же количество задач?
Как можно грамотно аргументировать и объяснить команде своё решение?
Я в таких случаях рисую CLD!
Вот как я бы объясняла команде ход своих мыслей:
Чем больше разброс в количестве задач, которые мы берём в работу, тем ниже консистентность данных. Чем она ниже, тем меньше точность статистики. Чем ниже точность статистики, тем меньше предсказуемость. А чем она ниже, тем больше тревожность бизнеса. Чем больше тревожность бизнеса, тем ниже его удовлетворённость. Ну а чем менее удовлетворён бизнес, тем меньше мотивация команды поддерживать одинаковое пополнение и тем меньше вероятность, что команда будет брать в работу каждый раз одно и то же количество задач.
👀 Как эта диаграмма выглядит, вы можете посмотреть на картинке внизу.
🖍 Как именно я создавала диаграмму?
1️⃣ Сначала выписала максимум понятных мне элементов системы, или переменных: предсказуемость поставки, стабильность количества задач, точность статистики, удовлетворённость бизнеса и так далее.
2️⃣ Потом проставила связи между этими переменными.
Важно помнить, что и переменные, и связи — нейтральные, их нейтральность помогает правильно читать CLD и видеть именно систему, а не набор случайно связанных друг с другом единичных событий.
3️⃣ Дальше я проверила, что CLD читается правильно и логично и действительно образует замкнутую систему. Для этого прочитала диаграмму сначала с условием, что команда пополняет систему каждый раз на одно и то же количество задач, а потом ещё раз перечитала при условии, что команда пополняет систему каждый раз по-разному.
4️⃣ Последним шагом я рассказываю команде эту логику на совместной встрече и отрабатываю возражения. Это я и предложила проделать моему менти.
Для того чтобы ваша логика была понятна команде и менеджменту, можно использовать и другие способы аргументации, но мне неизменно помогает Causal Loop Diagram. Этот инструмент помогает поднимать прозрачность и повышает осознанность команды.
Наташа 💫