Kanban.club

Кратко и по делу о Kanban, Scrum, LeSS и все, что может пригодиться в работе.

Jira. Быстрый фильтр для подзадач

Если у вас используется в вашем проекте Jira структура вида Epic -> Story -> Sub-task, то вам будет полезен следующий быстрый фильтр.

Кейс применения:
Есть доска, на ней дорожки (swimlanes) идут по Story, внутри которых есть Sub-task. При этом у вас есть Epic, которые содержат в себе story (epic_link), но естественно не содержат все под задачи этих историй.

Проблема:
Если мы делаем быстрые фильтры по разным Epic вида «Epic link» = №, то при выборе его у нас буду показываться только дорожки историй, а все подзадачи «исчезнут», так как они напрямую не привязаны к эпику, что логично.

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

8 ноября   Agile   epic   function   jira   lifehack   quick filter   story   sub-task

Продвинутая таблица результатов 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 мин) откроет вам гораздо больше. Я написал только о нескольких важных вещах, которые были очевидны для меня из таблицы результатов.

PDSA цикл Деминга (известный, как PDCA)

Оказывается, история с Циклом PDCA разворачивалась не шуточная, примерно как с пониманием SCRUM в наши дни. Деминг переживал, что слово «check» в английском значении будет «to hold back», поэтому хотел явно выделить этап Обучения, получения опыта из данных.

Еще интересно, что в цепочке событий этот научный подход начинают аж с самого Галилео.

Для тех, кто хочет копнуть глубже в оригинал.

9 сентября   history   PDCA   PDSA   Деминг

Кейс. Проведение 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. Не брать готовые презентации, а готовить, или свою презу, или свои флипы (рассказывать по слайду, а точнее читать с него — не удобно)

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

Кейс. Scrum после 3 месяцев работы

Что было выявлено по итогу присутствия на ретроспективе, у команды, которая уже около 3 месяцев работает по Scrum. Команда из 7 человек, причем ВП и СМ находятся в одной локации, а вся остальная команда в другой.

Что имеем из фактуры, над которой можно поработать:

  1. Цель спринта состоит из 8 пунктов, в формате что надо сделать. (причина — задачи не связаны друг с другом, а раз так, то и разные цели)
  2. Запланированный на спринт объем работы, команда не выполняет (команда хочет лучше оценивать задачи в человеко-часах и просит СМ дать им инструменты, чтобы трекать это Jira)
  3. Команда не довольна оценкой результативности от ВП по результатам обзора, в прошлый раз было 4.5 из 10, в этот раз 3.5 из 10, команда не довольна и хочет лучше планировать
  4. На ревью пользователи не приходят, так как им нечего показывать

Варианты, что можно улучшить Скрам-мастеру в его команде:

  1. Сейчас ВП и команда по разные стороны баррикад, так как на обзоре никого кроме ВП и команды нету, то это походит на отчетную встречу. По этому команда спрашивает у ВП, как хорошо она поработала, на что получает низкую оценку, так как ВП смотрит на разницу между что планировали и что сделали. Поэтому команда хочет защититься от этого, хочет начать мерить свое время, чтобы узнать что она молодец, но реальная причина не в этом. Результат — демотивация команды. СМ нужно вернуть команду и ВП на одну сторону и направить их к единой цели. Еще раз сформировать общее видение того, что делает команда (см. цель спринта). Цель сформулировать по SMART.
  1. Обратную связь получать от Пользователей, так она будет объективной и команда должна мочь сама оценить свою результативность без интерпретации ВП. Объективность можно достичь тем, что это будет какая-то измеримая цель: количество денег, пользователей и т. д.
  1. Признаться, что ниодна задача не сделана до конца и поставить самим себе за результат 0. Еще раз вернуться к теме, что такое DoD и чем он отличается от AC. СМ нужно запустить активность с командой по генерации DoD и посмотреть на свой бэклог спринта с тем, что вся команда уверена, что сможет сделать все запланированное с учетом согласованного DoD
  1. Команда формирует много целей спринта, так как видит элементы бэклога разными, но у нас же это команда и она делает общие цели. Для этого нужно посмотреть на нашу цель, на наших пользователей и постараться найти какую-то объединяющую метрику для всех элементов бэклога, так называемую единую линейку, по которой можно мерить все элементы. Если такой общей линейки найти не удается, то тут нужно остановиться и признать, что у нас это не команда и сделать перезапуск.
  1. Еще раз с командой проговорить цикл, что когда мы берем задачу в спринт, то обсуждаем АС (критерии приемки), все задачи обязательно проходят DoD. АС — для каждой задачи свой, DoD общий и его можно менять на ретроспективе. Команда получает ОС от пользователей напрямую, и это являются экологичным источником положительных или отрицательных эмоций, где ВП может подбодрить команду и прийти на планирование с новым задором.

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

