Принципы и ценности LeSS 💎

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

Почему Large-Scale Scrum — это Скрам

Масштабирование не должно изменять суть Scrum. Представьте большую компанию, которая решила внедрить Agile на уровне 10–15 команд. Они заводят отдельные бэклоги для разных компонент, вводят должности “главных скрам-мастеров” и устраивают многоэтапные планирования сверху вниз. Фактически получается не единый Scrum на несколько команд, а десяток разрозненных мини-скрамов плюс надстроенный сверху водопадопадный процесс. Получается, что вроде использовали Scrum, а выгоды не получили.

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

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

Пример
В одной крупной разработке изначально каждая из пяти команд выпускала частичный инкремент продукта один раз за спринт. Пользователю были бесполезны такие кусочки, а интегрировать их могли лишь раз в квартал. Команды жили каждая своим жизненным циклом и теряли общую цель.
После перехода на LeSS они отказались от раздельных спринтов — все 5 команд планировали спринт вместе и в конце показывали совместно работающий продукт целиком. После этих изменений сразу начали вскрываться проблемы с интеграцией, но команда могла решать их не в конце квартала, а тут же, по ходу спринта. Люди впервые увидели результат усилий в целом, а не только свою часть. Гибкость выросла многократно — если рынок требовал поменять направление, Product Owner менял приоритеты в общем бэклоге, и уже в следующем спринте команды синхронно переключались на новую фичу.

Эмпирический контроль процесса

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

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

На уровне большого продукта мы регулярно пересматриваем и сам продукт, и процессы, и даже оргструктуру, исходя из того, что мы узнали за спринт. Например, если совместное Sprint Review нескольких команд выявило, что пользователям не нужна половина запланированных фич, Product Owner вычеркивает лишнее и фокусирует все команды на чём-то действительно ценном. Если ретроспектива показала, что команды распределены по компонентам и это замедляет выпуск фич, то их реорганизовывают – например, переходят на кросс-функциональные фича-команды. Эмпиризм означает готовность менять сами правила игры, когда данные говорят, что прежние больше не работают.

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

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

Прозрачность

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

Во-первых, только выполненная работа считается работой. Никаких 80% готовности или бесконечные статусы “в процессе”. У каждой задачи есть чёткий критерий “готово” – Definition of Done – общий для всех команд. Если фича не соответствует DoD – например, она не протестирована или не интегрирована, – она не считается выполненной.

Во-вторых, короткие циклы и частые релизы делают состояние продукта видимым. Через несколько недель мы видим работающий инкремент – что в нём есть и какого оно качества.

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

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

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

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

Большее с помощью меньшего

Когда организация разрастается, возникает соблазн бороться со сложностью, добавляя ещё больше сложностей. В итоге на координацию уходит больше времени, чем на реальную работу. "Больше с помощью меньшего" (More with LeSS) означает, что можно достигать большего эффекта за счёт упрощения, а не за счёт усложнения. Этот принцип родом из Lean-подхода и эмпиризма – он одновременно и про процессы, и про структуру, и про мышление.

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

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

Пример
В одной компании, перешедшей на LeSS, менеджеры волновались:
— Почему у нас не нет отдельного руководителя над всеми? Кто будет следить за командами?
Но вскоре оказалось, что команды прекрасно синхронизируются напрямую с Product Owner'ом и между собой. Убрав промежуточное звено в виде проектных менеджеров, информация шла напрямую без искажений и задержек. Ответственность команд тоже возросла — они чувствовали себя хозяевами своей работы, а не исполнителями чужих указаний.
Да, поначалу было непривычно. Разработчикам пришлось самим ходить к пользователям за обратной связью, тестировщики вошли в состав команд и стали планировать работу вместе с программистами. Меньше передач из рук в руки означает меньше потерь информации и времени.
Несмотря на меньшее число контролирующих ролей, продукт выходит качественнее и быстрее. "Больше с помощью меньшего" также касается и менталитета — вместо того чтобы вводить правило на каждую проблему, в LeSS поощряются обучение и эксперименты.

Этот принцип часто идет вразрез с инстинктом менеджмента подстраховаться дополнительным контролем. Однако опыт масштабирования показывает: лишний контроль над процессом парадоксально снижает контроль над результатом. Сложность начинает расти нелинейно с каждой новой надстройкой.

