Внедрение LeSS в организации

Многие, начиная внедрение LeSS, рассчитывают обойтись изменением ряда практик. Но очень скоро выясняется, что LeSS требует пересмотреть устоявшиеся представления о том, как должна работать компания. Авторы LeSS отмечают, что LeSS заставляет организацию честно взглянуть на себя и убрать лишнее.

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

Типичные ошибки при внедрении LeSS

Практика показывает, что большинство ошибок при внедрении LeSS происходят от желания облегчить себе жизнь и обойти острые углы.

Широко, но поверхностно. Компания пытается сразу внедрить LeSS на несколько проектов или отделов, но не следует принципам. Авторы методологии предупреждают, что лучше сконцентрироваться на одном продукте и внедрить LeSS глубоко, чем запустить его сразу повсюду, но поверхностно.

Имитация вместо изменения структуры. Одна из главных ошибок – сохранить старую оргструктуру, просто навесив новые ярлыки. Например, объявить, что теперь у нас LeSS, но оставить десяток Владельцев продукта по компонентам, независимые команды с отдельными бэклогами и привычную иерархию менеджеров. Такой путь проще, недаром некоторые выбирают фреймворки наподобие SAFe, не требующие радикальной смены структуры. Но без единого бэклога продукта и кросс-функциональных команд изменения не произойдут. Процессы вроде новые, а проблемы старые.

Непонимание зачем и недостаточное обучение. Слишком часто компании бросаются масштабировать Scrum, не вложившись в обучение сотрудников. Команды и менеджеры могут формально выучить что делать, но не понять, зачем. На официальном сайте LeSS говорится: «помимо обучения тому, что и как изменить, еще важнее разъяснить смысл — почему мы это меняем». Типичная ошибка — считать само собой разумеющимся, что все и так поймут ценности LeSS.

Отсутствие системного подхода и цели. Нередко внедрение Agile-фреймворка начинается с того, что менеджмент решает заказать модную методику, не разобравшись, подходит ли она бизнесу. Мы советуем сначала подумать, что именно в организации вам хочется изменить, и лишь потом выбирать фреймворк.

Проектное мышление и непоследовательность. Другая ошибка – относиться к трансформации как к разовому проекту. То есть утвердить план, за полгода внедрить и успокоиться. Или как это бывает – создали видение изменений, запустили несколько инициатив, достигли формальных показателей, и объявили, что внедрение Agile завершено, можно дальше работать как обычно. Если после первых побед остановиться, то организация вскоре впадет в прежнее болото, а следующая трансформация начнется с отката предыдущей.

Конечно, этим списком ошибки не ограничиваются. У каждой компании могут быть свои грабли.

Сопротивление сотрудников и влияние культуры

Любое изменение – это работа с людьми, а люди не любят менять привычки. При внедрении изменений сопротивление неизбежно. Оно может быть тихим, как пассивное неприятие или открытым, как критика и отказ следовать новым правилам. Корни сопротивления лежат в человеческой природе и корпоративной культуре.

Во-первых, страх и неуверенность сотрудников. LeSS часто воспринимается как угроза: «Что будет с моей должностью? Справлюсь ли я с новой работой?». Если раньше тестировщик сидел в отделе тестирования, а аналитик писал требования у себя в кабинете, то теперь их хотят встроить в продуктовую команду. А там придется осваивать новые навыки, тесно сотрудничать с разработчиками, да еще и отвечать за результат целиком. Понятно, что многие почувствуют дискомфорт. Люди боятся потерять статус и работу, а слухи только подливают масла в огонь – «в Agile нет менеджеров», «в Scrum каждый сам по себе» и так далее.

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