После такого разбора, за такой период, СМ сказал: «Ааа.... я все сломал, ничего не работает, я почти убил команду» :)

И здесь лежит ловушка в том, что Scrum всегда не работает — и в этом и была задумка. В этом и есть источник улучшений команды для СМ. Включайте режим Коломбо, экспериментируйте, сначала сделайте все события скрам, потом улучшайтесь.

Реально убить команду СМ может только специально и это тоже надо уметь. Нельзя все сразу предусмотреть, каждая команда идет своим путем, ему нужно только помогать.

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

2019   DoD   scrum   scrum-case

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

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

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

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

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

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

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

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

Инструмент «Паутинка» для оценки событий Scrum

Порой Scrum-мастер задаётся вопросом: «Хорошо ли у нас проходят события Scrum?» однако, не может найти подходящий инструмент.

Инструмент «Паутинка» позволит команде на ретроспективе оценить события и совместно разработать план по улучшению.

Инструмент состоит из 3-х частей:
I часть — выравнивание критериев оценки с командой, что для команды 1, а что 5
II часть — совместная оценка событий участниками команды
III часть — сведение полученных оценок и разработка плана по улучшению

I. Выравнивание критериев оценки с командой

Подготовка: флипчарт с нарисованной шкалой оценки от 1 до 5

Команда и Scrum-мастер пишут на стикерах, что для них оценка «1», а что оценка «5».
Например:
«1» — нет цели/регулярное опоздание участников/плавающие события (в разное время)/отсутствие участников без уважительной причины;
«2» — тайминг не соблюдён/цель не досигнута/отсутствие участников без уважительной причины;
«3» — тайминг соблюдён/цель достигнута;
«4» — всё хорошо, фасилитирует Scrum-мастер;
«5» — команда всё делает сама, Scrum-мастер фасилитирует только ретроспективу

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

II. Совместная оценка событий участниками команды

Подготовка: флипчарт с матрицей событий

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

  • DSM (или Stand-up);
  • Планирование;
  • PBR (согласно Scrum guide не является отдельным событием, однако эта активность крайне важна для команды)
  • Обзор спринта
  • Ретроспектива
  • Спринт (как в целом команда оценивает достижение цели спринта, дополнительно можно включить оценку выполнения роли Владелец продукта и Scrum-мастер)

После того, как все наклеили, Scrum-мастер считает среднюю по каждой ячейке.
Оценки Scrum-мастера не учитываются при подсчёте средней они потребуются немного позже.

III часть — сведение полученных оценок и разработка плана по улучшению

Подготовка: флипчарт с паутинкой

На соответствующие оси «Паутинки» наносим разными цветами оценку команды и Scrum-мастера (см. картинку)

Расхождение линий оценки Scrum-мастера и команды — это фокус внимания для Scrum-мастера по тому, как он видит работу внутри команды.

Scrum-мастер фокусирует внимание команды на события, которые получили наименьшую оценку от команды и просит их написать на стикерах ответ на вопрос: «Что нам нужно сделать, чтобы данное событие улучшилось?»

Далее команда голосует точками за улучшение, выбирает ТОП3 для реализации и создаёт «план действий» 

Порой Kanban лучше, чем Scrum

В своей статье Брэнан Уовчко эксперт в Kanban и Scrum выделяет 5 условий, при которых Kanban подходит команде лучше, чем Scrum.

1. Низкая терпимость к изменениям

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

2. Очевидный на всех уровнях

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

3. Быстро меняющиеся приоритеты

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

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

4. Маленькие команды

Идеальный размер Scrum команды, это команда, которую можно накормить двумя пиццами (two pizza team). Это гарантирует, что команда достаточно маленькая, чтобы быть эффективной и достаточно большая, когда имеет смысл вкладывать временнЫе инвестиции во встречи. Если ваша команда меньше, чем two pizza team, вам больше подойдёт Kanban.

5. Сложное взаимодействие

Scrum изменил взгляд мира на работу — появились кросс-функциональные команды. Идея, что команда состоит из людей из разных отделов и дисциплин, меняет правила игры.

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

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

