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

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

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

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-тренинг»

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

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

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

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

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 вне ИТ активно применяется компаниями. Особенно когда речь идет о людях, решениях и процессах. Все это позволяет командам быть более гибкими и лучше достигать целей.

Мы дождались её: книга “Scrum. Революционный метод управления проектами» вышла на русском языке

Книга Книга "Scrum. Революционный метод управления проектами"Эту книгу ждали очень долго и вот она вышла на русском языке в издательстве «Манн, Иванов и Фербер». Дочитав книгу, хочу поделиться своими впечатлениями.

Уверен, что Книга «Scrum. Революционный метод управления проектами» в издании «Манн, Иванов и Фербер» станет книгой для каждого из вас: от читателей моего блога и знакомых из Agile сообществ до всех, кто хочет управлять проектами эффективно. Таких людей наберется немало, ведь быстрая реализация проектов кажется недостижимой мечтой. Но Джефф Сазерленд, автор самой популярной, из семейства Agile, методологии Scrum, так не думает. Он мыслит конструктивно, подкрепляя свою теорию интересными примерами. Название книги в английском варианте звучит очень амбициозно:»The Art of Doing Twice the Work in Half the Time”. Пожалуй, если бы автором был другой человек, я бы, мягко говоря, удивился. Но в случае с Джеффом Сазерлендом и невероятные истории становятся реальностью.

Начинается книга с рассказа о том, что натолкнуло автора на создание его методологии. Когда-то я уже переводил пост из блога Сазерленда «Как появился Scrum». Расширенный рассказ о появлении Scrum есть в первой главе, которая задает тон этому бестселлеру. Плюсы всей книги в простой и живой манере рассказчика, легком повествовании и умеренном объеме. С первых страниц создалось ощущение, что будто мы, я и старина Джефф, сидим рядом после конференции. И этот гуру управления делится со мной своим опытом. Что-то в стиле «один мой сосед задумал отремонтировать дом за 6 недель. Мы ему, конечно не поверили. Но ровно через 6 недель пришли к нему в гости отмечать новоселье…» Одна из многих динамичных историй, в которых участвовал сам Джефф Сазерленд и которые подчеркивают примеры применения Scrum. Не скучная реклама, а вдохновляющий на поступки опыт.

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

Сильная сторона книги в том, что рассказ построен на контрасте. С одной стороны, неэффективные проекты и организации (и такие до сих пор есть! мы знаем). С другой стороны, команды, которые достигли качественно иных результатов, применив Scrum.

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

Так что мой вывод прост. Книга «Scrum. Революционный метод управления проектами» интересная и универсальная, обязательная к прочтению. Джефф Сазерленд написал ее не столько для айтишников и убежденных “аджалистов”, а скорее для представителей бизнеса, менеджеров всех уровней и просто людей, которые хотят понять феномен Scrum.

 

P.S. После чтения книги у меня осталось много заметок. Значит мы еще вернемся к некоторым важным темам. Оставайтесь с нами.

Agile Eeastern Europe 2015: планируем Agile трансформацию

Agile Transformation is a ChangeДокладчики мирового уровня, новые взгляды и идеи, опыт зарубежных и местных компаний, мастер-классы и вдохновляющие неформальные беседы за кофе — все это вновь привлекает участников со всей Восточной Европы и не только.

Если вы вдруг еще не слышали, Agile Eastern Europe вновь состоится уже в эту пятницу. Желающие все еще могу зарегистрироваться и принять участие.

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

Отдельным треком идут воркшопы — это мастер-классы, мини тренинги, симуляции и другие практические виды обучения и обмена опытом. Именно к этому потоку я присоединяюсь со своим коллегой, Юрием Малишенко. Мы поговорим про Agile-трансформацию или изменение компаний в сторону Agile.

Изменение лежит в основе любой человеческой деятельности.

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

Когда мы говорим про agile – мы на самом деле имеем в виду то, что нам предстоит изменить существующий способ взаимодействия, чтобы стать более гибкими. Но что значит добиться успешного изменения? Что такое устойчивое изменение? Возможно ли управлять изменением?

