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»
Руслан, по наблюдениям перечисленными причинами неудачи внедрения Scrum далеко не ограничиваются.
Во-первых, гибкость гибкостью (или шустрость шустростью?), но здравого смысла никто не отменял. И если разрабатывается заведомо слабое, тупиковое решение, то до выхода из тупика разбазарится масса ресурсов. И не важно, с помощью какой методики разработки.
Во-вторых, неочевидна ГЛАВНАЯ причина слабых решений. А это архаичный (известный в США аж с середины 1930х годов) «Мозговой штурм». Заменить бы его хотя бы «старушкой» ТРИЗ (не говоря уже о куда более производительных американской Guided Brainstorming (GB), а тем более нашей Азбрейн)… Но куда там! Об этих системах большинство SCRUM-«креативщиков» даже и не слышало!
В-третьих, мешает общее отсутствие инфраструктуры внедрения инноваций. Какая разница, сколько интересных решений будет предложено на скрам-митингах, если ни одно из них не будет в итоге внедрено?
Наконец, SCRUM всё чаще пытаются применять далеко за пределами IT. Но реальное производство куда менее идеально, чем информационное.
попробовал в поиске найти - не получилось в соответствии с контекстом вашего ответа. Интересно, что это за метод?
Хочется разобраться с верным замечанием автора - Вот это авторское - "на первый взгляд"
"Scrum. Он подкупает чистотой и простотой процессов (на первый взгляд) ..."
Scrum по больше части уже стал профанацией - множество публикаций от людей не знающих предметную область.
Давно используем Extreme Programming - XP.
Agile методологий разработки программного обеспечения много, но вряд ли стоит ставить Scrum рядом с методологиями разработки работающего ПО.
Экстремальное программирование - XP - Это Agile, который воплощает в себе Дисциплину работы и разработки. И важность дисциплины понимали создатели Agile-манифеста. Пока что этого понимания не увидел ни в одной публикации о Scrum.
- из-за внешней простоты - вроде просто - менеджеры превращают всё в профанацию ... Эта "простота" Scrum и состоит в отсутствии дисциплины разработки - в таких условиях вы не можете получить от программиста качественный код, а это ведёт к тому, что на выходе получается от силы макет - а удачи случайны ...
Разумеется, не найдёте, поскольку разработка свежая (2018) и не публиковалась, используется пока как авторское ноу-хау.
Предшественник Азбрейна — метод Guided Brainstorming (GB) чуть более известен, хотя тоже не слишком широко. (Его разработка началась в 2008 году, а первые презентации в России состоялись в 2012.) Пока советую познакомиться с GB: http://gbtriz.com/ru/metod-guided-brainstorming
В своё время метод GB стал прорывом в ТРИЗ, увеличив скорость генерации до 300 идей изобретательского уровня в час. Но уже тогда был виден потенциал дальнейшего совершенствования.
Вкратце скажу, что метод Азбрейн отличается от GB большей детальностью на этапах постановки задачи, возвращением из АРИЗ понятий «оперативное время и зона», использованием вместо 30 атомарных GB-приёмов 20 (пока) векторов эволюции и другими деталями. Методика стала сложнее (для фасилитатора), но ещё производительнее (пока получаем до 600 «сырых» идей и, соответственно до 30-50 проработанных, готовых к превращению в бизнес-проекты концепций в час).
Главное достоинство и отличие Азбрейн — использование для решения задач изобретательского уровня творческими коллективами БЕЗ предварительного обучения (и даже кратких введений!), в режиме прямой фасилитации.
Сейчас с помощью Азбрейн примерно раз в 2-3 дня (иногда ежедневно) идут очные и дистанционные (вся Россия) сессии по решению бизнес-задач, нарабатываются свежие кейсы. Когда окончательно определюсь со схемой монетизации методики, возможно, опубликую.
Впрочем, опыт продвижения GB показывает, что публикации сегодня мало кого интересуют и ни от чего не защищают, так что не тороплюсь.
Поэтому пока познакомиться с Азбрейн проще всего на практике — подать заявку на решение какой-нибудь бизнес-задачи и оценить результат.
Спасибо!
Кроме фасилитатора в проработке деталей те же участники, что и в сессии по генерации идей?
Отчасти, да. (Потому, что неизбежно возникнут вторичные задачи, которые решаются аналогично первичным.) Отчасти нет. (Нужны специалисты другого плана — более инженерного, а затем и административного.)
Могут быть и теми же, но в другом режиме — критики, экспертной оценки и так далее.
В общем, фазу генерации и критики как в классическом мозговом штурме стоит разделить во времени (или в пространстве, или в участниках и т.д.). Но не столь строго и принципиально как в мозговом штурме.
На практике в предприятиях и организациях обычно создаётся ВРК с обязательным участием полномочного лидера и нескольких разнопрофильных ведущих специалистов. А на стадии реализации состав группы уточняется, в зависимости от специфики проекта.
Посмотрите мультик - в нём всё популярно рассказано: )))
Подъем и падение водопада
Здесь цитата верна, но есть контекст, который штампуется скрумовцами из статьи в статью. - А любую историю, которую рассказывают скрумовцы, нужно тщательно проверять - часто реального отношения к природе вещей она не имеет - только поток сознания, и особенно по поводу использования японского опыта ))). Обычно это выглядит так, когда они агитируют за свой Scrum:
"Waterfall - водопадная система разработки - методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии".
И вот такое описание для сравнение - полная лажа и подтасовка. Даже Уинстон Ройс, которому приписывают разработку этой "модели" - пытался, но не смог докричаться, что он не то имел в виду - он говорил об итеративной разработке. На практике все программисты работают итерациями, и возвращаются по нескольку раз к доработке своего кода, и они не один раз взаимодействуют со своими заказчиками.
В этой ошибке, как это обычно бывает, виноваты менеджеры и ... американские военные, которым был срочно нужен какой-нибудь стандарт для разработки своего ПО. Потом подключились европейские военные ))) - им тоже был нужен стандарт ...
Ломать - не строить (поговорка)
Наш мир стал более опасен из-за советов добрых людей - информация стала более доступна. Даже один из авторов канбан говорил, что это не методология, а некая присадка к "любому методу разработки" ...
Если разобраться с псевдо-японской подложкой этой присадки - это будут те же последовательные итерации, может быть небольшие ))), о которых говорил Уинстон Ройс ... Если у вас что-то уже работает, не надо сразу ломать - лучше подумать - возможно, вам пытаются продать то, что о у вас уже есть. Как уже говорилось, все настоящие Agile методологии воплощают в себе Дисциплину работы и разработки - вам нужно подумать об организации робот - и тогда можете придумать что-то сами, что-то модифицировать.
Не надо брать пример с Грефа, у него времени нет - ему постоянно нужно где-то засвечиваться в различных тусовках и прессе, чтобы подняться ещё выше ... пофиг на несколько потерянных миллиардов, у него ещё много в запасе ...
Да, вот это стоит взять на вооружение - бесплатно и работает во всех предметных областях .
А ТРИЗ - мощный рабочий инструмент!!! Недавно кто-то привел статистику о том, что ТРИЗ изучают как предмет и используют в своих работах около 100 Университетов мира ... в нашей стране как всегда - лучше будем ждать зарубежных консультантов с ТРИЗ в западной упаковке ...
Коллеги, спасибо за комментарии и интерес к статье! Отвечая Константину Куликову - Да, вы абсолютно правы. Причин неудачного внедрения Scrum намного больше, чем я смог охватить в статье. Но наверное основная - это желание внедрить эту методологию не понимая её ограничений и не имея достаточной для этого квалификации. Гибкие методологии стали для многих менеджеров модным трендом, который они пытаются использовать и внедрять независимо от отрасли, команды и целей. Внедрение Scrum такими "горе-внедренцами" превращается в карго-культ и профанацию. Попытки проводить ежедневные стендапы, ретроспективы и планирования, для вызова "волшебных гибких изменений". Всё это делается без понимания целей и осмысления аджайл-манифеста и заканчивается тоже предсказуемо - крахом и сентенциями на тему "фигня этот ваш скрам".