Agile-подход стал некой мантрой для многих руководителей IT-служб / отделов разработки в разных компаниях по всему миру. CEO, чаще всего, положительно воспринимают инициативу внедрения гибких методологий, потому что постоянно слышат, что в той или иной компании перешли на Scrum, Kanban, XP, Scrumban и сразу превратились в «инновационного лидера рынка или русский Google», как минимум.
Многие компании начинают свой путь в гибкость, выбирая Scrum. Он подкупает чистотой и простотой процессов (на первый взгляд), наличием множества успешных кейсов внедрения и большим количеством публикаций и книг.
Почему внедрение Scrum начинает буксовать
Иногда вообще заканчивается провалом. Одно из моих практических наблюдений – Scrum не работает, если в компании нет понятия продукта и владельца продукта. Это один из ключевых моментов. Если вы решили внедрить Scrum, начинать надо с определения продуктов, которые есть в компании, и их владельцев.
Далее надо обучить владельцев, чтобы они понимали зону и меру своей ответственности. В идеале – владельцы продуктов должны быть внутри блока IT. Один владелец, если он в блоке IT, может отвечать сразу за несколько продуктов, или за один большой продукт, например, сайт компании. Это в идеале, в реальности же, зачастую, приходится назначать владельцами сотрудников из бизнеса.
Часто получается так: руководитель HR-блока становится владельцем продукта «внутренний портал компании», главный бухгалтер – владельцем продуктов «MS Dynamics AX/1C» и так далее. Не могу сказать, что этот подход в корне неправильный, но он может создать множество ненужных проблем. Основные проблемы: отсутствие времени на работу с журналом пожеланий (backlog), приоритетами и дорожной картой по продукту (roadmap), непонимание системных и технических ограничений. Этого не видно на первоначальных этапах внедрения, но это становится камнем преткновения через какой-то промежуток времени.
Если нет возможности «держать» владельцев продуктов внутри IT-блока, надо назначать владельцами не руководителей функциональных блоков, а специалистов из этих блоков. Хорошие владельцы продуктов получаются из аналитиков, из менеджеров проектов. Когда есть понимание, кто за какой продукт отвечает, приходит время работы с приоритетами задач в backlog продукта и построении roadmap. Глубина roadmap, с которой стоит начинать – 1 год или даже 6 месяцев. Будем честны перед собой – на первоначальном этапе дорожные карты на более отдаленное будущее будут просто гаданием на кофейной гуще.
Идеальным вариантом для внедрения будет возможность сформировать отдельные команды под каждый продукт. Это позволит избежать конфликта за ресурсы между владельцами продуктов. Хотя объединение взаимозависимых продуктов и передача работы над ними одной команде будет приемлемым и разумным решением.
Работа с приоритетами в бэклоге и отсекание необязательных и неважных фич, до попадания в backlog продукта – это, наверное, самая важная задача владельца продукта. Он должен уметь говорить «нет» бизнесу, именно он регулирует поступление задач команде «на вход», именно он определяет ценность релизов. Это очень ответственная роль. Если владелец продукта не будет отсекать на входе непрозрачные, а иногда вообще нереализуемые и даже вредные «хотелки» бизнеса, то ценность релизов будет стремиться к нулю. Команда продукта будет находиться в подавленном состоянии, из-за отсутствия понимания ценности своей работы. Работа «на корзину» никому не добавляет мотивации.
Обучение и прояснение деталей нового рабочего процесса является важной частью успешного внедрения. Были кейсы, когда я недооценивал важность этого фактора, и это приводило к ненужным конфликтам и сложностям. Нельзя ограничиваться только обучением для команды внедрения. Недостаточно провести пару презентаций для остальных сотрудников, надо доносить изменения через все доступные корпоративные каналы коммуникаций – новости на внутреннем портале, плакаты на стенах в офисе, почтовые рассылки.
Оценка трудоемкости задач в бэклоге
Правильная оценка трудоемкости задач (фич) в бэклоге – важный фактор, влияющий на успешность работы по Scrum. По опыту могу сказать, что оценка в Story Points (единицы истории) работает хуже, чем оценка в рабочих днях или часах. Разработчики еще худо-бедно могут приспособиться и оценивать задачи в Story Points, а вот владельцы продуктов, особенно бизнес, очень настороженно относятся к таким оценкам. Бизнес привык оперировать понятными цифрами и когда им говорят, что их задача оценена в три «стори-поинта», или что их задачу оценили, как «медиум-фичу», то начинаются вопросы и сомнения. Особенно это вредно на начальных этапах внедрения, когда вес одной единицы истории плавает от спринта к спринту, что отрицательно влияет на восприятие нового подхода в компании. Не стоит отчаиваться после пары-тройки неудачных спринтов. Необходимо порядка десяти спринтов, чтобы все начало получаться и с оценкой, и с процессом реализации задач в спринтах.
Пожалуй, самое важное – Scrum относится к гибким методологиям. На него распространяются все пункты Agile-манифеста. Самый важный пункт, за которым кроется успех или неуспех внедрения, – это люди! Не забывайте, что «Люди и взаимодействие важнее процессов и инструментов». Общение между членами команды, заказчиками от бизнеса и всеми заинтересованными сторонами – это ключ к успеху. Все элементы Scrum можно и даже нужно адаптировать и модифицировать под конкретные реалии компании. Не видите необходимости проводить ретроспективы после каждого спринта – не проводите. Понимаете, что лучше помогать владельцам продуктов в категоризации задач в бэклоге, привлекая к этому процессу аналитиков и разработчиков, – делайте именно так. Ведь еще один важнейший пункт манифеста: «Готовность к изменениям важнее следования первоначальному плану».
Не бойтесь пробовать что-то новое. Не получилось со Scrum? Попробуйте Kanban, для многих небольших компаний Scrum избыточен. Экспериментируйте с длиной спринта, пробуйте различные инструменты, признавайте ошибки и начинайте новый цикл. С каждой новой командой и очередным внедрением будет получаться все лучше и лучше.
Надеюсь, эта статья будет чем-то вам полезна, поможет избежать некоторых ошибок и ваш путь к гибкости будет чуть менее тернистым.
Текст – участник Летнего конкурса статей «Менеджмент-2019»
Все правильно. Западный метод "из коробки" нужно еще адаптировать к нашим реалиям (которые у всех разные). Это и называется "внедрением". По-сути, что получится перенять в более-менее "нетронутом" виде - это идеологию, принципы метода. Которая, в целом, достаточно хороша и подходит для широкого круга задач. Более того, достаточно широко применяется в IT в менее формализованном виде.
1) Очень спорный подход к определению владельца продукта. Почему он должен быть из ИТ? По классике владелец продукта отвечает за полезность продукта бизнесу. Он должен знать, что нужно пользователям продукта. А сотрудник ИТ этого знать чаще всего не может. К тому же при заполнении бэклога такой владелец продукта будет, чего греха таить, блюсти интересы ИТ, а не бизнеса. Владелец продукта не должен говорить "нет" бизнесу, ведь по классике для команды именно он и является представителем бизнеса.
2) оценка в часах - это путь в никуда. В интернете есть много обсуждений на этот счёт. Оценка в сторипойтах трудна в начала, но с практикой привыкают все и бизнес тоже. Оценка в часах плоха ещё и тем, что если бизнесу говорят, что эта штука займёт 16 человек-часов, то через 2 дня бизнес будет ходить и ожидать готовности, что конечно же не так.
3) если вы не используете, что то из скрам, то это не скрам у вас, только и всего.
Денис, вы очень категоричны в суждениях :) Я не утверждаю, что надо делать именно так, а не по-другому. Почему вы уверены, что владелец продукта не должен говорить нет бизнесу? Именно он решает - отвергнуть фичу или включить её в беклог продукта. Нахождение же владельца продукта в блоке ИТ никак не влияет на знание продукта, его сильных и слабых сторон. Скорее наоборот - позволяет быть ближе к разработчикам и шарить знания по управлению продуктом с другими ВП. Если у вас замечательно проходит оценка в стори-поинтах и все люди от бизнеса понимают, что это такое и когда реально будет готова фича из беклога продукта, то оценивайте в стори-поинтах. Я написал про свой личный опыт внедрения и работы по гибким методологиям. Аджайл и скрам - это про гибкость, не стоит забывать об этом и превращать Scrum в жёсткое следование процессам и правилам, сводя на нет основное преимущество аджайл подхода - гибкость.
Все вцепились в Скрам, а ведь есть методологии и лучше.
Просто Скрам - тренд на западе, а наши попугайки любят повторять все западное и без учета отечественных особенностей...
"Почему внедрение Scrum начинает буксовать..." (с)
Автор очень много назвал причин. И все эти причины, как ни смешно, не относятся к основным. Основная причина, внимание:
- "... потому что его внедряют там, где он работать не может"
Если вы хотите проводить "скруммитинг" прорабов у ГИПа то вы можете это делать. И называть это скрамом. Но только водопад со всеми любимым календарно-сетевым графиком, проектной, рабочей документацией, отчётными документами и всеми стадиями работает на стройке.
Туда же мы радостно отправим такие отрасли как разработка аппаратного обеспечения, инфраструктурные проекты, системную интеграцию и так далее. Да вообще практически всё, что не ИТ и консалтинг в целом.
Вот почему не работает Scrum в первую очередь!
Перечисленное автором имеет место быть, но уже после этой причины. Спасибо за стаью, она будет полезна тем, кто внедряет Scrum там, где он может работать )))
За каждым таким вот эксперементом человеческие судьбы, эксперементируйте на людях и дальше, дорошой товарищ, надеюсь, что в своей жизни вы когда нибуть ощутите такие вот эксперементы на собвсвенной так сказать шкуре.
Ни разу еще не видел в своей жизни ни одного "продукта", созданного по аджайлу или как его там. Этим наверно можно пользоваться в каких то микропроктах без сложных многокомпонентных связей и интеграций.
Что каасается водопаданой модели - из за того, что на графике невозможно отразить итерации "менеджеры" не понимаюющий в разработке ничего и пришедшие руководить с курсов по PMP пытаются следовать графику от пункта до пункта, они не понимают, что график проекта в водопаде - это не догма а всего навсего предположение и он обязан меняться не реже одного раза в неделю.