Роли и организационная структура в LeSS

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

Large-Scale Scrum (LeSS) родился из стремления расширить Scrum на несколько команд, не растеряв при этом его дух и основные принципы. В этой главе мы хотим поделиться размышлениями о том, как в LeSS распределены роли и устроена структура организации. Будучи ориентированным на опытную аудиторию, глубоко разбирающуюся в Agile, мы будем говорить откровенно и прагматично. Это взгляд на то, чем LeSS отличается от классического Scrum, и какие открытия были сделали на этом пути.

Сохранение Scrum-ролей при масштабировании

В основе LeSS лежит предельно простой вывод: нам не нужны новые роли, чтобы масштабировать Scrum. 

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

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

Scrum-ролям уже присущ огромный потенциал

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

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

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

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

А раз нет официального «старшего разработчика» или «главного тестировщика», никто не может снять с себя ответственность, сославшись на то, что это «не моя роль». Все вместе отвечают за результат, помогая друг другу освоить недостающие навыки. Такая среда поощряет обучаемость и гибкость – ключевые качества Agile-команды.

Отличия LeSS от классического Scrum

Интересно, что формально роли в LeSS остаются теми же, что и в обычном Scrum, – но контекст их применения в масштабной среде вносит свои тонкие отличия. 

Когда у вас не одна Scrum-команда, а, скажем, пять или восемь, роль Владельца продукта приобретает ещё более стратегический оттенок. В Scrum Product Owner тесно работает с командой над деталями требований. В LeSS же один Владелец продукта на весь продукт взаимодействует сразу с несколькими командами и вынужден больше фокусироваться на общей картине, окупаемости и приоритетах на уровне всего продукта. 

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

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

Как же справляется один Product Owner?

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

LeSS поощряет Владельца продукта стать скорее катализатором прямого общения, чем единственным источником правды. Он направляет команды к пользователям, организует им встречи с бизнесом, чтобы разработчики услышали голос клиента из первых рук. 

Благодаря этому стирается узкое место в коммуникациях — вместо очереди в приемной у перегруженного Product Owner’а, появляются прямые диалоги «команда–заказчик». Информация больше не теряется при посредничестве, а команды чувствуют реальную сопричастность к проблемам пользователей. Для Product Owner’а это тоже благо. Освободившись от рутинного разжевывания каждой мелочи, он может сосредоточиться на стратегии и приоритизации, то есть на том, где действительно приносит максимальную пользу. 

По сути, в LeSS меняется баланс. Владелец продукта больше про “что важно сделать и зачем”, а команды про “как именно это сделать”. Это тонкое отличие от классического Scrum, где при одной команде Product Owner часто глубоко погружён и в детали требований, и в стратегию одновременно. Здесь же масштаб вынуждает его слегка отстраниться от микроменеджмента и доверить эту работу командам. Это стало возможным, потому что в LeSS меньше сложностей и промежуточных ролей, чем во многих других фреймворках масштабирования, — один Product Owner реально в состоянии управлять приоритетами нескольких команд, особенно когда сами команды берут на себя львиную долю уточнений и взаимодействия с заказчиками.

Scrum-мастер в LeSS 

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

В зрелой LeSS-организации мы часто видим ситуацию, когда один Scrum-мастер ведёт две, а то и три команды. Не из экономии, а из соображений эффективности. Когда команды встали на ноги, Scrum-мастеру разумно переключить фокус на улучшение всей системы и на взаимодействие команд между собой и с Product Owner’ом. Так он перестает быть “няней” одной команды и становится коучем организации в целом.

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

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

Минимальная иерархия – максимум ответственности

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

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

Например, в LeSS нет Project/Program Management Office (PMO) – проектных офисов просто не существует. Все задачи по координации и планированию, которые в классической организации ложились бы на PMO, распределяются между самими командами и Владельцем продукта. LeSS буквально растворяет традиционную роль менеджера проекта в ответственности команд и PO. 

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

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

