Scrum лёгок для понимания, труден для освоения.
Если вы пробовали работать по Scrum в своей компании, вы, вероятно, согласитесь с утверждением выше. Внедрить базовые события Scrum, сгруппироваться вокруг одного продукта или сервиса не так уж сложно. Но дальше в процессе появляется много «но», которые лежат и в культуре организации, и в разделении зон ответственности, и в готовности меняться.
Чтобы начать внедрение Scrum и других гибких подходов, нужно оценить готовность организации к этому и точно выяснить, нужен ли ей Scrum.
В этой статье поговорим о тех вещах, которые нужно предотвратить заранее, до внедрения фреймворка.
Культура компании
Все компании отличаются. Везде разные отделы, роли, персонал, рабочие соглашения, а в итоге — разная культура компаний. То, на чём сфокусирован продукт, тоже диктует культуру: строгие банковские продукты или инновационный стартап?
Организация должна официально дать свободу продуктовой команде:
- сотрудничать в определении приоритетов,
- проводить эксперименты,
- тратить время на обучение смежным компетенциям,
- получать конструктивную обратную связь по продукту,
- обеспечить возможности для быстрой доставки готового продукта.
Ключевой момент — организация в лице топ-менеджмента должна подписаться под тем, что она готова меняться (или хотя бы не мешать эксперименту по внедрению Scrum).
Принятие правил Scrum
Если запускается scrum-команда, все немногочисленные правила Scrum должны выполняться. Не называйте то, что запускаете словом Scrum, если заранее знаете, что никто в компании не разрешит тратить полтора часа на ретроспективу или никто не готов прийти на ревью спринта.
Одно из главных правил — соблюдать прозрачность. Процессы должны быть понятны всем, информация открыта, успехи озвучиваться наравне с проблемами.
Не меняйте правила игры, если проигрываете в ней. Если какое-то из правил трудно соблюдать, это звоночек к тому, чтобы оптимизировать процесс, а не отменить правило.
Владелец продукта
Без грамотного, уполномоченного принимать решения владельца продукта, Scrum даст результат «лучше, чем ничего», но вряд ли даст истинный переход к Agile.
Владелец продукта должен:
- ориентироваться на продуктовую разработку,
- принимать решения о дорожной карте продукта, согласовывать видение с ключевыми стейкхолдерами,
- нести ответственность за результат.
Структура организации должна выделить эту роль и установить ожидания от неё.
Состав бэклога
Это зона ответственности владельца продукта. Что тут важно? Бэклог должен состоять из фич, соответствующих критериям INVEST. Такие задачи можно декомпозировать, пойти итеративно: постепенно наращивать продукт — начинать с минимальной версии и добавлять новые функции.
Часто случается обратное — задачи формулируются с запросом «всё и сразу». Бизнес не соглашается на последовательную разработку, а команда месяцами не доводит задачу до статуса DONE.
До запуска scrum-команды бэклог нужно собрать с учётом такого подхода.
Внедрение сразу всех ролей
Scrum не может называться так, если в команде нет владельца продукта, scrum-мастера или обособленной команды разработчиков со всеми компетенциями. Не начинайте, если роль scrum-мастера не предусмотрена в компании или нет лица, готового взять на себя эти обязанности.
То же касается команды разработки. Люди должны быть собраны вокруг продукта, не оставаясь в своих отделах. До запуска нужно создать условия для того, чтобы люди были 100% выделены для работы в одной команде.
Обратите внимания на эти вещи, даже если Scrum уже запущен в вашей организации. После такой фундаментальной подготовки весь запуск scrum-команды займёт не больше недели.