Упражнение для обсуждения ролей в Scrum или другом Agile-методе

agiletopicscards-35

Для принятия “культуры Agile” важны понимание ролей и уход от должностей. В книге, о которой я писал раньше, Джеф Сазерленд рассказывает о своей первой Scrum-команде. Трансформация началась с того, что Джеф сказал им: “Порвите свои визитки”. Все практикующие “аджалисты» сходятся в том, что в Agile-методе важны роли — как наборы обязанностей, ответственностей и практик.

Для многих команд переход к Scrum (или к другой методологии из семейства Agile Software Development) начинается с определения того, кто и что делает, и за что отвечает. Понимание и обсуждение ролей всегда было частью моих публичных и командных тренингов. Сейчас я готовлю серию постов о создании Agile-тренинга для команды, и в результате опубликую готовый шаблон такого тренинга, поэтому расскажу об этом упражнении подробнее.

Самое простое, что приходит на ум для обсуждения ролей — сортировка терминов. В итоге механизм упражнения (или “игры”) предельно прост: участники делятся на группы по 2-4 человека и сортируют пачку терминов, которые относятся к ролям Scrum (в Scrum их 3, но вы можете ввести необходимое вам количество ролей). После работы в группах материал лучше закрепить общим обсуждением и уточнением, чтобы не было ошибок в понимании и разницы в трактовке. Я называют это “игра в бинго”. Мы берем одну роль, и каждая группа по очереди называет термин, который она отнесла к ней. Если остальные группы тоже отнесли термин к этой роли, они кричат “бинго”. Если нет — начинается обсуждение. Именно за обсуждения я и люблю это упражнение — в них мы проясняем понимание и углубляемся в аспекты той или иной практики, принципа или концепции.  Даже если у вашей группы достаточно опыта и расхождений в сортировке терминов нет, просите участников привести практические примеры. Так вы можете проверить их знания более глубоко.

Но где взять термины? Долгое время я использовал набор фраз, которые составил вместе с моими коллегами-консультантами. Но они были не совсем понятны участникам. С тех пор, как я узнал про Agile Topic Cards, я заменил фразы карточками, и все стало работать во много раз лучше!

Как вы помните (или можете прочитать), Agile Topic Cards представляют собой карточки, на которых нарисованы Agile-термины. Зеленые — это практики, синие — принципы, а красные — концепции. Из 166 карточек можно выбрать любое количество, которое покажется вам необходимым для дискуссии.

Лично я выбрал следующие номера:

Microsoft PowerPoint - Agile Topics Cards v3
2 – Definition of Done
По моему мнению, это ответственность команды, хотя Scrum-мастер может отвечать за внедрение и поддержку этого внутреннего договора.

Microsoft PowerPoint - Agile Topics Cards v3
3 – Vision
9 – User Story

agiletopicscards-10

10 – Backlog
Имеется в виду Product/Project Backlog, за которые отвечает Владелец Продукта.

agiletopicscards-11

11 – Trade Offs
Для меня это — договоренности и компромиссы, которых Владелец Продукта достигает между бизнесом и командой, но всегда можно обсудить, как это понимаете вы.

agiletopicscards-14-25
14 – Team Performance (Velocity и другие)
25 – 1:1s

Microsoft PowerPoint - Agile Topics Cards v3
26 – Vertical Slice
Это — хитрая карточка. Прежде всего имеется в виду, что Владелец Продукта должен мыслить функциональностью (Features), а не задачами. Но также нужно, чтобы команда сфокусировалась на всех технических аспектах и делала функциональность целостной — от UI до глубин БД. Эта дискуссия может перекликаться с тем, о чем я писал в статье “Какого цвета ваш Бэклог”.

