Вопрос масштабирования команд часто появляется в повестке дня топ-менеджеров, когда перед ними открываются новые возможности – быстро получить доход, получить существенные инвестиции, вывести компанию на более высокий уровень и тому подобное.
Девять беременных не родят за один месяц. – Народная мудрость
Почему руководители берутся масштабировать продуктовые команды?
Вопрос масштабирования команд часто появляется в повестке дня топ-менеджеров, когда перед ними открываются новые возможности – быстро получить доход, получить существенные инвестиции, вывести компанию на более высокий уровень и тому подобное.
Все это обычно связано с продвижением нового продукта на рынок (желательно, сделать это быстро, чтобы обойти конкурентов). Но сначала его нужно разработать, предусматривая внедрение современных гибких подходов, где лидером является Scrum.
Понимая “скрам” или нет, представители бизнеса (банковской, авиационной, нефтепромышленной и других отраслей) обращаются к IT-компаниям и ставят задачу: срочно и как можно быстрее создать продукт.
Продуктом может быть новая функциональность уже готового программного обеспечения, создание новой услуги, удовлетворения потребностей бизнеса (например, в области кибербезопасности, защиты данных, автоматизации процессов) и др.
Один из вопросов, больше всего волнующий любой бизнес – стоимость реализации проекта, на которую влияют следующие факторы:
- Сложность задачи (нужно ли привлекать научный потенциал, существуют ли готовые и аналогичные решения, которые могут ускорить разработку, есть ли необходимость привлекать дополнительные технологии или экспертизу из других отраслей и т.д.).
- Требования к продукту (вытекают из потребностей потребителей и задач бизнеса).
- Анализ стоимости аналогичных продуктов.
- Предварительный расчет человеческого ресурса, необходимого для реализации продукта.
- Расчеты обычных экономических факторов, влияющих на стоимость (постоянные затраты, переменные расходы и т.д.).
Руководствуясь данными предварительного анализа и собственной экспертизой, топ-менеджеры приходят к выводу: для реализации проекта нужно, условно говоря, 100 специалистов на шесть месяцев. Именно с таким “готовым решением” и обращаются к ИТ-подразделению: “Создайте нам систему автоматизации через полгода – срочно. Чтобы выполнить эту задачу быстро, мы хотим видеть, как над проектом работают десять команд по десять человек в каждой”.
Вот она, мина замедленного действия.
Почему внедрять Scrum сразу с большим количеством команд опасно
Кейс с аэрокосмической разработки
В 2012 году меня пригласили как скрам-коуча в одну из топовых компаний по разработке программного обеспечения в Восточной Европе работать над заказом для аэрокосмической отрасли.
Проект набирал обороты. Сформировали немалый беклог (более 1000 пользовательских историй!). Проведен предварительный анализ, расписаны требования к продукту – собрано достаточно данных для того, чтобы рассчитать средний прогнозируемый срок реализации – полтора года. Стоимость первого проекта – десять миллионов долларов. В случае успеха открывалась дверь значительно больших возможностей.
Для всех было очевидно, что небольшой скрам-команде не под силу справиться с масштабным и сложным проектом.
Чтобы выяснить, сколько команд понадобится, мы решили вычислить среднюю скорость одной и перенести ее показатели на все остальные. Эта логика была ясна для обеих сторон. Контракт подписали.
Довольно быстро мы привлекли целую толпу специалистов. Ежемесячно добавляли по 20 человек. Цель – 12 команд.
С позиции рацио я понимал логику менеджеров, но интуиция скрам-коуча посылала мне сигнал тревоги.
К счастью, я как раз находился в Солт-Лейк-Сити, штат Юта, США, на конференции, посвященной Аджайл-манифесту. Там мне выпала честь лично познакомиться с Кеном Швабером, одним из “отцов” Scrum. Я признался Кену, что меня беспокоила проблема одновременного запуска многих скрам-команд. Он внимательно выслушал мой кейс, после чего дал непопулярный ответ: “Немедленно иди к топ-менеджерам и скажи им не идти этим путем! Вы сильно провалитесь, и вот почему…”.
Позиция Швабера
Кен продолжил: “Суть управления в комплексном домене заключается в создании частых релизов, как проверка гипотезы о том, что команда может создавать работающий продукт. Дело не в команде, которая разрабатывает ту или иную функциональность. Сложность масштабной разработки заключается в интеграции. Соединить наработки многих команд в единый готовый инкремент – сверхсложная задача! “
– Выпустили ли вы уже релиз со своими командами? – уточнил Швабер.
– Нет. Пока мы сосредоточены на самой разработке. Деливери еще не было.
– Когда планируете?
– Через месяц.
– Вот как раз и остановитесь. Сделайте сначала первое деливери. До этого не масштабируйте ничего.
Далее Кен изрек зловещее пророчество: “Вот увидишь. Пройдет месяц. К вам придет заказчик и скажет: я уже ничего не хочу. Сделайте хоть что-то, чем наши клиенты могли бы пользоваться “.
Кен посоветовал сформировать одну скрам-команду, которая интегрирует все наработки, чтобы сделать первый релиз. Если удастся это сделать, то можно постепенно наращивать “производственную мощность”.
Я вернулся в Киев и сразу передал своим боссам послание Швабера, на что услышал такой ответ: “Слава, язык на замок! Делай себе тихонько свое дело. Десять миллионов долларов в нашем кармане”.
Менеджеры действительно были настроены оптимистично. Тогда мы договорились: если таки сумеем воплотить свою авантюру, то напишем книгу “Кен Швабер был неправ”.
Вскоре мы поняли, что писать нам придется другую книгу. Все произошло так, как предсказывал Кен. Пришел заказчик и слово-в-слово передал его послание.
Последствия
Мы как раз закончили формировать двенадцатую команду… Но слово заказчика – закон. Интеграцией занялась одна скрам-команда. Всех остальных поставили на паузу на несколько месяцев.
Впоследствии более ста специалистов осталось на улице. Проект закрыли как фейл. Компания получила отрицательный рейтинг. Несколько миллионов долларов попало на ее счет, и в долгосрочной перспективе компания потеряла миллионы долларов от недополученных доходов и понесла невосполнимую репутационную потерю.
Другие кейсы
Интересно, что таких кейсов много.
Прошло почти десять лет. Одна компания пригласила меня как скрам-мастера. Деньги были, но специалистов для своевременного завершения работы над сложным продуктом не хватало. Поэтому менеджеры решили нанять дополнительно две команды из аутсорса – инкогнито, чтобы не привлекать излишнее внимание.
Я им сказал (уже на третью неделю работы!) что-то вроде зловещего пророчества Швабера: “Уверяю вас, коллеги, на 99%: замысел провалится. Вы потеряете время и деньги”. Менеджеры удивились: “Откуда ты это знаешь? Тебе что-то известно о той аутсорс-компании? “
Я просто не слышал, чтобы после одновременного добавления нескольких команд с улицы, еще на полпути проекта, получилось что-то путное за короткое время.
Последствия решения управленцев: запуск продукта отложили на 6 месяцев!
Вопрос: почему топ-менеджмент не прислушивается к мнению профессионалов (скрам-коучей, в нашем случае)?
Почему руководители самоуверенно принимают решения, требующие профессиональных знаний, при этом игнорируя мнение экспертов?
НАКОНЕЦ УСПЕШНЫЙ КЕЙС
В финансовый кризис 2008 года многие банки потерпели крах. Одна из причин – отсутствие регулярного стресс-тестирования ликвидности большинства из них.
Крупнейший инвестиционный банк, входящий в десятку крупнейших в мире по количеству транзакций в день, обратился к нам с просьбой разработать автоматизированную систему стресс-тестирования ликвидности.
Наша рекомендация удивила менеджеров: “Найдите лучших 10 человек, не больше. Дайте им несколько месяцев на то, чтобы сфокусироваться на каждой итерации, каждом спринте, для создания интегрированного продукта. Это даст нам возможность увидеть, как на самом деле работает команда, с какой скоростью и производительностью. После этого можем продолжить наш разговор о масштабировании скрам-команд “.
У менеджеров был противоположный план – запустить несколько команд, еще и сразу! Мы жестко ответили, что в таком случае не сможем сотрудничать из-за высокого риска неудачного результата.
Наше мнение услышали. Когда выяснилось, что скорость команды вдвое меньше, чем ожидаемые расчеты менеджеров, мы почувствовали холодок по коже. Неудивительно, что некоторые руководители свирепствовали и давили на ускорение темпов вдвое.
Реалистично оценив ситуацию, мы решили сделать за полгода только самое ценное и нужное.
Мы четко сформировали продуктовую цель и создали продукт. Он не имел всех мелочей и прихотей, но оказался удивительно качественным и удовлетворял все главные потребности заказчика, среди которых – безопасность, надежность, точность.
Впоследствии мы узнали, что это был первый случай запуска продукта “без головной боли” в контексте банка.
Работали над тем продуктом мы вместе с моим нынешним партнером, соучредителем Agile.Live, Сергеем Прохоренко – одним из ведущих специалистов по масштабированию гибкой разработки SAFe (Scaled Agile Framework).
Вишенкой на торте была персональная благодарность топ-менеджера банка, который получил именно то, что хотел.
Ошибки бизнесменов в IT-решениях
Учитывая указанные проблемы, хочу выделить несколько типичных ошибок, на которые стоит обратить внимание каждому руководителю:
- “И швец, и жнец, и на дуде игрец” – иллюзия профессионализма во всем.
- Непонимание скрам-подхода.
- Непонимание роли команды в скрам.
- Непонимание проблем рекрутинга специалистов интеллектуальной сферы.
- Непонимание модели Такмана по формированию команды и соответствующего количества времени: Forming → Storming → Norming → Performing.
РЕКОМЕНДАЦИИ
- Для успешного масштабирования следует дать пространство одной команде (не более 10 участников) для того, чтобы сосредоточиться на качественных итерациях, создании ценного инкремента и регулярных релизах.
- Об удачном масштабировании стоит говорить, имея хотя бы одну успешную скрам-команду.
- То же самое касается стратегии инвестирования. Эффективная скрам-команда создает возможность естественно и постепенно наращивать инвестиционную мощность параллельно с таким же естественным и постепенным масштабированием.
- Сама команда должна решать, как часто, сколько и каких новых людей нужно добавлять (например, раз в месяц, а при достижении определенного количества образовывать две команды, после чего естественным образом – три и так далее).
Постепенно естественное развитие помогает вовремя и безболезненно устранять “зависимости” команд друг от друга и быстро достигать необходимой интеграции в создании ценного инкремента. Этот подход мы называем органическим увеличением.
Позиция скрама
Важно знать официальную позицию скрам-подхода. По пособию Scrum Guide 2020, независимо от количества команд, в Скраме на один продукт могут быть только:
- Один беклог продукта (product backlog).
- Один владелец продукта (Product Owner).
- Одна цель продукта (product goal).
- Единственная экосистема для всех команд.
- Единый интегрированный инкремент.
Отсюда, собственно, и вытекал совет Кена Швабера.
ВЫВОДЫ
- Менеджерам стоит помнить: девять женщин не родят ребенка за один месяц.
- Когда речь идет о больших деньгах, больших проектах, больших командах, то руководители склонны полагаться на собственную компетентность и не слышать голоса скрам-коучей и других специалистов, из-за чего наступают на те же грабли и теряют.
- Лидерам не стоит приписывать себе компетентность, которой у них на самом деле нет.
- Руководителям просто необходимо советоваться со специалистами, обладающими профессиональными знаниями.
- Менеджерам необходимо понять стратегию органического масштабирования (начиная от одной скрам-команды из 5-10 человек).
- Мы не рекомендуем начинать проект с одновременного запуска многих скрам-команд (кроме случаев трансформации уже существующих крупных команд с помощью SAFe).
- Вводя Scrum для масштабного проекта, следует сначала создать надлежащие условия для функционирования “десятерых”.
- Руководителям следует устранить бюрократические и другие преграды на пути функционирования скрам-команды, если они хотят настоящей цифровой трансформации компании и передовых позиций на рынке.
Автор: Слава Москаленко
Рекомендуемые статьи о скрам-командах и масштабировании
Пять уровней перехода на Agile: самоуправляемые команды
Ролевая модель Scrum: как возникла и почему важна
Самоуправляемые и самоорганизованные команды: Начало
Мой первый фейл во внедрении Agile-культуры
SAFe: какие компании нуждаются в масштабировании?
ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE
Ближайшие сертификационные тренинги Agile.Live: Professional Scrum Product Owner (PSPO), Advanced Scrum Master with PSM II Certification
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live