Блог

LeSS в МТС Кассе 2-я часть (основы Скрама и пилотная команда)

Начало обучения — подготовка к внедрению LeSS

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

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

Изучение основ Скрама

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

Разработка истории изменения вместе с руководителями

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

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

Изучаем Скрам на пилотном проекте

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

Результаты работы пилотной команды

  • За время первого Спринта пилотная команда смогла представить новую фичу, которую неожиданно добавили в Бэклог Продукта после первой встречи с клиентами. Потребность клиента быстро обнаружили, и фича была выпущена за неделю.
  • Конечные пользователи принимали участие в Обзорах Спринтов и регулярно давали обратную связь — как качественную, так и количественную.
  • Через несколько Спринтов работа команды существенно изменилась. Члены команды начали учиться и постепенно становились кросс-функциональной командой разработчиков. Так, опытный разработчик под Windows сказал во время Ретроспективы, что через несколько месяцев собирается начать писать код для Android.
  • Изменилось мышление и поведение членов команды. Они стали работать в парах и часто помогали друг другу. Они поняли, что, если каждый будет работать только над собственной задачей, они вряд ли смогут помочь друг другу и в долгосрочной перспективе научиться чему-нибудь у коллег.
  • Команда смогла создавать фичи по трём каналам одновременно.
  • Владелец Продукта получил более прозрачный процесс разработки. Ему нравилось то, что команда работала как «чёрный ящик», выбирая элементы в Бэклоге Продукта и выдавая в итоге завершённые фичи без необходимости в дополнительном контроле, координации и т. п.
  • Команда взаимодействовала с рынком напрямую. Им не требовались дополнительные роли для координации деятельности — они работали независимо.
  • Средняя продолжительность цикла разработки фичи сократилась в 2 раза по сравнению с разработкой в компонентных командах.
Я заметил, что некоторые члены компонентных команд стали посещать Обзоры Спринтов. Им было интересно, чем занимается пилотная команда.
Мы обнаружили несколько негативных последствий пилота, которые трудно было разрешить:
  • Владелец Продукта испытывал огромное давление. Ему пришлось одновременно работать и с пилотной фиче-командой, и с остальными компонентными командами. Он вёл два Бэклога Продукта. Первый — для пилота — был ориентирован на клиента, а второй содержал PBI с техническими задачами для компонентных команд.
  • Фиче-команда работала в отличных от компонентных команд условиях. Владелец Продукта защищал пилот от вмешательств во время Спринта (например, от производственных багов и запросов от технической поддержки). Поэтому некоторые заявили, что фиче-команда не может служить для них убедительным примером.
  • Возникло напряжение между фиче-командой и группой бизнес-аналитиков. Разработчики начали общаться с клиентами напрямую. Бизнес-аналитики стали считать саму идею фиче-команды угрозой для своего существования.
  • Фиче-команда не могла самостоятельно выпустить функционал на рынок. В продуктовой группе всё ещё сохранялась роль релиз-инженера, который проводил итоговое тестирование и принимал окончательное решение о выпуске набора фич. Поэтому продолжительность цикла разработки фичи на самом деле значительно сократилась, но верхнеуровневый Cycle Time остался приблизительно таким же. Фичи были разработаны, но задерживались в очереди на выпуск.