Кейс внедрения Scrum в компания SolarWinds
Контекст и проблемные области
Перед нашим клиентом - белорусской компанией LogicNow, после приобретения мировым лидером в области ПО для управления сетями и системами компанией Solarwinds, прежде всего стояли задачи выравнивания подходов разработки и внедрения Agile практик для возможности дальнейшего “общения на одном языке” внутри компании. При этом в белорусском офисе разработки Solarwinds не было четкого и согласованного понимания, что такое Agile, чем он может быть полезен, как повлияет на основные KPI и как в дальнейшем его масштабировать.
Компания обратилась в AgileLAB для того, чтобы трансформировать существующий подход разработки, адаптировать Agile практики к реалиям компании и внедрить культуру непрерывных улучшений, что позволило бы ускорить интеграцию с материнской компанией, а также повысить эффективность и включенность белорусского офиса.
Основные вызовы на старте:
Учитывая вызовы и запрос клиента, мы начали с аудита текущего состояния. Основными областями для нашего анализа были: управление продуктами и процессами, поддержка, обеспечение качества и автоматизация тестирования. По результатам анализа мы предложили комплексное решение, учитывающее те особенности, которые были в компании здесь и сейчас.
Компания обратилась в AgileLAB для того, чтобы трансформировать существующий подход разработки, адаптировать Agile практики к реалиям компании и внедрить культуру непрерывных улучшений, что позволило бы ускорить интеграцию с материнской компанией, а также повысить эффективность и включенность белорусского офиса.
Основные вызовы на старте:
- Недостаточное знание и понимание принципов и ценностей Agile, а также процесса Scrum в командах.
- Понимание и интерпретация процесса у разных участников расходились.
- Кросс-командные зависимости.
- Перегруженность владельцев продуктов.
- Риск снижения качества.
- Необходимость частой поставки.
- Сложность масштабирования текущего процесса.
- Ожидания, что люди станут более инициативными и мотивированными.
Учитывая вызовы и запрос клиента, мы начали с аудита текущего состояния. Основными областями для нашего анализа были: управление продуктами и процессами, поддержка, обеспечение качества и автоматизация тестирования. По результатам анализа мы предложили комплексное решение, учитывающее те особенности, которые были в компании здесь и сейчас.
Продуктовый менеджмент
Для того, чтобы сделать прозрачным процесс проработки идей до взятия в реализацию и чтобы понимать, с каким количеством элементов бэклога имеют дело владельцы продуктов, был разработан процесс Discovery.
За счет переформатирования команд нам удалось уменьшить количество продуктовых бэклогов и команд на владельца продукта, а благодаря запуску и поддержки команд - выстроить процесс коммуникаций владельцев продуктов с командами и их участия в командных событиях. Владелец продукта стал основным источником работ для команды.
Новая структура команд
Кроме того, команды не были полностью кросс-функциональными. Поэтому подходя к пересмотру состава, бэклогов и способа взаимодействия команд, мы преследовали следующие цели:
- Уменьшить количество зависимостей.
- Сделать команды кросс-функциональными.
- Выделить команду технологического контроля и руководства.
- Разделить роли Scrum мастера и тех. лида.
- Обособить команду, ответственную за сквозное тестирование решения и поставку (System Team)*.
Scrum процесс в командах OMG!, Ants, KB
Для трех продуктовых команд хорошо подошел Scrum. Эти команды работают в едином ритме спринтов, для синхронизации приоритетов используются встречи владельцев продукта с синьор владельцем продукта, который отвечает за общее продуктовое направление.
Процесс работы этих команд имеет следующие особенности:
- Владелец продукта отвечает за бэклог продукта. Участники команды могут вносить вклад.
- Встреча по проработке бэклога занимает 1-2 часа. Результат - список предварительно оцененных в стори поинтах пользовательских историй.
- Планирование спринта - 2-4 часа. Команда разделяет истории до подзадач и оценивает в часах. Проводится голосование об уверенности и берутся обязательства относительно цели спринта.
- Спринты двухнедельные. Длительность и ритм спринтов неизменны.
- Обзор спринта - 1 час, даже если спринт считается проваленным.
- Регулярная ретроспектива - 1 час с чаем и печеньем.
Процесс работы команды Plumbing
Команда Plumbing занимается технологическим развитием платформы и устранением инцидентов. По сравнению с тремя продуктовыми командами, ее деятельность носит менее неопределенный характер в части развития платформы, и более непредсказуемый - в части устранения инцидентов. Для того, чтобы ей было проще выстраивать взаимодействие с продуктовыми командами, особенности работы этой команды мы описали в терминах Scrum (хотя, конечно же, этот процесс уже нельзя называть Scrum'ом).
- Владелец продукта отвечает за бэклог продукта. Участники команды могут вносить вклад.
- Спринты двухнедельные. Длительность и ритм спринтов неизменны.
- Планирование спринта не проводится.
- Ежедневные синхронизационные встречи с участием владельца продукта.
- Встречи по проработке бэклога - дважды в неделю по 30 минут. Результат - приоритизированный и оцененный в стори поинтах список пользовательских историй и задач.
- Оценка историй - в стори поинтах, задач - в часах.
- Демо спринта - 1 час, раз в 2 недели.
- Легковесная версия определения готовности для задач.
- Регулярная ретроспектива - 1 час с чаем и печеньем.
- Ускоренная линия на доске с ограничением на 1 незавершенную задачу одновременно. Префикс [Red] означает, что взять задачу в работу надо не позднее, чем через час после ее появления.
- Стратегия ветвления - разные ветки для разных направлений работ (приведение к стандартам, производительность, AntiCrypto, SQL Cloud, хотфиксы).
- Слияние со “стабилизационной” веткой - по решению владельца продукта.
Процесс работы команды автоматизации тестирования
- Спринты двухнедельные. Длительность и ритм спринтов неизменны.
- Планирование спринта необязательное.
- Ежедневная встреча по синхронизации.
- Встреча по проработке бэклога занимает 1 час. Результат - список предварительно оцененных в стори поинтах пользовательских историй и задач.
- Оценка историй в стори поинтах, задач и тестов - в часах.
- Обзор спринта - 1 час, каждые 2 недели
- Регулярная ретроспектива - 1 час с чаем и печением.
- Ускоренная линия на доске - с ограничением на 1 незавершенную задачу одновременно.
Предложенные метрики
Для принятия решений на основании объективных данных была предложена и настроена система метрик. При этом мы уделили особое внимание области применения каждой метрики, чтобы избежать эффекта кобры в управлении через метрики.
Метрики прогресса итерации
- Диаграмма сгорания.
Метрики функционала итерации
- Запланированная Velocity против фактической.
- Количество запланированных историй против количества принятых ВП историй; доля успешной приемки историй.
Метрики качества итерации
- Покрытие юнит-тестами.
- Количество дефектов (открытых, закрытых и т.д).
- Количество созданных тестовых сценариев.
- Количество автоматизированных сценариев.
- Общее количество тестов в системе.
- Покрытие автотестами.
- Количество рефакторингов.
Метрики Agile
- Вовлеченность сотрудников - с помощью опросов и статистики HR.
- Удовлетворенность пользователей - с помощью опросов NPS.
- Производительность - время цикла или время работы над фичей.
- Общая адаптивность - усредненное значение Agile самооценки команд.
- Time to market - количество релизов функционала за квартал / год.
- Качество - количество звонков в поддержку за код, данные о дефектах.
Помимо уровня команд
Помимо изменений на уровне команд наши консультанты:
- Организовали сообщество практик Scrum, на котором Scrum-мастера могли делиться опытом, совместно решать проблемы и эскалировать нерешаемые проблемы на уровень лидеров трансформации.
- Внедрили квартальное планирование, обеспечивающее широкие возможности для сквозной коммуникации, выравнивания всех участников по целям и ожиданиям, определения зависимостей и, в целом, ускорения принятия решений.
- Для подготовки и успешного проведения квартального планирования внедрили практику спринта инноваций и подготовки к планированию, во время которого команды не работают над новыми фичами, а финализировали интеграции решения, работали над инфраструктурой и систематическими препятствиями, готовили бэклоги для квартального планирования.
Результаты
По итогам трех месяцев взаимодействия с AgileLAB были получены следующие результаты:
- Сформирована дорожная карта трансформации, которая включала структурные и процессные изменения.
- Сотрудники компании прошли обучения и получили основное понимания Agile, фреймворка Scrum и Kanban метода, а также принципов масштабирования.
- Было выстроено использование Scrum в трёх продуктовых командах.
- Другие команды стали жить в двухнедельных циклах планирования, сбора обратной связи и непрерывного улучшения.
- Процесс поставки стал более прозрачным и предсказуемым.
- Внутри компании был сформирован единый понятийный аппарат, который помог общению с другими компаниями холдинга на одном языке - на языке Agile, а также частой и предсказуемой поставки.
- Повысилась вовлеченность сотрудников и прозрачность изменений. Так, на обзоре спринтов представители поддержки стали проактивно интересоваться функционалом, который вскоре будет развернут на продуктивной среде.
- Увеличилось количество и качество коммуникаций между командами и представителями бизнеса.
- По завершении совместной работы были предоставлены рекомендации дальнейших шагов для развития Agile культуры и практик в компании.
Подойдет ли кейс вам?
Напишите нам, мы с вами свяжемся и подскажем, насколько такой подход применим в вашей ситуации.
Возможно будет интересно
Консультант на проекте
Консульнант на проекте
Понравился кейс?
Хотите узнать. можно ли сделать и у вас что-то подобное? Напишите нам, мы свяжемся с вами и расскажем.