8 заметок с тегом

Роман Петров

Продвинутая таблица результатов getKanban для большей пользы

перевод статьи Improving GetKanban Scoreboards for Deeper Learning from the Game от Алексея Жеглова

Мой коллега Дейв Уайт (Dave White) и я получили благодарность за эту нескучную и креативную таблицу результатов, которую мы получили играя в ГетКанбан на одном из наших тренингов.

ГетКанбан ( https://getkanban.com/ )- это популярная игра-симуляция, которая была изобретена Расселом Хэйли (Russell Healy) почти 10 лет назад. С тех пор, она стала уже стандартным инструментом на тренингах, таких как Сertified Kanban System Design (KMP I). Очень много людей, по всему миру, играют в нее на своих региональных митапах, а так же используют ее, как обучающий инструмент внутри своих компаний.

Конечно же, эту таблицу с результатами мы сделали не для красоты. Каждый визуальный элемент служит определенной учебной задаче. Давайте пробежимся по каждому элементу для понимания его назначения. Это может быть полезно для всех, кто будет играть.

Первое, Компании. Слово в верхнем левом углу. Рекомендуем не называть группы, играющими в игру, “командами”, особенно в контексте Северо-Американских корпораций. Четыре группы симулируют четыре компании. Их задача — это по шагам прийти к такому операционному решению, которое было бы направлено на достижение поставленной стратегической цели. Люди, которые описывают себя “участниками команды”, в Северо-Американском корпоративном английском, зачастую имеют недостаточно полномочий. Если вы нашли себя играющим в эту игру на платном Канбан тренинге, убедитесь, что с вами рядом правильные люди.

Второе, четыре колонки. У нас с Дейвом было на тренинге 26 студентов. Мы разделили их на четыре группы по 6 или 7 человек. Так как на каждые две группы нужен один тренер, то мы вели вдвоём. Если будет только один тренер, то увеличение нагрузки с трех до четырех увеличивает загрузку на треть, что означает нелинейное ухудшение реагирования на различные ситуации, проблемы и вопросы, которые возникают в процессе игры. Если вы проводите Канбан тренинг профессионально и собрали аншлаг, то возьмите себе второго тренера или разделите группу. Если вы заказчик Канбан тренинга, то ожидайте и требуйте стандартов и качества от ваших тренеров.

Третье, четыре цели. Каждая группа имеет разные цели, которые они должны достичь на протяжении игры. Идея в том, что это не абстрактное постоянное улучшение. Улучшение возможностей системы должно иметь стратегическую цель. Игроки должны освоить оптимальные параметры и правила, которые необходимы для достижение их целей. Некоторые игроки будут делать такие решения, которые не подходят для других игроков, так как у них разные цели. Решения по оптимизации на достижение максимальной прибыли будут отличаться от фокуса на времени выполнения, а в свою очередь, решения на достижение наибольшей предсказуемости по времени выполнения, будут отличаться от первых двух. Еще одна возможная цель, это увеличить пропускную способность (измеряемая в количестве сделанной работы). Искусственная цель может приводить к дисфункциям. Игроки могут понять это в какой-то момент во время игры и поменять свою цель.

По умолчанию, устанавливается цель по максимизации денег — прибыль от воображаемой компании. Для двух конкурирующих групп, мы даем им цели: больше всех денег и быстрее время выполнения. Для третьей группы, поставьте цель в наибольшей предсказуемости, а для четвертой — сделать больше всех задач.

Четвертое, примеры графиков в строке “цель”. Требуемые значения (красные линии), нарисованы только в правой части графиков, так как их системы не выполняют поставленную цель в начале, но должны достичь ее постепенно, пока не закончилась игра.

Пятое, здесь нет результата на 9 день, когда симуляция началась. Мы начинаем GetKanban с игры в день 9 со всеми группами одновременно на одном столе, по шагам объясняем правила игры и сразу показываем их соответствующими действиями на поле. Мы предпочитаем не использовать презентации для объяснения правил.
Это занимает больше времени, но игроки делают больше ошибок и задают больше вопросов по игровой механике, чтобы потом уделить больше времени самой игре и получить больше знаний от нее. В конце Дня 9 мы делаем небольшой перерыв. Все остальные группы копируют расстановку карточек на свои доски. Таким образом, все группы заканчивают День 9 с одинаковым счетом в банке (обычно $200) и поэтому нет необходимости тратить место на доске для этого. Вот почему, наша таблица результатов начинается с отчета в 12 День.

Шестое, День 15 — это важная точка синхронизации. Группы играют в игру с разным темпом. Если это не контролировать, то к концу игры разрыв может быть огромным. Это плохо, так как в конце идет закрепление итогов в дополнительный обучающий материал. Группа, которая закончит первой, будет скучать в ожидании остальных. Чтобы этого избежать, мы планируем так, чтобы окончание 15 дня совпало с обедом. Это мотивирует быстрые группы замедлиться, а медленные — ускориться. Группы отправляются на обед раньше или позже, но вот возвращаются уже синхронно. Разброс, накапливаемый между Днем 15 и Днем 21 (заключение игры), незначительный, и все группы заканчивают более или менее одинаково. Могу себе представить, как Рассел Хейли (создатель игры GetKanban) за многие годы, делал многочисленные изменения по улучшению игры, чтобы снизить этот непродуктивный разброс во временах игры.

Седьмое, мы делаем одно важное изменение правил со старта игры. Начинаем с пополнения очереди каждые три дня, а не ежедневно. Первое пополнение происходит на День 10, потом в 13, 16 и т. д. (Забегая вперед, один из персонажей в игры Маргарита, менеджер по маркетингу, в конце концов понимает, что ее моделируемая компания ведет довольно динамичный бизнес, и внедряет определенные изменения в своем отделе, которые позволяют пополнять очередь ежедневно, начиная с 16 Дня). Это изменение бросает интересный вызов в выборе оптимальной даты начала работ по элементу F2 с фиксированной датой поставки. День 10 — это слишком рано — высокие косвенные потери, День 13 — оптимальный, День 16 — есть риски не успеть. Это также показывает, как большая частота пополнения очереди создает больше вариантов планирования и приводит к большей гибкости.

Сделанное изменение, имеет еще одно важное назначение. Пополнение очереди в Канбан системе — это не что-то такое, что случается только на утреннем стендапе команды. (“Я чувствую, что начну эту работу сегодня”). Это действие по принятию обязательств, которое добавляет копилку бизнес обязательств и оно требует присутствия лиц принимающих решения, достаточно высокого уровня, кто может взять на себя ответственность перед клиентом за оказание сервиса, продукта или проекта. Изначальная частота пополнения очереди показывает ситуацию в большинстве компаний: лица принимающие решение не часто встречаются для такого разговора.

Восьмое, перерыв после Дня 15. День 15 — это самый настоящий экватор игры. Большинство играющих групп осознают, что они не приближаются к достижению своей цели. Я делаю грубые наброски, как показано в строке День 15 на таблице с результатами, чтобы подсветить существующую разницу и мы возвращаемся к объяснению этого, сразу после перерыва.

Например, группа стремящаяся к самому низкому времени выполнения, на самом деле замедляется. Они начали с 6-8 днями времени выполнения, а сейчас у них 6-10. Группа играющая на максимальную предсказуемость получает ее ухудшение: с распределением от 2 до 10 дней. Группа, которая должна заработать больше всех денег, сейчас находится на третьем месте из четырех, но что более важно ее время цикла (в среднем 8 дней) — это слишком медленно, чтобы получить долю рынка. Смоделированная обратная связь от рынка (спасибо Расселу за внесенные изменения в 5-ю версию игры) показывает, что приемлемый уровень составляет 3-4 дня.

Эта разница — это не вина игроков. Это обычное состояние. Игроки осваивают механику до Дня 11 или 12 (Помогает великолепное описание событий на карточках от Рассела). Они продумывают и принимают множество ситуационных решений вплоть до Дня 15, например: обходят узкое место Николая, справляются с зависимостью от общего разработчика Пети, перемещают кости (временно ускоряя некоторые этапы за счет других), и переприоритезируют элементы работы в очередях. Но, они не думают о стратегии. И вот теперь они к ней готовы. С начала Дня 16, мы получаем важный вызов: Маргарита изменяет частоту пополнения очереди, какой размер буфера теперь вам нужен? И если они не поймут это на День 16, то в День 17 их цикл обратной связи сомкнется и поможет ли им это понять?

Обсуждение на экваторе игры, дает нам возможность ввести Канбан термин: Обзор Сервиса Поставки (ОСП). Это именно то время и место, где мы можем количественно оценить эффективность нашего сервиса (продуктового конвейера или проекта) и сравнить его с ожиданиями клиентов. Мы не обсуждаем как проводить ОСП, так как мы не хотим отвлекать внимание от целей обучения в игре, мы просто сажаем семена будущего обучения.

Девятое, отбираем данные в Гистограммы времени выполнения за День 21. Игроки разрабатывают свою новую систему до конца Дня 21. Данные предыдущих дней могут не отражать текущую производительность системы, поэтому я отбрасываю эти данные и составляю график только по последнему дню. Изредка я замечаю, что игроки выбирают к поставке в День 21 задачи с наименьшим временем выполнения. В таких случаях, я планирую поставки на День 22+, и добавляю их времена выполнения к набору данных, чтобы его наиболее реалистичным.

Мы можем видеть, что окончательные гистограммы для первой группы показывают достижение цели. Их среднее время выполнения самое короткое, но “хвост” времени выполнения короткий, и именно так они решили проблему предсказуемости лучше, чем группа Предсказуемости (столбец номер 4 на доске). Группа Пропускной способности (столбец 2) эффективно переключилась на денежную цель и так же сделала это хорошо. Они в значительной степени попали в порог поставки за 4 дня. Их непредсказуемость (парочка задач с временем выполнения 10+ дней) была умеренной, и как оказалось, несущественной.

Десятое, этот список не все, что вы можете узнать играя в GetKanban. Правильный анализ результатов (45 — 60 мин) откроет вам гораздо больше. Я написал только о нескольких важных вещах, которые были очевидны для меня из таблицы результатов.

2019   dashboard   getKanban   score   Алексей Жеглов   перевод   Роман Петров

Кейс. Проведение Changeban в легком режиме

Дано: провести мини тренинг по канбан, для небольшой команды (ситуационной), которая состоит из представителей разных команд, но у которых есть общие инициативы над которыми они работают.

Решение: для этих целей взять Changeban из папки с полезностями (https://yadi.sk/d/IHOIBnS59-ZxLg) нашего Канбан.клуба и заодно обкатать русскую версию.

Что получилось:

  1. Для команды нужен был легкий формат, без графиков и метрик, показать как работают WIP-лимиты, поэтому сразу теорию про Lean Startup, тот что лежит под капотом этой симуляции, я пропустил — это оказалось правильным решением
  2. Колода карт, в отличии от монетки, мне понравилась больше. Каждый раунд — у тебя одинаковый набор, но раздается случайно и стендапы команды проходят динамично. Монетки, нужно подкидывать, они падают и теряется время и динамика.
  3. Очень здорово, что можно ставить цель, набрать 20 очков (включая бонусные).
  4. Использовать большие стикеры и маркерно-магнитную доску — то, что надо. Меньший формат требует уменьшения размера стикеров

Что можно улучшить:

  1. Брать колоду карт полную, у меня была от 6 до Туза, а нужно от 2 до Туза. Из-за этого команда из четырех человек сыграла только 9 раундов и не получила возможности выбить все 20 очков. Из-за этого, в первом раунде было 7 очков, а во втором только 10
  2. Я наклеил по 4-ре стикера, каждого цвета, а нужно все. Из-за этого я сделал «бесконечный бэклог», что было неправильно. Об этом я узнал, когда дошел до слайда дебрифа, а там был вопрос «что было бы, если ваш бэклог был бы бесконечным?». А он у них такой и был, по факту, и на фото можно увидеть, что было бы :))
  3. Не брать готовые презентации, а готовить, или свою презу, или свои флипы (рассказывать по слайду, а точнее читать с него — не удобно)

