Упражнение для обсуждения ролей в 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. Это некий сводный словарь терминов, но кроме  пиктограммы, там есть краткое пояснение. Хорошо подойдет для первичного понимания незнакомых терминов, а уже потом можно искать в интернете статьи и материалы, связанные с этими терминами.

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

Немного анонсов: Leading SAFe в Киеве и Agile Tour Belarus

safe

Совсем скоро пройдут два важных мероприятия.

23-24 сентября 2016 года в Киеве пройдет открытый сертификационный курс Leading SAFe, в котором мы детально изучим один из самых популярных фреймворков для масштабирования компании с помощью Agile — Scaled Agile Framework. За два дня обучения будут освещены принципы и практики Scaled Agile Framework® (SAFe®) версии 4.0, что актуально для масштабирования Agile в крупных компаниях, состоящих из множества зависимых команд и проектов. В завершение класса участники допускаются к сдаче экзамена на сертифицированного SAFe Agilist. Как один из организаторов и тренеров этого мероприятия, добавлю, что следующий такой класс состоится не скоро, так что не упустите возможность:) Детали мероприятия на страничке в facebook. Регистрация: https://goo.gl/klWS6l

24 сентября в Минске пройдёт AgileTour Belarus 2016 — конференция о гибких методологиях в управлении ИТ-проектами. Здесь планируют говорить о внедрении Agile в командах и компаниях, о возникающих проблемах и способах их решения. Организатор мероприятия — команда SPACE при поддержке AgileLAB, частью которого я являюсь. Конференция будет полезна руководителям компаний и менеджерам проектов, Scrum-мастерам и владельцам продуктов, разработчикам, аналитикам и тем, кто заинтересован в совершенствовании процессов разработки. Новые знания получат как опытные Agile-практики, так и новички. Стоимость — $73.

Участники предстоящих тренингов о гибких методологиях от AgileLAB могут попасть на мероприятие бесплатно или со скидкой 50%.

Приобрести билеты можно на сайте мероприятия.

Ключевые доклады конференции:

  • Lean Organization, or what’s slowing you down?
    Tomasz Wykowski (первый сертифицированный Scrum-тренер в Польше), расскажет, как проанализировать процессы работы над проектом и понять, насколько они результативны, и как правильно распределить время, чтобы обеспечить оперативную разработку ПО;

  • How minions can help creating a complementary team and finding a bliss?
    Vladimirs Ivanovs (международный консультант и тренер из Латвии) привезет доклад о старых добрых ролях в команде по Адизесу с массой анекдотичных примеров из реальной жизни;

  • Lean Change Management — управляем изменениями как стартапом
    Алексей Пикулев (лицензированный Management 3.0 и ICAgile тренер, Польша) расскажет, как научиться действовать спланировано и обдуманно, быть осмотрительными и осторожными и доводить задуманные изменения до реализации;

  • 5 опор команды или управленческий минимум
    Денис Тучин (Agile тренер, Россия) осветит типичные проблемы Agile-ретроспектив в условиях процесса непрерывного совершенствования и расскажет, как с ними бороться.

Полный список докладчиков доступен на agiletour.by, а новости конференции появляются на Facebook. Зарегистрироваться и приобрести билеты можно на сайте конференции.

Две интересные книги про переговоры

books-must-read

Сегодня я расскажу о двух книгах: “Я слышу вас насквозьМарка Гоулстоуна и “Договориться можно обо всемГвена Кеннеди. Сначала разберемся, чем они хороши. Для меня, как тренера, консультанта и Agile-коуча интересна та книга, которая оказалась полезной в работе; та, которую я буду советовать и выдержки из которой можно цитировать в общении и на тренингах, иллюстрируя тот или иной пример.