Прежде всего – нужна максимально прозрачная коммуникация и обучение. Люди должны понять, зачем компания затеяла LeSS и какие проблемы хочет решить. Важно честно говорить о трудностях перехода, и давать поддержку, которую хотят получить команды. Пусть в пилотную LeSS-группу войдут те, кто хочет попробовать новый подход. Менеджеры часто боятся такого шага – кажется, что теряешь контроль, – но на деле добровольцы могут стать двигателями перемен. Они первыми пройдут через обучение, попробуют новые практики и своим энтузиазмом подтянут остальных. Конечно, полностью на волонтёрах трансформацию не построишь – рано или поздно придется охватить всех – но начать с мотивированных людей эффективнее, чем принуждать скептиков с первого дня.

Как отмечают практики LeSS, в любой организации найдутся те, кто категорически не приемлет изменений. Их единицы, но они могут отравлять климат всей команды. Если упорное обучение и личные беседы не помогают, возможно, таких сотрудников придется переместить или отпустить. Это трудный шаг, но иногда необходимый, чтобы остальной коллектив мог двигаться вперед без постоянного негатива.

Наконец, культура изменения должна поощряться сверху. Если топ-менеджеры и лидеры команд активно участвуют в трансформации, признают свои ошибки, открыто обсуждают проблемы – сотрудники увидят, что изменения – это не чья-то прихоть.

Менеджмент как основной барьер

Одна из самых больших преград на пути LeSS – собственный менеджмент компании.

LeSS радикально меняет роль менеджеров. В традиционных иерархиях начальники решают, "что" и "как" должна делать команда. В Scrum же – и тем более в LeSS – эти ключевые решения отходят другим ролям. "Что делать" теперь определяет Владелец продукта, расставляя приоритеты для команд. "Как делать" решает сама команда, будучи самоорганизующейся и самостоятельно планируя свою работу. Менеджер больше не контролирует ни задачи, ни способы выполнения – и должен с этим смириться, ведь всю карьеру их ценили за умение командовать и принимать решения. Теперь же от них требуется отпустить бразды и перейти в роль наставника и фасилитатора. 

LeSS-организация фактически устраняет целые слои привычного менеджмента. Например, проектные менеджеры и PMO (офисы управления проектами) больше не нужны – их функции распределены между Владельцем продукта и командами. Неудивительно, что менеджеры, чьи позиции ставятся под вопрос, начинают сознательно или нет тормозить изменения.

Даже лояльные руководители часто оказываются не готовы к новой роли. Одно дело – подписать приказ о внедрении LeSS, другое – изменить собственное поведение. Менеджерам теперь следует “спускаться” к командам, узнавать реальные проблемы на месте («ходи и смотри» принцип), помогать устранять препятствия, обучать людей решениям проблем. Не каждый руководитель, много лет строивший карьеру на директивном стиле, сможет перестроиться. Иногда верхушка компании искренне хочет Agile, но средние начальники не умеют работать иначе, и продолжают раздавать указания, давить на команды, вмешиваться в спринты. По факту получается старый добрый микроменеджмент. Команды быстро замечают несоответствие и разочаровываются.

— Говорили, будет по-новому, а начальник как контролировал каждый шаг, так и контролирует.

Бывает и обратная ситуация: энтузиасты внизу пытаются запустить LeSS, а топ-менеджмент не дает добро на нужные изменения. Например, чтобы реорганизовать команды по продукту, может понадобиться перекроить департаменты, изменить штатное расписание и перераспределить ответственность.

До начала внедрения честно обсудите с ключевыми менеджерами, как изменится их роль, какие выгоды в итоге получит организация и они сами. Обучение по Scrum и LeSS специально для руководителей – отличный шаг. Им, как и всем, нужно пройти через этап “а зачем мне меняться?”. В этой ситуации помогает приглашение внешних Agile-экспертов.

От команды исполнителей – к команде предпринимателей

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

— Нам что, никто не скажет, как правильно? Мы сами должны решить?

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

LeSS предполагает кросс-функциональные команды, способные выполнить работу от начала до конца. Это значит, что больше нет “моё дело – код, а твоё – тесты”. Разумеется, экспертиза никуда не девается, люди по-прежнему обладают разными сильными сторонами. Но теперь каждый член команды готов при необходимости выйти за рамки своей прежней роли ради общего результата. Тестировщик участвует в анализе требований, разработчик – в написании авто-тестов, дизайнер – в обсуждении бизнес-ценности фичи и так далее.