Итог: результат мне понравился. Ребята смогли увидеть момент, что во втором раунде они стали друг другу помогать, только за счет того, что появились лимиты. Данную практику они решили взять себе на вооружение, посмотрю что у них приживется со временем.

2019   Changeban   кейс   опыт   Роман Петров

Сервис Жираф. Часть 1. Три команды в один поток создания ценности

Рубрика Микрокейсы.

Начало:
Есть три команды, которые делают свои задачи (треугольники, кружочки и звездочки), каждая делает свою локальную историю, причем общий результат брался потом из звездочек. Как можно понять, то есть много скрытых очередей и нет прозрачности, а какое же реально время выполнения задачи, так как задачи отваливаются в каждой из команд и даже по сделанным звездочкам нельзя понять (ретроспективно), какие задачи для этого делались и сколько времени ушло у всей команды.

Что поменяли:

  1. Поняли, что делают все команды и как всех вместе меряют: оказалось это количество сделанных квадратиков, причем они делаются по воронке, где квадратики могут выкидываться и тут важна хорошая конверсия и количество квадратиков.
  1. Новый поток стал над всеми командами и команды могут подключаться над любым этапом, а не только в своей компетенции. Раньше для того, чтобы нужно было доработать, ставилась новая задача в бэклог соответствующей команды или переоткрывалась уже сделанная.
  1. Добавились этапы для явного выделения этапа очереди, когда задача ждет следующего этапа.