Разумеется, полная безначальственность – утопия, да и не цель. В LeSS остаются руководители верхнего уровня, но их намного меньше, и роль их иная.

 Обычно есть Head of Product Group – условно говоря, глава всего продуктового направления. Названия могут различаться, но суть – человек, которому подчиняются все команды. LeSS избегает матричных структур и «пунктирных» подчинений. Каждая команда не разбита по нескольким начальникам, а имеет одно прямое руководство. И этот руководитель – скорее наставник, чем классический директор. Ожидается, что верхнеуровневый менеджер будет поддерживать команды через принцип «сходи-посмотри», устраняя системные препятствия и улучшая среду для работы команд. 

То есть его власть проявляется не в том, чтобы раздавать задания и контролировать каждый шаг, а в том, чтобы обеспечить всем остальным условия для эффективной работы. В идеале команды и Владелец продукта в LeSS – это партнёры на одном уровне, коллеги. Хотя формально PO и подчиняется Head of Product Group, в ежедневной работе с командами он действует как равноправный участник. Команды не воспринимают Product Owner’а как “начальника отдела”, которому нельзя возражать, – между ними устанавливается кооперация, основанная на доверии и общих целях.  Владелец продукта отвечает за направление ценности, команды – за реализацию, и ни одна сторона не доминирует. 

Это сильно отличается от типичных компаний, где разработчики – на дне пищевой цепочки, выше них начальники, ещё выше – руководители программ. LeSS сознательно стирает эти границы, оставляя минимум уровней между командой разработчиков и высшим руководством. Можно сказать, что ценность течёт горизонтально прямо к командам, минуя лишние инстанции, а управленческая поддержка выстраивается вертикально минимально необходимым образом.

Для команд такой сдвиг означает беспрецедентный уровень автономии и ответственности. С меньшим числом начальников нельзя просто отдать наверх проблему и ждать указаний – приходится самим искать решения. Поначалу это пугает, но именно так и растёт самоорганизация. Люди начинают более серьезно относиться к своим обязательствам, потому что понимают – кроме них самих, некому спасать проект на нижнем уровне. 

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

Трансформация роли менеджера

Одним из самых частых вопросов, которые мы слышали от руководителей традиционных организаций: «А что делать менеджерам в этой новой схеме? Неужели я больше не нужен?» 

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

Решение что разрабатывать — однозначно прерогатива Product Owner’а, поскольку он ближе всех к бизнес-ценности и приоритетам пользователей. Решение как организовать работу — отдаётся в руки команд, ведь только самоорганизующаяся команда вправе выбирать инструменты, договорённости и внутренние процессы. Получается, что традиционная власть менеджера над “что” и “как” исчезает, и если пытаться её сохранить, возникнет дублирование ролей и конфликт ответственности. Но это не означает, что менеджеры вовсе пропадают из Agile-организации. 

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

Менеджер в LeSS – это наставник по улучшениям. Он учит команды методам анализа и решения проблем, прививает им Lean-мышление, заботится об их росте. Он также играет важную роль в стирании системных препятствий, которые находятся за пределами владения отдельных команд. Например, если командам мешают устаревшие процедуры в компании или нехватка инфраструктуры, именно менеджер использует свое влияние, чтобы изменить процессы компании, обеспечить нужные ресурсы, сгладить путь для команд. Для этого менеджеру приходится идти и смотреть на место работы по принципу “Go See”, своими глазами понимать, с какими трудностями сталкиваются разработчики, тестировщики, клиенты. 

Такой менеджмент на основе Gemba (места, где происходит ценное действие) коренным образом отличается от сидения в кабинете и чтения отчетов. Менеджер становится своего рода поддерживающим лидером для Scrum-мастеров и команд, убирающим организационные помехи на их пути.

Высшее руководство в LeSS

Директора и вице-президенты по-прежнему определяют стратегию, работают над портфелем продуктов, инвестициями и прочим. Однако и их подход эволюционирует — от директора ожидается, что он будут учить своих подчинённых поддерживающему лидерству. 

Старший менеджер теперь — учитель менеджеров, наставляющий их, как эффективно обучать и поддерживать команды на местах. Культура управления смещается от командования к просвещению. Руководитель учит нижестоящего руководителя тому, как быть коучем для команд, а не контролёром. Это создаёт цепочку непрерывного обучения сверху вниз. И как итог, ценностный поток идей идёт горизонтально от клиентов к командам, а власть трансформируется в мудрость, текущую сверху вниз. Образно говория, в LeSS ценность движется горизонтально, а способность – вертикально.

Практически это значит, что многие привычные роли среднего звена отпадают за ненадобностью. К примеру, если раньше проектный менеджер составлял планы и следил за их исполнением, то теперь планирование выполняют сами команды в рамках Scrum-встреч, а прогресс прозрачно виден на досках и обзорах спринтов. Если раньше технический руководитель распределял задачи между разработчиками, то теперь этого не требуется – бэклог упорядочивает Product Owner, а задачи внутри спринта команда распределяет сама. 

Соответственно, классические PM и тех-лиды либо находят себя в новых ролях (Scrum-мастеров, Agile-коучей, менеджеров-наставников), либо организация сокращает эти позиции, чтобы избежать дублирования и путаницы. 

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

Владелец продукта в масштабах организации

Вернемся к роли Владельца продукта (Product Owner) и уделим ей ещё немного внимания, потому что при масштабировании именно вокруг неё возникает много вопросов. 

Часто мы слышим: «Как один человек может управлять приоритетами для десятка команд? Не станет ли он бутылочным горлышком?» 

Наш опыт подсказывает, что один Product Owner вполне может справиться, если правильно организовать взаимодействие. Как мы уже упоминали, критически важно, что в LeSS у продукта один бэклог и один Владелец продукта – то есть единое лицо, принимающее решения о приоритетах. Это фундаментальное отличие от некоторых других подходов, где вводятся целые иерархии ролей (главные PO, делегированные PO и т.д.). Мы верим, что продукт должен иметь единое сердце и мозг, чтобы не распасться на части. Этот принцип называется whole-product focus – фокус на продукте целиком, он предотвращает локальные оптимизации. Когда каждый кусочек продукта имеет своего «мини-шефа», велика опасность, что они начнут тянуть одеяло на себя. Один же Product Owner смотрит на ценность для всей системы, а не для отдельного модуля.

Однако, чтобы один человек смог объять такую широту, нужна особая организация работы вокруг него. Мы уже выяснили, что команды помогают PO, забирая на себя уточнение требований напрямую с бизнесом. То есть Product Owner больше концентрируется на упорядочении и стратегии, а на уровне детализации требований ему активно помогают команды. 

Можно сказать, роль PO смещается от микроменеджера требований к продуктовой стратегии. Он проводит много времени с внешними стейкхолдерами: пользователями, заказчиками, маркетингом. Его задача – принести в организацию максимум знания о том, что нужно рынку и клиентам. И наоборот, он же транслирует наружу прогресс и планы команд, формируя ожидания. Получается такой связующий лидер, который соединяет внешний мир и внутренний. Product Owner — это мост, а не «начальник». Он не должен стоять над командами с плёткой, он должен строить мосты между командами и пользователями, и между задачами и стратегией.

В больших продуктах часто есть вспомогательные люди – в LeSS Huge вводится понятие Area Product Owner для очень больших продуктов, разделённых на области. Но даже в таких случаях стараются сохранить прямое подчинение всех Area PO одному главному PO, чтобы иерархия оставалась минимальной и не превращалась в бюрократическую лестницу. 

Кроме того, команды сами зачастую выдвигают внутренних “делегатов” для общения с PO и бизнесом – например, ведущих разработчиков и аналитиков из команды, которые чаще контактируют с Владельцем продукта. Эти люди не оформляются как отдельные роли, но помогают связке «PO–команды» работать более слаженно.