Пожалуй, самые острые вопросы: 

— А что станет с нашими руководителями проектов? 

— А куда девать отдел тестирования? 

— У нас же были архитекторы, аналитики – их что, распустить? 

В LeSS действительно многие привычные роли исчезают как отдельные единицы. Например, как уже говорилось, классический руководитель проекта в LeSS-организации больше не нужен – планирование и координация выполняются самими командами и Владельцем продукта. Отдельные группы тестирования или QA – тоже нежелательное явление. Все эти функции должны войти в состав команд. То же касается и отделов бизнес-анализа, архитектуры – специалистов из них лучше распределить по командам, сделав их полноценными членами продуктовых команд.

Однако в реальности не всегда можно сразу махом упразднить все такие отделы. Возникает переходный период, и он чреват сложностями. Скажем, компания объявила о формировании фиче-команд, но люди продолжают числиться в старых функциональных отделах и отчитываться прежним начальникам. Происходит конфликт интересов: с одной стороны, команда требует лояльности общим целям, с другой – начальник отдела тянет одеяло на себя и задает свои задачи сотруднику. Если вы переводите тестировщика или аналитика в продуктовую команду, он больше не должен подчиняться руководителю тестировщиков или аналитиков. Иначе старые роли по привычке будут доминировать над новыми.

Когда команды получают больше свободы, автоматически приходит и больше ответственности. Например, установление строгих общих критериев “Готово” (Definition of Done) требует от команд освоения новых компетенций – иначе они не смогут самостоятельно доводить инкремент до потенциально выпускаемого состояния. Если нагрузочное тестирование включено в DoD, команда должна научиться его делать сама, возможно пригласив в состав человека с такими умениями. Это большие изменения, и они могут сначала замедлить работу – пока люди учатся, перестраиваются. Руководству важно понимать, что эти инвестиции окупятся, потому что такая команда намного продуктивнее в долгосрочной перспективе.

Представьте, что команда пробует сама планировать релиз и ошибается со сроками – клиент недоволен. Начальники вспоминают “старое доброе” и вводят обратно руководителя проекта для порядка. Чтобы этого избежать, надо закладывать прочный фундамент доверия. Ошибки – это нормально, мы учимся. Если что-то пошло не так, разбираем на ретроспективе и улучшаем процесс, но не делаем шаг назад к командно-контрольной модели.

Риски поверхностного внедрения

1. Сохранение старых проблем под новым соусом

Если менять только названия, но не суть, команды по-прежнему будут буксовать на тех же препятствиях. Например, в компании “X” провели тренинги, назначили во всех командах Скрам-мастеров, стали проводить Обзоры спринтов общим созвоном – вроде LeSS. Но при этом остались отдельные бэклоги для каждой команды, а главное – каждая команда всё так же пилит свой “подпродукт” под началом локального Product Owner. В итоге никакого единства цели не появляется. Перегруженная одна команда не получает помощи от другой, ведь та ничего не знает о её части продукта

2. Путаница ролей и ответственности

Полу-перемены хуже отсутствия перемен. Когда часть старых ролей сохраняется, а часть новых введена, люди оказываются в двойственной ситуации. К примеру, ввели роль общего Владельца продукта, но оставили проектных менеджеров “для подстраховки”. В результате команды имеют два центра влияния: Product Owner говорит одно, Project Manager – другое. Менеджеры, не до конца понявшие свою новую роль, продолжают вмешиваться в бэклог и давать задания напрямую. Кто на самом деле приоритизирует работу?

3. Дискредитация Agile в глазах команды 