Более чем полвека тому назад появилось такое понятие «Индекс цитирования». Его ввел в 1960 году Институт научной информации (основатель — Юджин Гарфилд). Хотя первые попытки индексировать количество ссылок на ту или иную публикацию предпринимались еще в 19 веке. Потом «Индекс цитирования» начали называть «Индекс интересных мыслей». Так вот, я эти две  книги прочитал давно, а в работе они мне помогают до сих пор. Я часто вспоминаю о них, привожу своим слушателям примеры из этих книг. Одним словом, мой личный индекс цитирования очень высокий.

Гвен Кеннеди «Договориться можно обо всем»
Эта книга, о переговорах, с фокусом на продажах. Суть слов Гвена в том, что мы всегда что-то продаем: вещи, идеи, услуги — в переговорных отношениях мы находимся почти постоянно.

Книга Гвена Кеннеди очень интересна своей структурой. Автор вводит идею четырех типов переговорщиков. И, соответственно, перед каждой главой дается некий кейс. Один из них – “совы”, очень мудрые переговорщики, которые ищут оптимальное решение. Есть еще “лисы”, которые всегда отстаивают  свою выгоду. “Лисы” и “совы”, наверное, наиболее удачные переговорщики. Но совы более экологичные, потому что они ищут решение, которое будет выгодно всем. Есть также “ослы” и “бараны”. Одни не понимают, что их все время так или иначе обманывают на переговорах, а вторые стоят на своем, даже если они не правы.

Автор говорит: «Вот такая ситуация: вы продаете или покупаете. Какое решение вы бы приняли? А, B, С, D». В конце главы он разбирает этот кейс: «Смотрите, вариант А принадлежит переговорщикам, которые упертые. Они не хотят признавать  мнение другой стороны. Вариант С, например, может принадлежать опытным переговорщикам, которые ищут наилучшее решение», и так далее. Таким образом, эта книга фактически является тренажером, если ее читать вдумчиво, анализировать свои ответы и понимать, почему ты ответил неправильно. Навыки, описанные в издании, очень быстро закрепляются, при том, что саму книгу читать просто интересно.

Свои выводы автор подкрепляет наглядными примерами из жизни. Например, почему нельзя давать скидки? Автор приводит рассказ о том, как во время «золотой лихорадки» за неким коммивояжером, ехавшим в город, погнались волки. Он начал отрезать куски и бросать им куски мяса от туши оленя, которая у него была с собой. Волки поняли, что им незачем останавливаться и есть кусок мяса, если у коммивояжера в санях еще целая туша. И они погнались за ним. Когда он приехал в город, его ругали все жители, потому что раньше волки никогда не гонялись за санями. А теперь коммивояжер показал, что это можно делать. По сути, этот пример показывает один из аспектов переговоров. Сейчас все потребители любят скидки. Тем не менее, для некоторых сфер бизнеса эта стратегия может оказаться невыгодной — вас будут “отжимать”, требуя еще больше.

В таком же контексте Гвен Кеннеди рассказал о продаже кофе. Всем известно, что кофе, который мы покупаем в кафе рядом, стоит в 20-30 раз дороже, чем кофейные зерна на плантации. И на самом деле, торги при закупке кофе – наиболее яркая область для  переговоров, потому, что там играет роль всё: кто доставляет кофе, кто фасует, кто его обжаривает и перемалывает.

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

Марк Гоулстон «Я слышу вас насквозь»
Вторая книга, которая мне очень сильно запомнилась: «Я слышу вас насквозь». Там отражены разные аспекты переговоров. Если первая книга — это элемент торгов, техники, как продавать и принимать какие-то предложения, то вторая – это больше про их психологический аспект. Автор книги — очень интересный человек, практикующий психолог, ведет тренинги для ФБР, для отделов переговоров при захвате заложников.

В первой части книги даётся теория и объясняется, как именно мозг принимает решения. Автор условно это называет «переход от НЕТ к ДА», ссылаясь при этом на книгу «12 правил мозга», написанную Джоном Мединой. Вторая часть  — это практические принципы принятия решений, которые мы не осознаем, но они есть. Третья часть книги — прикладные техники ведения переговоров. И четвертая — конкретные связки и конкретные примеры с пояснением, почему в той или иной ситуации оптимальной является эта или другая техника.

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

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