Итого: на этом этапе идет фокус на визуализацию работы всех команд, фокусировка на создании ценности всеми дружно и описание явных правил работы между командами.

Продолжение следует.

Автор Роман Петров

2019   Жираф   микрокейс   Роман Петров   эволюция

Отличия Definition of Done от Acceptance Criteria (CoS)

В нашей работе очень важно помнить о том, что нам нужна прозрачность (transparency) того, что делает команда, для всех кто работает с этой командой: это могут быть другие команды, Заинтересованные лица (они заинтересованы в том, что делает эта команда, и будут как-то использовать тот результат, что она делает), а в особенности для Владельца продукта.

Так как же Команде разработчиков договориться с Владельцем продукта о том, что же такое сделано? И тут, на помощь нам приходит Критерии Готовности (DoD или Definition of Done) — это чек-лист работ, которые проходит каждая из задач команды, после чего она может на каждую из них свою печать «Готово». Этим команда заверяет, что продукт сделан правильно.

Владелец продукта, принимая задачу от команды, уже знает, что все очевидное и ожидаемое, по умолчанию от команды, сделано. А чтобы, это действительно было так, то стоит, этот список действий, записать в явном виде и согласовать с двух сторон. Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц.

Кто составляет этот список?

Команда. Это именно команда, говорит, что для нее значит, что задача сделана, это общий список без привязки к контексту. Это может быть для ИТ проекта: «Прошли автотесты, Сделан регресс, Написана пользовательская документация, и т. д.», для доставки: «заказ собран в коробку, упакован в пакет, зарегистрирован в систему, наклеен штрих-код, положен на полку на складе».

