Как на 60% обеспечить успешность запуска Скрам-команд до старта

Как обычно стартуют аджайл-трансформации

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

Проблемы, с которыми сталкиваются пилотные Скрам-команды:

  • Зависимость от других подразделений, потому что они изначально непродуктовые (подразделение кредитного конвейера, подразделение мобильного банка) и не могут быть самостоятельными.
  • Отсутствие настоящего Владельца Продукта, который был бы мини-CEO и принимал быстрые решения, повышая гибкость Продукта и организации.
  • Трудности с выделением людей на фултайм и растаскивание Команды по частям.
  • Нет полноценных кросс-функциональных и кросс-компонентных команд.
  • Работа, прилетающая Команде со стороны функциональных руководителей.
  • Члены Команды находятся в разных локациях.
  • Зависимость от вендоров.
  • Иерархия внутри аджайловых команд. Техлиды и тимлиды тормозят самоорганизацию команд и принятие ими самостоятельных решений.

Всё вышеперечисленное можно объединить под названием «организационная гравитация». Кроме неё в организациях есть сотрудники, которые явно или скрыто прикладывают максимум усилий для того, чтобы пилотные команды ограничились лишь поверхностными изменениями. Мой опыт показывает, что большинство «пилотов» имеют очень ограниченный успех. Часто организации даже не подозревают о том, насколько успешными могли бы быть пилотные команды.

Как сделать «пилоты» более успешными

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

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

Эффективность команд определяется ещё до их появления

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

Я долго думал об отличиях этих команд от менее эффективных и очень обрадовался, когда увидел исследования Ричарда Хакмана и Рут Вейджмэн, — их работа полностью подтверждает мой личный опыт:

60% успеха Команды закладывается ещё до того, как Команда формально запущена

Согласно исследованиям Leading Teams Ричарда Хакмана и What It Takes To Make Them Great Рут Вейджмэн эффективность Команды определяется:

  • 60% — структурой Команды;
  • 30% — тем, как вы стартуете Команду;
  • 10% — качеством командного коучинга.

Дизайн и структура играют определяющую роль в будущем успехе Команды. Вот результаты исследования Рут Вейджмэн:

Как на 60% обеспечить успешность запуска Скрам-команд до старта

Правильная точка приложения усилий при старте аджайловых команд — организационная структура

Очевидно, что организационная структура значительно влияет на успех команд. Поэтому прежде чем запускать «пилот» по Скраму, нужно подготовить под него соответствующую структуру.

Ниже вы найдёте мой обычный чек-лист, который помогает оценить готовность компании к Скраму:

Неоптимальная структура — ФЕЙКОВЫЕ команды 🙁 Оптимальная структура — НАСТОЯЩИЕ команды 🙂
Фейковые продукты, сформированные вокруг внутренних бизнес-процессов или компонентов организации Команды образованы вокруг продуктов или сервисов, которые покупают конечные пользователи на рынке
Распределённые команды Команды сидят в одной комнате за одним большим столом
Наличие иерархии внутри команд (техлиды, тимлиды) Отсутствие иерархии, есть только титул Разработчик
Скрам-мастер и Команда находятся в разных локациях Скрам-мастер и Команда в одной локации
Команды не кросс-функциональны Кросс-функциональные и кросс-компонентные команды
Фейковый Владелец Продукта, не имеющий реальной власти, не владеющий бюджетом, который не может принимать стратегические решения Концепция мини-CEO. Владелец Продукта, как Стив Джобс, полностью владеет Продуктом
Контрактная игра в действии, наличие дедлайнов, коммитментов, успешность меряется по проектным критериям Успешность оценивается по доставленной ценности и бизнес-критериям (ROI, P&L etc.)
Наличие функциональных менеджеров у членов команд, которые могут влиять на их зарплату, отпуск и прочее Отсутствие функциональных менеджеров у Команды Разработки. Команда работает напрямую с Владельцем Продукта и полностью лояльна ему
Менеджеры запускают «пилоты» и формируют команды «Пилоты» организуются вокруг волонтёрского движения, и команды сами формируют свой состав
Команда имеет непостоянный состав и регулярно меняется Команда стабильна, основной состав сохраняется на протяжении 1–3 лет минимум
Система индивидуальных KPI Командные KPI
Разработчики получают зарплату в зависимости от уровня своей основной компетенции (Junior, Middle, Senior Java Developer) Разработчики получают зарплату в привязке к тому, насколько мультизадачными со временем они становятся (T-Shaped, П-Shaped люди)
Парт-тайм Скрам-мастер, часто совмещающий свою деятельность с разработкой Фултайм Скрам-мастер, у которого 1–3 Скрам-команды
Обучение не приветствуется, особенно в рабочее время Команды имеют доступ к необходимому обучению и расширяют свои компетенции

Кейс компании TOP Games Tech

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

Структура TOP Games Tech до перехода на Скрам
Структура TOP Games Tech до перехода на Скрам

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

Структура TOP Games Tech после перехода на Скрам
Структура TOP Games Tech после перехода на Скрам

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

Заключение

Мой опыт и исследования показывают, что командная эффективность на 60% определяется структурой, на 30% качественным стартом и на 10% коучингом. Чтобы повысить шансы на успех при запуске Скрам-команд, заручитесь поддержкой сверху и снизу и проведите организационные изменения ещё до старта. Удачи!

 

Автор статьи

Меня зовут Илья Павличенко, и я — Аджайл Коуч в компании Unusual-Concepts. Также я сертифицированный Скрам тренер в Scrum.org Я ни минуты не работаю, потому что занимаюсь любимым делом. Скрам — мое хобби и моя жизнь. Хотите больше узнать о том, как стать эффективным Скрам-мастером и Владельцем Продукта? Приходите на мои Professional Scrum Master (PSM) и Professional Scrum Product Owner (PSPO) тренинги.

Scrum ON!



Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *