Илья Павличенко, профессиональный Скрам-мастер от Scrum.org и коуч Unusual Concepts, поделился секретами успешного запуска Скрам-команд.
Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.
Как обычно начинаются аджайл-трансформации
Все начинается с того, что в компании появляется стратегическая инициатива по «внедрению» Аджайла. Фирма выделяет крупный бюджет и организует тендер на закупку услуг аджайл-коучей. После обучения запускаются пилотные команды, которые сразу начинают буксовать, оказавшись в инородном для них культурном ландшафте. Большинство аджайл-трансформаций, которые я видел, начинались именно так.
Проблемы, с которым сталкиваются пилотные Скрам-команды:
- Зависимость команды от других подразделений, потому что часто эти команды изначально непродуктовые (команда кредитного конвейера, команда мобильного банка) и не могут быть самостоятельными.
- Отсутствие настоящего владельца продукта, который был бы mini-CEO продукта и принимал быстрые решения, повышая гибкость продукта и организации.
- Трудности с выделением людей на фултайм и растаскивание команды по частям.
- Нет полноценных кросс-функциональных и кросс-компонентных команд.
- Работа, «прилетающая» команде со стороны функциональных руководителей.
- Члены команды находятся в разных локациях.
- Зависимость от вендоров.
- Иерархия внутри аджайл-команд. Техлиды и тимлиды тормозят самоорганизацию команд и принятие ими самостоятельных решений.
Все вышеперечисленное можно объединить под названием «организационная гравитация». Кроме нее, в организациях есть сотрудники, которые явно или скрыто прикладывают максимум усилий для того, чтобы пилотные команды ограничились лишь поверхностными изменениями. Мой опыт показывает, что большинство «пилотов» имеют очень ограниченный успех. Часто организации даже не подозревают о том, насколько успешными могли бы быть пилотные команды.
Как сделать «пилоты» более успешными
В небольшом стартапе успех во многом зависит от навыков членов команды, уровня доверия, заряженности и идейности людей, а также наличия хороших практик. В крупных организациях культуру поведения и образ мышления определяют другие факторы — наличие распределенных команд, уровень бюрократизации, система KPI и бонусов, количество этажей иерархии и другие.
Организационная гравитация настолько сильна, что правильнее сначала изменить структуру под будущие «пилоты», а затем лишь запускать Скрам-команды. Ниже я поясню, почему именно такой подход имеет более высокие шансы на успех.
Эффективность команд определяется еще до их появления
В моей практике были команды и компании, в которых результат «пилотов» был просто потрясающим, а команды довольно быстро входили в гиперпродуктивное состояние. Не было необходимости даже в метриках и KPI, чтобы увидеть разницу.
60% успеха команды закладывается еще ДО того, как команда формально запущена
Согласно исследованиям Ричарда Хакмана и Рут Веджмэн эффективность команды определяется следующими факторами:
- 60% — структурой команды;
- 30% — тем, как вы запускаете команду;
- 10% — качеством командного коучинга.
Дизайн и структура играют определяющую роль в успехе будущей команды. Вот результаты исследования Рут Вейджмэн:
При старте команд нужно уделить особое внимание организационной структуре
Очевидно, что организационная структура значительно влияет на успех команд. Поэтому прежде, чем запускать «пилот» по Скраму, нужно подготовить под него соответствующую структуру.
Ниже вы найдете мой обычный чек-лист, который помогает оценить готовность компании к Скраму:
Менее оптимальная структура :( | Более оптимальная структура :) |
Фейковые продукты, сформированные вокруг внутренних бизнес-процессов или компонентов организации. | Команды образованы вокруг продуктов или сервисов, которые покупают конечные пользователи на рынке. |
Распределенные команды (члены одной команды находятся в разных локациях). | Команды физически сидят в одной комнате за одним большим столом. |
Наличие иерархии внутри команд (техлиды, тимлиды). | Отсутствие иерархии, есть только один титул «разработчик». |
Скрам-мастер и команда находятся в разных локациях. | Скрам-мастер и команда в одной локации. |
Команды не кросс-функциональны. | Кросс-функциональные и кросс-компонентные команды. |
Фейковый владелец продукта, не имеющий реальной власти, не владеющий бюджетом, который не может принимать стратегические решения по продукту. | Концепция mini-CEO. Владелец продукта — «Стив Джобс» и полностью владеет продуктом. |
Контрактная игра в действии, наличие дедлайнов, коммитментов, успешность меряется по проектным критериям. | Успешность оценивается по доставленной ценности и бизнес-критериям (ROI, P&L etc.) |
Наличие функциональных менеджеров у членов команд, которые могут влиять на их зарплату, отпуск и прочее. | Отсутствие функциональных менеджеров у команды разработки. Команда работает напрямую с владельцем продукта и полностью лояльна ему. |
Менеджеры запускают «пилоты» и формируют команды. | «Пилоты» организуются вокруг волонтерского движения, и команды сами формируют свой состав. |
Команда имеет непостоянный состав и регулярно меняется. | Команда стабильна, основной состав сохраняется на протяжении, как минимум, 1-3 лет. |
Разработчики получают зарплату в зависимости от уровня своей основной компетенции. | Разработчики получают зарплату в привязке к тому, насколько мультизадачными со временем они становятся (T-shaped, П-shaped люди). |
Парт-тайм Скрам-мастер, часто совмещающий свою деятельность с разработкой. | Фултайм Скрам-мастер, у которого 1-3 Скрам-команды. |
Обучение не приветствуется, особенно в рабочее время. | Команды имеют доступ к необходимому обучению и расширяют свои компетенции. |
Кейс компании TOP Games Tech
До внедрения Скрама организация имела функциональную структуру с командами, образованными вокруг архитектурных компонентов и технологий. Владелец компании жаловался на низкую скорость разработки и отсутствие прозрачности. Команды не понимали, что происходит и куда движется компания. Представители бизнеса и разработчики не общались между собой напрямую, большое количество координирующих ролей создавали эффект испорченного телефона. Ключевые решения в разработке принимали техлиды и тимлиды, забирая у команд ответственность и лишая их возможностей для самоорганизации.
Структура TOP Games Tech до перехода на Скрам
Перед запуском Скрам-команд мы расформировали функциональные подразделения и пригласили владельцев продукта из отдела маркетинга. Позже мы расширили определение продукта и объединили все команды под одним владельцем продукта. Разработчики сами образовали стабильные продуктовые Скрам-команды с выделенными Скрам-мастерами. Для каждой команды выделили отдельное помещение, убрали координирующие позиции, упразднили должности тимлидов и техлидов. Все участники команд без исключения стали называться разработчиками. Собственник компании непосредственно участвовал в трансформации и давал добро на все организационные изменения. Получилась вот такая структура:
Структура TOP Games Tech после перехода на Скрам
Уже через три месяца образованная продуктовая группа показывала высокую производительность и гибкость. Через полгода компания успешно вышла с продуктом на конкурентный азиатский рынок. Я считаю, что залогом успеха стало вовлечение людей, которым вернули ответственность и дали самим трансформировать место работы.
Заключение
Мой опыт и исследования показывают, что командная эффективность на 60% определяется структурой, на 30% качественным стартом и на 10% коучингом. Чтобы повысить шансы на успех при запуске Скрам-команд, заручитесь поддержкой сверху и снизу и проведите организационные изменения еще до старта. Удачи!
Материалы по теме:
Три распространенных ошибки тех, кто захотел перейти на Scrum
«Псевдо-аджайл» только поначалу выглядит круто – разрушаем популярные мифы
Зомби не пройдут. Как выбрать Scrum-мастера для вашей команды
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Материалы по теме
- 1 Scrum вне разработки: где еще и каким образом можно применять эту методику
- 2 Нужно ли компании внедрять Scrum?
- 3 Зачем компании скрам-мастер и где его найти
- 4 В Москве пройдет конференция по гибким методам управления AgileDays 2021
- 5 Все, что вы хотели знать про Agile: принципы, методология, инструменты и отличие от Scrum
ВОЗМОЖНОСТИ
14 октября 2024
14 октября 2024
14 октября 2024