Фокус на продукте целиком

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

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

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

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

Принцип фокуса на целом – это культура мышления. Команда может быть формально кросс-функциональной, но продолжать мысленно сидеть в своём домене. В LeSS важно донести до всех участников, что их Definition of Done – это готовый продукт в руках у клиента. Если разработчик считает, что его дело — написать код, а там хоть трава не расти, то общий фокус теряется.

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

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

Пример
Проект из 12 команд сначала работал каждый со своим планом по компонентам. В итоге общий релиз задержался на 3 месяца, 2 из которых ушло на интеграцию и устранение несостыковок между модулями. После внедрения LeSS команды реорганизовали вокруг функций продукта и вели один общий бэклог. Уже следующий релиз вышел точно в срок, а интеграция заняла считанные дни, потому что фактически продукт был интегрирован на каждом спринте. Сотрудники признались, что поначалу им было непривычно лезть на чужую территорию, но быстро увидели преимущество — прямую связь своей задачи с конечным продуктом.
Фичи стали выходить целиком, и клиенты тоже заметили разницу — их больше не просили ждать следующего релиза, когда подключится такой-то модуль.

Ориентация на клиента

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

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

Практический способ добиться этого – увеличить прозрачность связи команды с конечным пользователем. В LeSS, например, Sprint Review проходят с участием реальных пользователей или заказчиков. Когда через каждый спринт пользователи смотрят на работающий продукт и дают обратную связь, все участники разработки поневоле начинают мыслить категориями клиента. Разработчик слышит: “Эта функция неудобна, мне сложно ей пользоваться” – и у него в голове щёлкает, что важно не просто написать код по спецификации, а сделать удобно для живого человека. А Product Owner, планируя следующий спринт, ориентируется не на то, что можно успеть, чтобы отчитаться, а на то, что более ценно доставить клиенту прямо сейчас. То есть приоритет определяется величиной клиентской ценности.

LeSS рекомендует искать метрики, отражающие ценность для клиента. Например, удовлетворённость пользователей, рост ключевых показателей продукта на рынке, сокращение времени отклика на запрос и тому подобные. Если команды видят, что их цель – повысить NPS (индекс лояльности клиентов) или, скажем, сократить время, за которое заказчик получает новую функциональность, то их решения будут отличаться от решений для цели – сделать 20 фич к концу квартала.

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

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

Пример
Когда наша команда принимала участие во внедрении LeSS в одной организации, мы смогли убедить руководство пересмотреть KPI — с количества выполненных требований на оценку клиентами новых релизов. И это перевернуло логику работы. Раньше главное было закрыть побольше пользовательских историй, и многие из них шли в релиз сырыми (но галочка-то поставлена).
После смены фокуса команды стали более тщательно выбирать, что вообще стоит делать. Они теснее общались с отделом продаж и поддержкой, чтобы понять боли пользователей. В итоге за год они выпустили функций меньше, чем планировали изначально, зато удовлетворённость клиентов взлетела, и показатели бизнеса тоже.

Непрерывное улучшение на пути к совершенству

Представьте, что компания перешла на Scrum, настроила процессы – и на этом всё. Проходит время, и процесс улучшений начинает замедляться. Качество продукта по-прежнему среднее, но баги повторяются от релиза к релизу. Производительность команд выросла в первые полгода, а потом опять стагнирует. Это типичная ситуация, когда организации не хватает культуры непрерывного улучшения. Это значит, что никогда не стоит считать процесс достаточным – всегда есть возможность сделать лучше. Без целенаправленных усилий по улучшению система постепенно деградирует. Люди привыкают к текущим проблемам и начинают воспринимать их как норму: "Ну, баги... А у кого их нет?" Конечно, совершенство недостижимо, но важно само стремление.

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

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

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

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

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

Системное мышление

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

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

Другой пример — метрики. Если каждой команде поставить разрозненные цели, они начнут тянуть каждая в свою сторону, иногда в ущерб друг другу. Системный взгляд требует задать общий критерий оптимизации — например, время от идеи до доставки клиенту — и выстроить всё под него.

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

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

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

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

Бережливое мышление