В Украине почти все компании, так или иначе, аутсорсинговые. И HR зачастую вынуждены торговаться как с клиентом за какие-то условия начала работы и так же с людьми, которые будучи в аутсорсинге начинают качать права. В этом плане HR специалистам точно будет интересно 🙂

В общем-то, эти книги вышли давно, но раз они у меня постоянно на слуху, значит, стоит поговорить о них снова. Хотя бы потому, что описанные в них техники существенно упрощают общение с клиентами и заказчиками!

Как создавать тренинги — практическое руководство на личном примере

practical-guide

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

Скажу сразу, что я не претендую на звание мега «тренера тренеров». Я начал проводить тренинги еще в 2007 году. Но с тех пор я многому научился, в том числе и сам прошел «тренинг для тренеров». Как показывает практика, если что-то долго делать, опыт и знания все-таки появятся 🙂

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

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

Этап 1. Хочу создать тренинг. С чего начать?
Я убежден: тренинг – продукт. А для продуктов я рекомендую создавать «Видение Продукта», которое помогает ответить на простые вопросы и держать в фокусе конечный результат.

Первый вопрос: «Для кого этот тренинг?»

Для команды, которая только думает о внедрении Agile-методов? Для команды, которая их уже практикует, но хочет переосмыслить, что и как они делают? Для группы менеджеров компании, которые хотят побольше узнать, как работать по Scrum-методологии? Для отдела DevOps, который внедряет Kanban? А может для HR-отдела, который хочет узнать новые слова или, наоборот, внедрить некие легковесные процессы, чтобы лучше делать свое дело? 🙂

Второй вопрос: «Зачем ИМ этот тренинг?»
Частично он выходит из ответа на первый вопрос, добавляя фокус и цели тренинга. Тренинг может быть направлен на ознакомление с широким кругом принципов и методов или на практические навыки в одной узкой области. Особенно хорошо, если участники соберутся уже на следующий день, чтобы использовать полученные знания и навыки.

Вопрос третий: «Какие у нас ограничения?»
Первое и самое распространенное ограничение – время. Если у меня есть один день, тогда можно рассчитывать на раскрытие 3-4-х тем, с учетом теории и практических упражнений. Два и больше дней, а это, можно сказать, уже роскошь, дают возможность глубоко погрузиться в разные темы, которые вместе создают целостное понимание отдельных частей общей картины. Но иногда время строго лимитировано и есть только полдня (примерно 4 часа) или мастер-класс на два часа. В таком случае нужно выбрать более узкий фокус и отказаться от многих интересных тем, которые вы не успеете рассмотреть.

Другое, не такое критическое ограничение – материалы. Флипчарт, стикеры и распечатки вы можете найти в любом офисе. Отлично, если есть возможность заранее собрать дополнительные материалы для упражнений – монеты, карточки для упражнений и прочие домашние заготовки. Поэтому, несмотря на мою безграничную любовь к Lego, я предпочитаю не использовать его для тренинга: нужно таскать с собой огромную коробку. А так я готов провести тренинг почти в любое время и в любом месте с минимальной подготовкой.

Конечно, на фоне всего этого у вас должна проскочить мысль о месте для тренинга. Где вы его проведете? Какое помещение вам доступно? Есть ли там столы для работы в группах и другие материалы? Об этом поговорим позже, когда приступим к упражнениям.

Дополнительные вопросы: «Какие критические атрибуты?» и «На что может быть похож этот тренинг?».

Частично они уже понятны из всех предыдущих ответов. Но стоит обратить внимание на один важный аспект: количество участников. Я сторонник концепции «Training from the back of the room» (тренинг из дальнего конца комнаты). Другими словами, я считаю, что в тренинге должно быть больше интерактива между участниками и меньше «монопольных» рассказов тренера. Лучше всего тренинг проходит в относительно небольших группах от 8 до 16 человек. При максимуме в 20 человек еще можно рассчитывать на внимание тренера к каждой группе участников. Если же у вас больше участников, то нужно будет думать о помощниках или об упражнениях, которые не требуют особого внимания тренера.

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

