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

Анастасия Бутова-Никишина

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019   scrum   scrum-master   Анастасия Бутова-Никишина   оценка событий Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019   Brendan Wovchko   kanban   Mike Cohn   scrum   Анастасия Бутова-Никишина

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

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

ВАЖНО:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВАЖНО:

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

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

Что такое продукт?

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

Но что же такое продукт?

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

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

Что является продуктом авиакомпании?

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

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

Всё ли перечисленное — продукты?

Определение продукта и примеры

Майк Кон определяет продукт как что-то (физическое или нет) созданное в процессе и предоставляющее ценность рынку.

Исходя из этого определения, стул будет продуктом, Microsoft Office тоже, услуги по Agile консультированию тоже продукт, картина тоже будет продуктом.

Таким образом, продуктом может быть что-то физическое (например, стул) или что-то цифровое (например, Microsoft Office, электронная книга, телевещание), также продуктом может быть услуга (например, Agile консультирование).

Продуктом может быть даже идея (например, запатентованный алгоритм).

Каждый из этих видов продуктов создаётся в процессе или, говоря проще, посредством одного или нескольких действий. Кто-то изготавливает и собирает стулья. Для Microsoft Office был создан дизайн, написан и протестирован код. Процесс, который создаёт продукт не обязательно формальный и определённый. Некоторые создатели могут даже и не знать о существовании процесса. Однако некоторая форма деятельности входит в создание каждого продукта.

Продукты могут быть определены рекурсивно

Продукт может существовать с другим продуктом. Например, у пишущей ручки есть стержень с чернилами. Ручка — продукт, однако и стержень с чернилами — продукт.

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

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

Продукты приносят ценность рынку

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

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

Применим определение продукта к примеру с авиакомпанией

Итак, если продукты создаются в процессе и приносят ценность рынку, является ли программные компоненты продуктами?

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

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

А что насчет системы мониторинга и планирования технического обслуживания самолётов? И это тоже продукт.
Она создана в процессе и также приносит ценность рынку. Какому рынку?

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

Тоже самое может быть сказано и о сайте авиакомпании, который позволяет пассажирам бронировать авиабилеты. Для сайта существует рынок.

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

Применение определения продукта к программным компонентам

Держа в голове вышесказанное, перейдём к программным компонентам. Если одна команда создаёт программу, которой пользуются другие команды, можем ли мы сказать, что программа — продукт?

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

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

Избегание субоптимизирующих продуктов

Согласно профессору Таер Воткинсу из  государственного университета экономики Сан Хосе (San Jose State University Economics) субоптимизация «относится к практике сосредоточения внимания на одном компоненте из всех и внесении изменений для улучшения только в один компонент... игнорируя эффект изменений на другие компоненты»

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

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

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

Word, Excel, PowerPoint и тд. — это отдельные продукты. У каждого из них свой владелец продукта и свой продуктовый бэклог.

С таким большим продуктом как Office, легко представить, что есть и продукты, которые представляют собой общую функциональность для Word, Excel и PowerPoint. Если говорить о проверке грамматики, то да, выделение компоненты как отдельного продукта имеет смысл. Функциональность по проверке грамматики ценна для рынка (другим команда нет необходимости создавать свою отдельную такую же компоненту с нуля).

Тем не менее, функции Excel {=СУММА; =СРЗНАЧ и прочее} нельзя выделять как продукт, так как эта функциональность уникальна для Excel, таким образом функциональность служит только одному клиенту. Слишком рискованно для данной функции выделять отдельного от Excel владельца продукта и отдельный продуктовый бэклог.

В дополнение к тому, что следует избегать продуктов для одного клиента, еще одним способом снижения неоптимального мышления при работе с несколькими продуктами является назначение главного владельца продукта (chief product owner).

Главный владелец продукта (chief product owner) — это стратегическая роль, он отвечает за формирование видения по всем подпродуктам. Например, для продукта Office главный владелец продукта (chief product owner) будет следить за тем, как каждый отдельный продукт влияет на весь пакет.

P.S.

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

Текст адаптирован с оригинальной статьи:
https://www.mountaingoatsoftware.com/blog/what-is-a-product

2019   Agile   Mike Cohn   Product   Анастасия Бутова-Никишина   Продукт

Немного о том, как научить команду строить User Story Map (из личного опыта)

Давайте попробуем сыграть в простую игру
«Собраться утром на работу (от момента пробуждения до момента закрытия за собой двери)». Я часто прошу поиграть своих коллег в неё до перехода к работе с настоящей — продуктовой User Story Map.
Саму же игру мне показали на курсе ICP в ScrumTrek, далее она обросла ещё небольшими изюминками и кажется предела совершенства нет, каждый раз что-то новенькое открывается, приходят инсайты от ребят :)

Суть её очень простая:
Для начала, вам следует разделить команды по 4-5 человек, больше будет сложнее, лучше в таком размере. Командам потребуется стол, а дальше лучше стена. Стикеры квадратные — сразу даём командам, стикеры побольше прямоугольные для Раунда 3.

Раунд 1 (10 минут) [индивидуальная работа — свой путь]
Каждому участнику/це надо на стикерах написать все свои действия, которые он/она осуществляет каждое (типичное) утро, собираясь на работу. Один стикер = одно действие. После того как время истекло, уточняем все ли закончили или нужно ещё немного времени. Чаще всего дополнительное время необходимо командам, где девушки :)
После завершения спрашиваем у каждого сколько примерно времени требуется для сбора на работу
{это нам-модераторам потребуется на последних 2-х раундах}

Раунд 2 (10 минут) [командная работа — объединение]
Команде необходимо теперь объединить свои действия (истории сбора на работу). И здесь лучше всего подойдёт стена. Одинаковые действия либо склеиваются, либо остаётся одно (чаще с более понятным почерком), если что-то не совсем одинаковое клеится так, чтобы видны были оба стикера, команда после решит что с этим делать.
В каком порядке будут действия — решает команда.

Раунд 3 (10 минут) [командная работа — группировка — формируем эпики]
Выдаём команде прямоугольные стикеры и говорим, что им необходимо сгруппировать действия и над каждой группой на прямоугольных стикерах написать названия.
{на этом этапе лучше профасилитировать каждую команду, так как есть риск, что они захотят под одну группу закинуть ОЧЕНЬ разные вещи — надо почелленджить}
А теперь начинается самое интересное :)

Раунд 4 (максимум 5 минут)
Ранее мы спросили сколько времени у каждого занимают сборы на работу — прикидываем сколько будет 1/3 от этого среднего и говорим, что у ребят минус эта 1/3 (например, они проспали и у них минус 30 минут) и им необходимо оставить только те действия, которые они успеют сделать. Что не успеют спустить ниже на уровне соответствующей группы, стикеры с названиями группы не трогаем.

Раунд 5 (максимум 5 минут)
Теперь мы отнимаем 1/2 их времени и просим проделать то же самое, что и в 4-ом раунде. Однако! добавляем условие (Acceptance criteria): собраться на работу в таком состоянии, в котором вас пропустит охрана на работу и примет коллектив или заказчик :)

Стикеры, которые не успеваем идут вниз, НО на уровень выше чем те, что на Раунде 4.
Если у вас будет желание дойти то нулевого уровня USM (skeleton) можно провести ещё несколько раундов — убирая минуты до того момента, как кто-то скажет «Да ну нафиг, позвоню на работу, скажу проспал/а!». Стикеры этого уровня как можно ближе к названиям групп, первая линия.

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

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

А ещё бывает нетипичное утро. Проснулись, а у вашего питомца случилось что-то не то, и вам надо прибрать. Неожиданность, которая забирает время и ... лучше всё-таки прибрать :))))) (это бага)

2019   User Story Mapping   Анастасия Бутова-Никишина   бэклог   игры

Самоорганизующиеся команды не собираются случайно

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

В Agile Manifesto самоорганизующиеся команды — это ключевой принцип: «Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд»

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

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

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

Не каждая Agile команда самоорганизуется одинаково

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

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

