У каждого scrum-мастера и agile-коуча хотя бы раз в жизни появляется команда, которая не видит путей для дальнейшего улучшения. В такой ситуации ретроспективы превращаются в мучительную пытку, а оправдывать их необходимость становится всё труднее и труднее.
Что же делать агенту изменений в такой ситуации? Как помочь команде открыть новые горизонты? Ведь именно мы призваны помогать организации и её сотрудникам встать на путь постоянного совершенствования (continuous improvement). К счастью, у меня как раз есть один рабочий рецепт.
🪄 Создаём пространство для инноваций с TRIZ
В случае с зашедшей в тупик командой отправной точкой для такого взгляда может быть одна из возможных вариаций освобождающей структуры TRIZ. Она заставляет группу взглянуть на знакомую проблему под новым углом. А регулярная ретроспектива как нельзя подходит для такого обсуждения!
Из каких же шагов она состоит?
🦹♂️ Для начала мы предлагаем команде примерять на себя роль суперзлодеев. Дайте им время, чтобы обдумать и записать ответы на вопрос:
«Что мы можем начать делать уже завтра, чтобы стать самой неэффективной командой на свете?».
Попросите разместить стикеры в колонку один под другим и дайте группе время на изучение и уточнение вариантов. Этот этап представляет собой фазу обратного мозгового штурма, поэтому не стоит ограничивать фантазию участников.
🧲 Прежде чем перейти к следующему этапу, мы добавляем на доску ещё одну колонку. После этого спрашиваем команду:
«Положа руку на сердце, что из этих вещей мы уже делаем как команда?»
Предложите участникам обсудить и передвинуть подходящие стикеры в новую колонку. Во избежание недопониманий можно сверяться по каждому стикеру, используя consensus check.
💡 После этого можно переходить к обсуждению решений выявленных проблем. Лично я люблю подходить к этому этапу творчески и часто предлагаю следующий вопрос:
«Какие из этих проблем мы можем решить, не вводя новых правил? Как?»
Такой вопрос помогает команде посмотреть на возможные улучшения своих процессов, договорённостей и взаимодействия сквозь призму Lean. То есть решить проблемы не путём добавления новых правил, а устраняя уже имеющиеся процессы, которые не приносят пользы.
Так, одна из моих команд решила убрать обязательный апрув от владельца сервиса на этапе code review. Данное требование сильно замедляло скорость разработки при сомнительной пользе: «владелец» являлся постоянным членом другой команды и не был погружён в контекст решаемых проблем.
🚦 Важные сигналы
Неспособность команды идентифицировать возможные улучшения даже в таком формате служит для нас важным сигналом. Это может не просто говорить о достижении плато в командной динамике, но и служить косвенным признаком приближения серьёзного кризиса. Подобная ситуация может потребовать других мер, таких как перезапуск команды или смена состава.
Проведение же подобной ретроспективы в новой команде (как на фото) может принести обратный эффект. Ворох вскрывшихся проблем и противоречий, часть из которых не может быть решена на данном этапе развития команды, только демотивирует участников.
Поэтому будьте осторожны — не повторяйте моей ошибки. И не говорите потом, что я не предупреждал! 😉
Денис 💚
Что же делать агенту изменений в такой ситуации? Как помочь команде открыть новые горизонты? Ведь именно мы призваны помогать организации и её сотрудникам встать на путь постоянного совершенствования (continuous improvement). К счастью, у меня как раз есть один рабочий рецепт.
🪄 Создаём пространство для инноваций с TRIZ
В случае с зашедшей в тупик командой отправной точкой для такого взгляда может быть одна из возможных вариаций освобождающей структуры TRIZ. Она заставляет группу взглянуть на знакомую проблему под новым углом. А регулярная ретроспектива как нельзя подходит для такого обсуждения!
Из каких же шагов она состоит?
🦹♂️ Для начала мы предлагаем команде примерять на себя роль суперзлодеев. Дайте им время, чтобы обдумать и записать ответы на вопрос:
«Что мы можем начать делать уже завтра, чтобы стать самой неэффективной командой на свете?».
Попросите разместить стикеры в колонку один под другим и дайте группе время на изучение и уточнение вариантов. Этот этап представляет собой фазу обратного мозгового штурма, поэтому не стоит ограничивать фантазию участников.
🧲 Прежде чем перейти к следующему этапу, мы добавляем на доску ещё одну колонку. После этого спрашиваем команду:
«Положа руку на сердце, что из этих вещей мы уже делаем как команда?»
Предложите участникам обсудить и передвинуть подходящие стикеры в новую колонку. Во избежание недопониманий можно сверяться по каждому стикеру, используя consensus check.
💡 После этого можно переходить к обсуждению решений выявленных проблем. Лично я люблю подходить к этому этапу творчески и часто предлагаю следующий вопрос:
«Какие из этих проблем мы можем решить, не вводя новых правил? Как?»
Такой вопрос помогает команде посмотреть на возможные улучшения своих процессов, договорённостей и взаимодействия сквозь призму Lean. То есть решить проблемы не путём добавления новых правил, а устраняя уже имеющиеся процессы, которые не приносят пользы.
Так, одна из моих команд решила убрать обязательный апрув от владельца сервиса на этапе code review. Данное требование сильно замедляло скорость разработки при сомнительной пользе: «владелец» являлся постоянным членом другой команды и не был погружён в контекст решаемых проблем.
🚦 Важные сигналы
Неспособность команды идентифицировать возможные улучшения даже в таком формате служит для нас важным сигналом. Это может не просто говорить о достижении плато в командной динамике, но и служить косвенным признаком приближения серьёзного кризиса. Подобная ситуация может потребовать других мер, таких как перезапуск команды или смена состава.
Проведение же подобной ретроспективы в новой команде (как на фото) может принести обратный эффект. Ворох вскрывшихся проблем и противоречий, часть из которых не может быть решена на данном этапе развития команды, только демотивирует участников.
Поэтому будьте осторожны — не повторяйте моей ошибки. И не говорите потом, что я не предупреждал! 😉
Денис 💚