Еще Сократ сказал, что вовлечение в обучение способствует запоминанию. Это знают все, кто так или иначе знаком с проблемой обучения практическим навыкам (а гибкие методы работы – тоже навык).

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

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

Создаем тренинг для участников, которые пока еще мало знакомы с Agile-принципами разработки и в частности Scrum-методом. Это может быть отдельная команда или сборная группа в компании. Цель тренинга – раскрытие основных тем, таких как понимание идеи Agile, знание практик работы по Scrum-методологии, методы командной оценки и планирования итераций и проектов. Также обязательно получение практических навыков, чтобы начать их применять сразу после тренинга. По времени мы можем рассчитывать на однодневный тренинг при оптимальном количестве в 15 человек.

Так и назовем его – «Однодневный Scrum-тренинг»

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

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

Конференции, открытые тренинги и воркшопы в ближайшее время

safe-icagile-scrum-game

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

13 мая 2016 года (on-line) в формате вебинара поговорим о том, как «Масштабировать компанию по Agile принципам«. Эта тема все больше и больше обсуждается и я решил собрать свои мысли и заодно дать небольшие пояснения об элементах, которые используются в Scaled Agile фреймворках. Участие бесплатное, регистрация обязательна.

15 мая 2016 года (Киев, Украина) играем в Scrum Card Game, о которой я недавно писал. Это хорошая возможность для всех: и тех, кто хочет немного соприкоснуться со скрамом, и для тех, кто хочет научиться фасилитровать эту игру, чтобы в игровой форме обучить основам Scrum. Количество мест ограничено, присоединяйтесь.

19-20 мая 2016 года (Киев, Украина) проводим первый в Украине открытый тренинг Leading SAFe (SAFe Agilist certification). На этом тренинге мы будем детально разбирать Scaled Agile Framework, практиковаться на симуляции, проводить планирование группой команд и учиться управлять портфолио на основе ценности для бизнеса. Скидка 20% по промо-коду tim.com.ua (Да-да, это для внимательных читателей 🙂 )

24-25 мая 2016 года (Минск, Беларусь) в рамках конференции IT Spring 2016 провожу также открытый тренинг Leading SAFe (SAFe Agilist certification), впервые в Беларуси. Еще раз напоминаю, что это тренинг по масштабированию Agile процессов для лидеров разработки и руководителей различных уровней.

26-27 мая 2016 года (Минск, Беларусь), также в рамках конференции IT Spring 2016, проводим тренинг ICP Agile Project Management. Это тренинг международного консорциума по гибким методологиям ICAgile по управлению Agile проектами для менеджеров проектов, а также Scrum мастеров, стремящихся к менеджменту проектов. Тренинг продвинутого уровня требует наличие одного из сертификатов мирового уровня по базовым владениям гибкими методологиями (CSM, CSPO, PSM или ICP).

29-30 мая 2016 года (Минск, Беларусь) конференция IT Spring 2016. 29 мая в рамках Keynotes Day буду говорить про «Масштабирование компании по Agile-принципам», на второй день проведу воркшоп «Scaled Ball point game».
Если вы хотите посетить и тренинги и конференцию — обратитесь к организаторам, у них есть интересное предложение 🙂

2-3 июня 2016 года (Днепропетровск, Украина) конференция ITEM (IT Evolution Meeting), где до конференции, 1 июня, проведу мастер-класс по созданию обучающих упражнений и игр AGILE GAME JAM, а во время конференции буду модерировать поток Project Management и выступлю с рассказом «Закат эпохи Agile или The Force Awakening» о том, как мы докатились до того, что известный бренд на букву «A» уже хоронят и при этом по прежнему индустрия нуждается в развитии и изменениях.