Можем ли мы ожидать самоорганизации от Agile команд?

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

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

Менеджмент осуществляет искусный контроль над самоорганизацией

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

«Выбор подходящих людей для проектной команды во время мониторинга изменений в групповой динамике и добавление или удаление участников в случае необходимости [является ключевой обязанностью менеджера]. „Мы бы добавили в команду более взрослого и более консервативного участника, если бы баланс слишком сильно сместился в сторону радикализма“, — сказал руководитель Honda. „Мы тщательно отбираем участников проекта после долгих размышлений. Мы анализируем различные личности, чтобы увидеть, будут ли они ладить“»

Поиск подходящих людей в Agile команду

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

1) Включите все необходимые компетенции

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

2) Сочетайте уровень технического мастерства

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

3) Находите баланс среди экспертов в определённой области

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

4) Ищите разнообразия

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

5) Учитывайте постоянство при формировании команды

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

Некоторые возражения по поводу самоорганизации команд

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

Один доминирующий человек будет принимать все решения

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

Если вы замечаете, что такое начинает происходить, поясните данному человеку, что в тех ситуациях, где ему кажется, что он лучше всех знает «как правильно делать», ему следует давать команде право высказать своё мнение.

Спросите у него, как он думает, сможет ли команда принять правильное решение, если он представит свои мысли как мнение, а не как неоспоримое решение.

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

Моя команда ожидает, что Scrum Master возглавит

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

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

Команда слишком «зелёная» для самоорганизации

Третье возражение заключается в том, что команда слишком «зелёная» для самоорганизации

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

К сожалению, часто данные возражения маскируют реальную причину: «Я не верю, что команда самоорганизуется так, как я хочу». Это очень плохо.

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

Текст адаптирован с оригинальной статьи:
https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly

2019   Agile   Mike Cohn   Анастасия Бутова-Никишина   команда

Разоблачение шести мифов о гибкой разработке продукта

Организации применяют agile подход по многим причинам:

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

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

Миф #1: agile только для разработки программного обеспечения

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

Agile в наши дни используется для всех форм разработки продуктов, от физических продуктов до облачных решений. Помимо продуктовой разработки, agile успешно используют:

~ маркетинговые команды для планирования и проведения кампаний;
~ адвокаты для управления делами и рабочей нагрузкой;
~ команды по организационной трансформации, в частности при переходе на agile;
~ команды руководителей для управления своими организациями;
~ семьи для улучшения времени, которое они проводят вместе;
~ пары при планировании свадьбы.

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

Если вас смущает отсылка к программному обеспечению в опубликованных документах, таких как Agile Manifesto, просто замените на слово «продукты». Замените, например, рабочее программное обеспечение на рабочие продукты и прочитайте еще раз: Рабочие продукты, важнее исчерпывающей документации. Это идеально подходит. Почему? Потому что agile работает со всеми видами продуктов, программное обеспечение является лишь одним из них.

Миф #2: менеджеру нет места в agile

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

Нет: часть работы не была забрана. Такие активности, как назначение задач конкретным людям никогда не должна быть самой важной частью работы менеджера

Менеджеры должны быть сфокусированы на создании среды и культуры, которые необходимы команде для развития. Их время не должно расходоваться на такие мелочи, как кто будет работать над какой задачей.

Питер Друкер — ведущий теоретик 20-го века в менеджменте, наиболее известный идеей управления по целям и созданием аббревиатуры SMART для постановки целей (цель должна быть конкретной, измеримой, достижимой, значимой и привязанной ко времени), сказал, что у менеджеров есть пять видов обязанностей:
1) постановка целей;
2) организация людей и работы;
3) мотивация и коммуникация;
4) измерение;
5) развитие людей

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

За многие годы существования agile ни одна из компаний не принимала решения об увольнении всех менеджеров. Да, некоторые менеджеры стали scrum-мастерами, некоторые Владельцами продуктов, тем не менее в agile есть место для менеджеров.

Миф #3: стэйкхолдеры могут вносить изменения, когда захотят

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

