Решил начать вести свой канал. Ну как канал. Дневник. Дневник Скрам-мастера. Буду записывать сюда свои наблюдения, практики, мысли и возможно давать ссылки на используемые книги и материалы. Ссылок много не хочется. Постараюсь давать только то, что использую в своей работе.
Немного о себе. Меня зовут Господчиков Сергей. Я Скрам-мастер. Я каждый день работаю с четырьмя командами разработчиков программного обеспечения. Мы практикуем LeSS (Large Scale Scrum). Точнее уже перешли LeSS Huge. LeSS это Scrum. Масштабируемый Скрам. Там добавлено лишь одно дополнительное событие. Называется оно Overall Retrospective. Это когда представители (2-3) всех команд собираются вместе и обсуждают имеющиеся проблемы на Общей ретроспективе. Мне близки ценности и принципы Agile манифеста. На досуге я занимаюсь переводом различным материалов по Agile тематике. Я поучаствовал в переводах Scrum Guide-2020, Nexus Guide и Kanban for Scrum Teams Guide.
Я не преследую цель набрать подписчиков и продвигать свои услуги. Это просто дневник. Будни Скрам-мастера. Читать его или нет - решать вам.

Пятница и следующий вторник у меня день ретроспектив. С тех пор как я стал Скрам-мастером каждая моя ретроспектива не повторяет предыдущую. Я использую одинаковый сценарий для каждой из четырех команд. Но они не повторяются от Спринта к Спринту. В этот раз с командами я использовал следующий вариант:

НАЧАЛО
Вместо обсуждения проблем сфокусируйте группу на позитивных моментах через формулирование позитивной цели ретроспективы, например:
Давайте обсудим как расширить наш лучший опыт использования инженерных практик

СБОР ИНФОРМАЦИИ
Проверьте себя на соответствие Agile чеклисту
Распечатайте чеклист, который лучше всего поможет команде идентифицировать зоны роста. Например:
Чеклист по инженерным agile практикам
Пройдитесь с командой по чеклисту. Соберите обратную связь, чтобы понять что хорошо и что плохо.
Обсудите где вы находитесь сейчас и в правильном ли направлении двигаетесь.
Это упражнение хорошо подходит когда итерация прошла гладко без инцидентов.

ФОРМИРОВАНИЕ ПОНИМАНИЯ
Докопаться до корневых причин проблемы постоянно задавая вопрос 'Почему?'
Объедините участников в малые группы (не более 4-х человек) и дайте каждой группе одну из выявленных проблем. Проинструктируйте группы:
Кто-то один постоянно задает вопрос 'Почему это произошло?' чтобы прояснить цепочку событий и выявить корневую причину
Запишите корневую причину (обычно это ответ на пятый вопрос 'Почему?')
Попросите группы поделиться своими результатами друг с другом.

ВЫРАБОТКА ПЛАНА ДЕЙСТВИЙ
Поставили перед собой большую цель? Определяем, какие шаги ведут к ней
Раздайте стикеры и маркеры. Опишите важную проблему, которую вы хотите решить, и приклейте стикер повыше на стену или доску. Попросите участников записать, что они могут сделать для решения проблемы. Повесьте стикеры с их идеями под первым стикером. Повторите то же самое для каждого стикера второго уровня. Можно ли осуществить идею за одну итерацию и понимают ли члены команды свою роль? Если ответ отрицательный, разбейте действие на этапы на следующем уровне дерева решения проблем.
Когда на нижнем уровне будут только понятные всем, краткосрочные задачи, проголосуйте точками за действия для следующей итерации.

ЗАВЕРШЕНИЕ РЕТРОСПЕКТИВЫ
Помним о своих хороших намерениях
Мысленно вернувшись к прошлым обсуждениям, участники делают памятку для самих себя о том, что им бы хотелось изменить в собственном поведении в ходе следующей итерации. Это упражнение на самоанализ — участники не делятся результатами с группой. Каждый участник забирает свой стикер и вешает у себя на рабочем месте.

Анкета инженерных практик (автор Мокевнин Кирилл)

Сегодня проводил ретроспективу у команды РО. Это понятие пришло к нам с LeSS Huge. Мы используем сейчас этот фреймворк. Он отличается от LeSS наличием одной дополнительной роли. Это Area Product Owner (АРО). Весь продукт разбивается на функциональный области (бывают различные варианты) - Эрии. В каждой эрии свой Владелец Эрии Продукта и набор команд. Авторы LeSS рекомендуют, чтобы это было от 4 до 8 команд. При этом Владелец Продукта (РО) остается единственным лицом. Он занимается бэклогом в "крупную клетку". Каждый элемент бэклога при этом получает признак эрии и для более детальной проработки уходит в команды соответствующей эрии. Команды работают с APO. За РО остается последнее слово в приоритетах элементов бэклога. При этом у нас остаются фиче команды. При этом у них единый Спринт, единый Инкремент, единый код и единый DoD Definition of Done (DoD). У нас три эрии. На момент перехода в них по две, а в одной эрии три команды. Такая структура готова для роста примерно до 30 команд.
Мы в команде РО решили как и команды использовать Скрам и работать Спринтами и также как и команды проводить ежедневные синхронизации и ретроспективы. Сегодня я использовал такой сценарий:

НАЧАЛО
Резюмируем последнюю итерацию в трёх словах
Попросите каждого участника описать последнюю итерацию тремя словами. Дайте одну минуту на размышления, затем выслушайте ответы. Это упражнение напомнит членам команды о прошедшей итерации, чтобы можно было с чего-то начать.

СБОР ИНФОРМАЦИИ
Чем гордятся и о чем сожалеют участники команды?
Разделите флипчарт на 2 колонки 'Гордость' и 'Сожаление'. Попросите участников записать на стикерах что вызывает чувство гордости, а что чувство сожаления. Каждая мысль на отдельном стикере. Когда участники закончат писать, попросите озвучить свои записи и наклеить в соответствующую колонку.
Начните групповое обсуждение задавая вопросы:
Что из озвученного удивило вас?
Какие выводы можно сделать?
Что это значит для нас, как для команды?

ФОРМИРОВАНИЕ ПОНИМАНИЯ
Что сделает следующую итерацию совершенной (на 10 баллов из 10)?
Разделите флипчарт на 2 колонки: узкая колонка 'Оценка' и широкая 'Улучшения'. Каждый оценивает прошедшую итерацию по шкале от 1 до 10. После чего группа должна предложить улучшения, которые сделают следующую итерацию идеальной (10 баллов из 10).

ВЫРАБОТКА ПЛАНА ДЕЙСТВИЙ
Участники предлагают и берут ответственность за действия
Подготовте флипчарт с 3 колонками 'Что', 'Кто' и 'Когда'. Спросите участников одного за другим, что они хотят сделать для улучшения команды. Запишите действие, договоритесь о том 'когда' оно должно быть сделано и попросите участника вписать своё имя.
Если кто-то предлагает действие для всей команды, то он должен договориться со всеми, чтобы они сами вписали своё имя.

ЗАВЕРШЕНИЕ РЕТРОСПЕКТИВЫ
Благодарим других членов команды и работаем над собой
Нарисуйте на доске таблицу с двумя столбцами: «Спасибо!» и «Моё действие». Попросите участников написать по одному стикеру для каждого столбца: за что я хочу поблагодарить коллегу; что я хочу изменить в своём поведении во время следующей итерации. Это может быть что-то незначительное. Пусть каждый прокомментирует свои ответы и приклеит стикеры на доску.

Как Скрам-мастеру помогать проводить изменения? Ведь он не может дать указания, у него нет подчиненных. Как понять, что изменение случится? Как сделать так, чтобы Тебе помогали?
Для этого есть интересные инструменты из теории управления изменениями. Я пользуюсь ими в работе. Сейчас я о них расскажу.
Первый инструмент я называю "Формула изменений". Что-то похожее я видел под названием "Формула перемен". Он очень простой и одновременно сложный. Его применяют ДО ИЗМЕНЕНИЙ, чтобы понять произойдет изменение или нет. A+B+C>D Первые три составляющие A,B,C должны пересилить D.
Первая составляющая А это весомая группа лиц и или одно весомое лицо (быть может кто-то из важных стейкхолдеров) которая недовольна текущей ситуацией, какой-то проблемой, которую Вы видите и задумали разрешить. Либо лиц много, либо их немного, но они имеют вес. Если эта составляющая мала, то недовольства нет и сдвинуть что-либо будет трудно. Изменение не случится.
Вторая составляющая В это все та же группа лиц или лица имеющие вес, но тут рассматривается видение перспективы. Точнее то, что мы получим в результате решения имеющейся проблемы. Быть может - куда мы придем в результате. Что-то конкретное и осязаемое. И снова как с первым слагаемым - если понимания нет, то никто туда не пойдет. Изменение не случится.
Третья составляющая C это возможность сделать первый безопасный шаг, с возможностью вернуться назад в случае первых же неудач. Безопасный, быть может недорогой эксперимент.
Так вот сумма всех этих слагаемых должна превышать четвертую составляющую D. Это затраты. Причем самые разные - деньги, время, нервы, эмоции, люди, риски и пр. Все что подходит под твой случай.
В идеале чтобы изменения пошли мы должны иметь ощутимые A, B и C c небольшим D.
В качестве примера. Необходим переход сустаревшего языка пограммирования на более современный. Есть небольшая группа разработчиков, недовольная текущей ситуацией в разработке Продукта, и которая топит за это. В разработке несколько команд. Есть пара авторитетных разработчиков из разных команд, которых устраивает текущая ситуация, они против этого. Ни у кого из большинства разработчиков нет понимания зачем это нужно и что мы получим в итоге. Есть небольшой несложный проект, на котором можно попробовать этот язык и безболезненно набить шишек. У Владельца Продукта есть опасения надолго замедлить разработку в случае такого перехода, это риски. А - веса нет, B - веса нет, C - имеет вес. D - имеет вес. Пройдет изменение? Скорее всего нет.
А хочется им помочь. Как с этим быть?

Для этого есть второй инструмент. Я называю его "Матрица изменений", хотя более правильное его название "План приверженности".
Нужно проанализировать и составить матрицу заинтересованных лиц с четырьмя столбцами - Кто, Помогает, Нейтрален, Против.
В строки нужно вписать всех участников, которые оказывают или могут оказать влияние на формулу изменений.
Возьмем наш пример:
1. Авторитетный разработчик 1 - Против.
2. Авторитетный разработчик 2 - Против.
3. Разработчики команд - Нейтрален.
4. Владелец Продукта - Против
Список может быть любым. Теперь наша задача перевести всех, кто "Против" в разряд "Нейтрален", а лучше "Помогает". А тех, кто "Нейтрален" в разряд "Помогает". Чтобы это сделать нам нужно для каждой строки (заинтересованного лица) провести анализ и предложить варианты необходимых действий, чтобы это случилось. Например, авторитетным разработчикам можно рассказать об этой идее и показать все преимущества, которые они получат в случае перехода на новый язык. Тем самым мы сдвигаем их в разряд "Нейтрален". Если есть финансовая возможность и затраты не слишком высоки - можно отправить их учится и получить сертификат на новый язык программирования. Тогда мы переведем их в разряд "Помогают". С остальными разработчиками можно провести встречу и рассказать - что нас ожидает в случае перехода на новый язык. Это вторая составляющая нашей формулы изменений. Нужно вовлечь их в изменение, тогда они станут помогать и перестанут быть нейтральными. С владельцем Продукта сложнее. Мы можем посчитать возможное увеличение производительности, представив ему экспертные статьи. Увеличение производительности позволит ускорить время вывода продуктовых идей на рынок. Это позволит певести его в разряд "Нейтрален". Все это нужно делать открыто. Иначе есть риск что тебя обвиненят в манипуляциях. В результате проделанной работы мы получим возможность провести изменение. Конечно, жизнь богаче чем данный пример. Главное – инструменты эти работают и позволяют понять что нужно сделать, чтобы изменения случились. Особенно полезна "Формула изменений".

Уже вторая команда заказывает большой длинный стол и соответствующий компьютер с двумя дисплеями для парного программирования. Мы шли к этому почти полтора года. Команды сами приходят к решению использовать эту практику. Им никто это не навязывает.

Так выглядит рабочая доска для Спринт Бэклога одной из команд.

Задали мне тут вопрос - каково расписание Скрам-мастера? Чем он занят целый день? Попробовал сделать фотографию рабочего дня. Ловите!
8:00 - Пришел на любимую работу.
8:10-8:25 За чаем обсудили с коллегами потребность в более глубоком первичном обучении Продукту вновь принятых сотрудников. Также пришли к выводу о необходимости в периодическом тестировании на знание Продукта. Это позволит проводить более качественное тестирование и в перспективе снизить количество дефектов. Задумался о целях по улучшению.
8:30-8:45 - участвовал с командой "Рост" на Ежедневном Скраме. Обсуждали прогресс движения к цели Спринта. Провели планирование на следующие 24 часа.
9:00-9:15 - участвовал с командой Владельца Продукта на ежедневном Скраме. Работали через Skype. Провели планирование на следующие 24 часа.
9:15-9:30 - участвовал с командой "Фиксики" на ежедневном Скраме. Обсуждали прогресс движения к цели Спринта. Провели планирование на следующие 24 часа.
9:30-9:40 - участвовал (часть события) с командой "Сторкрафт" на ежедневном Скраме. Обсуждали прогресс движения к цели Спринта. Провели планирование на следующие 24 часа.
9:40-9:55 - участвовал с командой "Вегас" на ежедневном Скраме. Обсуждали прогресс движения к цели Спринта. Провели планирование на следующие 24 часа.
9:55-10:15 - с удовольствием прочитал материалы от Майкла Джеймса в русском переводе по роли Владельца Продукта и работе команд. Закинул командам для изучения http://blog.agilix.ru/wp-content/uploads/2019/08/Why-Scrum-Isnt-Making-Your-Company-Very-Agile-v2_ru-1.pdf
10:20-10:40 - обсудил с коллегой из отдела обучения каким образом происходит обучение специалистов техподдержки и бизнеса. Пытаюсь для себя понять схему распространения знаний о продукте, включая выходящие обновления. Некоторые разработчики говорят, что на система очень сложная и им иногда не хватает знаний о системе.
10:40-10:55 - еще раз перечитал Evidence-based Management Guide. Это про доказательный менеджмент, а само руководство про измерение бизнес-ценности. Прихожу к мысли о необходимости метрик, которые позволили бы нам измерять прогресс в продуктовых улучшениях. https://scrumorg-website-prod.s3.amazonaws.com/drupal/2019-05/EBM_Guide%20January_2019.pdf Чуть ранее я вошел в состав группы переводчиков этого документа от scrum.org на русский язык. Сейчас перевод близится к завершению.
11:00-12:05 - участвовал с разработчиками в сообществе практик по тестированию. Обсуждали вопросы автоматизации тестирования выпуска релиза. Основная проблема сейчас это высокий уровень ручного тестирования. Фактически релиз делается двумя командами (облако и кассовый софт). Автоматизация регрессионного тестирования позволила бы нам сократить время на выпуск и поэтапно перейти к работе над релизом только одной командой (высвобождаем для бизнес-задач почти 15% ресурса). В дальнейшем мы можем улучшаться и сократить это время до нескольких дней (сейчас это занимает две недели). В настоящее время этот процесс буксует из-за низкого приоритета элементов Бэклога, связанных с этой проблемой. Прийти к конкретным решениям не получилось. Договорились, что я расскажу им в четверг про управление изменениями (формула и матрица изменений), чтобы помочь сдвинуть ситуацию с мертвой точки.
12:05-13:05 - пообедал.
13:05-13:45 - просматривал и отвечал на почту и в корпоративном чате.
14:00-15:20 - участвовал во встрече сообщества Бекэнд разработчиков. Обсуждали вопросы, связанные с приоритетами технических элементов Бэклога. Это элементы, связанные с улучшением внутренних процессов - CI/CD, работой внутренних компонентов системы, архитектурой, переходом на новые технические решения и т.д. Сейчас есть проблема, связанная с более высокими приоритетами бизнес-задач. Эти элементы не попадают в Спринты. Технический долг растет. Ищем пути решения.
15:20-15:30 - готовился к Общему PBR (Overall PBR) в эрии "Маркировка" (2 команды). Разложил карты, включил проектор, камеру, проверил микрофон (Владелец Продукта в эрии сейчас в Москве)