Product Owner не является менеджером команд, команды не «подчиняются» ему в иерархическом смысле. Да, он определяет что делать, устанавливает приоритеты, но как и кем это будет делаться – вне его власти. 

В этом отношении PO – первый среди равных, объединённый с командами общей ответственностью за успех продукта. Такая установка меняет психологию сотрудничества: команды не боятся спорить с Product Owner’ом, предлагать свои идеи, влиять на backlog. А Владелец продукта, в свою очередь, видит в командах партнеров, которые помогают ему достичь цели, а не «исполнителей его воли». Да, финальное слово всегда за PO – это важно, иначе будет хаос. Но качество решений повышается, когда они принимаются не в вакууме кабинета, а в постоянном диалоге с теми, кто эти решения воплощает и общается с клиентами напрямую.

Отсутствие отдельных ролей специалистов и влияние на эффективность

Когда люди впервые узнают, что в LeSS нет привычных ролей “аналитик”, “архитектор” и “тестировщик”, у них возникает много сомнений. «Разве можно обойтись без тестировщиков? А кто будет думать об архитектуре?»

Всем будут заниматься команды, в составе которых есть люди с разными навыками. Вспомните истоки Scrum – в нём изначально не было должности тестировщика или аналитика, есть просто разработчики (Developers), совместно обладающие всеми необходимыми компетенциями. LeSS лишь перенес этот принцип на уровень масштабной разработки. 

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

Какие выгоды это даёт? Прежде всего – исключаются многочисленные передачи эстафеты. В традиционном процессе требование переходит от аналитика к разработчику, от разработчика к тестировщику, от тестировщика к отделу развертывания… Каждая такая передача – точка возможной задержки и потери информации. 

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

Устранение бюрократических преград

В компаниях бывало: “Мы не можем внедрить фичу, потому что ждём от архитекторов одобрения дизайна” или “тестовый отдел загружен, продукт задерживается”. 

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

В некоторых компаниях бывает страх, что если нет должности системного архитектора, архитектура развалится. Наш опыт показывает, что лучшая архитектура выходит там, где за неё чувствуют ответственность все. Когда каждый разработчик осознаёт, что он тоже отвечает за долгосрочную устойчивость системы, решений “на авось” становится меньше.

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

Поначалу инженеры узкого профиля могут испытывать дискомфорт: “Неужели мне, аналитику, придется писать автотесты?” или “Программисты будут сами дизайнить архитектуру без меня?”. Но практика показывает, что границы ответственности расширяются постепенно, с ростом навыков. Люди начинают ценить, что их работа стала более разнообразной и творческой. А организация видит результаты — меньше стен между отделами и больше совместного творчества. В конечном счёте, исчезновение отдельных ролей — это не цель сама по себе, а средство добиться командной работы в полном смысле. Когда роль архитектуры, качества, бизнеса перестаёт принадлежать одному человеку, она становится общей ценностью всей команды, и это, как ни удивительно, повышает и качество архитектуры, и качество продукта.

Простота масштабируется лучше, чем сложность

Отказ от новых ролей и сверхсложной структуры — это не упрощение ради упрощения, а стратегический ходом. LeSS сохраняет минимум иерархии и максимум доверия к людям. Да, для этого приходится переосмыслить роль менеджеров, превратив их из начальников в поддерживающих лидеров. Да, Product Owner’у придётся выйти из зоны комфорта и научиться отдавать детализацию командам, сфокусировавшись на стратегии. И узким специалистам тоже придётся стать более разносторонними. Но взамен организация получит гибкость, скорость и ориентированность на продукт целиком, которых трудно было достичь в рамках старой иерархии.

Масштабирование Agile не требует масштабирования бюрократии. 

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

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

Хочется верить, что такой подход к масштабированию возвращает нас к человеческой стороне работы: доверию, ответственности и совместному творчеству.