Дневник Скрам-мастера

Управление проектами

Дневник Скрам-мастера
Программирование
Подписаться
Для проведения изменений можно использовать модель шести шагов изменения. Это цикл:


1. Сформируйте осознание необходимости изменений (Ретроспективы в помощь).
2. Создайте руководящую коалицию (Заручитесь поддержкой лидеров и руководства).
3. Сформулируйте видение и разработайте стратегию (https://t.me/myscrum/124).
4. Отвечайте на сопротивление (https://t.me/myscrum/125).
5. Управляйте переход (напомни, как-нибудь расскажу про Контур управления).
6. Поддерживайте темп. Пробуй. У тебя все получится!

Дневник Скрам-мастера
Программирование
Подписаться
Сопротивление изменениям.

Оно есть всегда. Людей пугает необходимость изменений. Если снова вспомнить формулу изменений, то для того, чтобы изменение произошло должно быть:
1. Недовольство текущей ситуацией большой группы или "большого человека".
2. Видение будущего после проведения изменения большой группы или "большого человека".
3. Безопасный первый шаг, с возможностью вернуться назад в предыдущее состояние.
4. Все эти пункты не должны превышать затраты
- материальные, временные,эмоциональные и пр.Если все это соблюдается
- изменение очень вероятно произойдет. Отсюда вытекают причины сопротивления. Их немного (основано на Кантер (Kantor), цитируется по Лоренцу (Lorenz), 1985):
1. Потеря контроля. Ощущение у людей, что изменения проводят "над ними", а не они.
2. Потеря лица. Кто-то теряет лицо или статус.
3. Утрата идентичности (самоопределения). Расставание с прежними символами и традициями.
4. Утрата компетентности. Прежняя компетентность становится ненужно. Например при смене технологии и инструмента.
5. Личная неопределенность. Когда люди не знают к чему приведут изменения. Это их пугает.
6. Неожиданность. Внезапные изменения. Вызывает скепсис и оборонительную реакцию.
7. Больше работы. Частая ситуация. Работы становится все больше.
8. Прошлые обиды. Люди сопротивляются, если инициатор доставлял им неприятности в прошлом.
9. Неопределенные последствия. Изменения в одной области приведут к неопределенности в другой.
10. Реальные угрозы. Угроза как индивидуальным, так и групповым интересам
- закрытие проекта, потеря бюджета и пр. Как с этим работать? Составляете план приверженности (я называю это матрицей изменений) https://t.me/myscrum/10 Для каждой строки (человека или группы лиц) описываете причину сопротивления и подбираете подходящую стратегию. Дальше работаете с сопротивлением.

Дневник Скрам-мастера
Программирование
Подписаться

Как то в начале дневника я упоминал про то, как можно работать с изменениями https://t.me/myscrum/9 Там я рассказывал про формулу изменений и матрицу изменений (план приверженности). Сегодня хочу поделиться основными причинами сопротивления изменениям и стратегиями работы с этим сопротивлением. Я обещал рассказать об этом Артему Летюшеву (@artemletya). Придумал не я. Эти материалы я взял из оконченного мной курса MBA Открытого университета Великобритании (Книга
3. Управление организацией и персоналом: Учебное пособие для слушателей/Пер. с англ.
- АНО ВО МИМ ЛИНК, 2019). Это работает и помогает. Я применяю это в своей работе, проверено все это многократно. Итак есть пять классических операционных стратегий управления изменениями:
1. Директивная стратегия. Быстрая. Степень сопротивления высокая. Сопротивление ломают.
2. Экспертная стратегия. Достаточно быстрая. Управление изменением как технической проблемой. Привлечение специалистов-экспертов при поддержке сверху. Степень сопротивления выше средней.
3. Переговорная стратегия. Средний темп. Переговоры и уступки. Вовлечение в изменение. Сопротивление среднее и ниже среднего.
4. Образовательная стратегия. Медленная. Формирование видения будущего (вспоминаем второй элемент формулы изменений https://t.me/myscrum/9) Сопротивление небольшое. Формирование приверженности изменениям.
5. Стратегия участия. Медленная. Вовлечение участников. Формирование группы энтузиастов-волонтеров. Сопротивление низкое. Стратегии эти применяются для различных людей и групп людей. Нет одинаковой стратегии для всех. Для проведения изменений можно использовать матрицу, которую я описывал https://t.me/myscrum/10. Дальше я расскажу про причины сопротивления.

Дневник Скрам-мастера
Программирование
Подписаться
Сегодня на Ретроспективах в четырех командах работали с Causal Loop Diagram.

Работали с потерями. Для начала мы выявили самые затратные по времени действия, которых можно было избежать и которые явились для команды Muda (термин из Lean, означающий потери). Команды сами отобрали такие действия и ранжировали их. Выбрали самые затратные из них. А потом уже мы вместе рисовали саму диаграмму с прямыми и обратными связями (P и N на моей диаграмме соответственно). В трех из четырех команд мы выявили самоусиливающиеся петли обратной связи, завязанные на одну из причин потерь. Самоусиливающиеся это когда одна из причин усиливаясь, влияет на другую причину, та на еще ряд причин и последняя из них влияет на исходную. Петля усиливается, если равновесие нарушается. Интересный инструмент системного мышления. Но рисовать в такие диаграммы в одиночку бессмысленно
- только с командой. Подробно на русском об этом рассказано в переводе https://less.works/ru/less/principles/systems-thinking

Дневник Скрам-мастера
Программирование
Подписаться
Сегодня провожу Обзор Спринта.

Одиннадцать команд. Собрание на 95 человек в онлайн. Команды рассказывают и показывают сделанное за Спринт. Приглашенные гости
- бизнес, крупные клиенты, партнеры, разработчики дают обратную связь. Укладываемся в 2 часа. Но мы ожидаем дальнейшего роста количества команд. Скорее всего формат придется менять.

Дневник Скрам-мастера
Программирование
Подписаться
Поучаствовал в переводе «Kanban guide for Scrum teams».
Дневник Скрам-мастера
Программирование
Подписаться
Сегодня снова встретил чудесное - " Из прошлого надо брать огонь, а не пепел".

Сегодня снова встретил чудесное
- "Из прошлого надо брать огонь, а не пепел". Тоже ведь про Скрам-мастера и его модель поведения.

Дневник Скрам-мастера
Программирование
Подписаться
" Не надо сгибаться под ветром, который ещё не подул".

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

Дневник Скрам-мастера
Программирование
Подписаться

Вчера на Ретроспективе команды Владельца Продукта (да, есть у нас и такое) воспользовался для погружения участников вопросом, который я подсмотрел в канале Scrum тренера Андрея Толмачева Growth Ninja. Андрей очень интересный человек, несколько лет назад он участвовал в запуске Scrum в нашей организации. И вопрос очень интересный
- Сколько нового мы узнали за прошедший Спринт о рынке, клиентах, и их проблемах? Я стащил картинку и разместил ее на своей доске в Miro. Коллеги точками показали свое мнение. А потом я дал слово каждому, кто хотел рассказать о том, почему он поставил точку именно в эту позицию. Было интересно. Мне кажется полезным думать об этой теме, особенно для продуктовых команд. Возможно и Тебе пригодится https://t.me/growth_ninja/3

Дневник Скрам-мастера
Программирование
Подписаться
Начал снова использовать для проведения Ретроспективы Miro.

Сегодня взял три вопроса для разминки из чата "Нестыдная фасилитация" https://t.me/no_shame_facilitation/78 Miro бесплатный, поэтому начал формировать одну доску для всех команд, добавляя туда новые инструменты для фасилитации.

Дневник Скрам-мастера
Программирование
Подписаться
Сегодня день многокомандного PBR.

Это выделенный день, когда все команды уточняют элементы Бэклога для следующего Спринта
- оценивают их, готовят приемочные критерии, обсуждают варианты реализации. У нас нет выделенных аналитиков, над прояснением работают все разработчики. По итогу мы получим список элементов, которые будут использоваться для Планирования в начале следующего Спринта (через три рабочих дня). Для работы мы используем такой инструмент Zoom как Сессионные залы. В данном случае мы создали 4 зала, которые названы по наименованию наших эрий (доменные зоны Продукта). В каждой эрии есть Area Product Owner (АРО), который работает над прояснением Бэклога в соответствующем зале вместе с разработчиками. Также в мероприятии участвует бизнес (отдел по работе с крупными клиентами), представители технической поддержки и конечно же Product Owner (он у нас один). Участники могут перемещаться из зала в зал и помогать друг-другу. В 16:00 мы встретимся в общем зале и обсудим результаты своей работы.

Дневник Скрам-мастера
Программирование
Подписаться

Обзор Спринта. Восемьдесят участников. Четыре эрии (домена). Уже десять команд. Растем!

Дневник Скрам-мастера
Программирование
Подписаться

Сегодня для проведения PBR (Product Backlog Refinement
- уточнение Бэклога Продукта) семью командами используем такой механизм Zoom как "Сессионные залы". Все участники (а их около сорока человек) распределяются по заранее созданным изолированным залам. Каждый зал это список элементов Бэклога по темам, который необходимо проработать до такого состояния, чтобы элемент можно было взять в работу на следующий Спринт. Разработчики могут перемещаться между залами, помогая друг-другу. Участники работают самостоятельно, на принципах самоорганизации. Фасилитируют процесс два Скрам-мастера (один из них я). К концу дня мы получим список оцененных элементов "Sprint Ready". В следующий понедельник эти элементы будут взяты в работу командами на Планировании.

Дневник Скрам-мастера
Программирование
Подписаться

Бывает, что элемент Бэклога (в формате User Story) попадает на Планирование буквально накануне. Это редко, но случается. В этом случае для понимания сложности, объема работы и неопределенности (не времени выполнения) по ходу планирования производится оценка с помощью Planning Poker. Если элемент больше 5 SP (Story Points), то мы также готовим приемочные критерии, необходимые для ответа на вопрос "Как мы поймем, что элемент готов в части функциональных требований?". Оценка нужна не для оценки времени (мы не знаем заранее какая команда будет работать с этим элементом
- в разной команде будет разная оценка времени), а лишь для выравнивания общего понимания. Оценка теряет смысл сразу после начала работы на элементом в Спринте. Мы используем стандартный инструмент "Опросы" от Zoom. Если оценки расходятся, как в данном случае, то мы просим высказаться только тех, у кого самые большие или самые маленькие оценки, обсуждаем и голосуем заново. Голосуют только разработчики (с любой специализацией, включая QA и UX/UI).

Дневник Скрам-мастера
Программирование
Подписаться
Понедельник.

Общее планирование на 7 команд и 49 участников онлайн. Эта часть планирования даст нам ответ на вопрос ЗАЧЕМ мы собрались на этот Спринт и ЧТО мы будем делать в этом Спринте, чтобы достичь Продуктовой цели. Не позднее чем через два часа команды разойдутся в малые группы на заключительную часть планирования, по результатам которой они будут понимать КАК они будут достигать Цель Спринта. Спринт начался!

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...