До встречи!

Scrum Card Game — настольная Scrum игра

Scrum Card Game - настольная Scrum игра
Когда я только начинал вести тренинги по Scrum методологии и принципам Agile разработки, пришло понимание — теория легко забывается. Проще учится на своем опыте. Так мне понадобилась Scrum игра.

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

Так родилась идея, а затем и настольная игра — Scrum Card Game. С тех пор она отлично послужила мне и многим моим коллегам-консультантам. Меня неоднократно просили сделать ее доступной для широкой публики те, кто хоть раз в нее играл.
Настало время! 🙂

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

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

Для игры вам понадобится сделать игровые карточки: достаточно скачать инструкцию на странице игры Scrum Card Game — там же внутри есть шаблон карточек для печати. Вам также понадобятся два кубика (игральные кости) на каждую команду. Команды рекомендую собирать по 4-5 человек, максимум 6. Они работают независимо друг от друга, поэтому игру можно использовать и для большой аудитории, лишь бы были запасные наборы 🙂

Итак, объявите цель игры: каждая команда разрабатывает новый продукт и после третьей итерации выходит в “production” со всем, что они успеют сделать.

Каждая команда должна Запланировать спринт, Исполнить спринт и Адаптироваться на основе своего опыта. Зайдите на страницу игры и скачайте подробные инструкции.

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

Scrum Card Game опубликована по Creative Commons Attribution-ShareAlike 4.0 International License. Это означает, что вы можете свободно использовать игру в своей работе, даже в коммерческих тренингах и проектах, при условии, что упомянете авторство и источник, а также при условии, что все производные игры публикуются под такой же лицензией.

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

Притчи о любви к пользователям

love-to-users2

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

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

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

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

Притча первая: "Туалет в торговом центре"

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

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

В задании наверняка было указано так: «должно быть четыре умывальника, четыре мыльницы для них и большое зеркало». Вот так — коротко и ясно.

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

Результат получился такой:
toilet mirror

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

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

Притча вторая: «Номер для двоих в отеле»

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

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

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

Кажется, что разделить душ и туалет на две комнаты — ничего особенного. Но как известно, все гениальное — просто.  Так стандартное решение «как везде» превратили в другое, более удобное. И дизайнеры не испугались отойти от аксиомы «все так делают». Пользователи оказались важнее.

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

К чему я это все?

Я уже писал о том, что "мне не нужно техзадание". Старый подход, который давно изжил себя. Описание будущего продукта в стиле «система должна» совершенно неуместно. Система никому и ничего не должна: она неживая и сама по себе ничего не хочет. В современном мире фокус уже давно сместился на пользователя. Любое решение (будь то ПО или что-то другое) создается в первую очередь для нужд людей, которые будут его применять на практике. Неудачное решение, причиняющее постоянные неудобства, обречено быть забыто. Оно так и умрет, не отыскав своих покупателей.

Важно думать в стиле «пользователю нужно» или «пользователь хочет». Только так и никак иначе мы будем точно понимать, что мы делаем и зачем.

Большинство читателей уже знакомы с форматом записи требований, которые так и назвали «Истории Пользователя». Суть идеи проста, пишем в стиле:
Как <КТО>, я хочу <ЧТО>, потому что <ЗАЧЕМ> 

На первый взгляд, идея элементарная, но одновременно она очень мощная. Ведь мы сразу концентрируемся на (ЗАЧЕМ) — целях, которыми будет руководствоваться (КТО) — пользователь нашего решения. Таким образом, создавая свое решение, мы думаем о том, будет ли удобно пользоваться тем, что мы сделали.

Есть еще целый ряд Agile-методов анализа нужд и описания требований: Use Case, Story Mapping, Impact Mapping.

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

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

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

Agile вне ИТ или как построить машину, пользуясь Agile-принципами

agileWIKISPEED

