Напишите нам

Кейс внедрения Scrum в компания SolarWinds

КОНТЕКСТ ТРАНСФОРМАЦИИ

Перед нашим клиентом - белорусской компанией LogicNow, после приобретения мировым лидером в области ПО для управления сетями и системами компанией Solarwinds, прежде всего стояли задачи выравнивания подходов разработки и внедрения Agile практик для возможности дальнейшего “общения на одном языке” внутри компании. При этом в белорусском офисе разработки Solarwinds не было четкого и согласованного понимания, что такое Agile, чем он может быть полезен, как повлияет на основные KPI и как в дальнейшем его масштабировать.

Компания обратилась в AgileLAB для того, чтобы трансформировать существующий подход разработки, адаптировать Agile практики к реалиям компании и внедрить культуру непрерывных улучшений, что позволило бы ускорить интеграцию с материнской компанией, а также повысить эффективность и включенность белорусского офиса.

ОСНОВНЫЕ ВЫЗОВЫ НА СТАРТЕ:
  • Недостаточное знание и понимание принципов и ценностей Agile, а также процесса Scrum в командах.
  • Понимание и интерпретация процесса у разных участников расходились.
  • Кросс-командные зависимости.
  • Перегруженность владельцев продуктов.
  • Риск снижения качества.
  • Необходимость частой поставки.
  • Сложность масштабирования текущего процесса.
  • Ожидания, что люди станут более инициативными и мотивированными.

Учитывая вызовы и запрос клиента, мы начали с аудита текущего состояния. Основными областями для нашего анализа были: управление продуктами и процессами, поддержка, обеспечение качества и автоматизация тестирования. По результатам анализа мы предложили комплексное решение, учитывающее те особенности, которые были в компании здесь и сейчас.

ПРОДУКТОВЫЙ МЕНЕДЖМЕНТ

Для того, чтобы сделать прозрачным процесс проработки идей до взятия в реализацию и чтобы понимать, с каким количеством элементов бэклога имеют дело владельцы продуктов, был разработан процесс Discovery.
За счет переформатирования команд нам удалось уменьшить количество продуктовых бэклогов и команд на владельца продукта, а благодаря запуску и поддержки команд - выстроить процесс коммуникаций владельцев продуктов с командами и их участия в командных событиях. Владелец продукта стал основным источником работ для команды.

НОВАЯ СТРУКТУРА КОМАНД

Кроме того, команды не были полностью кросс-функциональными. Поэтому подходя к пересмотру состава, бэклогов и способа взаимодействия команд, мы преследовали следующие цели:
  • Уменьшить количество зависимостей.
  • Сделать команды кросс-функциональными.
  • Выделить команду технологического контроля и руководства.
  • Разделить роли Scrum мастера и тех. лида.
  • Обособить команду, ответственную за сквозное тестирование решения и поставку (System Team)*.