15:30-16:10 - провел (фасилитровал) Общий PBR в эрии "Маркировка". Это событие проходит в среду второй (заключительной) недели Спринта, но может проходить не каждый Спринт. Только если есть срочные элементы, которые появились на второй неделе и их нужно будет взять в следующий Спринт. После этого PBR элемент уточняет (формирует приемочные критерии) отдельная команда, так проводить многокомандную обычную встречу уже не получается из-за недоставка времени. Результат - оцененный элемент Бэклога будет более подробно разобран завтра в 10:00 обеими командами. Там же будут сформированы приемочные критерии. Они смогли найти время для этой встречи. Решение о том, кто будет реализовывать его будет принято командами на Планировании Спринта, в обычном режиме.
16:10-16:45 - написал, согласовал и отправил обоснование для HR департамента на поездку в сентябре на тренинг Kanban System Design (KMP1) к Алексею Пименову. Это необходимо для выделения средств на обучение и командировку.
16:45-17:55 - участвовал с командой "Вегас" в "Вечернем Скраме". Эта команда сама решила и собирается в конце рабочего дня, чтобы подвести итоги и понять прогресс движения к цели Спринта.
17:00 – отправился отдыхать.

Пятница второй недели - пора Обзоров и ретроспектив :) День очень насыщенный. До обеда провел двухчасовой Обзор Спринта. После обеда четыре часовых рестроспективы в разных командах. Этот день выжимает все соки. Шесть часов на ногах в режиме Нон-стоп. Времени мало. Перерывов между ретроспективами для меня нет. Успеваю только наполнить стакан чаем. Уложить ретроспективу в час очень сложно. Очень большую помощь в этом вопросе мне оказывает опыт, приобретенный в годы работы тьютором (преподаватель-наставник) на программе MBA The Open University. Там было много групповых занятий и необходимость жесткого ограничения по времени. Все это со взрослыми людьми уровня топ-менеджеров и собственников. Перед этим я проходил специальное обучение и даже имею диплом о переподготовке в качестве предподавателя-андрогога (учитель для взрослых, по аналогии с педагогом).

В этот раз на ретроспективах я решил обновить нашу карту "Здоровья команд". Примерно год назад мы решили сделать срез по командам и спросить их как они себя чуствуют. Для этого была использована модель здоровья команд от Спотифай. Материалы брал здесь https://www.scrum.ua/blog/articles/squad-health-check-model?fbclid=IwAR3R-YKBMx9_eypPy1rV8kFQPMC1kFUsbJAojh9EakgZUQOFU0gLpPe59Xg В общем в пятницу на ретроспективах мы повторили это упражнение. Делается легко. Распечатываем карточки и по очереди зачитываем. Команда голосует точками в зоны "Зеленый-Желтый-Красный". Самое сложное тут это сделать так, чтобы команда выработала общий реультат по каждому пункту. Т.е по итогу на каждую карточку должно быть не много точек, а единое мнение по ее цвету. Вот тут то и возникает много споров и мнений по этому вопросы. Примерно как в покере планирования я даю высказаться тем, у кого мнение отличается от остальных. В результате выравнивается понимание и оценка происходящего. Сама модель при периодическом использовании позволяет отслеживать динамику изменений по всем аспектам жизни команд разработчки. При желании можно добавить свои карточки. В моем случае уже на примере четырех команд из семи видно, что фокус проблем сейчас на инженерных практиках. Мы накопили техдолг (было очень "жаркое" лето и мы активно набирали клиентов). Многие части системы требуют рефакторинга. Есть проблемы с автоматизацией выпуска релиза. Все это замедляет работу. На общей картине это отлично видно. Эти проблемы уже активно решаются и мы выправляем ситуацию. С 1 июля один из опытных разработчиков перешел на созданную должность (CTO) в качестве технического коуча. Это менеджер, но не в классическом понимании. Он скорее работает по модели "Менеджмент 3.0". Его задача - развитие скилов, подбор людей в команды (вместе с ними) и развитие инженерных практих. Радуют карточки "Команда" и "Веселье". У нас все получается. Есть проблемы с целеполаганием. Вообще, замечаю, что с ростом зрелости команд они все чаще задают вопрос Владельцу Продукта о том, зачем мы делаем ту или иную фичу. Команды хотят ясных целей и видения по развитию Продукта. Это зона роста. Над этим также надо работать.