Один из самых популярных вопросов, который мне задают на тренингах как применять Agile-методы в не IT-проектах.  Разработка нового или развитие существующего программного обеспечения всегда была областью высокой неопределенности. Тут сложно рассчитывать на то, что даже типовой проект пойдет точь-в-точь как предыдущие. Вопрос не в том, будут ли изменения в первоначальных требованиях, а скорее в том, как быстро они появятся.  В тоже время, многие другие проекты условно сводятся к “производству”: изготавливаются почти одинаковые продукты по типовому процессу.  Эти проекты условно-линейные и полностью поддаются планированию.

И все же люди из обычного мира бизнеса часто сравнивают разработку ПО и автомобильный конвейер. Иногда на моем тренинге или после доклада слегка наивный слушатель заявляет: “Мы же не можем собирать машину по частям: сначала колеса, потом двигатель, потом капот”. Подобное заблуждение возникло из-за подмены понятия конвейера, где идет сборка однообразных моделей тех же машин, и работы дизайнерского бюро. Разработка ПО — проблема из области дизайна, а не производства.

Чтобы окончательно развеять заблуждение относительно автомобилей, давайте посмотрим на проект разработки автомобиля с использованием Agile-принципов. Я имею ввиду проект WIKISPEED. Он участвовал в конкурсе суперэкономичных автомобилей, как автомобиль пригодный для езды по официальным дорогам, который потребляет два литра на 100 километров.  До этого попытки собрать подобный автомобиль велись на протяжении уже десятка лет. Это должен быть не просто некий космический болид, где пилот лежа проедет по идеально ровной пустыне. Речь идет о машине, в которой мы с вами можем ездить по городу и автотрассам. Машине, у которой расход на 100 км чуть больше 2-х литров.

В своем интервью автор проекта  Джо Джастис (Joe Justice) рассказывает, что с самого первого места работы он работал менеджером в Agile-командах. Для него это был, по сути, образ мысли и стиль жизни. Джастису довелось работать над разработкой ПО в маленьких и больших распределенных командах. Опять же, перед ним НЕ стояла задача сделать “Agile-машину” или “Lean-машину”. У него была цель создать ультра-эффективный автомобиль с помощью команды волонтеров, распределенной по всему миру. И уже как лидер и менеджер Джо Джастис выбирал методологию, которая помогла группе работать результативно.

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

Итак, команда взялась собрать машину. Участники знали общие требования: обычная комплектация машины, комфортная для каждого. Также они знали дополнительные требования — необходимое для “быть пригодным к езде по официальным дорогам”.

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

Это то, что я называю «Agile продукта». Для меня этот термин обобщает все методы и принципы принятия решений. Все, что надо делать дальше, чтобы приносить определенную пользу. Она может выражаться как в результате, потребляемом пользователями, так и в знании или прояснении рискованных областей. Если интересно, погуглите на темы “Lean Design Thinking” и “Agile Product Design”. Та же, популярная нынче, концепция Lean Startup большей частью адресует эту область.   

Одной из проблем проекта WIKISPEED было то, что команда распределена. Десятилетия назад говорил о том, что Agile методы лучше работают для команд, сидящих рядом. За последнее время появилось много инструментов, которые могут обеспечить команде общую среду общения: YouTube для записи демонстрации, Google Docs, онлайн доски задач, сервис конференц-звонков и, немаловажное, общая email рассылка на команду. Эти инструменты позволили распределенной команде волонтеров чувствовать себя так же, как Scrum команды, сидящие в одной комнате.

Плюс к тому же, одним из обязательных условий для них была  прозрачность всех обсуждений и документов. Даже если они создаются “другими” командами, каждый может посмотреть материалы соседей, когда ему это необходимо. Сюда же стоит добавить большую автономность принятия решений у команд, которые работают над развитием тех или иных частей машины. В проекте участвовали 44 человека. Все они были волонтерами, для которых проект WIKISPEED был хобби.

