Организации применяют 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

«Когда 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

Сказать «нет» может быть очень сложно. Большинство хочет удовлетворить других. И, когда мы говорим «нет», мы разочаровываем/расстраиваем обратившихся к нам.

Однако, говорить «нет» стейкхолдерам — важная часть работы Владельца продукта (далее — ВП). Задача ВП — оптимизировать ценность продукта, а не говорить «да» каждой просьбе стейкхолдеров.
Каждый раз, когда ВП говорит «да» какой-либо функциональности (далее — фиче) одного стейкхолдера, он говорит «нет» будущей фиче. Время команды ограничено и сказанное сегодня «да», потребует сказать «нет» следующей, более поздней, возможности.
Таким образом, умение говорить «нет» — это навык, который ВП надо развивать.

6 рекомендаций о том, как это сделать вежливо, но решительно.

1. Будьте предельно ясны со стейкхолдерами: это нет или на данный момент нет?
Когда ВП сообщает стейкхолдеру, что не отдаёт данной фиче приоритет, ВП должен чётко довести до стейкхолдера, что означает его «нет».
Если вы, как ВП говорите, что ваша команда никогда не будет работать над этой фичей, не сейте надежду у стейкхолдера, чтобы он ещё раз попросил об этом в будущем. Это пустая трата их времени и вас будет расстраивать постоянно говорить «нет», когда вы знаете, что никогда не будете работать над этой фичей. Важно не позволять стейкхолдеру уходить с мыслью, что он может прийти к вам через месяц в то время, как ваш ответ был, что вы никогда не собираетесь с работать с его фичей.
Если же, с другой стороны, вы говорите стейкхолдеру «на данный момент нет» — это означает, что позже вы, возможно, поработаете над этой фичей — будьте в этом предельно ясны.
Например, вы можете сказать так:
• К сожалению, мы не можем поработать над этим сейчас. Поверьте, я бы очень хотел, однако, мы уже договорились разработать (скажите, что именно) к Августу. Мне необходимо сохранить фокус команды или мы рискуем не выполнить наши договоренности. Вы можете напомнить мне о вашей фиче в Августе, и я обещаю рассмотреть возможность заняться ей.
Обратите внимание, я не обещал заняться сразу же этой фичей, а обещал рассмотреть возможность.
Также обратите внимание, что ответственность остаётся у стейкхолдера о том, чтобы напомнить вам о фиче. Я делаю это для того, чтобы быть уверенным, что к тому моменту фича ещё будет важна. Если стейкхолдер не захочет сделать такую маленькую вещь, как напомнить вам о фиче, у меня будет вопрос, была ли фича вообще важной или срочной.

2. Выражайте признательность/благодарность и проявляйте эмпатию к стейкхолдерам
Когда к ВП обращается стейкхолдер с просьбой, ему следует выразить признательность/благодарность и понимание почему данная фича для него важна.
Некоторые стейкхолдеры находят время, чтобы узнать о вашей команде. Это говорит о том, что они заинтересованы в вашем продукте. Выразите стейкхолдеру свою признательность за то, что он нашёл на это время. Вам достаточно сказать:
• Спасибо. Я благодарен, что вы думаете о том, как сделать наш продукт лучше
Помимо того, что ВП следует выражать признательность/благодарность, ему также следует проявлять эмпатию к ситуации стейкхолдера.
Вы собираетесь сказать «нет» фиче, которая очень важна для него. Фича, возможно, как минимум по мнению стейкхолдера, поможет достичь целей, поставленных перед его руководителем, или повлияет финансово.
Перед тем, как проявить эмпатию, будьте уверены, что Вы понимаете почему эта фича важна стейкхолдеру. Если же нет, постарайтесь это понять перед тем, как сказать «нет».
Пример выражения эмпатии:
• Я понимаю, что данная фича важна Вам для достижения (скажите чего)

Говорите искренне. Я не думаю, что я уникален в том, что был разочарован/расстроен неискренним проявлением эмпатии.

3. Предлагайте только одну причину вашего отказа.
Когда ВП говорит «нет» это лучше делать с указанием одной веской причины, а не целого списка. Когда вы предлагаете список, люди склонны находить самую сомнительную и начинать её оспаривать.
Представьте, что я Ваш стейкхолдер и я прошу Вас, чтобы Ваша команда отложила текущую работу и начала работать над моей фичей и Вы мне говорите.
• К сожалению, я не могу этого сделать. Мы уже запланировали спринт. Команде нужно будет другое планирование и им это не по- нравится. И я уверен, что мы сейчас работаем над важной фичей.
Как Вы думаете, какую причину я оспорю? То, что Вам нужно ещё одно планирование или то, что команда сейчас работает на более приоритетной фичей?
Я начну с того, что команде нужно будет провести ещё одно планирование и ей это не понравится. Я могу предложить сделать эту встречу более приятной и провести её за обедом, на котором я куплю всем пиццы.
Если Вы будете не согласны с моим планом, я изменю наш разговор: мы спорим о том, чтобы провести встречу или нет, а не о достоинствах моей фичи. А этот спор выиграть достаточно сложно и это не правильная почва для принятия решения.
Будьте решительными и предлагайте только одно самую вескую причину сказать «нет».
Если стейкхолдер убедит вас изменить мнение, аргументировав свою точку зрения, вполне возможно стоит подумать о достаточности вторичных причин. Если они недостаточны, возможно, Вам придется сказать этой фиче «да».

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

5. Объясните стейкхолдеру последствия ответа «да»
Говоря «нет» стейкхолдеру, ВП следует объяснить последствия ответа «да»
Например:
• Если мы будем вместо текущей работы работать над Вашей фичей, мы не сможем уложиться в основной срок.
• Команда уже работает сверхурочно. Я не могу добавить это к их работе, не удалив что-то уже обещанное (скажите кому).
Объяснение стейкхолдеру последствий поможет ему понять и, я надеюсь, проявить эмпатию к тому, почему Вы говорите «нет»

6. Предложите стейкхолдеру альтернативу
Вместо того, чтобы прямо сказать «нет» стейкхолдеру ВП может предложить альтернативу.
Вы можете предложить, например, такое:
• Мы, возможно, не сможем сделать всё, что Вы просите, однако, что-то мы можем сделать.
• Я не могу переключить команду на эту фичу прямо сейчас, что, если мы начнём над ней работать через 3 недели?
Будьте осторожны: предлагайте альтернативу только тогда, когда Вы действительно её имеете в виду.

Сказать «нет» не должно быть сложно.
ВП часто боится сказать «нет» и разочаровать стейкхолдера. Однако, сказать «нет» не должно быть сложно.
Я обнаружил, что, будучи предельно ясным, приводя одну вескую причину отказа, а не список, проявляя эмпатию и выражая признательность/благодарность, напоминая, что мы преследуем одну конечную цель, объясняя последствия ответа «да» и предлагая альтернативу, сказать «нет» намного проще.

Оригинал: https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder