Методология Agile в разработке программного обеспечения радикально поменяла то, как работает бизнес в последние несколько лет. Простая идея, связанная с тем, что каждый существенный этап разработки (спринт) должен согласовываться с заказчиком, чтобы в итоге точно получилось именно то, чего он хочет, к настоящему момент обросла множеством вспомогательных «лучших практик», технологий, поддерживающего программного обеспечения и стандартов.
Однако до недавнего времени не существовало эффективного решения по масштабированию Agile-практик в том случае, технологическая компания расширилась и ее бизнес-процессы усложнились. Решением оказался востребованный фреймворк Scrum@Scale (Scrum at Scale), который появился несколько лет назад.
Разработанный на стыке двух управленческих концепций: Scrum и Agile, он позволяет масштабировать процесс разработки в компании и убедиться в том, что сделанные изменения действительно работают.
Scrum@Scale работает
Это уже факт, поскольку есть известный специалистам опыт десятков организаций, которые решили с его помощью возникающие при росте бизнеса проблемы.
Процесс работы над проектом в Agile напоминает движение по спирали. На каждом этапе вам нужно продвигаться дальше, захватывая все новые аспекты создаваемого IT-решения. Результатом прохождения той или иной фазы разработки становится так называемое потенциально готовое к поставке приращение продукта (PSPI, Potentially Shippable Product Increment).
К сожалению, по мере роста бизнеса, требуется учитывать усложнение процессов, чтобы Agile практики сохраняли эффективность. В зависимости от особенностей бизнеса и его целей, сети scrum-команд, образующие экосистемы Agile, начинают использовать Scrum@Scale, чтобы плавно перейти на работу в большем масштабе. Типичной ситуацией в компаниях является работа нескольких отдельных групп инженеров над разными аспектами одного и того же продукта. Когда производственный процесс накладывается на изменения самой организации, синхронный ритм разработки Agile начинает сбиваться в результате потери информации, между процессами, которые контролируют разные отделы и структурные подразделения и других сбоев в корпоративной коммуникации.
Scrum at scale помогает командам в проектах работать ритмично и установить именно такую производительность и пропускную способность, которая не будет приводить к проблемам. Парадигма Scrum содержит все необходимые инструменты, чтобы скоординировать усилия групп разработчиков с различными особенностями. Вы, как руководитель, сможете убедиться в том, что команды разработчиков по-прежнему работают на одну цель и обеспечены необходимыми ресурсами.
Кейс страховой IT-платформы Insurtech: масштабирование Agile при минимуме инвестиций
Хорошим примером масштабирования Agile c Scrum@Scale, который иллюстрирует все это, стал проект 2025 года в Insurtech, американской компании, специализирующейся на автоматизации покупки страховых услуг.
Вызовы: компания более 30 лет работала в привычной ситуации рынка страхования, однако стала ощущать давление технологических стартапов и терять рынок. Было принято решение работать над повышением эффективности деятельности по разработке и внедрять Scrum в сочетании с Agile, хотя бюджета на обучение и внедрение почти не было. Тем самым планировалось ответить на растущие претензии компании-акционера и сохранить долю рынка несмотря на возросшую конкуренцию. Беда в том, что ни акционеры, ни руководство компании не спешили принимать активное участие в изменениях. Их поддерживала лишь часть наемного менеджмента, которой владельцы дали карт-бланш на изменения.
Переход на Scrum@Scale: решением привлеченного внешнего консультанта была сделана ставка на фреймворк, масштабирующий Agile с использованием методов Scrum. С помощью автоматизированных инструментов, предусмотренных во фреймворке, удалось разделить программистов компании на scrum-группы, наладить менеджмент Scrum of Scrums, то есть совещания, в котором участвуют по одному представителю от каждой такой группы. Была выбран представитель руководства в работе, который на языке Agile называется чемпионом. Он помог организовать эффективное обучение. Сотрудники освоили Scrum Guide.
Результаты: спустя два месяца после начала проекта на 55% выросла общая удовлетворенность потребителей, которую рассчитывали отделы продаж и маркетинга по своим критериям. На 37% повысилось удовлетворенность потребителей, вычисляемая руководством. На 34% вырос такой показатель, как удовлетворенность команд разработки. На 15% снизилось количество дефектов при оказании услуг потребителям продукции компании.
Выученные уроки: оказалось, что в условиях недостатка поддержки проектов Agile и Scrum в среде руководства, можно обойтись без формирования полноценной EAT – своеобразная комиссия истеблишмента компании, подкрепляющая внедрение новых технологий управления разработкой. До этого наличие такой структуры считалось обязательным условием успешного завершения проекта. Топ-менеджмент сбросил эту функцию на двух вице-президентов, то есть на лиц с меньшими полномочиями в компании. Тем не менее, проект удалось привести к победе. Еще один урок состоял в том, что если ресурсы на обучение скромные – добейтесь хотя бы освоения командой Scrum Guide – это уже заложит основу для положительного результата. Также наш опыт показал, что если коллектив разработчиков, которые трудятся по методологии Agile, включает хотя бы 4-5 scrum-команд, то лучше сразу переходить Scrum@Scale, так как уже возникает потребность в масштабировании. Если этого не сделать, команда может начать возвращаться к старым неэффективным практикам сразу после того, как наемный коуч завершит обучение и сотрудники останутся один на один со своими задачами.
Кейс банка BAC Credomatic: уменьшение путаницы в бизнес-процессах через масштабирование
Хорошим примером чересчур быстрого роста компании, после которого процессы Agile утратили эффективность, мы считаем историю с никарагуанским банком BAC Credomatic. Банк очень быстро вырос. Чтобы отладить после этого работу, приняли решение перейти на Scrum@Scale.
Вызовы: персонал этой крупной банковской компании составил 20 тыс. человек, сотрудники и разработанные IT-инструменты обслуживали клиентов в пяти странах Центральной Америки». Из-за того, что банк вырос слишком быстро, его финансовые показатели стали напоминать параболу. Когда проблемы в процессах накопились в достаточном количестве, прибыль, которая ранее росла, начала падать. Проект внедрения Scrum@Scale должен был переломить ситуацию.
Переход на Scrum@Scale: коллектив всех IT-отделов компании разделили на 100 scrum-команд, решив охватить фреймворком не только программистов, но отделы маркетинга и HR для большей интеграции. Создали необходимые органы управления Agile- и Scrum-проектами EAT, EMS, а также применили ключевые паттерны scrum, в частности interrupt buffer. Проблемы, о которых сигнализировала каждая маленькая группа разработчиков стекались в одно место – Metascrum, орган управления системой, который был общим для всех отделений банка.
Результаты: удалось тонко настроить Agile и ритм работы разработчиков под ставшие более сложными бизнес-процессы. BAC Credomatic выиграл World Finance award в номинации лучший онлайн-банкинг и лучшее мобильное приложение.
Выученные уроки: scrum-команды должны быть кросс-функциональными, интеграция отделов разработки с HR и маркетингом в рамках Agile может давать высокие результаты.
Кейс консалтинговой компании Teamflow: спасение корпоративной культуры путем масштабирования Agile и Scrum@Scale
Интересная с точки зрения специалиста по Agile ситуация возникла у немецкой компании Teamflow. По словам эксперта, эта компания долга сохраняла небольшой штат и сформировала уникальную корпоративную культуру личной ответственности специалистов и доверия. Отношения стали рушиться, когда в результате роста компании Agile-процессы стали давать сбои, а старые сотрудники увольняться в результате несогласия с политикой руководства. Продажи упали. Было решено внедрять фреймворк Scrum@Scale.
Вызовы: многие сотрудники решали рабочие вопросы самостоятельно и могли действовать с полной личной инициативой. Таков был привычный способ работы организации, которым гордилось руководство. Требовалось так внедрить Scrum@Scale, чтобы сохранить эту особенность, тем не менее решив проблему несогласованных действий в более крупном коллективе.
Переход на Scrum@Scale: чтобы сотрудники сохранили личную инициативу, ряд возможностей фреймворка был отключен. При этом акцент во внедрении был сделан на создании централизованного хранилища данных SDS (Software-defined storage) на восемь scrum-команд разработчиков. Все работали обучались на основе этого хранилища и при реализации циклов подготовки новых спринтов имели общий язык.
Результаты: общая SDS не только сделала действия программистов и других разработчиков более прозрачными, но сделала действия всех пользователей прослеживаемыми и прозрачными, при том, что каждый сохранил самостоятельность. Это восстановило дух доверия и сотрудничества в организации, воссоздав корпоративную культуру времен ее основания. Возросшая эффективность процессов увеличила прибыль компании в 8,87 раз, сделав ее конкурентоспособной.
Выученные уроки: чтобы тонко настроить масштабирование Agile под уникальные потребности иногда нужно тщательно отобрать тот функционал Scrum@Scale, который будет полезен, не подключая универсальный, но губительный в конкретной ситуации.
Попробуете систему в деле? (это бесплатно)
👉 Щелкните здесь, чтобы создать аккаунт 👈
Пробная версия доступна сразу же после создания аккаунта + мы пришлем письмо с подробными инструкциями.