Достаточно ли это для Владельца продукта?

Очевидно, нет! То, что код прошел все технические процедуры, а коробка лежит в красивом виде на правильной полке, не говорит ничего о содержимом. Для содержимого, есть дополнительный критерий, называемый Критерий Приемки (Acceptance Criteria). Он уже составляется Владельцем продукта, для того чтобы понимать, что сделали вещь правильную.

Соединение DoD и AC, дает нам прозрачность в том, что была сделана правильная вещь правильным способом.

Давайте посмотрим на это, на примере метафоры нашего любимого аэропорта.

Мы приходим в аэропорт и сдаем багаж. Каждый багаж проходит необходимые проверки: по размеру, весу и содержимому. Если в самолет загрузили багаж, то команда самолета уверена, что все, что загружено правильной формы, безопасно и т. д. Эти все процедуры — это критерии готовности (DoD), в которых вам можно, что сдав свой багаж, вы получите его целым по прилету. И тут-то содержимое чемоданов — это критерий приемки (AC), он то и важен для вас, в соответствии с ним, вы смотрите, что все что вы положили в чемодан, прилетело в целости и сохранности.

Т. е. у вас с перевозчиком есть договоренность, что значит доставленный груз, но ценность — это то, что внутри. Принимаете работы вы уже смотря на то, что внутри.