Сегодня был интересный день. Прошла ретроспектива команды Владельца Продукта. Вели вдвоем еще с одним Скрам-мастером, я больше на подхвате был. Обсудили «Здоровье команд», договорились, что в четверг сделаем сессию целеполагания - коллеги расскажут про стратегию, ближайшие бизнес-цели и про видение Продукта. Это позволит выровнять понимание и вектор команд и Владельца Продукта. После обеда было еще три ретроспективы, две из которых вел я. Это Overall Retrospective (Общая ретроспектива), то самое событие, которое добавлено в LeSS. На ней присутствуют представители всех команд и обсуждаются общие для всех команд вопросы. Она проводится после Спринта, обычно во вторник следующей за ним недели. Поскольку мы используем LeSS Huge, у нас все команды разбиты на три LeSS эрии. В каждой свой Скрам-мастер и несколько команд. Я веду две эрии и соответственно сегодня провел две полуторачасовых ретроспективы. Обсуждали вопросы работы с багами, укомплектованность тестовым оборудованием и проблемы общего кода. Для обсуждения приглашали руководителя отдела техподдержки. Договорились изменить процесс PBR и некоторые несрочные баги попробовать разбирать еще до начала Спринта. Приняли решения по изменению процесса заказа тестового оборудования и выработали соглашения по общему доступу к коду некоторых частей нашей системы. Код для всех наших семи команд общий. Это позволяет любой нашей команде реализовать любой элемент Бэклога без зависимостей от других фиче-команд. Устал. Но усталость приятная. Почему то общение с людьми и фасилитация подобных мероприятий лишает меня сил. Пришел домой пролежал пару часов. Только сейчас немного восстановился. Завтра будет более или менее свободный день. Планирую заняться вопросами формирования целей Спринта, углубить свою экспертизу по этому вопросу.

С утра поучаствовал во встрече Сообщества практик. Сообщество тестировщиков. Сообщества это форма активности. Она неформальная. Этого никто не заставляет делать. Это потребность в общении людей, работающих в определенной профессиональной области или над одним из компонентов. Это встреча-событие, которое происхоит периодически или по необходимости. Почему эта потребность возникает? Это одна из практик координации в LeSS. Поскольку у нас фиче-команды (кросс-компонентные и кросс-функциональные) то люди, обладающие определенными скилами (в данном случае по тестированию) разбросаны по разным командам. И им необходимы встречи, чтобы синхронизировать идеи, мысли, архитектурные решения. Обычно там есть неформальный лидер (неформальный компоентный или функциолнальный Ментор), который и фасилитирует встречи, оформляет результаты и драйвит сообщество. Еще раз - туда никто не загоняет, это просто потребность. Приходить туда могут любые сотрудники. Сегодня, например, один из Андроид-разработчиков поднял вопрос о том что для нас значит качественный продукт и как это качество измерить (мы как раз обсуждали это вчера на ретроспективах). Был проведен мозговой штурм (я был обычным участником). Общим решением были выработаны возможные метрики для измерения качества. Часть обсудили и решили как будем собирать. Также сразу возник вопрос - как это использовать? Оставили пока этот вопрос открытым. Разошлись в раздумьях. Будем пробовать оценивать качество и вырабатывать решения для его улучшения.