Организационная гравитация

«БОСС» в помощь | Принятие решений
Текст | Илья ПАВЛИЧЕНКО, agile-коуч в компании Unusual-Concepts, сертифицированный scrum-тренер

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

Большинство agile-трансформаций, которые я видел, начиналось именно так. Проблемы, с которыми сталкиваются пилотные scrum-команды:

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

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

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

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

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

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

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

Я долго думал об отличиях этих команд от менее эффективных и очень обрадовался, когда обнаружил исследования Ричарда Хакмана и Рут Вейджмэн. Их работа полностью подтверждает мой личный опыт: 60% успеха команды закладывается еще ДО того, как команда формально запущена.

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

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

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

Рис. 1

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

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

В таблице на стр. 65 вы видите мой обычный чек-лист, который помогает оценить готовность компании к scrum.

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

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

Рис. 2

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

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

Рис. 3

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

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