Принцип бережливого мышления (Lean thinking) тесно связан с системным, но заслуживает отдельного внимания, потому что привносит ценности бережливого производства (Lean production) в мир разработки. В его основе два столпа: уважение к людям и настрой на постоянное устранение потерь. В контексте масштабируемого Scrum бережливое мышление помогает решить проблему неэффективной организации и раздутости процессов.

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

— Всегда так работали. Менеджер должен утвердить документ – подождите недельку.

Устраняйте все, что не несёт ценности клиенту. Например, если процесс требует заполнять отчёт, который никому не помогает улучшить продукт, от него стоит отказаться. Или если разработчик каждый раз ждёт два дня, пока отдельный отдел развернёт тестовое окружение, процесс нужно упростить — сократить время цикла и убрать лишнее ожидание. Бережливое мышление помогает оценить пользу каждого действия: "создает ли это ценность или это бесполезная работа для внутреннего успокоения?"

LeSS на каждом шагу старается минимизировать восьмерку видов потерь, известных в Lean:

перепроизводство,
ожидание,
потери транспортировки,
потери на лишние движения,
лишняя обработка,
лишние запасы,
дефекты,
неиспользованный потенциал сотрудников.

Если все решения принимают только начальники, а у инженеров не спрашивают мнения – компания теряет кучу идей по улучшению, которые видны тем, кто ежедневно в работе. LeSS исправляет это, поощряя вовлечение команд в решение проблем, открытость в общении и подход «пойди и посмотри» («Go See»). Руководитель в LeSS – это человек, который регулярно присутствует там, где создаётся продукт, общается с командами и помогает им учиться. Менеджер выступает скорее как учитель и коуч, передающий знание, а не как начальник, раздающий приказы. Такой стиль рождает доверие – сотрудники чувствуют, что их уважают, прислушиваются, и отвечают таким же вниманием к целям компании.

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

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

Наконец, Lean делает упор на постоянное улучшение – что впрямую перекликается с предыдущим принципом. Менеджеры в LeSS постоянно задают командам направление: «Что мы можем улучшить в процессе? Где есть трудности? Давайте понаблюдаем и найдём, где время тратится впустую». И вместе с командами реализуют улучшения.

Теория массового обслуживания или управление очередями (Queueing Theory)

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

Очереди в процессах разработки – скрытые рассадники потерь времени. В малых масштабах ещё можно отследить задачи вручную, но когда одновременно множество команд работают над сотнями задач, система легко перегружается. Если менеджмент не понимает природу очередей, начинается давление: «Надо работать быстрее! Нужно взять больше задач! Раз у нас 10 команд, давайте засунем в спринт в 10 раз больше элементов бэклога!» Но чем больше вы загружаете систему сверх её пропускной способности, тем длиннее становятся очереди и тем медленнее средняя скорость выполнения каждого элемента. Представьте дорожную пробку – если машин слишком много, то все стоят. Если добавить ещё машин, поедут ли они быстрее? Нет, станет только хуже.

Ограничивайте незавершенную работу (WIP), следите за размерами очередей задач и учитывайте вариативность. Если у вас есть узкое место – скажем, один эксперт по безопасности, через которого проходят все фичи, – не бросайте ему на стол сразу 50 задач. Они встанут в очередь, и время ожидания возрастет по экспоненте. Лучше выбирайте по одной-две задачи с учётом приоритета и загружайте этого эксперта постепенно.

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

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

— Почему эффективны малые кросс-функциональные команды?
— Они уменьшают очереди между специализациями.
— Почему опасно брать слишком много проектов сразу?
— Потому что система перегрузится и все проекты пострадают.

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

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

Как добиться устойчивых улучшений

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

Мы подготовили серию статей о Large-Scale Scrum и постарались простым языком объяснить, как работает LeSS и как применять его на практике. Статьи можно читать в любом порядке. Все материалы о LeSS можно найти в методических материалах по LeSS или по ссылке:

Введение в LeSS (Large-Scale Scrum)
Роли и организационная структура в LeSS
Процесс спринта и события в LeSS
Как техническое совершенство в LeSS помогает сохранить качество и гибкость при масштабировании
Внедрение LeSS в организации
Масштабирование с помощью LeSS Huge