Kanban не использует временные рамки для создания предсказуемости, он использует время выполнения заказа (lead time), поэтому он способен устойчиво поддерживать неограниченное количество действий и взаимодействий.

Scrum и Kanban не являются конкурентами или врагами. Оба являются средством, помогающим командам и их заинтересованным сторонам достичь устойчивого успеха. Не думайте, что лучше всего подойдет то, что вы лучше понимаете или чаще используете. Будьте agile и экспериментируйте с обоими!

Текст адаптирован с оригинальной статьи:

https://www.mountaingoatsoftware.com/blog/when-kanban-is-the-better-choice

Проведение командной сессии по инструменту «5 пороков команды» по одноименному бизнес-роману П. Ленсиони

Инструмент «5 пороков команды» П. Ленсиони отлично помогает командам посмотреть как у них идут дела внутри, провести самодиагностику и выработать шаги по повышению эффективности командной работы.

ВАЖНО:

  1. Проводится опытным Scrum-мастером/Agile-коучем, который знает и понимает как работать с командной динамикой и умеет управлять конфликтами.
  2. Рассчитана на зрелую Agile-команду численностью не более 12 человек.
  3. Первая встреча выездная на 1 день, далее уже в формате ретроспектив

Шаги до встречи:

Чтобы эффективно провести сессию до её начала вам необходимо:

  1. «Продать» данный инструмент команде, в которой вы планируете это сделать, чтобы они понимали цель;
  2. Получить согласие от всех участников команды на проведение данной сессии. Этот аспект очень важен, так как в течение всего мероприятия участники будут выходить из зоны комфорта, они должны быть к этому готовы и согласны;
  3. Направить всем участникам команды тест, который им необходимо заполнить до сессии и принести с собой (тест вы можете найти здесь: https://is.gd/Jz9xXR);

На командной сессии:
Первая часть: открытие продолжительность ~1 ч.

  1. Как и в начале ретроспективы необходимо создать атмосферу. Для этого можно использовать любой дизайн, например с сайта https://retromat.org/
  1. Подготовьте заранее флипчарт, на котором будет написано «Команда — это ...»
    Попросите каждого участника на одном стикере написать одно слово, которое продолжит предложение «Команда — это...», затем попросите каждого участника поочередно подойти к флипчарту и озвучивая, наклеить свой стикер. После того как все наклеят свои стикеры, подведите общий итог, что в целом получилось.
  1. Подготовьте заранее заготовки флипчартов с правилами и расписание сессии.
    Перед тем как перейти к цели встречи с участниками команды необходимо договорится о правилах (например, правило поднятой руки, одного микрофона, парковка, не отвлекаемся на девайсы и т. п.) и о расписании (лучше делать сессию 50 мин. работы и 10 мин. отдыха).
    ВАЖНО: Обязательно получите «ОК» от команды на правила и расписание, в течение встречи, вы не раз будете возвращать команду к правилам. «ОК» также важно получить, чтобы не было сопротивления от команды, так как это их встреча, если им что-то не нравится или они хотят что-то добавить, измените написанное или создайте новый флипчарт.
  1. Перейдите к цели. Озвучьте цель и спросите команду согласны ли они с данной целью (цель следует написать на флипчарте, чтобы команда видела)
    Пример цели: Остановиться, выдохнуть и посмотреть как у нас идут дела внутри, провести самодиагностику и выработать шаги по повышению эффективности нашей командной работы.
    ВАЖНО: если команда не согласна с целью, то совместно создайте новую, удовлетворяющей всех цель сессии.

Вторая часть: общее понимания и диагностика продолжительность ~3 ч.

  1. Ещё раз познакомьте команду с инструментом, расскажите кто его создатель (Патрик Ленсиони) и где можно в интересной форме о нём прочитать (одноименный бизнес-роман «5 пороков команды»). Покажите команде треугольник, но пустой :)
  1. Скажите команде: «Перед тем как приступить к работе с треугольником давайте сведём результаты ваших тестов в единое»
    Это можно сделать на флипчарте, но для скорости и удобства лучше сделать в Excel. Не показывайте команде результаты, вы вернётесь к ним немного позже — сохраните интригу.
    (Excel вы можете найти здесь: https://is.gd/Jz9xXR)
  1. Верните команду к флипчарту с пустым треугольником и начните совместно с ними заполнять и прорабатывать уровни. Так как вы уже ранее встречались с командой и рассказывали про данный треугольник, здесь важно включить участников в совместное «вспоминание»
    Спросите: «Помнит ли кто-то, что у нас на первом уровне?» После того, как назвали, запишите в треугольник. Далее спросите: «Есть ли кто-то кто считает, что доверие не важно в команде?» Если такие есть спросите: «Можешь, пожалуйста, рассказать почему?» Не критикуйте и не переубеждайте, просто выслушайте и посмотрите на реакцию других участников. Если участник не готов сказать — это его право. Если вдруг начинается дискуссия аккуратно остановите её и верните команду к цели сессии.
  1. Попросите участников команды на стикерах (1 стикер = 1 мысль) написать, что они понимают под фразой «Взаимное недоверие», далее каждый из участников выходит и, озвучивая, клеит свои стикеры. Когда все наклеили свои стикеры, уточните не хотят ли они ещё что-то добавить и если у кого-то возник инсайт, обязательно запишите. Это упражнение повторяем для всех уровней, однако, с небольшим дополнением: уточните не хотят ли участники переместить свои стикеры на другой уровень.
  1. Вернитесь с командой к тесту и посмотрите на результаты, которые получились. В первую очередь посмотрите на те пороки, которые набрали 3-5 баллов. Если у команды получилось более одного порока в данном диапазоне начните с самого первого, например, тест показал, что у команды Порок#1 и Порок#3 попали в диапазон 3-5 баллов, начните с Порока#1 и проработайте его до конкретных шагов и первых результатов и только потом переходим к следующему пороку
  1. Для этого шага у вас заранее должен быть подготовлен флипчарт с вопросом «А как это у нас?».
    Попросите участников команды на стикерах (в данном случае можно использовать длинные стикеры) написать ответ на вопрос «А как это у нас?». На этом шаге важно понять как этот порок проявляется у команды. После того как участники команды написали, попросите наклеить, озвучивая написанное.

ВНИМАНИЕ! На этом этапе при озвучивании может произойти конфликт, поэтому заранее договоритесь с командой, что они могут задавать уточняющие вопросы, и конструктивно реагировать. В случае, если эмоции взяли верх переведите встречу в рациональное поле вернув команду к цели сессии. Если вы видите что конструктивный конфликт переходит на межличностный между двумя участниками, покажите, что вам не безразлична данная ситуация и вы готовы подключиться к её разрешению после сегодняшней встречи. Возможно, после этого шага команде потребуется перерыв.

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

ВНИМАНИЕ: остальные кластеры не выкидываются, а остаются для рассмотрения на будущих ретро команды, желательно не раньше получения первых результатов по первому кластеру.

После данного блока команду желательно отпустить на обед.

Третья часть: разработка плана действий продолжительность ~2 ч.

  1. Для данного шага необходимо подготовить флипчарт с вопросом «Как улучшим ситуацию?»
    Итак, команда выбрала для себя первый кластер, с которым будет работать. Попросите команду на стикерах написать решения (1 стикер = 1 решение). Далее каждый участник озвучивая, клеит свои стикеры на флипчарт.
  1. После того, как все участники наклеили свои предложения проверьте их на адекватность по матрице («решает/не решает» проблематику и сможем «сами/нужна помощь»). Зачитайте каждый стикер и совместно с командой отнесите стикер в соответствующую ячейку. После того как все стикеры распределены фокусируйте внимание команды на ячейки «решает/сами» и «решает/нужна помощь».
    Стикеры, которые по мнению команды попали в «решает/нужна помощь» — это область работы Владельца продукта и Scrum-мастера/Agile-коуча. Уточните у команды чья по их мнению им нужна помощь.
    Далее переходите к стикерам в ячейке «решает/сами» и разрабатываем план действий (см. http://kanban.club/all/do-action-plan/)

ВАЖНО:

  1. В течение данного сессии не переходите на работу в малых группах, здесь важна динамика целой команды и ощущение их самих себя как единого целого. Важна динамика их всех целиком
  2. Если команда начинает позитивно что-то обсуждать и хихикать, не вмешивайтесь, просто молча подождите, когда команда вернётся — это важный командообразующий момент;
  3. Если команда начинает что-то конструктивно обсуждать, не вмешивайтесь, это их встреча и, возможно, им надо выговориться, подождите, когда команда к вам вернётся.
  4. Как только чувствуете, что команда «накалена» или «устала» — сделайте перерыв. Возвращая команду с перерывов сделайте краткий обзор того, что было сделано до ухода на перерыв (recap).

Мы будем рады вашим комментариям. Удачной вам сессии.

Отличия 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) Условия удовлетворения ожиданий

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

Ранее Ctrl + ↓