Возможно, самый большой риск, что люди разочаруются в самой идее Scrum/LeSS. Они честно пытаются работать по-новому, но видят, что руководство не делает необходимых шагов. Например, стоит команде принять неудобное для начальства решение – его сразу же отменяют сверху. Или обещали убрать бюрократию, а её стало еще больше (теперь кроме старых отчетов добавились новые метрики Agile). В следующий раз, когда организация созреет для настоящих преобразований, доверия уже не останется. Кроме того, клиенты и стейкхолдеры, однажды услышав, что “мы внедрили LeSS”, будут ожидать ускорения и улучшения качества. Если этих улучшений нет, пострадает репутация команды в их глазах. 

— Даже Agile им не помог, наверное, дело в самих людях.

4. Привычка обходить принципы 

Псевдо-внедрение приучает организацию к опасной мысли: “процессы существуют для галочки, главное – обойти их и сделать по-своему”. Например, иметь одного формального Product Owner, но фактически продолжать получать требования от нескольких бизнес-аналитиков по старой схеме. Возникает феномен ScrumBut (“Мы делаем Scrum, но… не убрали менеджеров, не объединили бэклог и т.д.”). Это состояние даже хуже отсутствия методологии, потому что люди тратят силы на поддержание видимости и лавирование, вместо того чтобы честно договориться, как работать эффективно.

Сложности внедрения в разных корпоративных культурах

Каждая организация уникальна, и тип корпоративной культуры сильно влияет на то, с какими сложностями встретится LeSS.

Традиционные корпорации

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

Главная сложность – слом вертикали власти. LeSS предлагает радикально упластить структуру, убрать лишние звенья. Для корпорации это почти революция. Средний менеджмент почувствует угрозу своему влиянию и статусу. Внедрение LeSS заденет интересы целых отделов. Каждое сокращение должности или слияние отделов может восприниматься как удар по чей-то карьерной истории.

Вторая проблема – привычки сотрудников. В иерархиях люди привыкли действовать по инструкциям. Даже если им дать свободу, они могут первое время ждать указаний. Культура послушания и боязнь наказания за ошибку парализуют самоорганизацию. Требуется время и сильная поддержка, чтобы сотрудники поверили: “правда можно самим? за это не накажут?”.

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

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

Продуктовые стартапы

Особенность стартапа – хаотичный рост. Пока компания маленькая, Scrum в чистом виде работает отлично. Но при росте до нескольких команд часто возникает “звездная” структура вокруг основателей. Они принимают все решения и команды зависят от них. Старшие сотрудники управляют младшими, а процессы становятся разными в каждой команде. Сложность в том, что стартап никогда раньше не следовал чужим процессам, и вдруг появлется LeSS – пусть и легковесный, но всё же фреймворк с определенными правилами. Некоторым это может не понравиться.

Второй момент – роль основателей и лидеров. В стартап-культуре обычно есть ярко выраженные лидеры продукта (CTO, CEO, продуктовые гении), которые привыкли лично управлять многими аспектами. При LeSS им тоже нужно отойти в сторону в операционных вещах, доверив, например, приоритизацию единому Product Owner’у, а ежедневное самоуправление – командам.

В отличие от гигантов, культура стартапов обычно более открыта экспериментам. Молодой коллектив легче обучить – у многих нет 20-летнего багажа работы в waterfall, им проще принять agile-принципы. 

Государственные компании и крупные госкорпорации

Государственные компании славятся консерватизмом и множеством регуляций. Хотя сейчас многие из них декларируют цифровую трансформацию, на практике перемены идут тяжело.

Часто есть внешние требования, которые определяют процессы – закон, приказ министерства и ГОСТы. Полностью выбросить это нельзя – регулятор не поймет. Значит, LeSS-командам придется как-то уживаться с внешними бюрократическими рамками. Это может выражаться в гибридных подходах: например, внутри команды спринты и релизы по Scrum, но для отчетности наверх готовятся документы по шаблону.

В госкультурe, как ни прискорбно, часто распространено избегание ответственности. Лучше перестраховаться, согласовать десять раз, чем одному принять решение и потом отвечать. Это противоположно Agile-принципу “люди взаимодействуют напрямую и быстро принимают решения”. Распространена фраза: “инициатива наказуема”. Побороть это можно лишь долгим воспитанием новой культуры доверия.

В госорганизациях люди нередко работают по принципу “от звонка до звонка”, а инициативность не вознаграждается рублем. В таких условиях Agile-трансформация может натолкнуться на отсутствие внутренней мотивации у сотрудников. Им перемены не нужны – их и так все устраивает. Управлять такими настроениями крайне сложно. Возможно, часть персонала действительно не удастся включить, придется обновлять состав. Или же необходимо создать новые стимулы внутри: признание лучших команд, нематериальные бонусы за предпринимательское поведение.

Тем не менее, и в госсекторе бывают успешные примеры. Если, например, замминистра или директор департамента искренне продвигает продуктовый подход и прикрывает команды от формальностей, давая им маневр, — шансы есть.

Аутсорсинговые и сервисные компании

Особый случай – ИТ-аутсорсинг и проектные компании, где команды работают не на собственный продукт, а на проекты заказчиков.

LeSS строится вокруг продукта и единого бэклога. В аутсорсинге же у компании 5 разных клиентов, для каждого – свой проект и своя команда. Применить классический LeSS можно разве что для одного крупного клиента, где задействовано несколько команд. Тогда эти команды и образуют продуктовую группу, а Product Ownerом становится представитель клиента. 

Или связка клиент + внутренний продакт-менеджер.

Сложность в том, что внешний Product Owner может не уметь работать по LeSS. Если заказчик консервативен, провайдер либо вынужден делать Scrum внутри и waterfall снаружи, либо отказаться от LeSS для этого проекта.

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

Часто договор с клиентом прописывает процессы, артефакты и контрольные точки. Если контракт жестко водопадный, провайдер мало что может поменять в процессах. А даже если не жестко – отношения “заказчик-подрядчик” подразумевают определенную дистанцию. Команды могут не иметь прямого доступа к конечным пользователям, что усложняет сбор обратной связи и тормозит итерации. В LeSS идеология – продуктовая компания, а в аутсорсинге – проектно-контрактная. Примирить их тяжело. Одно из решений: внедрять элементы LeSS внутри, но внешне продолжать работать по условиям клиента. Фактически, это будет не классический LeSS, а гибрид. Вдруг клиент созреет для совместной Agile-работы.

Многие сервисные компании происходят с Восточной Европы и Азии, где “клиент всегда прав”. Это хорошо, но порой ведет к подчиненной позиции: команда не чувствует продукт своим, она пишет то, что сказали. Чтобы LeSS заработал, даже внешний, нужна продуктовая вовлеченность – ощущение, что мы вместе с заказчиком делаем классный продукт, а не просто оказываем услугу.

Пошаговый процесс внедрения LeSS

Как же подойти к внедрению грамотно, чтобы учесть эти трудности? 

Шаг 1. Заручиться поддержкой и пониманием топ-менеджмента

Любая масштабная трансформация начинается сверху. Прежде чем трогать команды, убедитесь, что высшее руководство не просто дало разрешение, а активно поддерживает и понимает суть LeSS. В компании должны быть влиятельные лидеры. Объясните топам, что без их участия ничего не выйдет, потому что предстоят радикальные изменения структуры. Поддержка первых лиц необходима хотя бы потому, что придется менять организационную структуру и роли. Если генеральный директор, CTO или руководитель бизнес-направления сами не верят в LeSS, лучше сначала поработать над этим – например, провести для них workshop и показать кейсы. 

Шаг 2. Обучить руководство и изменить их мышление

Часто топ-менеджеры соглашаются на Agile, не до конца осознавая, что и им самим придется меняться. Поэтому следующим шагом станет глубокое обучение ключевых руководителей. Погрузите их в принципы Scrum/LeSS, можно провести имитационную игру, где они побывают в роли команды. Важно, чтобы менеджмент понял, что ждет компанию и какую роль они должны играть. Особое внимание – начальникам отделов и проектным менеджерам. Возможно, кому-то из них придется переосмыслить свою карьеру – стать Скрам-мастером или перейти в другую функцию. Лучше откровенно обсудить: “Вот эти ваши обязанности отпадут, а вот здесь нужна ваша помощь”. Иногда полезно пригласить внешнего LeSS-тренера, чтобы он донес до менеджеров новые ценности. 

Нельзя перепрыгивать этот шаг – иначе потом, вместо поддержки, вы получите скрытое сопротивление от тех, кто просто не понял, что происходит.

Шаг 3. Вовлечь и подготовить команды

Следующий шаг – сами исполнители, команды разработки и все связанные с ними роли. Они будут жить и работать в новой системе, поэтому важно завоевать их доверие. Объявите цели перехода на LeSS, проведите серии встреч с коллективами: расскажите, каких перемен ждать и почему это хорошо для них. Будьте готовы к вопросам и скепсису – отвечайте честно. Организуйте обучение для команд. Начать стоит с однодневного тренинга по LeSS, а затем более глубокие курсы по ролям (например, обучение Скрам-мастеров, Product Owner’ов). Командам предстоит многому научиться, ведь зачастую они не знают, как работают другие части продукта.

Обратите внимание, кто из коллег проявляет интерес. Именно волонтёры, готовые к переменам, помогут убеждать остальных и вытягивать сомневающихся. Но нельзя забывать и о другой стороне: выявить тех, кто категорически против. С такими людьми нужно поработать индивидуально: выяснить причины страха и попытаться адресовать их проблемы. Если ничего не помогает, придется принимать решение о их дальнейшей роли. К сожалению, иногда лучшим решением будет перевести ярых противников на другие проекты или отделы, где Agile не требуется. Либо расстаться с ними.

Шаг 4. Тщательная подготовка к запуску LeSS

Продолжайте обучать сотрудников конкретным навыкам: как вести единый Бэклог продукта, как декомпозировать эпики на истории, как писать Definition of Done и т.д. Можно попрактиковаться на симуляциях спринта до реального запуска, чтобы команды попробовали роли и события в безопасной обстановке. Четко решите, что считается продуктом в контексте группы LeSS. Например, вместо узкого “модуль X” взять продукт “Наш мобильный банк целиком”.

На основе волонтерства и аналитики навыков сформируйте кросс-функциональные фиче-команды. Возможно, придется перемешать людей из прежних отделов, чтобы в каждой команде были все необходимые компетенции. Обратите внимание на размер и стабильность: команды 5-9 человек, закрепленные за продуктом постоянно. Очень важный момент – переподчинение. Люди внутри LeSS-продуктовой группы не должны более подчиняться начальникам своих бывших функциональных отделов. Выстройте новую орг. диаграмму: например, все инженеры Product A теперь подчиняются “Главе продуктовой группы A”, а не своим старым начальникам.

Выберите единого Владельца продукта для данного продукта. Часто это представитель бизнеса или главный продакт-менеджер. Убедитесь, что у него будет время работать с несколькими командами, и руководство делегирует ему полномочия по приоритезации. Назначьте или наймите достаточно Скрам-мастеров – по одному на 1-3 команды.

Посмотрите на HR-процедуры: систему мотивации и оценки. Исправьте показатели, которые противоречат Agile – например, уберите KPI “выполнение индивидуального плана”, заменив на командные OKR. Продумайте, что делать бывшим руководителям. Обговорите, как теперь будут проходить аттестации, найм – с учетом мнения команды и т.д.

Если продукт сложный, заранее позаботьтесь об инфраструктуре: единая система отслеживания бэклога, Continuous Integration, автоматизация тестирования хотя бы базовая. Командам будет тяжело самоорганизоваться, если, к примеру, у них нет общего доступного стенда для совместной сборки кода. И сообщите всей организации, что будет новый процесс. Особо проработайте взаимодействие с отделами, которые остаются вне LeSS-команды: юридический, маркетинг, эксплуатация и пр. Им объясните, как теперь взаимодействовать с продуктовыми командами.

Шаг 5. Запуск новой системы

Настал момент X – начать работать по-новому. Здесь возможны два подхода в зависимости от масштаба:

Big Bang (мгновенный переход) – оптимален для небольших продуктовых групп до 50 человек. В условленный день вы официально объявляете новую структуру, новые команды и запускаете первый LeSS-спринт. Все старые проекты и роли прекращают существование в этой группе одновременно. Команды с этого дня работают с общим бэклогом, общим Product Owner’ом, проводят синхронизационные встречи и так далее. Практика показывает: если тянуть резину и внедрять постепенно, очень высок риск отката назад.

Постепенный переход “волнами” – применяется, если вы внедряете LeSS Huge (более 8 команд, свыше 50-60 человек) или несколько продуктов. Здесь физически невозможно одним махом перестроить сотни людей – организационный шок будет слишком велик, да и опытных Скрам-мастеров может не хватить. Поэтому выбирается первая волна (скажем, 40-50 человек, 5-6 команд) – для них делается Big Bang переход, как выше. Остальные пока работают по-старому, наблюдают и готовятся. Через некоторое время, когда первая группа более-менее заработала, запускается следующая продуктовая область по LeSS, и так далее. Главное – не распылять внимание: лучше полностью преобразовать одну часть, чем все понемногу. Волновой подход хорош тем, что позволяет учесть уроки первой волны во второй. Однако имейте в виду: растягивать паузы между волнами опасно – некоторые могут решить, что их это не коснется. 

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

— Давайте на время перехода сохраним старых PM-ов как консультантов.

Нет, это почти всегда мешает.

— Пропишем регламенты, что если что – сразу сообщайте директору.

Тоже плохо. Дайте новой системе шанс заработать без искусственного вмешательства старых элементов, иначе люди не прочувствуют ответственность.

Шаг 6. Поддержка и улучшение после запуска

После перехода начинается самый долгий этап – укоренение LeSS и непрерывное улучшение. Первые месяцы команды будут притираться к новым ролям и учиться на ошибках. По опыту, нужно ~3-6 месяцев, чтобы продуктивность начала восстанавливаться и превышать исходный уровень. До этого времени – терпение и помощь.

Наставничество и коучинг. Скрам-мастера постоянно обучают команды Scrum-практикам, фасилитируют ретроспективы, работают с динамикой групп. Product Owner учится взаимодействовать сразу с несколькими командами, ему может понадобиться помощник или совет от более опытного продакт-менеджера.

Форумы обмена опытом. Проводите общекомандные ретроспективы (Overall Retrospective) – это позволит выявлять системные проблемы, может быть новая структура создала нежелательные эффекты. Совместно ищите решения. Создайте сообщества практик (Guilds) по интересам: тестирование, DevOps, аналитика – чтобы бывшие специалисты узких направлений делились знаниями с другими командами.

Поддержка моральная и поощрение. Празднуйте успехи, благодарите команды за усилия: “Ура, мы выпустили инкремент без задержки!” или “Сократили цикл разработки фичи на 20%”. В то же время защищайте их от внешнего давления, если они начнут сравнивать себя с другими отделами.

Постепенное расширение улучшений. Когда команды немного освоились, можно углублять Definition of Done – добавлять новые аспекты качества, которые могли оставить на потом. Также сейчас время приблизиться к идеалу, когда каждая команда способна выпустить полностью готовый инкремент самостоятельно.

Измерение и результаты. Отслеживайте динамику ключевых показателей: время выхода на рынок, частота релизов, удовлетворенность клиентов, качество. Поначалу может быть просадка, но через 4-6 месяцев тенденция должна стать положительной.

Помните, что команды – тоже люди. Им требуется время привыкнуть к новым реалиям. Пока они привыкают, будут ошибки, вопросы, даже откаты. Ваша задача – держать руку на пульсе и постоянно учиться. Но и это не конец – далее следует бесконечный путь улучшений (Kaizen) по принципам LeSS.

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