Давайте рассмотрим ситуацию с заказом еды в ресторане

Вы говорите официанту, что хотите курицу. Затем сразу же говорите, «Нет, лучше лосося». В данном случае изменение вам ничего не стоит.

Однако, если вы измените своё мнение позже, это будет вам чего-то стоит. Если вы скажите официанту, что хотели бы лосося вместо курицы после того, как кухня уже начала готовить, это будет стоить приготовленного впустую блюда (за которое ресторан может вас попросить расплатиться)

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

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

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

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

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

Миф #4: Каждый участник agile команды должен быть универсальным

Участник agile команды должен быть способен делать всё — самый популярный миф об agile командах.

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

Это абсолютно не так.

Agile командам не надо, чтобы каждый обладал всеми компетенциями, командам нужно, чтобы ценили тех, кто обладает несколькими компетенциями.

Чтобы понять ложность этого мифа, давайте рассмотрим пример с модным рестораном

В ресторане есть Шеф-кондитер, который умеет делать выпечку, десерты, хлеб и другие хлебобулочные изделия. Его роль звучит как высококвалифицированная, но специализированная. Другой специализированной ролью на кухне может быть Соусье́, который отвечает за соусы, за всё, что подается с соусом, также за тушение и обжарку в соусах.
На хорошо организованной кухне было бы неплохо, если бы Шеф-кондитер мог помочь Соусье́, возможно, нарезав немного лука, но ни Шеф-кондитер, ни Соусье́, не способны полностью выполнять работу друг друга.

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

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

Баланс может быть достигнут в большинстве команд, даже если несколько её участников владеют только одной компетенцией.

Миф #5: Agile команды не планируют

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

Любая agile команда планирует на тот горизонт, который необходим для принятия важного решения.

На самом деле, несмотря на этот миф, agile командам проще создавать надежные планы, потому что она знает насколько быстро производит продукт.

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

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

Миф #6: Agile команда не создаёт архитектуру и дизайн своего продукта

Пришло время разоблачить последний миф: миф о том, что agile команда не создаёт архитектуру и дизайн своего продукта.

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

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

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

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

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

Текст адаптирован с оригинальной статьи:
https://www.mountaingoatsoftware.com/blog/six-agile-product-development-myths-busted

2019   Agile   Mike Cohn   Анастасия Бутова-Никишина   Владелец Продукта   Гибкая разработка продукта   Мифы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019   Mike Cohn   scrum-master   Анастасия Бутова-Никишина   команда   Роман Петров   скрам-мастер

3 вопроса, которые позволят определить компания agile или нет

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

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

Тем не менее, было бы полезно иметь возможность быстро оценить уровень agile компании. Например, кандидат до принятия предложения хотел бы понять насколько компания agile или же консультант до начала работы с клиентом.

Для того, чтобы помочь в такой и схожих ситуациях, можно начать с 3-х вопросов, которые покажут насколько на самом деле компания (или команда) agile.

Оценка функциональности agile команд

Вопрос 1: Как часто ваши команды полностью интегрируют свои продукты?
Этот вопрос позволит понять насколько команды кросс-функциональные и как часто их структура позволяет доводить всё до конца.

Изначально, данный вопрос был сформулирован иначе: как часто продукты поставляются пользователям? Однако, ответ на такую формулировку менее информативен, так как поставка сильно зависит от того, насколько часто её хотят клиенты. Например, если возьмем, компанию Amazon — она может обновлять свой сайт несколько раз в день и клиентам с этим нормально, однако такое неприемлемо для мобильных телефонов.

Возможно вы будете крайне разочарованы, если за время доставки вашего нового iPhone из Apple Store, компания Apple выпустит ещё два новых телефона. Таким образом частота, с которой продукт выпускается, не ответит вам на вопрос, насколько компания agility.

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

Оценка приверженности лидеров agile

Вопрос 2: Как вы реагируете, если возникла критическая бизнес ситуация, которая не позволяет выполнить запланированное в ранее установленный срок?