В пиццерии

DoD: пицца приготовлена, пожарена, нарезана, упакована в коробку / подана на стол и нигде в процессе не испорчена

Acceptance Criteria: пицца именно того размера и вида (состав ингредиентов), какого заказал клиент.

Говоря математическим языком: DoD — это необходимое условие, а AC — это достаточное условие. Они всегда идут рука об руку, но путать их не надо.

Еще, для больших команд, применяется критерий готовности Релиза (Definition of Done for a Release).

Если вам не нравится слово Критерий приемки, то можете взять вариант Хенрика Книберга «Как продемонстрировать» (How to demo) или Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction). Эти варианты больше подходят для задач без ИТ, например, в высокоуровневых бизнес-целях.

Что такое идеальный DoD?

DoD — это те работы, которые мы делаем с каждым элементом бэклога, каждый спринт. И в идеале, у вас в результате есть то, что сразу можно поставить \ отдать пользователю. Но что делать, если для этого нужно сделать что-то еще? Например, провести сборку, сделать нагрузочное тестирование, подготовить документацию, получить согласования от юристов, бухгалтерии, безопасников и т. д. Быть честным!

Нужно подсветить всю эту работу, которая НЕ будет готова в конце спринта. Она будет накапливаться и с ней нужно что-то делать. Задача Scrum команды, честно признавать что еще нужно делать и находить решения, чтобы с каждым новым спринтом, таких работ становилось все меньше.

Список Критериев может создаваться как самим Владельцем продукта, а может и командой разработки. Команда, на планировании или PBR, может задавать вопросы относительно этого списка в целях прояснения понимания, что нужно сделать, а так же предлагать от себя дополнительные критерии. Здесь важный нюанс, что ответственность за то, как будет проверяться каждый элемент бэклога, лежит на Владельце продукта.

Сокращенно, AC — называть не удобно и можно путать с Agile Coach, Автоматизированная Система и т. д. Поэтому, давайте пользоваться термином CoS (Conditions of Satisfaction) Условия удовлетворения ожиданий

Автор: Роман Петров

2019   Acceptance Criteria   Conditions of Satisfaction   Definition of Done   DoD   How to demo   UnDone   Роман Петров

Правильный порядок применения практик Канбан

Идея, указания практик в определенной последовательности, имеет смысл, так как предполагалось, что именно в такой последовательности нужно их и применять. Но на практике, каждый раз выходит иначе. Предлагаем картинку-памятку, как следует это практики применять в жизни.

Почему именно такой порядок?

  1. Визуализация — мы начинаем с того, что осознаем, как мы сейчас работаем, какой у нас процесс. Это первый очень большой стресс. На этом этапе, команда такой низкой зрелости, что спрашивать ее о том, какие у нее цели изменений и как они будут их мерить, или банальные (выпускать как можно быстрее) или общие (сократить time-to-market)
  1. Явные правила — следующий шаг, это описать свои правила для внешнего заказчика, либо договориться внутри себя (если команд несколько и они делают один продукт). Тут тоже возникает ряд сложностей, раньше такого не делали и все устные договоренности и то, что само собой подразумевалось, нужно описать в явном и общедоступном месте
  1. Циклы обратной связи — теперь, чтобы закрепить полученный результат, прописываем обязательно получение обратной связи от заказчика для каждого элемента работ (обычно это значительно чаще, чем раз в квартал), а так же ретро для команды. Первая такая ретроспектива проводится на при проведении STATIK. Этот шаг, позволяет не усугублять текущее положение и уже начать работу над совершенствование визуализации и явных правил работы, так как обычное дело, что то что было создано в первой попытке нуждается в улучшении
  1. Измеряй время выполнения работ, после того, как наш процесс стабилизировался, можно начинать собирать метрики и смотреть, как мы работаем сейчас. Для нас это является первой доказательной точкой того, что происходит в действительности в работе команды/сервиса
  1. Ограничивай незавершенную работу — наконец, мы сможем увидеть явное влияние того, как помогает нам оптимизировать поток, за счет установики WIP-лимитов с использованием Закона Литтла. Эта точка, дает сильный заряд гордости за полученный результат от проделанной работы и мотивации на новые улучшения на основе метрик.
  1. Эволюционируй. Поздравляем, ваша канбан-система создана и встала на рельсы постоянных улучшений с оглядкой на ожидания заказчиков и предназначение системы, если кончено вы все сделали правильно :)

