Блеск и нищета внедрения Scrum

Сложно найти, легко потерять и невозможно забыть
(неизвестный автор, возможно, про Scrum)

Так сложилось, что лично у меня слово Agile в первую очередь ассоциируется со Scrum. Да и не только у меня: Product Owner и Scrum Master, ретро и дейли, - все это термины, раскрученные этим фреймворком (поправьте меня, если я ошибаюсь). На конференциях, на тренингах, в статьях только и разговоры, что о Scrum.

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

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

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

Изображение с сайта https://i.ytimg.com/vi/qBSAnK5PGQk/maxresdefault.jpg

Scrum, я выбираю тебя! 

Как правило, когда утомленная waterfall'ом компания решает внедрять Agile, выбор падает именно на Scrum. У него есть четкий и понятный Scrum Guide: правила, роли, активности - вы их наверняка знаете, даже если далеки от гибких методологий.  Консультанты Agile гораздо активнее рекламируют Scrum, нежели другие практики, но это не точно. Внедрение тоже не кажется каким-то сложным: раздаем роли, добавляем в календарь новые встречи и наслаждаемся качественным результатом каждую итерацию. А потом что-то начинает идти не так.

Что же на самом деле произошло? (с)

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

1. Scrum изначально не был нужен. Цели бизнеса и его условия не соответствуют выбранной методологии.
   Одно из основных преимуществ Scrum - это максимизация бизнес ценности в условиях сильной неопределенности. Возможность быстро получить и оценить результат, переориетироваться на более выгодные направления, постоянно улучшать свои процессы - это те преимущества, которые дает Scrum. Этот фреймворк хорошо подойдет, если вы развиваете свой портал недвижимости (привет, N1) или новый электронный сервис. Но есть большое количество проектов, где итоговый результат уже зафиксирован в том или ином виде. Например, в виде договора с клиентом, что через год он получит систему с определенными возможностями. Или проекты, где есть значительный поток задач, не направленных на создание новой бизнес-ценности (доработки, связанные с законодательством, или просто большой объем сопровождения). Для таких проектов Scrum не дает значительных преимуществ, но накладывает ограничения.
2. Scrum внедряется не как фреймворк, а как процесс. 
   Как подчеркивается в Scrum Guide "Скрам не является процессом или техникой для создания продуктов". При этом так бывает, что при внедрении Scrum происходит демонтаж всех waterfall процессов и замена их на активности Scrum. Но фреймворк не дает ответы на вопросы согласования архитектуры, релизную политику или практику контроля трудозатрат. По моему убеждению, для работ по Scrum нужны более качественные процессы, чем для waterfall , чтобы поддерживать высокий темп разработки и быструю обработку обратной связи.
3. Бизнес не готов/не хочет/не может работать гибко.
   Ты можешь быть сколько угодно Scrum, но какая разница, если заказчик отвечает на вопросы раз в неделю. То, какими процессами вы будете пользоваться, во многом зависит от заказчика (в общем случае, скорее даже от заинтересованных сторон). И с этой точки зрения, Scrum накладывает на заказчика довольно жесткие ограничивания: ваш Owner должен постоянно взаимодействовать с командой, должен предоставлять, какую бизнес ценность он хочет получить, давать качественную обратную связь.
   И это еще не все: он должен быть готов к тому, что в какие-то моменты ему придется тратить деньги только ради опыта. Если вы работаете по waterfall, то знаете куда придете через неделю/месяц/год (по крайней мере такая иллюзия есть), в Scrum нет даже иллюзии. Все, что вы знаете - это то, что в конкретный момент времени вы делаете именно то, что вам сейчас необходимо (в отличие от того же waterfall, где интрига сохраняется до самого конца). И тут очень важно, чтобы свои выгоды понимал не только бизнес, но и, например, его финансовый блок. Потому что в случае Scrum речь идет не об оплате конкретного перечня услуг по договору, а об инвестициях в команду и надежду на то, что они окупятся.
4. Scrum внедряется без каких-то своих частей
   Waterfall хорошо дополняется практиками из Scrum, но вот элементы Scrum не очень хорошо заменяются практиками из waterfall. Функциональное разбиение команд вместо кросс-функционального ломает общий информационный контекст и модель коммуникаций Scrum. Руководитель, планирующий задачи на каждого члена команды, убивает командную ответственность. И таких неравнозначных замен придумано много.
   Я не ханжа, но считаю, что в случае таких изменений всегда имеет смысл вернуться к пунктам 1, 2, 3 и понять, действительно ли нужно внедрять именно Scrum?

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

Чек-лист по внедрению чего угодно Scrum

1. Какова ваша цель? Какие у вас ограничения? Действительно ли вам нужен именно Scrum?
2. Готов ли к Scrum ваш бизнес? А его финансовый и юридический отделы?
3. Вы сами готовы к Scrum? Готовы менять организационную структуру, проводить перераспределение власти ролей в вашем проекте?
4. Вы создали видение процессов после внедрения Scrum? Как они будут интегрированы с фреймворком?

И в завершении очень интересный доклад от Артема Каличкина на эту тему. Специально поставил его в конце, чтобы у вас был повод дочитать статью до конца :)