Один из лучших индикаторов насколько компания привержена agile  — это то как она реагирует, когда возникает критическая бизнес ситуация. Если по какой либо причине команда не может достичь договоренных ранее сроков, компания отвечает «У нас нет времени на всю эту agile ерунду; у нас есть дэдлайн» или же сотрудники понимают, что критическая бизнес ситуация — это время для еще большего применения agile.

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

Раскрытие скрытых agile дисфункций

Вопрос 3: Расскажите мне о вашем лучшем Скрам-мастере или Владельце продуктов

На этом вопросе может подняться несколько красных флажков:

Скрам-мастера компании работают со множеством команд
Есть место для споров о нужности Скрам-мастера на полное время (прим. full-time) однако, точно плохо, когда менеджер называет своим лучшим Скрам-мастером того, который работает с 20 командами.

Скрам-мастер слишком директивный
Бывает, что несмотря на то, что компания утверждала, что применяет Scrum, она решила позволить менеджерам проектов сохранить своё наименование, а не «переименовывать их всех в Скрам-мастеров».

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

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

Трёх вопросов может быть недостаточно, но они — определённо хорошее начало

Возможно определить насколько компания agile только по трём вопросам достаточно сложно, в течение интервью вы можете составить более полное и детальное представление о том насколько компания agile.

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

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

Текст адаптирован с оригинальной статьи: https://www.mountaingoatsoftware.com/blog/three-questions-to-determine-if-an-organization-is-agile

2019   Mike Cohn   Анастасия Бутова-Никишина   оценка уровня Agile

Как быть уверенным, что работаешь над самыми важными элементами бэклога?

«Когда Agile команды работают только над срочными элементами, результат чаще всего их не удовлетворяют»

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

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

Ловушка Agile приоритезации: в начале каждого спринта выбираем что делать

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

  1. критичная проблема, пришедшая от технической поддержки
  2. то, что вчера повлияло на продажи;
  3. последний каприз очень важного стейкхолдера

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

Приоритезация без цели — это как покорение вершины без карты

В Колорадо есть 53 вершины, высота которых достигает 14,000 футов (4,267 метров). Есть 2 способа покорить вершину.
Первый способ: вы просто едете к подножию горы и начинаете восходить к самой высокой точке, которую вы видите. Почти наверняка это будет ложная вершина, которая кажется только вершиной, потому что затеняет настоящую вершину.

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

Вы идете по этому пути, пока, наконец, не увидите настоящую вершину, но между вами и вершиной глубокая долина и чтобы достичь вершины в 14,000 футов, вы должны сначала спуститься на 10,000 футов, а потом подняться обратно.

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

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

Много-спринтовая цель: карта Владельца продукта (пример: User story mapping)

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

И так заманчиво вместо этого заняться краткосрочными пожарами.

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

Когда приоритезируете помните, что срочное редко бывает важным

Президент Соединенных Штатов Эйзенхауэр знал, насколько важно различать важные и срочные вопросы.
Эйзенхауэра часто цитируют так:

«То, что важно, редко срочно, а то, что срочно, редко важно».

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

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

Владельцу продукта следует определять значимую цель ежеквартально

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

Всё это означает, что Владельцу продукта жизненно важно определить основную цель и, возможно, в перспективе на 3 месяца — это достаточный срок.

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

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

Это должно быть значительным. Для нового продукта это может быть минимально жизнеспособный продукт (MVP — minimum viable product), для существующего продукта — добавление минимальной рыночной функции  (MMF — minimum marketable feature), некоторые компании называют это чрезвычайно важной целью (WIG — wildly important goal)

Владея основной целью — будь то в форме MVP, MMF или WIG — Владелец продукта сможет лучше оценить срочные элементы. Если работа над срочным элементом более важна, чем работа по достижению основной цели, то все силы команды должны быть направлены на работу с ним.

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

Оригинал статьи: https://www.mountaingoatsoftware.com/blog/how-to-ensure-youre-working-on-the-most-important-items-each-iteration

2019   Mike Cohn   Анастасия Бутова-Никишина   Владелец Продукта   перевод
Ранее Ctrl + ↓