Автор: Роман Петров

2019   coaching   kanban-method   практики   Роман Петров

10 Практических советов как стать хорошим скрам-мастером

1. Никогда не принимай решения за команду, не спросив её

Как у скрам-мастера команды, у тебя нет права (власти) принимать от имени команды запросы на изменения (неважно насколько они малы).  Даже если ты абсолютно уверен, что команда справится с этим изменением, ты должен сказать: «Мне нужно обсудить это с командой, прежде чем мы скажем ‘да’»

И конечно же не подписывай команду ни под какие дэдлайны, или что-либо ещё, не пообщавшись сначала с ней (командой). Возможно, тебе не надо говорить со всей командой — для ряда команд достаточно, чтобы часть сказала «да, мы можем это сделать», для ряда команд нужно, чтобы сказали все, без общего собрания.
Но это всё же будет их решение, не скрам-мастера

2. Помни, что ты там, чтобы помочь команде стать лучше

Быть скрам-мастером не про то, чтобы самому стать лучше.
Ты становишься лучше, когда команда становится лучше.
Команда становится лучше, когда делает отличную работу

Ты поймёшь, что делаешь свою работу хорошо, когда другие, вне команды, начнут интересоваться нужен ли ты вообще. Да, это может звучать пугающе, если твой руководитель начнёт интересоваться твоей необходимостью, но хороший руководитель знает, что твои компетенции и экспертиза создают впечатление твоей ненужности в то время, как ты незаменим.

3. Не бей команду по голове книгой с правилами agile

Ни Scrum, ни agile не пришли к нам с книгой правил (несмотря на то, что некоторые пытались её создать)
Если у продукта есть клиент, следует подумать о написании пользовательских историй (user stories), но истории не являются требованиями в agile. Если кому-то необходимо знать, когда будет поставлен продукт — оценивайте, если такой необходимости нет, возможно, и оценка не нужна. Если вам кажется, что обратная связь в конце спринта — это уже поздно, делайте обзоры в то время, как фича сделана.

Быть agile означает соблюдать принципы и ценности, которые лежат в основе agility. Если команда остается верной принципам и ценностям, она не собьется сильно с пути, несмотря на то, что ей говорят другие

4. Ничто не постоянно, поэтому экспериментируй со своим процессом

Экспериментирование со своим процессом — это часть соблюдения принципов agile. Вдохнови команду попробовать новые вещи. Твоей команде нравятся двухнедельные спринты, и они думают, что работают великолепно? Отлично. А теперь попроси команду поработать недельный спринт или трехнедельный спринт и понаблюдай за результатами. Эксперименты не всегда могут быть комфортны, но — это лучший способ убедиться, что команда продолжает открывать что-то новое, лучшие способы работы

5. Убедись, что команда и стейкхолдеры относятся друг к другу как к равным

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

6. Защищай команду, включая те способы, о которых ты даже и не думал

Возможно, наиболее частый agile-совет — этот тот, что скрам-мастер должен защищать команду от слишком требовательного Владельца продукта или стейкхолдеров. И это хороший совет.
Иногда Владельцы продукта «просят» слишком много, слишком часто и слишком требовательно. Это вынуждает команды ускоряться, чаще всего жертвуя качеством, что позже отразится на продукте. Поэтому хороший скрам-мастер защищает команду от этого.

Однако, вы не часто услышите, что хороший скрам-мастер также должен защищать команду от самодовольства.
Хорошие agile-команды постоянно самосовершенствуются. Другие команды останавливаются в развитии, скорее всего бессознательно, думая что они достаточно развились. И возможно они были значительно быстрее и лучше уже до того как услышали об agile. Но даже великие команды часто становятся намного лучше.
Великие скрам-мастера защищают команды от ощущения, что им больше нечему учиться.