При этом часть команд была объединена, часть - дополнена компетенциями, необходимыми для работы с новыми бэклогами, часть - сформирована вновь.
Scrum процесс в командах OMG!, Ants, KB
Для трех продуктовых команд хорошо подошел Scrum. Эти команды работают в едином ритме спринтов, для синхронизации приоритетов используются встречи владельцев продукта с синьор владельцем продукта, который отвечает за общее продуктовое направление.
Процесс работы этих команд имеет следующие особенности
Владелец продукта отвечает за бэклог продукта. Участники команды могут вносить вклад.
Встреча по проработке бэклога занимает 1-2 часа. Результат - список предварительно оцененных в стори поинтах пользовательских историй.
Планирование спринта - 2-4 часа. Команда разделяет истории до подзадач и оценивает в часах. Проводится голосование об уверенности и берутся обязательства относительно цели спринта.
Спринты двухнедельные. Длительность и ритм спринтов неизменны.
Обзор спринта - 1 час, даже если спринт считается проваленным.
Регулярная ретроспектива - 1 час с чаем и печеньем.
Процесс работы команды Plumbing
Команда Plumbing занимается технологическим развитием платформы и устранением инцидентов. По сравнению с тремя продуктовыми командами, ее деятельность носит менее неопределенный характер в части развития платформы, и более непредсказуемый - в части устранения инцидентов. Для того, чтобы ей было проще выстраивать взаимодействие с продуктовыми командами, особенности работы этой команды мы описали в терминах Scrum (хотя, конечно же, этот процесс уже нельзя называть Scrum'ом).
  • Владелец продукта отвечает за бэклог продукта. Участники команды могут вносить вклад.
  • Слияние со “стабилизационной” веткой - по решению владельца продукта.
  • Оценка историй - в стори поинтах, задач - в часах.
  • Регулярная ретроспектива - 1 час с чаем и печеньем.
  • Демо спринта - 1 час, раз в 2 недели.
  • Планирование спринта не проводится.
  • Ускоренная линия на доске с ограничением на 1 незавершенную задачу одновременно. Префикс [Red] означает, что взять задачу в работу надо не позднее, чем через час после ее появления.
  • Стратегия ветвления - разные ветки для разных направлений работ (приведение к стандартам, производительность, AntiCrypto, SQL Cloud, хотфиксы).
  • Легковесная версия определения готовности для задач.
  • Ежедневные синхронизационные встречи с участием владельца продукта.
  • Спринты двухнедельные. Длительность и ритм спринтов неизменны.
Процесс работы команды автоматизации тестирования
  • Оценка историй в стори поинтах, задач и тестов - в часах.
  • Сложности в применение Scrum у существующих Agile команд.
  • Обзор спринта - 1 час, каждые 2 недели
  • Планирование спринта необязательное.
  • Регулярная ретроспектива - 1 час с чаем и печением.
  • Ежедневная встреча по синхронизации.
  • Спринты двухнедельные. Длительность и ритм спринтов неизменны.
  • Ускоренная линия на доске - с ограничением на 1 незавершенную задачу одновременно.
  • Встреча по проработке бэклога занимает 1 час. Результат - список предварительно оцененных в стори поинтах пользовательских историй и задач.
ПРЕДЛОЖЕННЫЕ МЕТРИКИ
Для принятия решений на основании объективных данных была предложена и настроена система метрик. При этом мы уделили особое внимание области применения каждой метрики, чтобы избежать эффекта кобры в управлении через метрики.

Метрики прогресса итерации

  • Диаграмма сгорания.

Метрики функционала итерации

  • Запланированная Velocity против фактической.
  • Количество запланированных историй против количества принятых ВП историй; доля успешной приемки историй.

Метрики качества итерации

  • Покрытие юнит-тестами.
  • Количество дефектов (открытых, закрытых и т.д).
  • Количество созданных тестовых сценариев.
  • Количество автоматизированных сценариев.
  • Общее количество тестов в системе.
  • Покрытие автотестами.
  • Количество рефакторингов.

Метрики Agile

  • Вовлеченность сотрудников - с помощью опросов и статистики HR.
  • Удовлетворенность пользователей - с помощью опросов NPS.
  • Производительность - время цикла или время работы над фичей.
  • Общая адаптивность - усредненное значение Agile самооценки команд.
  • Time to market - количество релизов функционала за квартал / год.
  • Качество - количество звонков в поддержку за код, данные о дефектах.
ПОМИМО УРОВНЯ КОМАНД
Помимо изменений на уровне команд наши консультанты:
  • Организовали сообщество практик Scrum, на котором Scrum-мастера могли делиться опытом, совместно решать проблемы и эскалировать нерешаемые проблемы на уровень лидеров трансформации.
  • Внедрили квартальное планирование, обеспечивающее широкие возможности для сквозной коммуникации, выравнивания всех участников по целям и ожиданиям, определения зависимостей и, в целом, ускорения принятия решений.
  • Для подготовки и успешного проведения квартального планирования внедрили практику спринта инноваций и подготовки к планированию, во время которого команды не работают над новыми фичами, а финализировали интеграции решения, работали над инфраструктурой и систематическими препятствиями, готовили бэклоги для квартального планирования.

результаты

Успехи трансформации, с учетом проведенного квартального планирования, которые повлияли на сокращение Time to Market:
  • Сформирована дорожная карта трансформации, которая включала структурные и процессные изменения.
  • Сотрудники компании прошли обучения и получили основное понимания Agile, фреймворка Scrum и Kanban метода, а также принципов масштабирования.
  • Было выстроено использование Scrum в трёх продуктовых командах.
  • Другие команды стали жить в двухнедельных циклах планирования, сбора обратной связи и непрерывного улучшения.
  • Процесс поставки стал более прозрачным и предсказуемым.
  • Внутри компании был сформирован единый понятийный аппарат, который помог общению с другими компаниями холдинга на одном языке - на языке Agile, а также частой и предсказуемой поставки.
  • Повысилась вовлеченность сотрудников и прозрачность изменений. Так, на обзоре спринтов представители поддержки стали проактивно интересоваться функционалом, который вскоре будет развернут на продуктивной среде.
  • Увеличилось количество и качество коммуникаций между командами и представителями бизнеса.
  • По завершении совместной работы были предоставлены рекомендации дальнейших шагов для развития Agile культуры и практик в компании.
Возможно будет интересно
Консультант на проекте
Ирина Тетерук
Agile коуч, тренер, консультант
Консульнант на проекте
Антон Марюхненко
Agile коуч, тренер, консультант