agiletopicscards-31
31 – Adaptive Planning
Это ответственность Владельца Продукта. Картинка показывает движение к Цели (эта Цель — звезда, нарисованная на карточке Vision(#3)).

agiletopicscards-40-41-42-47-54
40 – Code Review
41 — Slicing
42 – Test Driven Development
47 – KPI’s
54 — Timebox

agiletopicscards-60
60 – Team Development
Эта картинка означает модель развития команды Брюса Такмана: Forming-Storming-Norming-Performing.

agiletopicscards-63
63 – End to End testing

agiletopicscards-64

64 – Decision Making
По-моему, это Владелец Продукта решает, чего не делать, и говорит пожеланиям “да” или “нет”.

agiletopicscards-66

66 – Face to Face conversation
Эту картинку я трактую так: команда должна предпочитать прямое общение другим типам коммуникации.

agiletopicscards-68
68 – Pair Programming

agiletopicscards-69
69 – Autonomy
Здесь подразумевается, что cross-functional-команда должна иметь достаточно автономности.

agiletopicscards-71-99
71 – Collective Code Ownership
72 — Visualization
78 – Motivation
83 – Transparency
84 – Sprint Burndown
85 – Release Burnup
86 – Forecasts and Velocity
87 – Retrospective
89 – Team dependencies
94 – Relative Estimation
95 – Poker Planning
99 – Iterative & Incremental

agiletopicscards-100

100 – Backlog Grooming
Тут я обычно даю выбрать большинству. Иногда Владелец Продукта заинтересован в том, чтобы узнать от команды “цену” следующих элементов бэклога. Иногда Scrum-мастер заинтересован в том, чтобы команда получила качественные Элементы Бэклога (PBI) до начала планирования следующего спринта.

agiletopicscards-101-107

101 – Continious Deployment
102 – Continious Delivery
104 – Clean Code
107 – Daily StandUp

agiletopicscards-111
111 – Demo
Продемонстрировать результаты и получить обратную связь — это ответственность команды (!). Во всяком случае, в нормальных компаниях :).

agiletopicscards-114

114 – Risks
Риски, о которых заботится Владелец Продукта, или менеджер, который стоит за командой и Sсrum-мастером (на картинке основные категории рисков: Бизнес, Технологии, Социальный, Дедлайны).

agiletopicscards-117
117 – Outcome VS Output
Владелец Продукта занимается тем, что максимизирует результат (Outcome) – больше счастливых пользователей.

agiletopicscards-120-143
120 – Continious Integration
126 – Servant Leadership
128 — Refactoring
132 – Automated Test Checking
143 – Sprint Backlog

agiletopicscards-146
146 – Team Kick-off/Lift-off
Это означает запуск новых команд или запуск нового проекта в команде.

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

Agile Topics Cards — универсальный инструмент agile-коуча, и не только

agiletopicscards

Agile Coaching — это практическая работа с командой, которая позволяет ее членам освоить гибкие подходы к разработке программного обеспечения. Но даже если вы не коуч, а руководите командой или организовываете проекты, вам нужен простой инструмент, который поможет объяснить все необходимые термины и понятия.

Для меня таким инструментом стали Agile Topics Cards. Это карточки с визуализацией терминов философии Agile Software Development. Их придумал Джимми Джанлен (Jimmy Janlen) из шведской консалтинговой группы Crisp, которая уже радовала нас трудами Хенрика Книберга и Маттиаса Скарина.

Всего карточек — 162. Каждая карточка содержит термин и его визуализацию.

Карточки делятся на:

зеленые: практики, техники и инструменты;

синие: темы для обсуждения;

красные: абстрактные модели и теории.

Чтобы начать работать с терминами, карточки (или их часть) нужно распечатать и желательно заламинировать.

Только представьте количество вариантов их использования! Джимми предлагает 9 первоначальных идей:

  1. Выбор темы для обсуждения в формате Lean Coffee.
  2. Вдохновение для статей в блоге (мне точно стоит попробовать! :))
  3. Обсуждение один на один — отличный вариант для парного коучинга.
  4. Источник тем для очередной ретроспективы в команде.
  5. Личное развитие: выберите термин и за 20 минут попробуйте найти в гугле как можно больше информации на эту тему.
  6. Аудит/оценка состояния команды или организации: выберите определенные карточки и проанализируйте, знают или не знают про эти термины в команде, делают/не делают и т. п.
  7. Тема недели: выберите карточку и повесьте ее на видном месте, чтобы в течении недели побуждать обсуждение этой темы командой.
  8. Рассказ историй: произвольно выберите 4-5 карточек и рассказывайте с их помощью истории.
  9. Короткое выступление на произвольно выбранные темы для обмена знаниями (например, во время обеда).

Меня познакомили с этими карточками на моем любимом  «слете коучей” Play4Agile. Там собираются такие, как я, чтобы обменяться идеями и практиками, и создать новые игры для обучения и развития команд. Конечно же, мы решили придумать как можно больше упражнений с этими карточками.

Вот вам несколько наших идей:

  1. Speed Dating with Agile Topics Cards. Всем участникам раздаются выбранные карточки, и каждый по очереди рассказывает своему партнеру о том, что знает на эту тему. Затем один ряд участников сдвигается, и новые пары повторяют обсуждение.
  2. С помощью карточек можно договориться о практиках и принципах, которые хочет применять вся команда. Для этого карточки делятся на три категории: необходимые (Must), полезные (Should) и просто интересные (Nice to have).
  3. С помощью терминов можно обсудить ответственность и практики для каждой из ролей в команде (это упражнение стало моим любимым, и я напишу о нем отдельно).
  4. Сортировка связанных терминов (Like to like). Можно складывать рядом термины, которые вы считаете связанными между собой. Получается эдакий мега-пазл.
  5. Сортировка карточек по категориям «прекратить» (Stop doing), «начать» (Start) и «продолжить» (Continue) хорошо подойдет для ретроспективы или просто командного обсуждения совместной работы.
  6. Можно использовать карточки как дополнение к другим играм или техникам фасилитации. Например, к созданной с моим участием игре Nobody’s Perfect или другой, не менее интересной игре — Fearless Journey.
  7. Ну и для завершения на веселой ноте — карточки можно использовать для игры в “крокодила”. Первая команда передает игроку второй команды карточку с термином, а он должен изобразить его только знаками, без слов, или хотя бы не используя ключевые слова. Члены второй команды должны угадать, что это за термин 🙂

Хорошим дополнением к карточкам станет книжка Agile Planet. Это некий сводный словарь терминов, но кроме  пиктограммы, там есть краткое пояснение. Хорошо подойдет для первичного понимания незнакомых терминов, а уже потом можно искать в интернете статьи и материалы, связанные с этими терминами.

Как видите, идей можно придумать очень много. Рекомендую вам как можно скорее скачать файл с карточками и начать их использовать.

Самообучение — первое правило сложных систем или о чем я рассказывал на AgileBaseCamp

AgileBaseCamp 15 марта 2014 Прошедшая конференция Agile Base Camp была посвящена Вовлеченности и Ответственности, что на мой взгляд, непосредственно связано с людьми и командами.

Люди — очень «сложные системы», и каждый по-своему уникален. Внедряя новые методы работы и новые практики, мы заставляем людей меняться. Как у любой сложной системы, результат и реакция могут быть не такими, как планировалось.

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

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

На мой взгляд, это первое и с самое главное правило для сложных систем — адаптация своего поведения. В своем рассказе я  привел практические инструменты адаптации и на примерах рассказал, как команды могут качественно учится на своем опыте. (далее…)