7. Запрети себе использовать слово «провал»

Как правило «провальным спринтом» команды называет такой спринт, в котором не достигла всего, что она запланировала. Не стоит это считать провалом, особенно если команда завершила большинство запланированных элементов или если она быстро справилась с чрезвычайной ситуацией. Когда баскетболист бросает мяч в корзину и увеличивает счет, это называется заброшенный мяч. Когда игрок промахивается, это называется попыткой забросить мяч. Не провал. Попытка. Хорошие скрам-мастера помогают командам корректировать свое мышление так, чтобы те считали спринты и фичи, которые не соответствуют их ожиданиям, попытками, а не провалами

8. Хвали чаще, но всегда искренне

Никогда не произноси ложную похвалу. Никто не хочет этого слышать. Однако, когда команда делает действительно хорошую работу, дай ей об этом знать, похвали. Скорее всего, это происходит не слишком часто

9. Поощряй команду, если она начала делать твою работу

Команда, для которой agile в новинку, будет в значительной степени полагаться на своего скрам-мастера или agile-коуча. Такая команда может не знать как уложиться в 15 минут на ежедневном скрам митинге (прим. ежедневном стэндапе). Или она может не понимать важности параллельной работы или необходимости быть кросс-функциональной.

То же самое справедливо в отношении неопытной спортивной команды. Тренер маленьких детей, которые учатся играть в футбол, обязан научить их всему. Когда тренируются маленькие дети, их тренер бегает вдоль боковой линии всю игру, крича: “Бей и беги!». Если бы он этого не делал, маленькие игроки могли забыть об этом. Даже когда он так кричит, время от времени какой-нибудь ребенок просто садится на траву и глазеет вокруг.

Сравните тренера маленьких детей с тренером команды Кубка мира. В команде Кубка мира игроки знают, что нужно делать. Если тренер опаздывает на тренировку, игроки знают с каких упражнений им начинать. Тренеру Кубка мира не нужно напоминать игрокам, чтобы били и бежали. В то же время, команда Кубка мира никогда не скажет вам, что им больше не нужен тренер.

Независимо от того, насколько хороша agile-команда, она получает пользу, от того, что у неё есть cкрам-мастер или agile-коуч. Однако, хорошие agile-команды сами берут на себя некоторые простые коучинговые задачи для освоения навыков, необходимых им в продуктовой разработке.

10. Молчи и слушай

Оставаться молчаливым и позволить команде самой найти решение проблемы — это одна из самых сильных практик в коучинге и менторстве.

Это может быть трудно. Когда ты видишь, что команда изо всех сил пытается понять, что предпринять — тебе несомненно хочется вмешаться и помочь советом, но если ты решаешь проблемы за команду или с готовностью предлагаешь советы, команда начинает ждать что ты решишь за неё любую возникающую проблему.

Это не означает, что ты никогда не сможешь предлагать свои решения, ты же умный человек, в противном случае эта роль не для тебя, однако, одна из составляющих быть хорошим скрам-мастером означает помогать командам научиться находить решения самостоятельно. Если ты решаешь каждую проблему, с которой сталкивается команда, у неё не будет возможности научиться делать это самой

Текст адаптирован с оригинальной статьи:  https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need

План действий

Визуализированный план действий — это отличный результат продуктивной встречи, например ретроспективы. Он позволяет структурировать дальнейшие шаги, закрепить ответственных, сроки, а также задать критический вопрос, как мы поймем, что «это сделали?» и «что это решило нашу задачу?» Для такой структуры предлагается шаблон План Действий

План действий

Рекомендуется на команду брать не больше 3-х улучшений, которые они обязуются сделать до следующей ретроспективы. Если команда к следующей ретроспективе сделала не все три, то нужно уменьшить до двух. Если не было сделано ни одной задачи, то выбрать только одну и всем фокусироваться на ее выполнении.

Вопрос генерации и выбора решений, находится за рамками этого поста.