Это то, что я называю “Agile людей”. Принципы самоорганизации, совместная работа группы над одной целью итерации, общая ответственность за результат просто неотъемлемые части Agile-методов и самой философии “гибкости” и сотрудничества. Многие современные книги о менеджменте, мотивации, лидерстве и командообразовании говорят о том как использовать эти принципы для достижения максимума в работе “креативных команд”. Если покопаться, то термин “Intelectual workers” ввел еще дедушка Питер Друкер. В современном мире большинство работ относится к этому типу, а не только разработка ПО.

Ну и понятно, что учитывая опыт главного менеджера-организатора, все команды WIKISPEED работали по Scrum, адаптированному для их ситуации. У них были спринты-итерации и небольшие команды, которые фокусировались на улучшении тех или иных параметров автомобиля. В течение итерации команды ежедневно синхронизировались и  активно общались. Как правило в режиме “информация для всех”. А в конце итерации собиралась новая версия автомобиля. Члены команды вместе смотрели на полученный результат и обсуждали, что можно улучшить как в продукте, так и в их способе работы над ним.

Это то, что я называю “Agile процессов”. Все методологии и фреймворки, которые помогают быстро начать двигаться к результату, адаптируются под условия проекта. К сожалению они наиболее видимая часть “айсберга”, который мы называем Agile. По той же причине популярен Scrum — для него проще всего найти курсы или тренинги. При этом нередко совершенно забывают об остальных, упомянутых выше аспектах. На мой взгляд, они гораздо важнее любой методологии.

Если оглянуться и присмотреться, то сегодня многие компании, далекие от разработки ПО, применяют принципы и философию Agile. И дело не только в примере об автомобиле. Кроме разработки автомобиля, я знаю много других случаев: написание  сценария телесериала, ведение юридической практики, оказание контент-услуг. Agile вне ИТ активно применяется компаниями. Особенно когда речь идет о людях, решениях и процессах. Все это позволяет командам быть более гибкими и лучше достигать целей.

Должен ли ScrumMaster быть немного занудой?

scrummaster

У вас бывало такое ощущение, что ваш ScrumMaster (или даже просто ваш менеджер) ведет себя как зануда? Вот эти его напоминания о взятых на себя обязательствах, о том, что вы обещали вчера на стендапе и сегодня говорили совершенно о другом, о договоренностях в команде и всяких там definition of done. И за опоздания на стендап ругается. А еще эти его трекеры типа JIRA или напоминания о том, что слишком много работы в прогрессе — явный способ завалить обещанное. Или вот эта паника, если Burndown не идет близко к прогнозу.

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

А теперь вопрос к первой группе читателей — которым кажется, что их ScrumMaster “занудничает” — что вы делаете, когда он оказывается прав? Когда напоминания о недоделанной работе позволило довести ее до конца, когда вовремя поднятая “паника” в середине итерации позволила собраться, приложить усилия и сделать то, что обещали. Или наоборот, в конце итерации вы понимаете, что если бы его не проигнорировали, результаты вашей команды были бы лучше. Кто из вас на ретроспективе сказал “да, ты был прав”? 🙂

Большая свобода, которая дается идеей само-организации в команде, подразумевает и ответственность за результат. И если кто-то напоминает своим коллегам о взаимных обещаниях или о чем договаривались все вместе — это, на мой взгляд, признак того, что он переживает за результат. Всё это как раз и есть проявление взаимной ответственности, “под-отчетность” друг-другу и реальная помощь в том, чтобы становится лучше.

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

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

P.S.

Важный момент, ScrumMaster не может быть “засранцем” — это означает, что он сам раздает задачи, сам говорит команде, где они были не правы, говорит что делать, чтобы исправить текущую ситуацию, не слушает их мнение и, что самое ужасное, говорит в конце итерации “я же говорил” 🙂

Такие люди точно никогда не получат благодарности или признания от команды — они просто не оставляют команде места для роста и свободы принятия собственных решениях. Таких, я думаю, никто не любит 😉