Многие считают, что изменение это просто – оценили текущее состояние, нарисовали цель, подготовили план и поехали! Ничего не напоминает? Многие внедряют Agile, делая это совсем негибким способом.

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

Ждем вас на мастер-классе для экспертов, в пятницу 27 марта в потоке Workshops в рамках Agile Eastern Europe 2015.

Продуктивный тренинг — это заслуга участников

IC-Agile

Я большой сторонник концепции «Training from the back of the room». Кто хоть раз был у меня на тренинге знает, что большая часть времени — это интерактив с участниками и работа в группах. Поэтому я твердо уверен, что отличный тренинг — это большей частью заслуга участников 🙂

На днях мы проводили открытый тренинг «Гибкая разработка ПО», аккредитованый международным Agile консорциумом (ICAgile International Consortium for Agile). Напарником в этот раз был мой коллега Андрей Баглай, за что ему отдельное спасибо.

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

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

Я уже получил ряд писем от людей, не успевших попасть и спрашивающих о следующих тренингах, поэтому и решил как-то исправить ситуацию. Хочу сообщить, что 28-29 ноября, 2014 года в Минске состоится такой же класс по Agile управлению проектами, также аккредитованный международным Agile консорциумом.

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

Еще раз спасибо всем участникам тренингов и читателям блога.
Оставайтесь с нами.

Видео: Scaled Agile Framework за 7 минут — все, что нужно знать о SAFe

safe

На сегодняшний день Scrum является наиболее популярным фреймворком среди всех методов Гибкой Разработки ПО (Agile Software Development). Это видно по тому, о чем чаще всего говорят в статьях и на конференциях, также популярность подтверждается результатами опросов.

В то же время, все больше компаний сталкиваются с ситуацией, когда у вас есть сразу несколько команд, работающих над одним продуктом или проектом. Очевидно, что «Простой Ванильный Скрам» (plain vanilla scrum) тут не подходит. Конечно, Кен Швабер давно уже упомянул «великую мудрость»: Скрам-Скрамов (Scrum of Scrums) — встречу синхронизации между командами. Но на практике, одна эта встреча не помогает решить все вопросы организации масштабного проекта и координации 2-х и более команд. Во всяком случае исходя из моего опыта 😉

Последние года три, я постоянно сталкиваюсь с такими крупными проектами и компаниями, которые создают Enterprise Agile методы и культуру. (далее…)

Анонсы мероприятий, которые нельзя пропустить :-)

events

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

Начну с того, что организовываем мы — и это долгожданная IT-People PechaKucha. Пока это даже не анонс, а преданонс. Пока мы только собираем рассказы, и уже совсем скоро откроем регистрацию и сделаем полный анонс. Само мероприятие пройдет 13 марта, и в этот раз мы сосредоточимся на теме Стартапов и Продуктовых компаний. Так что если вам есть чем поделиться, можете подать свою тему! PechaKucha — это бесценный опыт и всегда очень интересно 🙂

А вот с 28 февраля по 1 марта в Киеве пройдет конференция Selenium Camp 2014. Эта ежегодная конференция пройдет уже в четвертый раз, что не может не радовать, так как хороших узкоспециализированных мероприятий такого масштаба совсем немного. Уже готова программа конференции, и вовсю идет регистрация. Всем, кто так или иначе интересуется или планирует заинтересоваться Selenium и всем, что с этим связано, очень рекомендую.

15 марта пройдет в Киеве конференция AgileBaseCamp. В это раз организаторы вязли направление «Вовлеченность и ответственность». Уже сформирована программа и полным ходом идет регистрация. Очень много разноплановых докладов, должно быть познавательно и интересно, так что рекомендую сходить.

И если уж говорить о мероприятиях со словом «Agile», то 21-22 марта в Москве состоится масштабная конференция AgileDays 2014.  Здесь я сам планирую принять самое что ни на есть непосредственное участие, и расскажу много чего интересного, и воркшоп проведу, но об этом потом, в любом случае буду рад увидеться в Москве!