Как пользоваться шаблоном:

  1. Вписываете название команды (помогает при фотографировании, вспомнить по фото, к какой команде идти за напоминанием)
  2. Выбрать количество действий, которое команда будет выполнять (от 1 до 3). Если команда просит выбрать больше — не соглашайтесь и предлагайте чаще проводить ретроспективы.
  3. Сначала пишите «Что» требуется сделать.
  4. Блок «Зачем» — является опциональным. Его стоит заполнять, если вы хотите усилить или поддержать мотивацию на высоком уровне продолжительное время. Рекомендуется в него вписать контекст, в котором было придумано соответственное решение, а так же что будет, если это произойдет?, а что будет, если это не решать?
  5. Найдите волонтера (убедитесь в добровольности исполнителя), кто готов взяться за решение этой задачи.
  6. Совместно со всей командой опишите по пунктам, как вы проверите, что эта задача была сделана
  7. Установите срок. Называется волонтером-исполнителем, без давления, но с возможностью по челленджить. Если срок дальше, чем следующая регулярная(!) ретроспектива, то разбить задачу на этапы и указать, что будет сделано к следующему ретро. Если ретро проходят не регулярно, то оставить так как есть. Следите, чтобы этот срок не был навязан кем-либо из команды.
  8. Теперь пришло время, собрать команду помощников-волонтеров. Задача не всегда может быть простой и нужна будет команда, для ее реализации. Помните, что исполнитель имеет право отказаться от помощи, какого-либо участника, без объяснения причин.

Лист отдается команде, прикрепляется на стену, рядом с рабочими местами, чтобы служить информационным радиатором и напоминать о том, что необходимо сделать.

Автор: Роман Петров

Эмпирический подход к оцениванию

Когда вам необходимо оценить сколько времени потребуется на решение той или иной задачи, есть два разных подхода:

  1. Аналитический. Разложить задачу на элементарные составляющие, оценки которых обычно не составляют труда, и сформировать из них интегральную оценку;
  2. Эмпирический. Обратиться к предыдущему опыту и посмотреть сколько времени тратилось на подобные задачи в прошлом;

Использование аналитического подхода является популярным, но у него есть свои ограничения, снижающие возможности. При декомпозиции можно «забыть» какие-либо не очевидные на этапе оценивания задачи. Часто оценивающий становится «жертвой» со стороны манипуляций заказчика, желающего получить из него «приемлемую» для себя оценку. Бывает, что избыточная декомпозиция вместо улучшения оценки приводит, наоборот, к снижению точности оценивания и т. д.

Эмпирический подход подразумевает иной способ прогнозирования. Представьте себе, что вам на работе назначили встречу на 9 утра и вам «до зарезу» необходимо попасть на нее вовремя (не раньше и не позже). В итоге вы пытаетесь определить во сколько нужно выйти из дома. Можно поступить как в предыдущем случае и прикинуть количество остановок транспорта и среднее время его движения между ними. Кто-то еще вспомнит, что у транспорта есть свой интервал ожидания, кто-то добавит, что вообще-то до остановки и от нее тоже нужно время чтобы дойти. Но мы же обычно делаем по-другому: из своего ежедневного опыта мы знаем, сколько времени нам нужно, чтобы доехать до работы.

Поскольку, мы повторяем этот опыт каждый день, то эти данные намного надежнее любых вычислений. И самое главное: они учитывают все «неизвестные» и/или «забытые» факторы, такие как необходимость спуститься на улицу из дома и подняться к себе на лифте в офисе (в некоторых организациях в час пик это, кстати, нетривиальная задача), раздеться, дойти до переговорной команды и т. д.

Значит ли это, что эмпирический подход всегда лучше? При всей его красоте, у него тоже есть свои ограничения. Пожалуй, наиболее заметное — это необходимость наличия опыта для сравнения. Если с подобной задачей вы еще не сталкивались ранее, и не можете её сопоставить ни с чем известным для вас, то такой подход конечно «не взлетит».

Использование обоих подходов требует применения подходящих инструментов. В аналитическом способе, мы применяем оценку во времени, но что делать в эмпирической парадигме?