Нужно ли компании внедрять Scrum?

Scrum — термин, заимствованный из регби, который означает схватку за мяч, «навал» всех игроков на одну задачу. Применительно к рабочим процессам он описывает способ решения сложных организационных задач. 

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

Scrum – один из основных инструментов для реализации подобного подхода к работе. Он применим не только к работе в ИТ, но и к решению маркетинговых, HR, дизайнерских и других задач.

Что такое Scrum

Scrum включает в себя набор событий, ролей, правил и артефактов, которые базируются на ценностях и принципах, схожих с культурой Agile. 

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

Авторы метода предлагают отказаться от привычного поэтапного подхода к работе, равно как и от иерархии «начальник-подчиненный». Вместо этого предоставляется свобода (а с ней и ответственность) сотрудникам делать то, что они считают правильным. 

Работа в Scrum ведется в рамках «спринта», который является контейнером для остальных мероприятий, задает временные границы.

В рамках спринта регулярно проводятся планирование, ежедневный Scrum (короткая ежедневная встреча, для обсуждения прогресса достижения цели спринта и при необходимости корректировки планов), обзор спринта и ретроспектива – за счет этого формируется ритм работы команды.

Главным драйвером изменений в описанном подходе выступает Scrum-команда, которая по ходу спринта превращает работу в инкремент – то есть реализует прирост функциональности продукта в виде новых фич и исправления старых ошибок. 

За состав фич, которые будут реализованы в рамках инкремента отвечает Product Owner, который принимает решение «что делать?». Разработчики же сами разбираются, как они будут реализовывать задачу. 

Задача скрам-мастера – выстраивать баланс в рамках взаимодействия всех членов команды и обучать участников кросс-функциональной части навыкам самоуправления, устранения препятствий и достижения поставленных целей.

Кому нужен Scrum и как адаптировать его на практике

Scrum – революционный фреймворк, внедрение которого влечет за собой кардинальные изменения в организации и требует регулярной поддержки процесса непрерывного развития.

Важно понимать, что изменение ключевых идей или структуры Scrum, исключение каких-либо элементов или отступление от правил приводит к сокрытию проблем, ограничивает преимущества метода и потенциально делает его бесполезным. 

Для минимизации рисков рекомендуется сначала запустить «пилотный проект», в рамках которого можно оценить эффективность и необходимость Scrum в организации. Только после подтверждения гипотезы можно тиражировать его на остальные продукты. 

В среднем достижение организацией высокого уровня Agile-зрелости при наличии опытных команд и поддержке «сверху и снизу» занимает не менее двух-трех лет.

Отраслевых ограничений применения у Scrum нет, но важно не превращать фреймворк в карго-культ. Часто традиционные проекты гораздо проще и быстрее реализовать, выполняя работу поэтапно и последовательно, потому что работа в scrum-командах требует толерантности к ошибкам и прохождения командами определенных этапов развития.

Командный спорт

Agile Manifesto – перечень базовых ценностей и принципов гибкой разработки, который лег в основу фреймворка Scrum. В качестве одного из его постулатов утверждается превалирование «people over processes and tools». Другими словами – люди и их взаимодействие важнее процессов и инструментов. 

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

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

Участники Scrum-команд не испытывают в процессе работы ощущения «я много работаю, но делаю что-то не то», появляется больше осмысленности и больше уверенности в качестве своего труда. Классические методологии этого эффекта не дают, поскольку не предполагают моментальную реакцию на бизнес-изменения.

Частые ошибки внедрения: руководство по устранению

Важно отметить, что Scrum не гарантирует мгновенных успехов. К фреймворку нужно привыкать, возможно даже сталкиваться с неудачами и разочарованиями на первых порах. Важно не терять энтузиазм и дать время сотрудникам привыкнуть к новым реалиям, построив для них комфортную среду для развития.

Пока проблемы Agile-трансформации остаются: по данным Forbes Insights и MIT Sloan Management Review, около 47% agile-трансформаций заканчиваются провалом – это почти половина.

Почему так происходит? Разбираем типичные ошибки.

• Механический Scrum

Любая Agile-трансформация содержит в себе не только процессные изменения, но и культурные. Без изменения образа мышления невозможно достичь значимых результатов от внедрения Scrum.

Например, руководитель проекта с опытом 20 лет работы на одном месте начинает выполнять роль product owner – формирует перечень требований к продукту, соотносит их с требованиями рынка, анализом потребительских трендов и так далее. 

В какой-то момент работы вместо Daily Scrum он начинает проводить классические «планерки в отделе», авторитарно назначать ответственных на выполнение задач, единолично принимать все решения. Это обнуляет ключевой принцип, который может быть получен от Scrum-фреймворка – эффект самоорганизующейся команды. 

Еще один типичный пример – Scrum Master становится администратором таск-трекера Jira и ежедневно передвигает задачи по статусам вместо развития компетенций и коучинга команды на достижение целей при корректном соблюдении принципов руководства Scrum. 

• Несоблюдение рекомендаций из первоисточников

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

Причины этой ошибки могут быть разными, например, восприятие Scrum как командного фреймворка, используемого для формирования новой организационной структуры, вместо фокусирования на развитии продукта. Или отмена ретроспективы из-за непонимания ее ценности и важности для команды или загруженности команды в текущий период работы.

• Отсутствие регулярных коммуникаций и синхронизаций с заинтересованными лицами

По данным исследования State of Agile, прозрачность взаимодействий членов команды и оперативное управление изменениями – две важнейшие составляющие, от которых зависит успех Agile-трансформаций. 

Регулярная синхронизация с ключевыми заинтересованными лицами позволяет увеличить прозрачность взаимодействий, а также сформировать единое понимание целей и план по их достижению.

Тут тоже возникают сложности. Например, только что сформированная команда, стремящаяся использовать Scrum, общается с ключевыми участниками только по почте и не проявляет активности под предлогом «ранее было отправлено письмо, и ответ не получен».

• Отсутствие видения продукта

Наличие четких и понятных целей по развитию продукта и долгосрочного плана помогает направлять команду в нужное русло, вдохновлять клиентов и пользователей. Видение дает общее понимание того, в каком направлении мы хотим двигаться. 

Кроме того, видение продукта поддерживает Product Owner в выборе того, что стоит реализовывать в продукте, а что нет. К сожалению, часто возникают ситуации, когда Product Owner не формирует цели дальше, чем на один спринт и не делится планами с командой. Без четкого понимания scrum-командой вектора развития продукта результат будет непредсказуемым. 

• Недооценка метрик и регулярных оценок зрелости организации

Метрики в Agile-трансформации выполняют роль GPS-навигатора, они дают понимание, куда и с какой скоростью движется команда и продукт, позволяя вовремя вносить корректировки и тестировать актуальные гипотезы. 

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

Существуют и универсальные инструменты, например, фреймворк доказательного менеджмента (Evidence Based Management), в котором подробно описаны группы метрик, влияющие на бизнес-гибкость организации.

Для оценки зрелости организации популярен инструмент Agility Health Radar – опросник зрелости, который позволяет визуально понять, что именно и почему проседает в процессе трансформации.

Как получить максимум

Необходимо соблюдать два базовых правила, чтобы получить от работы по проектам в рамках Scrum максимальный эффект.

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

Эксперименты, кооперация, итерации и ориентация на пользу для конечного клиента являются ключевыми характеристиками этого процесса. 

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

Постоянно развивать инструменты для работы в новом ключе требует усилий, но зато и обеспечивает постоянные возможности для повышения эффективности работы.

Фото на обложке: Berk Ozel/shutterstock.com