Кейс внедрения 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'ом).
  • Владелец продукта отвечает за бэклог продукта. Участники команды могут вносить вклад.
  • Спринты двухнедельные. Длительность и ритм спринтов неизменны.
  • Планирование спринта не проводится.
  • Ежедневные синхронизационные встречи с участием владельца продукта.
  • Встречи по проработке бэклога - дважды в неделю по 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 были получены следующие результаты:
  1. Сформирована дорожная карта трансформации, которая включала структурные и процессные изменения.
  2. Сотрудники компании прошли обучения и получили основное понимания Agile, фреймворка Scrum и Kanban метода, а также принципов масштабирования.
  3. Было выстроено использование Scrum в трёх продуктовых командах.
  4. Другие команды стали жить в двухнедельных циклах планирования, сбора обратной связи и непрерывного улучшения.
  5. Процесс поставки стал более прозрачным и предсказуемым.
  6. Внутри компании был сформирован единый понятийный аппарат, который помог общению с другими компаниями холдинга на одном языке - на языке Agile, а также частой и предсказуемой поставки.
  7. Повысилась вовлеченность сотрудников и прозрачность изменений. Так, на обзоре спринтов представители поддержки стали проактивно интересоваться функционалом, который вскоре будет развернут на продуктивной среде.
  8. Увеличилось количество и качество коммуникаций между командами и представителями бизнеса.
  9. По завершении совместной работы были предоставлены рекомендации дальнейших шагов для развития Agile культуры и практик в компании.
Подойдет ли кейс вам?
Напишите нам, мы с вами свяжемся и подскажем, насколько такой подход применим в вашей ситуации.
Возможно будет интересно
Консультант на проекте
Ирина Тетерук
Agile коуч, тренер, консультант
Консульнант на проекте
Антон Марюхненко
Agile коуч, тренер, консультант