Обучение — подготовка к LeSS

Почему для внедрения LeSS нужно изменить оргструктуру

Эффективное внедрение LeSS (как и эффективное внедрение однокомандного Скрама) обычно означает изменение организационной структуры (руководство «Три принципа внедрения»). Причина в том, что большинство оргструктур оптимизирует индивидуальные результаты работы и в рамках таких структур происходит множество локальных оптимизаций. LeSS упрощает организационные структуры. Этот фреймворк преследует оптимизационные цели, для достижения которых, как правило, требуются структурные изменения:

• доставка наивысшей ценности для клиента;
• адаптивность компании (способность резко поменять курс ради доставки бизнес-ценности);
• обучение.

Мы пригласили топ-менеджеров, разработчиков и руководителей всех функциональных подразделений (отделы маркетинга, продаж, нормативно-правового соответствия и пр.) принять участие в двухдневном тренинге по основам Скрама — Professional Scrum Foundations (PSF). Тренинг помог им понять ценности и принципы, лежащие в основе работы Скрам-команды. Существуют руководства по внедрению фреймворка LeSS в организации (руководство «Начало работы»). Первым же шагом в руководстве говорится о необходимости обучить всех. Теперь я осознаю, что с самого начала не обучил всех сотрудников должным образом и поэтому не строго следовал рекомендациям. Из-за этого очень быстро возникли проблемы с добровольцами и поддержкой внедрения фреймворка.

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

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

Второй артефакт — сама история изменения. История выглядит как краткое обращение к сотрудникам компании, в котором подчеркиваются ключевые моменты:

• почему нам сейчас необходимы перемены;
• что мы собираемся предпринять.

«Раньше мы были гибкой небольшой компанией. Нам это нравилось, потому что мы были независимы, а вся информация — прозрачной. Потом мы стали расти, становились больше — и в один прекрасный день получили инвестиции от МТС. Это оказало влияние на наши взгляды и увеличило количество задач. Поэтому нам необходимы изменения в структурах и процессах для того, чтобы стать более эффективными, исключить ошибки и улучшить качество продукта. Нам нужна поддержка коучей, чтобы достичь гибкости».

После воркшопа каждый сотрудник получил электронную версию этого обращения.

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

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

• Через несколько Спринтов работа команды существенно изменилась. Члены команды начали учиться и постепенно становились кросс-функциональной командой разработчиков. Так, опытный разработчик под Windows сказал во время Ретроспективы, что через несколько месяцев собирается начать писать код для Android.
• Изменилось мышление и поведение членов команды. Они стали работать в парах и часто помогали друг другу. Они поняли, что, если каждый будет работать только над собственной задачей, они вряд ли смогут помочь друг другу и в долгосрочной перспективе научиться чему-нибудь у коллег.

• Команда смогла создавать фичи по трём каналам одновременно.
• Владелец Продукта получил более прозрачный процесс разработки. Ему нравилось то, что команда работала как «чёрный ящик», выбирая элементы в Бэклоге Продукта и выдавая в итоге завершённые фичи без необходимости в дополнительном контроле, координации и т. п.
• Команда взаимодействовала с рынком напрямую. Им не требовались дополнительные роли для координации деятельности — они работали независимо.
• Средняя продолжительность цикла разработки фичи сократилась в 2 раза по сравнению с разработкой в компонентных командах.

Я заметил, что некоторые члены компонентных команд стали посещать Обзоры Спринтов. Им было интересно, чем занимается пилотная команда.

Мы обнаружили несколько негативных последствий пилота, которые трудно было разрешить:

• Владелец Продукта испытывал огромное давление. Ему пришлось одновременно работать и с пилотной фиче-командой, и с остальными компонентными командами. Он вёл два Бэклога Продукта. Первый — для пилота — был ориентирован на клиента, а второй содержал PBI с техническими задачами для компонентных команд.
• Фиче-команда работала в отличных от компонентных команд условиях. Владелец Продукта защищал пилот от вмешательств во время Спринта (например, от производственных багов и запросов от технической поддержки). Поэтому некоторые заявили, что фиче-команда не может служить для них убедительным примером.
• Возникло напряжение между фиче-командой и группой бизнес-аналитиков. Разработчики начали общаться с клиентами напрямую. Бизнес-аналитики стали считать саму идею фиче-команды угрозой для своего существования.
• Фиче-команда не могла самостоятельно выпустить функционал на рынок. В продуктовой группе всё ещё сохранялась роль релиз-инженера, который проводил итоговое тестирование и принимал окончательное решение о выпуске набора фич. Поэтому продолжительность цикла разработки фичи на самом деле значительно сократилась, но верхнеуровневый Cycle Time остался приблизительно таким же. Фичи были разработаны, но задерживались в очереди на выпуск.